Rework OMAP4+ HDMI audio support

Since RFC version of the patch set:
- Split callbacks removal patch away from "Integrated ASoC DAI component driver implementation" patches for easier reading

This set of patches fixes OMAP4+ HDMI audio. The structure of the implementatin looks a bit different than before. Instead of creating a driver specific API for a separate ASoC component driver to connect to, this implementation integrates an the component driver into the HDMI driver.

The idea is to use an existing ASoC component driver API instead of creating a new custom API for each HDMI IP and to avoid splitting the driver to half for separate video and audio parts connected with the API.

The new implementation also uses simple-audio-card for a machine driver instead of having its own HW specific machine driver.

Removes omap-hdmi DAI driver, omap-hdmi-card driver, the related Kconfig options, and Makefile entries. The HDMI DAI drivers has been integrated directly to OMAP4+ HDMI drivers and simple-card driver is used instead of omap-hdmi-card driver.

Since RFC version of the patch set:
- Split callbacks removal patch away from "Integrated ASoC DAI component driver implementation" patches for easier reading

This set of patches fixes OMAP4+ HDMI audio. The structure of the implementatin looks a bit different than before. Instead of creating a driver specific API for a separate ASoC component driver to connect to, this implementation integrates an the component driver into the HDMI driver.

The idea is to use an existing ASoC component driver API instead of creating a new custom API for each HDMI IP and to avoid splitting the driver to half for separate video and audio parts connected with the API.

The new implementation also uses simple-audio-card for a machine driver instead of having its own HW specific machine driver.

The patches are based on 3.15-rc2 merged with
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next and
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-omap5

Everything is pushed here here:
git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio

On 12 May 2014 11:12, Jyri Sarha <[email protected]> wrote:

hey, this worked straight away :)

But there seems to be something wrong with the channel mapping.

For stereo (speaker-test -c 2) the mapping is correct.

But for -c 4 and -c 8 it gets weird:
speaker-test -c 4 -s X # where X is 1-4
1: Front Left is Rear Left
2: Front Right is Rear Right
3: Rear Right is Front Right
4: Rear Left is Front Left

speaker-test -c 8 -s X # where X is 1-8
1: Front Left is Rear Left
2: Center is Rear Left
3: Front Right is Rear Right
4: Side Right is Front Right
5: Rear Right is silent
6: Rear Left is Center
7: Side Left is Front Left
8: LFE - Rear Right

I think you need to check what channel order ALSA expects. I believe speaker-test does the right thing on my HTPC normally connected to my receiver.

Quoted 2 lines · Joachim Eastwood

On 12 May 2014 11:12, Jyri Sarha <[email protected]> wrote:

...

Quoted 24 lines

hey, this worked straight away :)

But there seems to be something wrong with the channel mapping.

For stereo (speaker-test -c 2) the mapping is correct.

But for -c 4 and -c 8 it gets weird:
speaker-test -c 4 -s X # where X is 1-4
1: Front Left is Rear Left
2: Front Right is Rear Right
3: Rear Right is Front Right
4: Rear Left is Front Left

speaker-test -c 8 -s X # where X is 1-8
1: Front Left is Rear Left
2: Center is Rear Left
3: Front Right is Rear Right
4: Side Right is Front Right
5: Rear Right is silent
6: Rear Left is Center
7: Side Left is Front Left
8: LFE - Rear Right

Quoted 4 lines

I think you need to check what channel order ALSA expects. I believe speaker-test does the right thing on my HTPC normally connected to my receiver.

I checked the implementation and there was indeed something weird there, but the implementation can not explain the FL and FR channels jumping around. FL and FL should always be the first two channels in all configurations and the implementation does not touch them.

The implementation uses 8ch HDMI setup for anything above 2ch with "Audio InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC

This is a closest match to ALSA 8ch mapping (according to sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR

Current implementation has FLE and FC channels correctly swapped, but it shifts them to last two channels and RL, RR, SL, SR are shifted down to fill the place. This is all wrong and I'll try to come up with a fix for that. Unfortunately I can not test anything beyond 2 ch myself so I would need someone to volunteer to test my patch.

Use correct variable name for base address.

Signed-off-by Jyri Sarha <[email protected]>

---
 drivers/video/fbdev/omap2/dss/hdmi5_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/video/fbdev/omap2/dss/hdmi5_core.c +0 -0

index 270ebdd..af88e3c 100644

Signed-off-by Jyri Sarha <[email protected]>

---
 drivers/video/fbdev/omap2/dss/Kconfig |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

drivers/video/fbdev/omap2/dss/Kconfig +0 -0

index 8921a7a..ecc2f50 100644
@@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI
 	  HDMI support for OMAP4 based SoCs.
 
 config OMAP4_DSS_HDMI_AUDIO

Adds a simple-card sound node for HDMI audio, the associated hdmi-codec node, and sound-dai-cells propeties to the DAI nodes.

Signed-off-by Jyri Sarha <[email protected]>

---
 arch/arm/boot/dts/omap4-panda-common.dtsi |   21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

arch/arm/boot/dts/omap4-panda-common.dtsi +19 -1

index d2c45bf..c04f453 100644
@@ -41,7 +41,7 @@
 		};
 	};
 
