mbox series

[0/5] ASoC: ti: davinci-mcasp: Fix the DIT mode and OMAP4 support

Message ID 20210704150450.20106-1-peter.ujfalusi@gmail.com
Headers show
Series ASoC: ti: davinci-mcasp: Fix the DIT mode and OMAP4 support | expand

Message

Péter Ujfalusi July 4, 2021, 3:04 p.m. UTC
Hi,

it has been on my todo list for several years to support McASP on OMAP4 devices.
For Galaxy Nexus we had an omap-mcasp driver (which was mostly a stripped down
davinci-mcasp driver) to support what was needed on that specific phone + it's
dock for S/PDIF (48KHz, 16bit, stereo).

Not many (if any) device available to test the DIT mode of McASP.
I have used BeagleBone White (McASP1 AXR3 can be routed to a pin) to get the
S/PDIF mode working then PandaES for OMAP4 support (on PandaES the gpio_121 is
not used and the signal is routed to expansion J6 pin14)

In theory the McASP in OMAP5 should be working after this series, but the OMAP5
TRM is not public and I do not have one to check the addresses and see if there
is a way to test it on omap5-uevm.

Mark, Tony:
The ASoC and dts patches can go via separate tree I felt that it is better if
they are together, at least initially.

Nikolaus: fyi, this might be useful for Pyra?

Regards,
Péter
---
Peter Ujfalusi (5):
  ASoC: ti: davinci-mcasp: Fix DIT mode support
  ASoC: dt-bindings: davinci-mcasp: Add compatible string for OMAP4
  ASoC: ti: davinci-mcasp: Add support for the OMAP4 version of McASP
  ARM: dts: omap4-l4-abe: Correct sidle modes for McASP
  ARM: dts: omap4-l4-abe: Add McASP configuration

 .../bindings/sound/davinci-mcasp-audio.txt    |   1 +
 arch/arm/boot/dts/omap4-l4-abe.dtsi           |  39 ++--
 include/linux/platform_data/davinci_asp.h     |   1 +
 sound/soc/ti/Kconfig                          |   1 +
 sound/soc/ti/davinci-mcasp.c                  | 168 +++++++++++++++---
 5 files changed, 168 insertions(+), 42 deletions(-)

Comments

H. Nikolaus Schaller July 5, 2021, 1:32 p.m. UTC | #1
Hi Péter,

> Am 04.07.2021 um 17:04 schrieb Peter Ujfalusi <peter.ujfalusi@gmail.com>:
> 
> Hi,
> 
> it has been on my todo list for several years to support McASP on OMAP4 devices.
> For Galaxy Nexus we had an omap-mcasp driver (which was mostly a stripped down
> davinci-mcasp driver) to support what was needed on that specific phone + it's
> dock for S/PDIF (48KHz, 16bit, stereo).
> 
> Not many (if any) device available to test the DIT mode of McASP.
> I have used BeagleBone White (McASP1 AXR3 can be routed to a pin) to get the
> S/PDIF mode working then PandaES for OMAP4 support (on PandaES the gpio_121 is
> not used and the signal is routed to expansion J6 pin14)
> 
> In theory the McASP in OMAP5 should be working after this series, but the OMAP5
> TRM is not public and I do not have one to check the addresses and see if there
> is a way to test it on omap5-uevm.
> 
> Mark, Tony:
> The ASoC and dts patches can go via separate tree I felt that it is better if
> they are together, at least initially.
> 
> Nikolaus: fyi, this might be useful for Pyra?

Yes, definitively.

I just wonder how compatible it is with the "old" omap-mcasp driver we carry
along for the Pyra:

https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=sound/soc/ti/omap-mcasp.c;h=24d839a24f34ec02456176744d3690016592b5a3;hb=7789ab635e56a2fd9fe04ca2e9ccfeaccb8e0f52

Does it now have additional functionality or robustness?
And does it need changes of the OMAP5 device tree?

And also important seems to be the ABE/AESS integration where we so far failed
to make it work again on more recent kernels. Our most recent patch set is here:

