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-mca...
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/2f0a632db0b52321f1fc3623d08... 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/...
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