[alsa-devel] [RESEND PATCH v3 0/5] ARM: OMAP4+: HDMI: Update platform devices for audio
Hi Mark, Tomi, Liam, Tony,
I am resending this series as Mark and possibly other people missed it.
This set aims to be the version 3 of my previous submission[1] and aims to address the comments that Mark and Tomi kindly provided on such submission.
The creation of the platform device for the HDMI audio interface from within the OMAPDSS HDMI driver that was previously submitted[2] is resubmitted to be complemented with code to relocate to arch/arm/mach-omap2/display.c the creation of the platform devices for the HDMI ASoC codec and card drivers. This series does not break the HDMI audio functionality in any patch.
Also, the names of the platform devices are changed to give them more logical and more descriptive names.
As the commit
commit 14840b9a83c6a56629db2ba0ec247503e975f143 Author: Ricardo Neri ricardo.neri@ti.com Date: Tue Nov 6 00:19:17 2012 -0600
OMAPDSS: HDMI: Create platform device for audio support
is reverted in Tomi's git://gitorious.org/linux-omap-dss2/linux.git master branch, this series applies cleanly.
Changes from v1: *Put in a single series all the patches related to platform device updates. *Now HDMI audio works correctly in every patch. *Remove reference to the TPD12S015 HDMI companion chip as the ASoC drivers are not aware of this and other chips could be used in the future.
Changes from v2: *Split in two patches the renaming and the relocation of the platform devices. *Create a separate patch to pass only the address offset of the DMA data port to the audio interface platform device. *Keep the name hdmi-audio-codec to not refer to explicitly to OMAP. The codec can be made generic in a different patch series submitted to alsa-devel.
BR,
Ricardo
[1]. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80785.html [2]. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79795.html
Ricardo Neri (5): ARM: OMAP4+: HDMI: Rename platform devices for ASoC drivers ARM: OMAP4: Assign IDs to DSS HDMI devices ARM4: OMAP4+: HDMI: Relocate devices for audio codec and card ARM: OMAP4+: HDMI: Relocate the device for audio interface ARM: OMAP4+: HDMI: Refine the DMA port resource for audio
arch/arm/mach-omap2/board-4430sdp.c | 9 ++--- arch/arm/mach-omap2/board-omap4panda.c | 9 ++--- arch/arm/mach-omap2/devices.c | 31 ---------------- arch/arm/mach-omap2/display.c | 31 ++++++++++++++++ drivers/video/omap2/dss/hdmi.c | 62 ++++++++++++++++++++++++++++++++ sound/soc/omap/omap-hdmi-card.c | 4 +-- sound/soc/omap/omap-hdmi.c | 5 ++- sound/soc/omap/omap-hdmi.h | 2 -- 8 files changed, 103 insertions(+), 50 deletions(-)
-- 1.7.10.4
Assign more logical and meaningful names to the platform devices used by ASoC OMAP HDMI drivers.
The previous omap-hdmi-audio device is renamed as omap-hdmi-audio-card This is to better illustrate the fact that it describes the whole HDMI audio in a given board.
The previous omap-hdmi-audio-dai is renamed as omap-hdmi-audio. The -dai part is removed to not have references to ASoC concepts in the OMAPDSS HDMI driver. Also, as it will be used by the ASoC HDMI CPU DAI driver, the name refers only to OMAP HDMI audio functionality, irrespective of the board.
The names of the ASoC drivers are also updated accordingly.
Signed-off-by: Ricardo Neri rneri@dextratech.com --- arch/arm/mach-omap2/devices.c | 4 ++-- sound/soc/omap/omap-hdmi-card.c | 4 ++-- sound/soc/omap/omap-hdmi.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index cba60e0..66518b2 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -356,7 +356,7 @@ static inline void omap_init_dmic(void) {} defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
static struct platform_device omap_hdmi_audio = { - .name = "omap-hdmi-audio", + .name = "omap-hdmi-audio-card", .id = -1, };
@@ -371,7 +371,7 @@ static void __init omap_init_hdmi_audio(void) return; }
- pdev = omap_device_build("omap-hdmi-audio-dai", + pdev = omap_device_build("omap-hdmi-audio", -1, oh, NULL, 0, NULL, 0, 0); WARN(IS_ERR(pdev), "Can't build omap_device for omap-hdmi-audio-dai.\n"); diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c index eaa2ea0..07b9959 100644 --- a/sound/soc/omap/omap-hdmi-card.c +++ b/sound/soc/omap/omap-hdmi-card.c @@ -27,12 +27,12 @@ #include <asm/mach-types.h> #include <video/omapdss.h>
-#define DRV_NAME "omap-hdmi-audio" +#define DRV_NAME "omap-hdmi-audio-card"
static struct snd_soc_dai_link omap_hdmi_dai = { .name = "HDMI", .stream_name = "HDMI", - .cpu_dai_name = "omap-hdmi-audio-dai", + .cpu_dai_name = "omap-hdmi-audio", .platform_name = "omap-pcm-audio", .codec_name = "hdmi-audio-codec", .codec_dai_name = "omap-hdmi-hifi", diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c index f59c69f..db08501 100644 --- a/sound/soc/omap/omap-hdmi.c +++ b/sound/soc/omap/omap-hdmi.c @@ -37,7 +37,7 @@ #include "omap-pcm.h" #include "omap-hdmi.h"
-#define DRV_NAME "omap-hdmi-audio-dai" +#define DRV_NAME "omap-hdmi-audio"
struct hdmi_priv { struct omap_pcm_dma_data dma_params;
On Fri, Jan 04, 2013 at 05:26:23PM -0600, Ricardo Neri wrote:
Assign more logical and meaningful names to the platform devices used by ASoC OMAP HDMI drivers.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
While Pandaboard and SDP4430 have only one HDMI output connector, it may be possible that future boards and SoCs support more than one HDMI output. Thus, we define the identifier of the device. This is used by display common code to identify and create the platform devices for HDMI audio drivers.
Signed-off-by: Ricardo Neri rneri@dextratech.com --- arch/arm/mach-omap2/board-4430sdp.c | 3 +++ arch/arm/mach-omap2/board-omap4panda.c | 3 +++ 2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 3669c12..5a486d9 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -666,6 +666,9 @@ static struct omap_dss_device sdp4430_hdmi_device = { .type = OMAP_DISPLAY_TYPE_HDMI, .channel = OMAP_DSS_CHANNEL_DIGIT, .data = &sdp4430_hdmi_data, + .dev = { + .id = -1, + }, };
static struct picodlp_panel_data sdp4430_picodlp_pdata = { diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index bfcd397..9f336a3 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -440,6 +440,9 @@ static struct omap_dss_device omap4_panda_hdmi_device = { .type = OMAP_DISPLAY_TYPE_HDMI, .channel = OMAP_DSS_CHANNEL_DIGIT, .data = &omap4_panda_hdmi_data, + .dev = { + .id = -1, + }, };
static struct omap_dss_device *omap4_panda_dss_devices[] = {
Hi Ricardo,
You need to rebase this patch as the code has been moved to dss-common.c file now. So it would not apply.
Sebastien
On 01/05/2013 12:26 AM, Ricardo Neri wrote:
While Pandaboard and SDP4430 have only one HDMI output connector, it may be possible that future boards and SoCs support more than one HDMI output. Thus, we define the identifier of the device. This is used by display common code to identify and create the platform devices for HDMI audio drivers.
Signed-off-by: Ricardo Neri rneri@dextratech.com
arch/arm/mach-omap2/board-4430sdp.c | 3 +++ arch/arm/mach-omap2/board-omap4panda.c | 3 +++ 2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 3669c12..5a486d9 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -666,6 +666,9 @@ static struct omap_dss_device sdp4430_hdmi_device = { .type = OMAP_DISPLAY_TYPE_HDMI, .channel = OMAP_DSS_CHANNEL_DIGIT, .data = &sdp4430_hdmi_data,
.dev = {
.id = -1,}, };
static struct picodlp_panel_data sdp4430_picodlp_pdata = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index bfcd397..9f336a3 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -440,6 +440,9 @@ static struct omap_dss_device omap4_panda_hdmi_device = { .type = OMAP_DISPLAY_TYPE_HDMI, .channel = OMAP_DSS_CHANNEL_DIGIT, .data = &omap4_panda_hdmi_data,
.dev = {
.id = -1,}, };
static struct omap_dss_device *omap4_panda_dss_devices[] = {
I never got a response to my query, not even an RTFM (although I'm pretty sure this isn't in the M). So, in case anyone else is wondering, here's what I've since found:
- The kernel packages do NOT limit themselves to taking an entire released ALSA package. In particular, the 3.6.X series has a number of improvements and changes that aren't in the latest (year old) alsa-driver 1.0.25 package. I'll guess that they're taken directly from the alsa GIT repository, but it's hard to know.
- The alsa-driver package installs items that are NOT a part of the kernel package. The alsasound startup script and the ALSA headers are the examples I've found so far, but there may be more items.
- When installed, the alsa-driver package installs its modules into the currently running kernel's directories. So, if you want to have the latest system, you need to install the kernel, reboot into that kernel, install alsa-driver, reinstall the kernel, and reboot again. Ugh.
<rant> ALSA's Achilles heel has always been its documentation, whether for developers (the Doxygen-generated documents are at times comically uninformative) or for end-users (e.g. the lack of information such as the above). Please: those of you in the know, spend some time documenting this powerful and confusing system. Yes, you know how to use it, but isn't the goal to have it support the thousands/millions of audio users out there, and not just the dozen or so core ALSA developers? </rant>
Thanks, Dan
At 4:12 PM -0500 1/17/13, Daniel Griscom wrote:
We're working to build a consistent Linux audio environment for our embedded audio product,with known versions of both ALSA and the kernel (we're specifically considering kernel 3.6.6). We are not clear, however, exactly what version of the ALSA kernel-space tools are included with the kernel, nor are we clear on exactly what each ALSA package is used for.
In order to simplify any responses, I'll give my best guess as to what's included in the kernel and each ALSA package: let me know where I went wrong.
So, am I right that...
- Kernel 3.6.6 includes exactly alsa-driver-1.0.25 (I'm actually
guessing not, but let me know.)
alsa-driver-1.0.25 is all included in the kernel release, and can be ignored
alsa-lib is the user-space library that we complile our tools
against, and that communicates with ALSA in the kernel through the device and /proc tree (required)
- alsa-utils are various generic ALSA command line tools, such as
amixer, aplay, alsaconf, etc (required)
- alsa-tools are various more obscure tools and loaders (probably
not required)
- alsa-firmware are binary drivers for various third-party products
(probably not required)
- alsa-plugins are plugins for various ALSA needs (e.g. Jack)
(probably not required)
alsa-oss is the OSS compatibilty layer (not required)
pyalsa is the Python bindings for ALSA (not required)
And, some final questions:
- What version of ALSA and the kernel are needed to fully support
implicit feedback?
- Given our audio focus, what version kernel would you recommend?
Thanks, Dan
At Fri, 25 Jan 2013 10:10:18 -0500, Daniel Griscom wrote:
I never got a response to my query,
... because you're hanging your post to an utterly irrelevant thread? It's the second time, so I guess the previous time wasn't an accident.
not even an RTFM (although I'm pretty sure this isn't in the M). So, in case anyone else is wondering, here's what I've since found:
- The kernel packages do NOT limit themselves to taking an entire
released ALSA package. In particular, the 3.6.X series has a number of improvements and changes that aren't in the latest (year old) alsa-driver 1.0.25 package. I'll guess that they're taken directly from the alsa GIT repository, but it's hard to know.
The 1.0.25 *released* tarball is what was released. It won't change. The tarball created from the latest GIT is called "snapshot".
And note that the alsa-driver version number has been already deprecated in the recent kernel. The confusing number 1.0.25 was dropped, finally.
In short, forget about alsa-driver released packages. Stick with the driver included in your kernel, or use alsa-driver snapshot tarball (but carefully).
- The alsa-driver package installs items that are NOT a part of the
kernel package. The alsasound startup script and the ALSA headers are the examples I've found so far, but there may be more items.
They are no longer necessary stuff, but kept there since they are mostly harmless. You can run "make install-modules" to install only modules.
- When installed, the alsa-driver package installs its modules into
the currently running kernel's directories. So, if you want to have the latest system, you need to install the kernel, reboot into that kernel, install alsa-driver, reinstall the kernel, and reboot again. Ugh.
Hm, did you read INSTALL file? The installation to an update (or extra) directory is suggested. Pass a proper --with-moddir configure option.
<rant> ALSA's Achilles heel has always been its documentation, whether for developers (the Doxygen-generated documents are at times comically uninformative) or for end-users (e.g. the lack of information such as the above). Please: those of you in the know, spend some time documenting this powerful and confusing system. Yes, you know how to use it, but isn't the goal to have it support the thousands/millions of audio users out there, and not just the dozen or so core ALSA developers? </rant>
You seem to overestimate the numbers. I dream of dozen of core developers, too.
Speaking of implicit feedback: it's been since 3.5, but lots of bug fixes are found in 3.7. So better to use 3.7, I guess.
HTH,
Takashi
Thanks, Dan
At 4:12 PM -0500 1/17/13, Daniel Griscom wrote:
We're working to build a consistent Linux audio environment for our embedded audio product,with known versions of both ALSA and the kernel (we're specifically considering kernel 3.6.6). We are not clear, however, exactly what version of the ALSA kernel-space tools are included with the kernel, nor are we clear on exactly what each ALSA package is used for.
In order to simplify any responses, I'll give my best guess as to what's included in the kernel and each ALSA package: let me know where I went wrong.
So, am I right that...
- Kernel 3.6.6 includes exactly alsa-driver-1.0.25 (I'm actually
guessing not, but let me know.)
alsa-driver-1.0.25 is all included in the kernel release, and can be ignored
alsa-lib is the user-space library that we complile our tools
against, and that communicates with ALSA in the kernel through the device and /proc tree (required)
- alsa-utils are various generic ALSA command line tools, such as
amixer, aplay, alsaconf, etc (required)
- alsa-tools are various more obscure tools and loaders (probably
not required)
- alsa-firmware are binary drivers for various third-party products
(probably not required)
- alsa-plugins are plugins for various ALSA needs (e.g. Jack)
(probably not required)
alsa-oss is the OSS compatibilty layer (not required)
pyalsa is the Python bindings for ALSA (not required)
And, some final questions:
- What version of ALSA and the kernel are needed to fully support
implicit feedback?
- Given our audio focus, what version kernel would you recommend?
Thanks, Dan
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At 4:28 PM +0100 1/28/13, Takashi Iwai wrote:
At Fri, 25 Jan 2013 10:10:18 -0500, Daniel Griscom wrote:
I never got a response to my query,
... because you're hanging your post to an utterly irrelevant thread? It's the second time, so I guess the previous time wasn't an accident.
How so? Is there a hidden email field that tracks threads independent of the thread titles? If so, my apologies: my (antique) email client must be doing things behind my back.
not even an RTFM (although I'm pretty sure this isn't in the M). So, in case anyone else is wondering, here's what I've since found:
- The kernel packages do NOT limit themselves to taking an entire
released ALSA package. In particular, the 3.6.X series has a number of improvements and changes that aren't in the latest (year old) alsa-driver 1.0.25 package. I'll guess that they're taken directly from the alsa GIT repository, but it's hard to know.
The 1.0.25 *released* tarball is what was released. It won't change. The tarball created from the latest GIT is called "snapshot".
And note that the alsa-driver version number has been already deprecated in the recent kernel. The confusing number 1.0.25 was dropped, finally.
Ah. Is there somewhere I could find out information such as this?
In short, forget about alsa-driver released packages. Stick with the driver included in your kernel, or use alsa-driver snapshot tarball (but carefully).
- The alsa-driver package installs items that are NOT a part of the
kernel package. The alsasound startup script and the ALSA headers are the examples I've found so far, but there may be more items.
They are no longer necessary stuff, but kept there since they are mostly harmless. You can run "make install-modules" to install only modules.
Is the installed /etc/init.d/alsasound not needed? It seems to do a number of tasks when starting and stopping.
How do I install the ALSA headers without installing the rest of the (obsolete) contents? "make install-headers" inside alsa-driver-1.0.25?
And, does alsa-driver install anything else outside of the kernel modules?
- When installed, the alsa-driver package installs its modules into
the currently running kernel's directories. So, if you want to have the latest system, you need to install the kernel, reboot into that kernel, install alsa-driver, reinstall the kernel, and reboot again. Ugh.
Hm, did you read INSTALL file? The installation to an update (or extra) directory is suggested. Pass a proper --with-moddir configure option.
<rant> ALSA's Achilles heel has always been its documentation, whether for developers (the Doxygen-generated documents are at times comically uninformative) or for end-users (e.g. the lack of information such as the above). Please: those of you in the know, spend some time documenting this powerful and confusing system. Yes, you know how to use it, but isn't the goal to have it support the thousands/millions of audio users out there, and not just the dozen or so core ALSA developers? </rant>
You seem to overestimate the numbers. I dream of dozen of core developers, too.
Speaking of implicit feedback: it's been since 3.5, but lots of bug fixes are found in 3.7. So better to use 3.7, I guess.
HTH,
Takashi
Thanks, Dan
At 4:12 PM -0500 1/17/13, Daniel Griscom wrote:
We're working to build a consistent Linux audio environment for our embedded audio product,with known versions of both ALSA and the kernel (we're specifically considering kernel 3.6.6). We are not clear, however, exactly what version of the ALSA kernel-space tools are included with the kernel, nor are we clear on exactly what each ALSA package is used for.
In order to simplify any responses, I'll give my best guess as to what's included in the kernel and each ALSA package: let me know where I went wrong.
So, am I right that...
- Kernel 3.6.6 includes exactly alsa-driver-1.0.25 (I'm actually
guessing not, but let me know.)
- alsa-driver-1.0.25 is all included in the kernel release, and
can be ignored
- alsa-lib is the user-space library that we complile our tools
against, and that communicates with ALSA in the kernel through the device and /proc tree (required)
- alsa-utils are various generic ALSA command line tools, such as
amixer, aplay, alsaconf, etc (required)
- alsa-tools are various more obscure tools and loaders (probably
not required)
- alsa-firmware are binary drivers for various third-party products
(probably not required)
- alsa-plugins are plugins for various ALSA needs (e.g. Jack)
(probably not required)
alsa-oss is the OSS compatibilty layer (not required)
pyalsa is the Python bindings for ALSA (not required)
And, some final questions:
- What version of ALSA and the kernel are needed to fully support
implicit feedback?
- Given our audio focus, what version kernel would you recommend?
Thanks, Dan
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Mon, 28 Jan 2013 10:50:04 -0500, Daniel Griscom wrote:
At 4:28 PM +0100 1/28/13, Takashi Iwai wrote:
At Fri, 25 Jan 2013 10:10:18 -0500, Daniel Griscom wrote:
I never got a response to my query,
... because you're hanging your post to an utterly irrelevant thread? It's the second time, so I guess the previous time wasn't an accident.
How so? Is there a hidden email field that tracks threads independent of the thread titles? If so, my apologies: my (antique) email client must be doing things behind my back.
Hmm, why doubled posts?
not even an RTFM (although I'm pretty sure this isn't in the M). So, in case anyone else is wondering, here's what I've since found:
- The kernel packages do NOT limit themselves to taking an entire
released ALSA package. In particular, the 3.6.X series has a number of improvements and changes that aren't in the latest (year old) alsa-driver 1.0.25 package. I'll guess that they're taken directly from the alsa GIT repository, but it's hard to know.
The 1.0.25 *released* tarball is what was released. It won't change. The tarball created from the latest GIT is called "snapshot".
And note that the alsa-driver version number has been already deprecated in the recent kernel. The confusing number 1.0.25 was dropped, finally.
Ah. Is there somewhere I could find out information such as this?
Track the kernel git tree. All commits are found there.
In short, forget about alsa-driver released packages. Stick with the driver included in your kernel, or use alsa-driver snapshot tarball (but carefully).
- The alsa-driver package installs items that are NOT a part of the
kernel package. The alsasound startup script and the ALSA headers are the examples I've found so far, but there may be more items.
They are no longer necessary stuff, but kept there since they are mostly harmless. You can run "make install-modules" to install only modules.
Is the installed /etc/init.d/alsasound not needed?
No, if you have already a similar one. As mentioned, this is nothing but a reference implementation.
Takashi
It seems to do a number of tasks when starting and stopping.
How do I install the ALSA headers without installing the rest of the (obsolete) contents? "make install-headers" inside alsa-driver-1.0.25?
And, does alsa-driver install anything else outside of the kernel modules?
- When installed, the alsa-driver package installs its modules into
the currently running kernel's directories. So, if you want to have the latest system, you need to install the kernel, reboot into that kernel, install alsa-driver, reinstall the kernel, and reboot again. Ugh.
Hm, did you read INSTALL file? The installation to an update (or extra) directory is suggested. Pass a proper --with-moddir configure option.
<rant> ALSA's Achilles heel has always been its documentation, whether for developers (the Doxygen-generated documents are at times comically uninformative) or for end-users (e.g. the lack of information such as the above). Please: those of you in the know, spend some time documenting this powerful and confusing system. Yes, you know how to use it, but isn't the goal to have it support the thousands/millions of audio users out there, and not just the dozen or so core ALSA developers? </rant>
You seem to overestimate the numbers. I dream of dozen of core developers, too.
Speaking of implicit feedback: it's been since 3.5, but lots of bug fixes are found in 3.7. So better to use 3.7, I guess.
HTH,
Takashi
Thanks, Dan
At 4:12 PM -0500 1/17/13, Daniel Griscom wrote:
We're working to build a consistent Linux audio environment for our embedded audio product,with known versions of both ALSA and the kernel (we're specifically considering kernel 3.6.6). We are not clear, however, exactly what version of the ALSA kernel-space tools are included with the kernel, nor are we clear on exactly what each ALSA package is used for.
In order to simplify any responses, I'll give my best guess as to what's included in the kernel and each ALSA package: let me know where I went wrong.
So, am I right that...
- Kernel 3.6.6 includes exactly alsa-driver-1.0.25 (I'm actually
guessing not, but let me know.)
- alsa-driver-1.0.25 is all included in the kernel release, and
can be ignored
- alsa-lib is the user-space library that we complile our tools
against, and that communicates with ALSA in the kernel through the device and /proc tree (required)
- alsa-utils are various generic ALSA command line tools, such as
amixer, aplay, alsaconf, etc (required)
- alsa-tools are various more obscure tools and loaders (probably
not required)
- alsa-firmware are binary drivers for various third-party products
(probably not required)
- alsa-plugins are plugins for various ALSA needs (e.g. Jack)
(probably not required)
alsa-oss is the OSS compatibilty layer (not required)
pyalsa is the Python bindings for ALSA (not required)
And, some final questions:
- What version of ALSA and the kernel are needed to fully support
implicit feedback?
- Given our audio focus, what version kernel would you recommend?
Thanks, Dan
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400 _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400
At 4:28 PM +0100 1/28/13, Takashi Iwai wrote:
At Fri, 25 Jan 2013 10:10:18 -0500, Daniel Griscom wrote:
I never got a response to my query,
... because you're hanging your post to an utterly irrelevant thread? It's the second time, so I guess the previous time wasn't an accident.
Are there hidden email headers that maintain threads independent of the subject line? If so then my apologies: my (antique) email client has been hiding them from me.
not even an RTFM (although I'm pretty sure this isn't in the M). So, in case anyone else is wondering, here's what I've since found:
- The kernel packages do NOT limit themselves to taking an entire
released ALSA package. In particular, the 3.6.X series has a number of improvements and changes that aren't in the latest (year old) alsa-driver 1.0.25 package. I'll guess that they're taken directly from the alsa GIT repository, but it's hard to know.
The 1.0.25 *released* tarball is what was released. It won't change. The tarball created from the latest GIT is called "snapshot".
And note that the alsa-driver version number has been already deprecated in the recent kernel. The confusing number 1.0.25 was dropped, finally.
In short, forget about alsa-driver released packages. Stick with the driver included in your kernel, or use alsa-driver snapshot tarball (but carefully).
Well, that's good to know. How do you refer to ALSA release versions now? Just by the kernel version that the various file versions are included into?
- The alsa-driver package installs items that are NOT a part of the
kernel package. The alsasound startup script and the ALSA headers are the examples I've found so far, but there may be more items.
They are no longer necessary stuff, but kept there since they are mostly harmless. You can run "make install-modules" to install only modules.
But, I don't want to just install the alsa-driver-1.0.25 modules if more recent ones are included in the kernel distributions; I only need whatever's in alsa-driver that is NOT in the kernel distributions, for example:
- Is /etc/init.d/alsasound not needed? It seems to do a number of things on startup/shutdown.
- How can I independently install the ALSA headers: "make headers-install" inside alsa-driver-1.0.25?
And, are there any other components that alsa-driver installs that are NOT included in the kernel distributions?
- When installed, the alsa-driver package installs its modules into
the currently running kernel's directories. So, if you want to have the latest system, you need to install the kernel, reboot into that kernel, install alsa-driver, reinstall the kernel, and reboot again. Ugh.
Hm, did you read INSTALL file? The installation to an update (or extra) directory is suggested. Pass a proper --with-moddir configure option.
I missed that: thanks.
Reading the INSTALL doc on that option, it mentions using a relative path to put the installed modules in a subdirectory so as to preserve the existing versions: why would I want to do that?
<rant> ALSA's Achilles heel has always been its documentation, whether for developers (the Doxygen-generated documents are at times comically uninformative) or for end-users (e.g. the lack of information such as the above). Please: those of you in the know, spend some time documenting this powerful and confusing system. Yes, you know how to use it, but isn't the goal to have it support the thousands/millions of audio users out there, and not just the dozen or so core ALSA developers? </rant>
You seem to overestimate the numbers. I dream of dozen of core developers, too.
I hear you. But, that makes it even more important that the documentation be as complete as possible, so that a) you few developers don't get pestered by we not-yet-in-the-know users, and b) the knowledge you each have built up over the years isn't lost when one of you moves on to other projects.
Speaking of implicit feedback: it's been since 3.5, but lots of bug fixes are found in 3.7. So better to use 3.7, I guess.
That's good information.
HTH,
Takashi
It most definitely does. Thank you.
Dan
P.S. And, I'll make sure to start a new thread next time.
At Mon, 28 Jan 2013 11:14:59 -0500, Daniel Griscom wrote:
At 4:28 PM +0100 1/28/13, Takashi Iwai wrote:
At Fri, 25 Jan 2013 10:10:18 -0500, Daniel Griscom wrote:
I never got a response to my query,
... because you're hanging your post to an utterly irrelevant thread? It's the second time, so I guess the previous time wasn't an accident.
Are there hidden email headers that maintain threads independent of the subject line?
In-reply-to and references headers.
If so then my apologies: my (antique) email client has been hiding them from me.
not even an RTFM (although I'm pretty sure this isn't in the M). So, in case anyone else is wondering, here's what I've since found:
- The kernel packages do NOT limit themselves to taking an entire
released ALSA package. In particular, the 3.6.X series has a number of improvements and changes that aren't in the latest (year old) alsa-driver 1.0.25 package. I'll guess that they're taken directly from the alsa GIT repository, but it's hard to know.
The 1.0.25 *released* tarball is what was released. It won't change. The tarball created from the latest GIT is called "snapshot".
And note that the alsa-driver version number has been already deprecated in the recent kernel. The confusing number 1.0.25 was dropped, finally.
In short, forget about alsa-driver released packages. Stick with the driver included in your kernel, or use alsa-driver snapshot tarball (but carefully).
Well, that's good to know. How do you refer to ALSA release versions now? Just by the kernel version that the various file versions are included into?
Just use the kernel version as the reference. That's enough.
- The alsa-driver package installs items that are NOT a part of the
kernel package. The alsasound startup script and the ALSA headers are the examples I've found so far, but there may be more items.
They are no longer necessary stuff, but kept there since they are mostly harmless. You can run "make install-modules" to install only modules.
But, I don't want to just install the alsa-driver-1.0.25 modules if more recent ones are included in the kernel distributions;
That's why I wrote you should forget alsa-driver packages.
I only need whatever's in alsa-driver that is NOT in the kernel distributions, for example:
- Is /etc/init.d/alsasound not needed? It seems to do a number of
things on startup/shutdown.
It's a thing the distro should take care of. The installed one is a reference init script. Forget this.
- How can I independently install the ALSA headers: "make
headers-install" inside alsa-driver-1.0.25?
The necessary header files are already included alsa-lib source tree, and/or included in the kernel tree itself. You never need to install them separately nowadays. Forget this.
And, are there any other components that alsa-driver installs that are NOT included in the kernel distributions?
Basically nothing. Or, maybe alsa-info.sh. But this script can be fetched from the web page as well.
- When installed, the alsa-driver package installs its modules into
the currently running kernel's directories. So, if you want to have the latest system, you need to install the kernel, reboot into that kernel, install alsa-driver, reinstall the kernel, and reboot again. Ugh.
Hm, did you read INSTALL file? The installation to an update (or extra) directory is suggested. Pass a proper --with-moddir configure option.
I missed that: thanks.
Reading the INSTALL doc on that option, it mentions using a relative path to put the installed modules in a subdirectory so as to preserve the existing versions: why would I want to do that?
Because it makes your life easier. It keeps the original modules intact, thus you can manage the updates more easily.
<rant> ALSA's Achilles heel has always been its documentation, whether for developers (the Doxygen-generated documents are at times comically uninformative) or for end-users (e.g. the lack of information such as the above). Please: those of you in the know, spend some time documenting this powerful and confusing system. Yes, you know how to use it, but isn't the goal to have it support the thousands/millions of audio users out there, and not just the dozen or so core ALSA developers? </rant>
You seem to overestimate the numbers. I dream of dozen of core developers, too.
I hear you. But, that makes it even more important that the documentation be as complete as possible, so that a) you few developers don't get pestered by we not-yet-in-the-know users, and b) the knowledge you each have built up over the years isn't lost when one of you moves on to other projects.
Sure. But note that the information you've asked are all obsoleted things. So, it won't be a big problem even if this information is lost, unless anyone digging Trojan city again :)
Takashi
Speaking of implicit feedback: it's been since 3.5, but lots of bug fixes are found in 3.7. So better to use 3.7, I guess.
That's good information.
HTH,
Takashi
It most definitely does. Thank you.
Dan
P.S. And, I'll make sure to start a new thread next time.
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400
At 5:29 PM +0100 1/28/13, Takashi Iwai wrote:
At Mon, 28 Jan 2013 11:14:59 -0500, Daniel Griscom wrote:
But, I don't want to just install the alsa-driver-1.0.25 modules if more recent ones are included in the kernel distributions;
That's why I wrote you should forget alsa-driver packages.
I only need whatever's in alsa-driver that is NOT in the kernel distributions, for example:
- Is /etc/init.d/alsasound not needed? It seems to do a number of
things on startup/shutdown.
It's a thing the distro should take care of. The installed one is a reference init script. Forget this.
- How can I independently install the ALSA headers: "make
headers-install" inside alsa-driver-1.0.25?
The necessary header files are already included alsa-lib source tree, and/or included in the kernel tree itself. You never need to install them separately nowadays. Forget this.
And, are there any other components that alsa-driver installs that are NOT included in the kernel distributions?
Basically nothing. Or, maybe alsa-info.sh. But this script can be fetched from the web page as well.
... but how would I have known all this without grilling you? And "basically nothing" is a long way from "nothing" when you're dealing with an unfamiliar and poorly documented system.
You seem to overestimate the numbers. I dream of dozen of core developers, too.
I hear you. But, that makes it even more important that the documentation be as complete as possible, so that a) you few developers don't get pestered by we not-yet-in-the-know users, and b) the knowledge you each have built up over the years isn't lost when one of you moves on to other projects.
Sure. But note that the information you've asked are all obsoleted things. So, it won't be a big problem even if this information is lost, unless anyone digging Trojan city again :)
Not at all true: the fact that much of this is obsolete is itself undocumented.
The alsa-project.org home page has a list of eight ALSA packages to download: there's no indication anywhere that any of them are considered obsolete. And the description of the various packages' contents is mostly missing; some of the packages include README files that describe contents, others have basically nothing (e.g. the description of the "alsa-tools" package is "Tools").
I've registered for an alsa-project.org account, and I see that I could edit the Download page, but I'd likely get some of the details wrong. Five minutes by someone who did know the details, however, (e.g. you?) would greatly reduce your users' confusion.
My $0.02, Dan
Takashi
Speaking of implicit feedback: it's been since 3.5, but lots of bug fixes are found in 3.7. So better to use 3.7, I guess.
That's good information.
HTH,
Takashi
It most definitely does. Thank you.
Dan
P.S. And, I'll make sure to start a new thread next time.
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400
At Mon, 28 Jan 2013 12:06:34 -0500, Daniel Griscom wrote:
At 5:29 PM +0100 1/28/13, Takashi Iwai wrote:
At Mon, 28 Jan 2013 11:14:59 -0500, Daniel Griscom wrote:
But, I don't want to just install the alsa-driver-1.0.25 modules if more recent ones are included in the kernel distributions;
That's why I wrote you should forget alsa-driver packages.
I only need whatever's in alsa-driver that is NOT in the kernel distributions, for example:
- Is /etc/init.d/alsasound not needed? It seems to do a number of
things on startup/shutdown.
It's a thing the distro should take care of. The installed one is a reference init script. Forget this.
- How can I independently install the ALSA headers: "make
headers-install" inside alsa-driver-1.0.25?
The necessary header files are already included alsa-lib source tree, and/or included in the kernel tree itself. You never need to install them separately nowadays. Forget this.
And, are there any other components that alsa-driver installs that are NOT included in the kernel distributions?
Basically nothing. Or, maybe alsa-info.sh. But this script can be fetched from the web page as well.
... but how would I have known all this without grilling you?
Feel free to ask, and also update the information on alsa-project.org web page. It's a Wiki, supposed to be updated by any users.
And "basically nothing" is a long way from "nothing" when you're dealing with an unfamiliar and poorly documented system.
Then how about start adding the new information you got now? :)
You seem to overestimate the numbers. I dream of dozen of core developers, too.
I hear you. But, that makes it even more important that the documentation be as complete as possible, so that a) you few developers don't get pestered by we not-yet-in-the-know users, and b) the knowledge you each have built up over the years isn't lost when one of you moves on to other projects.
Sure. But note that the information you've asked are all obsoleted things. So, it won't be a big problem even if this information is lost, unless anyone digging Trojan city again :)
Not at all true: the fact that much of this is obsolete is itself undocumented.
The alsa-project.org home page has a list of eight ALSA packages to download: there's no indication anywhere that any of them are considered obsolete. And the description of the various packages' contents is mostly missing; some of the packages include README files that describe contents, others have basically nothing (e.g. the description of the "alsa-tools" package is "Tools").
I've registered for an alsa-project.org account, and I see that I could edit the Download page, but I'd likely get some of the details wrong. Five minutes by someone who did know the details, however, (e.g. you?) would greatly reduce your users' confusion.
Well, I don't know what user doesn't know. That's a part of the problem. Documentation takes time, and replying this kind of mail takes more time. So I'd really appreciate if anyone starts digging into the web page, correct and update the information there. If anything is missing or uncertain, feel free to ask on ML.
thanks,
Takashi
My $0.02, Dan
Takashi
Speaking of implicit feedback: it's been since 3.5, but lots of bug fixes are found in 3.7. So better to use 3.7, I guess.
That's good information.
HTH,
Takashi
It most definitely does. Thank you.
Dan
P.S. And, I'll make sure to start a new thread next time.
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400
-- Daniel T. Griscom griscom@suitable.com Suitable Systems http://www.suitable.com/ 1 Centre Street, Suite 204 (781) 665-0053 Wakefield, MA 01880-2400
At 6:16 PM +0100 1/28/13, Takashi Iwai wrote:
At Mon, 28 Jan 2013 12:06:34 -0500, Daniel Griscom wrote:
... but how would I have known all this without grilling you?
Feel free to ask, and also update the information on alsa-project.org web page. It's a Wiki, supposed to be updated by any users.
I've added detailed information on the various ALSA packages to the ALSA download page at http://www.alsa-project.org/main/index.php/Download. Please look it over and correct any errors. Enhancements and illuminations would also be greatly appreciated.
Dan
At Mon, 4 Feb 2013 12:03:56 -0500, Daniel Griscom wrote:
At 6:16 PM +0100 1/28/13, Takashi Iwai wrote:
At Mon, 28 Jan 2013 12:06:34 -0500, Daniel Griscom wrote:
... but how would I have known all this without grilling you?
Feel free to ask, and also update the information on alsa-project.org web page. It's a Wiki, supposed to be updated by any users.
I've added detailed information on the various ALSA packages to the ALSA download page at http://www.alsa-project.org/main/index.php/Download. Please look it over and correct any errors. Enhancements and illuminations would also be greatly appreciated.
Thanks!
Takashi
Hi Sebastien,
On 01/25/2013 08:44 AM, Sebastien Guiriec wrote:
Hi Ricardo,
You need to rebase this patch as the code has been moved to dss-common.c file now. So it would not apply.
Thanks! I will send a new rebased version.
Ricardo
Sebastien
On 01/05/2013 12:26 AM, Ricardo Neri wrote:
While Pandaboard and SDP4430 have only one HDMI output connector, it may be possible that future boards and SoCs support more than one HDMI output. Thus, we define the identifier of the device. This is used by display common code to identify and create the platform devices for HDMI audio drivers.
Signed-off-by: Ricardo Neri rneri@dextratech.com
arch/arm/mach-omap2/board-4430sdp.c | 3 +++ arch/arm/mach-omap2/board-omap4panda.c | 3 +++ 2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 3669c12..5a486d9 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -666,6 +666,9 @@ static struct omap_dss_device sdp4430_hdmi_device = { .type = OMAP_DISPLAY_TYPE_HDMI, .channel = OMAP_DSS_CHANNEL_DIGIT, .data = &sdp4430_hdmi_data,
.dev = {
.id = -1,}, };
static struct picodlp_panel_data sdp4430_picodlp_pdata = {
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index bfcd397..9f336a3 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -440,6 +440,9 @@ static struct omap_dss_device omap4_panda_hdmi_device = { .type = OMAP_DISPLAY_TYPE_HDMI, .channel = OMAP_DSS_CHANNEL_DIGIT, .data = &omap4_panda_hdmi_data,
.dev = {
.id = -1,}, };
static struct omap_dss_device *omap4_panda_dss_devices[] = {
Relocate the creation the platform devices for audio the HDMI audio codec and the audio card to display.c. This allows the display code to create the required platform devices based on what is wired on the board. Thus, as many devices as required are created; or none if the HDMI ouptut is not implemented.
Signed-off-by: Ricardo Neri rneri@dextratech.com --- arch/arm/mach-omap2/board-4430sdp.c | 6 ------ arch/arm/mach-omap2/board-omap4panda.c | 6 ------ arch/arm/mach-omap2/devices.c | 7 ------- arch/arm/mach-omap2/display.c | 31 +++++++++++++++++++++++++++++++ 4 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 5a486d9..0830d98 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -383,11 +383,6 @@ static struct platform_device sdp4430_dmic_codec = { .id = -1, };
-static struct platform_device sdp4430_hdmi_audio_codec = { - .name = "hdmi-audio-codec", - .id = -1, -}; - static struct omap_abe_twl6040_data sdp4430_abe_audio_data = { .card_name = "SDP4430", .has_hs = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT, @@ -422,7 +417,6 @@ static struct platform_device *sdp4430_devices[] __initdata = { &sdp4430_vbat, &sdp4430_dmic_codec, &sdp4430_abe_audio, - &sdp4430_hdmi_audio_codec, };
static struct omap_musb_board_data musb_board_data = { diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 9f336a3..561a5a7 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -126,11 +126,6 @@ static struct platform_device panda_abe_audio = { }, };
-static struct platform_device panda_hdmi_audio_codec = { - .name = "hdmi-audio-codec", - .id = -1, -}; - static struct platform_device btwilink_device = { .name = "btwilink", .id = -1, @@ -140,7 +135,6 @@ static struct platform_device *panda_devices[] __initdata = { &leds_gpio, &wl1271_device, &panda_abe_audio, - &panda_hdmi_audio_codec, &btwilink_device, };
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 66518b2..6d37438 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -355,11 +355,6 @@ static inline void omap_init_dmic(void) {} #if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \ defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE)
-static struct platform_device omap_hdmi_audio = { - .name = "omap-hdmi-audio-card", - .id = -1, -}; - static void __init omap_init_hdmi_audio(void) { struct omap_hwmod *oh; @@ -375,8 +370,6 @@ static void __init omap_init_hdmi_audio(void) -1, oh, NULL, 0, NULL, 0, 0); WARN(IS_ERR(pdev), "Can't build omap_device for omap-hdmi-audio-dai.\n"); - - platform_device_register(&omap_hdmi_audio); } #else static inline void omap_init_hdmi_audio(void) {} diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 282c814e..6cc9cea 100644 --- a/arch/arm/mach-omap2/display.c +++ b/arch/arm/mach-omap2/display.c @@ -414,6 +414,37 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) } }
+ /* Create devices for HDMI audio drivers */ + for (i = 0; i < board_data->num_devices; i++) { + struct platform_device *au_pdev; + struct omap_dss_device *dssdev = board_data->devices[i]; + bool card_created = false; + + if (dssdev->type != OMAP_DISPLAY_TYPE_HDMI) + continue; + + /* We need only one device for the audio card */ + if (card_created == false) { + au_pdev = create_simple_dss_pdev("omap-hdmi-audio-card", + -1, NULL, 0, dss_pdev); + if (IS_ERR(au_pdev)) { + pr_err("Could not build platform_device for omap-hdmi-audio-card\n"); + return PTR_ERR(au_pdev); + } + card_created = true; + } + + /* One device for each HDMI connector in the board */ + au_pdev = create_simple_dss_pdev("hdmi-audio-codec", + dssdev->dev.id, + NULL, 0, dss_pdev); + if (IS_ERR(au_pdev)) { + pr_err("Could not build platform_device for hdmi-audio-codec\n"); + return PTR_ERR(au_pdev); + } + + } + return 0; }
The HDMI display and audio functionality share the same resources (e.g., register spaces). The ASoC HDMI CPU-DAI driver needs access to some (but not all) the resources of the dss_hdmi platform device. As such resources are within the address space of omapdss_hdmi, it makes sense to have the DSS HDMI driver to create the platform driver with the required resources.
Signed-off-by: Ricardo Neri rneri@dextratech.com --- arch/arm/mach-omap2/devices.c | 24 ---------------- drivers/video/omap2/dss/hdmi.c | 59 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 59 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 6d37438..9fdc1f9 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -352,29 +352,6 @@ static void __init omap_init_dmic(void) static inline void omap_init_dmic(void) {} #endif
-#if defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI) || \ - defined(CONFIG_SND_OMAP_SOC_OMAP_HDMI_MODULE) - -static void __init omap_init_hdmi_audio(void) -{ - struct omap_hwmod *oh; - struct platform_device *pdev; - - oh = omap_hwmod_lookup("dss_hdmi"); - if (!oh) { - printk(KERN_ERR "Could not look up dss_hdmi hw_mod\n"); - return; - } - - pdev = omap_device_build("omap-hdmi-audio", - -1, oh, NULL, 0, NULL, 0, 0); - WARN(IS_ERR(pdev), - "Can't build omap_device for omap-hdmi-audio-dai.\n"); -} -#else -static inline void omap_init_hdmi_audio(void) {} -#endif - #if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
#include <linux/platform_data/spi-omap2-mcspi.h> @@ -620,7 +597,6 @@ static int __init omap2_init_devices(void) */ omap_init_audio(); omap_init_camera(); - omap_init_hdmi_audio(); omap_init_mbox(); /* If dtb is there, the devices will be created dynamically */ if (!of_have_populated_dt()) { diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 769d082..0dde2b5 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -60,6 +60,9 @@ static struct { struct mutex lock; struct platform_device *pdev; +#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) + struct platform_device *audio_pdev; +#endif
struct hdmi_ip_data ip_data;
@@ -822,6 +825,51 @@ static void hdmi_put_clocks(void) }
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) +static int hdmi_probe_audio(struct platform_device *pdev) +{ + struct resource *res; + struct platform_device *aud_pdev; + struct resource aud_res[2] = { + DEFINE_RES_MEM(-1, -1), + DEFINE_RES_DMA(-1), + }; + + res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0); + if (!res) { + DSSERR("can't get IORESOURCE_MEM HDMI\n"); + return -EINVAL; + } + + /* + * Pass this resource to audio drivers to find the DMA port address. + * Audio drivers should not ioremap it. + */ + aud_res[0].start = res->start; + aud_res[0].end = res->end; + + res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0); + if (!res) { + DSSERR("can't get IORESOURCE_DMA HDMI\n"); + return -EINVAL; + } + + /* Pass the audio DMA request resource to audio drivers. */ + aud_res[1].start = res->start; + + /* create platform device for HDMI audio driver */ + aud_pdev = platform_device_register_simple("omap-hdmi-audio", + pdev->id, aud_res, + ARRAY_SIZE(aud_res)); + if (IS_ERR(aud_pdev)) { + DSSERR("Can't instantiate hdmi-audio\n"); + return -ENODEV; + } + + hdmi.audio_pdev = aud_pdev; + + return 0; +} + int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts) { u32 deep_color; @@ -1111,6 +1159,12 @@ static int __init omapdss_hdmihw_probe(struct platform_device *pdev)
hdmi_probe_pdata(pdev);
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) + r = hdmi_probe_audio(pdev); + if (r) + DSSWARN("could not create platform device for audio"); +#endif + return 0;
err_panel_init: @@ -1127,6 +1181,11 @@ static int __exit hdmi_remove_child(struct device *dev, void *data)
static int __exit omapdss_hdmihw_remove(struct platform_device *pdev) { +#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) + if (hdmi.audio_pdev != NULL) + platform_device_unregister(hdmi.audio_pdev); +#endif + device_for_each_child(&pdev->dev, NULL, hdmi_remove_child);
dss_unregister_child_devices(&pdev->dev);
Instead of passing the complete address space to the platform device for audio, just pass the address offset of the DMA port for audio samples. Thus, we prevent that two drivers try to ioremap the same resources. This is to be safe, as the ASoC HDMI CPU-DAI driver will not need to ioremap such resource.
Signed-off-by: Ricardo Neri rneri@dextratech.com --- drivers/video/omap2/dss/hdmi.c | 9 ++++++--- sound/soc/omap/omap-hdmi.c | 3 +-- sound/soc/omap/omap-hdmi.h | 2 -- 3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c index 0dde2b5..b758f83 100644 --- a/drivers/video/omap2/dss/hdmi.c +++ b/drivers/video/omap2/dss/hdmi.c @@ -829,6 +829,7 @@ static int hdmi_probe_audio(struct platform_device *pdev) { struct resource *res; struct platform_device *aud_pdev; + u32 port_offset, port_size; struct resource aud_res[2] = { DEFINE_RES_MEM(-1, -1), DEFINE_RES_DMA(-1), @@ -841,11 +842,13 @@ static int hdmi_probe_audio(struct platform_device *pdev) }
/* - * Pass this resource to audio drivers to find the DMA port address. + * Pass DMA audio port to audio drivers. * Audio drivers should not ioremap it. */ - aud_res[0].start = res->start; - aud_res[0].end = res->end; + hdmi.ip_data.ops->audio_get_dma_port(&port_offset, &port_size); + + aud_res[0].start = res->start + port_offset; + aud_res[0].end = aud_res[0].start + port_size - 1;
res = platform_get_resource(hdmi.pdev, IORESOURCE_DMA, 0); if (!res) { diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c index db08501..33418fc 100644 --- a/sound/soc/omap/omap-hdmi.c +++ b/sound/soc/omap/omap-hdmi.c @@ -281,8 +281,7 @@ static __devinit int omap_hdmi_probe(struct platform_device *pdev) return -ENODEV; }
- hdmi_data->dma_params.port_addr = hdmi_rsrc->start - + OMAP_HDMI_AUDIO_DMA_PORT; + hdmi_data->dma_params.port_addr = hdmi_rsrc->start;
hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0); if (!hdmi_rsrc) { diff --git a/sound/soc/omap/omap-hdmi.h b/sound/soc/omap/omap-hdmi.h index 6ad2bf4..33d7a93 100644 --- a/sound/soc/omap/omap-hdmi.h +++ b/sound/soc/omap/omap-hdmi.h @@ -25,8 +25,6 @@ #ifndef __OMAP_HDMI_H__ #define __OMAP_HDMI_H__
-#define OMAP_HDMI_AUDIO_DMA_PORT 0x8c - #define OMAP_HDMI_RATES (SNDRV_PCM_RATE_32000 | \ SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | \ SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 | \
On Fri, Jan 04, 2013 at 05:26:27PM -0600, Ricardo Neri wrote:
Instead of passing the complete address space to the platform device for audio, just pass the address offset of the DMA port for audio samples. Thus, we prevent that two drivers try to ioremap the same resources. This is to be safe, as the ASoC HDMI CPU-DAI driver will not need to ioremap such resource.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
participants (5)
-
Daniel Griscom -
Mark Brown -
Ricardo Neri -
Sebastien Guiriec -
Takashi Iwai