Hi,
On 9/20/23 17:52, Andreas Kemnade wrote:
> Hi,
>
> On Wed, 20 Sep 2023 09:33:53 +0300
> Tony Lindgren <tony@xxxxxxxxxxx> wrote:
>
>> Hi,
>>
>> * Péter Ujfalusi <peter.ujfalusi@xxxxxxxxx> [230919 18:25]:
>>>
>>>
>>> On 7/5/23 22:03, Andreas Kemnade wrote:
>>>> Commit 349355ce3a05 ("ARM: OMAP2+: Drop legacy platform data for omap4 mcbsp")
>>>> dropped prcm_fck for omap4,
>>
>> The prcm_fck should be there in the dts for each mcbsp interconnect targe
>> module as "fck" alias and get's enabled/disabled when the mcbsp driver
>> calls runtime PM.
>>
>> So maybe the description should explain that things broke as the aliases
>> for prcm_fck and pad_ck no longer get added.
>>
>>> it also dropped the pad_fck for that matter.
>>
>> OK so an alias is needed for that too.
>>
>> That's the MCPDM_CLKCTRL pad_clks_ck alias, right? Seems like the
>> pad_clks_ck should be claimed by the mcpdm and mcbsp drivers if they are
>> used? I guess it would be for some external device use case?
>>
>>>> so the clk_src might not be >available making the
>>>> clk_get(src) fail.
>>>
>>> Wow, so OMAP4 audio is pretty broken if would ever need to select FCLK?
>>> By default we don't on OMAP4, but this is astonishing.
>>
>> So sounds like we just got lucky because of -ENOSUCHUSERS? The mcbsp works
>> for me, not sure how come I'm not seeing this issue, does it now only work
>> for the default clock source?
>>
> Well, I did not run into any problems (besides of no sound output)
> as long as I tried to use the codec side as bitclock/frameclock-master and
> that is what droid4 does...
Looks like only omap3 pandora is using external clock source for McBSP,
most OMAP4/5 devices tend to use McPDM and in most cases the McBSP is
not the clock provider, so the clocking does not matter.
It is going to cause issues on new boards, but those are unlikely to
surface.
--
Péter