https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/aess-v5

Anyways I am happy to see a little progress on the omap4/5 audio subsystem.

BR and thanks,
Nikolaus



> 
> Regards,
> Péter
> ---
> Peter Ujfalusi (5):
>  ASoC: ti: davinci-mcasp: Fix DIT mode support
>  ASoC: dt-bindings: davinci-mcasp: Add compatible string for OMAP4
>  ASoC: ti: davinci-mcasp: Add support for the OMAP4 version of McASP
>  ARM: dts: omap4-l4-abe: Correct sidle modes for McASP
>  ARM: dts: omap4-l4-abe: Add McASP configuration
> 
> .../bindings/sound/davinci-mcasp-audio.txt    |   1 +
> arch/arm/boot/dts/omap4-l4-abe.dtsi           |  39 ++--
> include/linux/platform_data/davinci_asp.h     |   1 +
> sound/soc/ti/Kconfig                          |   1 +
> sound/soc/ti/davinci-mcasp.c                  | 168 +++++++++++++++---
> 5 files changed, 168 insertions(+), 42 deletions(-)
> 
> -- 
> 2.32.0
>
Péter Ujfalusi July 5, 2021, 2:10 p.m. UTC | #2
Hi Nikolaus,

On 05/07/2021 16:32, H. Nikolaus Schaller wrote:
> Hi Péter,
> 
>> Am 04.07.2021 um 17:04 schrieb Peter Ujfalusi <peter.ujfalusi@gmail.com>:
>>
>> Hi,
>>
>> it has been on my todo list for several years to support McASP on OMAP4 devices.
>> For Galaxy Nexus we had an omap-mcasp driver (which was mostly a stripped down
>> davinci-mcasp driver) to support what was needed on that specific phone + it's
>> dock for S/PDIF (48KHz, 16bit, stereo).
>>
>> Not many (if any) device available to test the DIT mode of McASP.
>> I have used BeagleBone White (McASP1 AXR3 can be routed to a pin) to get the
>> S/PDIF mode working then PandaES for OMAP4 support (on PandaES the gpio_121 is
>> not used and the signal is routed to expansion J6 pin14)
>>
>> In theory the McASP in OMAP5 should be working after this series, but the OMAP5
>> TRM is not public and I do not have one to check the addresses and see if there
>> is a way to test it on omap5-uevm.
>>
>> Mark, Tony:
>> The ASoC and dts patches can go via separate tree I felt that it is better if
>> they are together, at least initially.
>>
>> Nikolaus: fyi, this might be useful for Pyra?
> 
> Yes, definitively.
> 
> I just wonder how compatible it is with the "old" omap-mcasp driver we carry
> along for the Pyra:
> 
> https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=sound/soc/ti/omap-mcasp.c;h=24d839a24f34ec02456176744d3690016592b5a3;hb=7789ab635e56a2fd9fe04ca2e9ccfeaccb8e0f52
> 
> Does it now have additional functionality or robustness?

The davinci-mcasp with series does work on OMAP4. I could not made the
omap-mcasp working. I have picked the driver from pyra in hopes that it
is working so I will ahve a stable base.
Have you tested it?

the omap-mcasp supports only 48KHz and 16bit, no passthrough, no 24bit,
all is hardwired for the Galaxy Nexus setup, afaik.

The davinci-mcasp should be better all around, I think the PM side is
also more robust.

The other point is that I would not accept the omap-mcasp driver
upstream. The IP is the same so the driver should be also...

> And does it need changes of the OMAP5 device tree?

In a similar way as the dts patches in this series.
fwiw:
https://github.com/omap-audio/linux-audio/commit/2f0a632db0b52321f1fc3623d088a741aeb72ef7
is the patch I have for PandaES to get S/PDIF working.

> And also important seems to be the ABE/AESS integration where we so far failed
> to make it work again on more recent kernels.

The McASP is not routed via ABE/AESS, it has been always handled outside
of the firmware, so it is just a simple link outside.

> Our most recent patch set is here:
> 
> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/aess-v5