-	sound: sound {
+	sound: sound@0 {
 		compatible = "ti,abe-twl6040";
 		ti,model = "PandaBoard";
 

@@ -65,6 +65,24 @@
 			"AFMR", "Line In";
 	};
 
+	sound@1 {
+		compatible = "simple-audio-card";
+
+		simple-audio-card,cpu {
+			sound-dai = <&hdmi>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&hdmi_audio>;
+		};
+	};
+
+	hdmi_audio: hdmi_audio@0 {
+		#sound-dai-cells = <0>;
+		compatible = "linux,hdmi-audio";
+		status = "okay";
+	};
+
 	/* HS USB Port 1 Power */
 	hsusb1_power: hsusb1_power_reg {
 		compatible = "regulator-fixed";

So all of the above .dts changes are already implied when we have HDMI video on the board. Is there no way to prevent every board needing to add those exact same nodes to get HDMI audio?

Hi,

Quoted 12 lines · Jyri Sarha

Signed-off-by Jyri Sarha <[email protected]>

---
  drivers/video/fbdev/omap2/dss/Kconfig |   10 +++++++++-
  1 file changed, 9 insertions(+), 1 deletion(-)

drivers/video/fbdev/omap2/dss/Kconfig +0 -0

index 8921a7a..ecc2f50 100644
@@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI
  	  HDMI support for OMAP4 based SoCs.
 

drivers/video/fbdev/omap2/dss/Kconfig config OMAP4_DSS_HDMI · line 81

Quoted 11 lines

drivers/video/fbdev/omap2/dss/Kconfig +9 -1

  config OMAP4_DSS_HDMI_AUDIO
-	bool
+	bool "HDMI audio support for OMAP4"
+	depends on OMAP4_DSS_HDMI
+	depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
+	default y
+	help
+	  HDMI audio support for OMAP4 based SoCs. Adds integrated
+	  ASoC Digital Audio Interface component driver into OMAPDSS
+	  module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
+	  devicetree description for full HDMI audio support.

What does "for full HDMI audio support" mean? What's the partial support? =)

Quoted 40 lines · Jyri Sarha

Quoted 2 lines · Joachim Eastwood

On 12 May 2014 11:12, Jyri Sarha <[email protected]> wrote:

...

Quoted 24 lines

hey, this worked straight away :)

But there seems to be something wrong with the channel mapping.

For stereo (speaker-test -c 2) the mapping is correct.

But for -c 4 and -c 8 it gets weird:
speaker-test -c 4 -s X # where X is 1-4
1: Front Left is Rear Left
2: Front Right is Rear Right
3: Rear Right is Front Right
4: Rear Left is Front Left

speaker-test -c 8 -s X # where X is 1-8
1: Front Left is Rear Left
2: Center is Rear Left
3: Front Right is Rear Right
4: Side Right is Front Right
5: Rear Right is silent
6: Rear Left is Center
7: Side Left is Front Left
8: LFE - Rear Right

Quoted 4 lines

I think you need to check what channel order ALSA expects. I believe speaker-test does the right thing on my HTPC normally connected to my receiver.

I checked the implementation and there was indeed something weird there, but the implementation can not explain the FL and FR channels jumping around. FL and FL should always be the first two channels in all configurations and the implementation does not touch them.

Quoted 6 lines

The implementation uses 8ch HDMI setup for anything above 2ch with "Audio InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC

This is a closest match to ALSA 8ch mapping (according to sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR

hm, okey. I haven't look at the code but it do seem strange. But with speaker-test -c 4 the front and back are surely swapped here.

I'll do some more testing and also check with my HTPC. btw, I only have a 5.1 setup over here so I can't test all the discrete channels.

Quoted 5 lines

Current implementation has FLE and FC channels correctly swapped, but it shifts them to last two channels and RL, RR, SL, SR are shifted down to fill the place. This is all wrong and I'll try to come up with a fix for that. Unfortunately I can not test anything beyond 2 ch myself so I would need someone to volunteer to test my patch.

I have the dev kit setup up over here so I can test your patches.

Quoted 54 lines · Joachim Eastwood

Quoted 40 lines · Jyri Sarha

Quoted 2 lines · Joachim Eastwood

On 12 May 2014 11:12, Jyri Sarha <[email protected]> wrote:

...

Quoted 24 lines

hey, this worked straight away :)

But there seems to be something wrong with the channel mapping.

For stereo (speaker-test -c 2) the mapping is correct.

But for -c 4 and -c 8 it gets weird:
speaker-test -c 4 -s X # where X is 1-4
1: Front Left is Rear Left
2: Front Right is Rear Right
3: Rear Right is Front Right
4: Rear Left is Front Left

speaker-test -c 8 -s X # where X is 1-8
1: Front Left is Rear Left
2: Center is Rear Left
3: Front Right is Rear Right
4: Side Right is Front Right
5: Rear Right is silent
6: Rear Left is Center
7: Side Left is Front Left
8: LFE - Rear Right

Quoted 4 lines

I think you need to check what channel order ALSA expects. I believe speaker-test does the right thing on my HTPC normally connected to my receiver.

I checked the implementation and there was indeed something weird there, but the implementation can not explain the FL and FR channels jumping around. FL and FL should always be the first two channels in all configurations and the implementation does not touch them.

Quoted 6 lines

The implementation uses 8ch HDMI setup for anything above 2ch with "Audio InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC

This is a closest match to ALSA 8ch mapping (according to sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR

hm, okey. I haven't look at the code but it do seem strange. But with speaker-test -c 4 the front and back are surely swapped here.

I'll do some more testing and also check with my HTPC. btw, I only have a 5.1 setup over here so I can't test all the discrete channels.

Quoted 7 lines

Quoted 5 lines

Current implementation has FLE and FC channels correctly swapped, but it shifts them to last two channels and RL, RR, SL, SR are shifted down to fill the place. This is all wrong and I'll try to come up with a fix for that. Unfortunately I can not test anything beyond 2 ch myself so I would need someone to volunteer to test my patch.

I have the dev kit setup up over here so I can test your patches.

I did some more testing over here.

My HTPC (nVidia ION2 based) works good with speaker-test and all channels are where they are suppose to be.

On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s 1; done" and this had an interesting effect.
Most of the time FL (Front Left) is swapped with BL (Back Left) but about every 10th time the sound comes out in the FL speaker... So there something weird going on here. Same story for the right channel.

I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:

[ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
[ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open

interface 58006000.encoder: -19

But after replugging the HDMI connector a couple of times it starts to work.

I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.

Quoted 1 line · Joachim Eastwood

On 14 May 2014 18:25, Joachim Eastwood <[email protected]> wrote:

Quoted 12 lines

I did some more testing over here.

My HTPC (nVidia ION2 based) works good with speaker-test and all channels are where they are suppose to be.

On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s 1; done" and this had an interesting effect.
Most of the time FL (Front Left) is swapped with BL (Back Left) but about every 10th time the sound comes out in the FL speaker... So there something weird going on here. Same story for the right channel.

Quoted 7 lines

I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:

[ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
[ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open

interface 58006000.encoder: -19

But after replugging the HDMI connector a couple of times it starts to work.

Quoted 1 line

I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.

On the 3.4 Variscite kernel:
Linux version 3.4.0-1489-omap4 (uri@pluto) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #27 SMP PREEMPT Sun Apr 7 13:27:10 IDT 2013
git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git + Variscite vendor patches

Both speaker-test -c 4 and -c 8 works. All channels are where they are suppose to be.

Hot plugging is broken, though. So the HDMI must be connected on boot, but that might be the Variscite board setup.

Quoted 10 lines · Jyri Sarha

Since RFC version of the patch set:
- Split callbacks removal patch away from "Integrated ASoC DAI component driver implementation" patches for easier reading

This set of patches fixes OMAP4+ HDMI audio. The structure of the implementatin looks a bit different than before. Instead of creating a driver specific API for a separate ASoC component driver to connect to, this implementation integrates an the component driver into the HDMI driver.

Quoted 7 lines

The idea is to use an existing ASoC component driver API instead of creating a new custom API for each HDMI IP and to avoid splitting the driver to half for separate video and audio parts connected with the API.

The new implementation also uses simple-audio-card for a machine driver instead of having its own HW specific machine driver.

Can you guys please post this split into the following separate parts for the maintainers to merge:

- ASoC changes
- DSS changes
- DTS changes

And once those are all in, please post the defconfig changes.

Quoted 26 lines · Tony Lindgren

Quoted 10 lines · Jyri Sarha

Since RFC version of the patch set:
- Split callbacks removal patch away from "Integrated ASoC DAI component driver implementation" patches for easier reading

This set of patches fixes OMAP4+ HDMI audio. The structure of the implementatin looks a bit different than before. Instead of creating a driver specific API for a separate ASoC component driver to connect to, this implementation integrates an the component driver into the HDMI driver.

Quoted 7 lines

The idea is to use an existing ASoC component driver API instead of creating a new custom API for each HDMI IP and to avoid splitting the driver to half for separate video and audio parts connected with the API.

The new implementation also uses simple-audio-card for a machine driver instead of having its own HW specific machine driver.

Can you guys please post this split into the following separate parts for the maintainers to merge:

- ASoC changes
- DSS changes
- DTS changes

Quoted 1 line

And once those are all in, please post the defconfig changes.

Tony, this series will get delayed until 3.17, but I'd like to merge the HDMI DMA channel changes to omap4/omap5.dtsi already to 3.16. They are patches 13 and 15.

Those are very trivial, but I'd rather have acks from you for all the .dts changes I'll be sending.