[RESEND PATCH v3 0/5] ARM: OMAP4+: HDMI: Update platform devices for audio

[RESEND PATCH v3 0/5] ARM: OMAP4+: HDMI: Update platform devices for audio

[Ricardo Neri]

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

[RESEND PATCH v3 1/5] ARM: OMAP4+: HDMI: Rename platform devices for ASoC drivers

[Ricardo Neri]

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;
-- 
1.7.10.4

Re: [RESEND PATCH v3 1/5] ARM: OMAP4+: HDMI: Rename platform devices for ASoC drivers

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[RESEND PATCH v3 2/5] ARM: OMAP4: Assign IDs to DSS HDMI devices

[Ricardo Neri]

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[] = {
-- 
1.7.10.4

Re: [alsa-devel] [RESEND PATCH v3 2/5] ARM: OMAP4: Assign IDs to DSS HDMI devices

[Sebastien Guiriec]

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[] = {
>

Re: ALSA versions versus kernel versions

[Daniel Griscom]

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

-- 
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400

Re: ALSA versions versus kernel versions

[Takashi Iwai]

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
> 

Re: ALSA versions versus kernel versions

[Daniel Griscom]

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
>>


-- 
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400

Re: ALSA versions versus kernel versions

[Takashi Iwai]

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
> 

Re: ALSA versions versus kernel versions

[Daniel Griscom]

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.

-- 
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400

Re: ALSA versions versus kernel versions

[Takashi Iwai]

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
> 

Re: ALSA versions versus kernel versions

[Daniel Griscom]

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
>>


-- 
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400

Re: ALSA versions versus kernel versions

[Takashi Iwai]

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
> 

Re: ALSA versions versus kernel versions

[Daniel Griscom]

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

-- 
Daniel T. Griscom             griscom@suitable.com
Suitable Systems              http://www.suitable.com/
1 Centre Street, Suite 204    (781) 665-0053
Wakefield, MA  01880-2400

Re: ALSA versions versus kernel versions

[Takashi Iwai]

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

Re: [alsa-devel] [RESEND PATCH v3 2/5] ARM: OMAP4: Assign IDs to DSS HDMI devices

[Ricardo Neri]

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[] = {
>>
>

[RESEND PATCH v3 3/5] ARM4: OMAP4+: HDMI: Relocate devices for audio codec and card

[Ricardo Neri]

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;
 }
 
-- 
1.7.10.4

[RESEND PATCH v3 4/5] ARM: OMAP4+: HDMI: Relocate the device for audio interface

[Ricardo Neri]

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);
-- 
1.7.10.4

[RESEND PATCH v3 5/5] ARM: OMAP4+: HDMI: Refine the DMA port resource for audio

[Ricardo Neri]

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 | \
-- 
1.7.10.4

Re: [RESEND PATCH v3 5/5] ARM: OMAP4+: HDMI: Refine the DMA port resource for audio

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]