mbox series

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

Message ID 20210705194249.2385-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 5, 2021, 7:42 p.m. UTC 
Hi,

Changes since v1:
- Do not calculat that we allow one serializer in DIT mode, just set the
  max_active_serializers to 1.
  Reported-by: kernel test robot <lkp@intel.com>

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                  | 176 +++++++++++++++---
 5 files changed, 175 insertions(+), 43 deletions(-)

Comments

Mark Brown July 7, 2021, 5:32 p.m. UTC | #1 
On Mon, Jul 05, 2021 at 10:42:44PM +0300, Peter Ujfalusi wrote:

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

I'm happy to take both through ASoC?  The patches look fine to me.
Péter Ujfalusi July 8, 2021, 6:44 p.m. UTC | #2 
Hi Mark, Tony,

On 07/07/2021 20:32, Mark Brown wrote:
> On Mon, Jul 05, 2021 at 10:42:44PM +0300, Peter Ujfalusi wrote:
> 
>> 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.
> 
> I'm happy to take both through ASoC?  The patches look fine to me.

Tony prefers if I leave the TRM documented (but not working) Smart-idle
mode intact in DT for the McASP and add some quirk via
drivers/bus/ti-sysc.c.
Tony, can you confirm it?

The ASoC patches are not affected by this, it is just that we need to
block SIDLE mode in a different way than how I did it in the last patch.

I'll take a look on how to implement the needed quirk for the McASP
module, then I can send the dts+ti-sysc patch to linux-omap.
Péter Ujfalusi July 9, 2021, 12:59 p.m. UTC | #3 
On 09/07/2021 15:40, Mark Brown wrote:
> On Fri, Jul 09, 2021 at 09:31:05AM +0300, Tony Lindgren wrote:
> 
>>> The ASoC patches are not affected by this, it is just that we need to
>>> block SIDLE mode in a different way than how I did it in the last patch.
> 
>>> I'll take a look on how to implement the needed quirk for the McASP
>>> module, then I can send the dts+ti-sysc patch to linux-omap.
> 
>> OK sounds good to me.
> 
> So should I queue the ASoC patches and then let the DT patches go via
> Tony's tree?

Yes, please. I don't know when I will have time to revisit the DT part.
Mark Brown July 12, 2021, 10:46 a.m. UTC | #4 
On Mon, 5 Jul 2021 22:42:44 +0300, Peter Ujfalusi wrote:
> Changes since v1:
> - Do not calculat that we allow one serializer in DIT mode, just set the
>   max_active_serializers to 1.
>   Reported-by: kernel test robot <lkp@intel.com>
> 
> 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).
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/5] ASoC: ti: davinci-mcasp: Fix DIT mode support
      commit: bbdd3f4dbe81e19b9123bc54e23ed54517615524
[2/5] ASoC: dt-bindings: davinci-mcasp: Add compatible string for OMAP4
      commit: 5dcd276e1525e0c7ae7aa1f0426b6343ebf994e0
[3/5] ASoC: ti: davinci-mcasp: Add support for the OMAP4 version of McASP
      commit: 0238bcf80e972f2ce25d767e54f89a9e49773f6e

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark