[alsa-devel] [PATCH v2] ASoC: ti: omap-mcpdm: Add support for pdmclk clock handling

[Peter Ujfalusi]

On 10/25/19 8:17 PM, Tony Lindgren wrote:
> Hi,
> 
> * Peter Ujfalusi <peter.ujfalusi at ti.com> [191025 13:05]:
>> McPDM module receives it's functional clock from external source. This
>> clock is the pdmclk provided by the twl6040 audio IC. If the clock is not
>> available all register accesses to McPDM fails and the module is not
>> operational.
>>
>> this has been lurking in my next-wip branch for some time...
>> It might not needed anymore as I have not heard about issues with McPDM for a
>> while.
>>
>> It was dropped back then because some core parts were not picked in time and
>> this caused some issues, but can not find the exact reason
> 
> Yes it's a strange solution to clock the internal mcpdm module
> externally :)

Strange is a bit of understatement ;)

> AFAIK it's now already handled properly by ti-sysc. We have a common
> omap4-mcpdm.dtsi configure mcpdm clock forthe module, then ti-sysc
> driver defers probe until the mcpdm clock is available. And for omap5
> we have omap5-board-common.dtsi configure it.

I see that the

clocks = <&twl6040>;
clock-names = "pdmclk";

are added to the mcpdm node (some patch from me, some new). But the
McPDM driver itself never requests this clock w/o this patch.

> So probably the only thing omap-mcpdm.c driver needs to do is to
> call PM runtime functions, maybe it's already doing that.

Yes, it has support for pm_runtime.

Looking at ti-sci I think I know why it works. ti-sci will get the
'pdmclk' as a clock for the device and going to manage it because the
SYSC_QUIRK_EXT_OPT_CLOCK is set for McPDM.
So pm_runtime is going to handle the clock coming from twl6040.

And now I remember to test these ti-sci changes :o
I wonder why I have not dropped this patch back then from my wip branch.

Let's just ignore this patch.

- Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki