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