Yes, I'm following it ;)

> Anyways I am happy to see a little progress on the omap4/5 audio subsystem.

It is in maintenance mode as there is not much of an interest outside of
a small group of people, but I try to help to get it better for Pyra.

> BR and thanks,
> Nikolaus
> 
> 
> 
>>
>> Regards,
>> Péter
>> ---
>> Peter Ujfalusi (5):
>>  ASoC: ti: davinci-mcasp: Fix DIT mode support
>>  ASoC: dt-bindings: davinci-mcasp: Add compatible string for OMAP4
>>  ASoC: ti: davinci-mcasp: Add support for the OMAP4 version of McASP
>>  ARM: dts: omap4-l4-abe: Correct sidle modes for McASP
>>  ARM: dts: omap4-l4-abe: Add McASP configuration
>>
>> .../bindings/sound/davinci-mcasp-audio.txt    |   1 +
>> arch/arm/boot/dts/omap4-l4-abe.dtsi           |  39 ++--
>> include/linux/platform_data/davinci_asp.h     |   1 +
>> sound/soc/ti/Kconfig                          |   1 +
>> sound/soc/ti/davinci-mcasp.c                  | 168 +++++++++++++++---
>> 5 files changed, 168 insertions(+), 42 deletions(-)
>>
>> -- 
>> 2.32.0
>>
>
H. Nikolaus Schaller July 5, 2021, 3:33 p.m. UTC | #3
> Am 05.07.2021 um 16:10 schrieb Péter Ujfalusi <peter.ujfalusi@gmail.com>:
> 
> Hi Nikolaus,
> 
>> 
>> Yes, definitively.
>> 
>> I just wonder how compatible it is with the "old" omap-mcasp driver we carry
>> along for the Pyra:
>> 
>> https://git.goldelico.com/?p=letux-kernel.git;a=blob;f=sound/soc/ti/omap-mcasp.c;h=24d839a24f34ec02456176744d3690016592b5a3;hb=7789ab635e56a2fd9fe04ca2e9ccfeaccb8e0f52
>> 
>> Does it now have additional functionality or robustness?
> 
> The davinci-mcasp with series does work on OMAP4. I could not made the
> omap-mcasp working. I have picked the driver from pyra in hopes that it
> is working so I will ahve a stable base.
> Have you tested it?

AFAIR it was not tested. e have the sound system working (with some glitches)
but that goes through McPDM I think.

> 
> the omap-mcasp supports only 48KHz and 16bit, no passthrough, no 24bit,
> all is hardwired for the Galaxy Nexus setup, afaik.
> 
> The davinci-mcasp should be better all around, I think the PM side is
> also more robust.
> 
> The other point is that I would not accept the omap-mcasp driver
> upstream. The IP is the same so the driver should be also...

:)

> 
>> And does it need changes of the OMAP5 device tree?
> 
> In a similar way as the dts patches in this series.
> fwiw:
> https://github.com/omap-audio/linux-audio/commit/2f0a632db0b52321f1fc3623d088a741aeb72ef7
> is the patch I have for PandaES to get S/PDIF working.

If I find a little time it should not be difficult to replace your
new driver and fix the DTS in our ABE/AESS branch.

> 
>> And also important seems to be the ABE/AESS integration where we so far failed
>> to make it work again on more recent kernels.
> 
> The McASP is not routed via ABE/AESS, it has been always handled outside
> of the firmware, so it is just a simple link outside.

Ah, ok. Makes it easier to test :)

> 
>> Our most recent patch set is here:
>> 
>> https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/aess-v5
> 
> Yes, I'm following it ;)
> 
>> Anyways I am happy to see a little progress on the omap4/5 audio subsystem.
> 
> It is in maintenance mode as there is not much of an interest outside of
> a small group of people, but I try to help to get it better for Pyra.

And a lot of public information has been lost (OMAPpedia). But there are some backups:

https://web.archive.org/web/20181111114134/http://omappedia.org/wiki/Audio_Drive_Arch

BR and thanks,
Nikolaus