Re: [RFC PATCH] ASoC: qcom: q6apm-lpass-dais: start the graph at prepare

[Srinivas Kandagatla]

On 7/10/26 3:32 PM, Jorijn van der Graaf wrote:
> On Wed, Jul 08, 2026 at 11:13:18PM +0100, Srinivas Kandagatla wrote:
>> I guess you are referring to the IBIT clk that dsp provides, not the mclk.
>>
>> Could you not enable this from the machine driver?
> 
> Yes - SEN_MI2S_IBIT, provided by the DSP, not the mclk. And enabling
> it from the machine driver is what I tested with the series you
> point at below:
> 
> On Wed, Jul 08, 2026 at 11:18:50PM +0100, Srinivas Kandagatla wrote:
>>> So for v2 I would keep the two behaviours apart per interface type:
>> This is not going to scale, please try to enable the required clocks
>> from machine driver. Pl take a look at this series
>>
>> https://lore.kernel.org/linux-sound/20260706132009.1496321-1-mohammad.rafi.shaik@xxxxxxxxxxxxxxxx/
> 
> I tested that series (v3) before sending my previous mail -
> the report was buried in a long mail though, so here is the setup
> and result again in a bit more detail. I carried the series onto
> the tree my board runs, described SEN_MI2S_IBIT as the "bclk" of a
> dai@147 subnode per the new binding, and set mi2s_bclk_enable in
> the board data, so the machine driver votes the clock at hw_params.
> The vote itself succeeds - the DSP acks it and clk_summary shows
> the clock prepared and enabled at 1536000 during the stream - but
> the amplifiers' synchronous power-up check at prepare still reports
> "no clocks", and with the graph started at prepare the same codec
> powers up with no bit-clock vote at all. So on this board the bit
> clock only reaches the codec once the graph is started; the PRM
> vote alone does not drive it.
> 
> The question that decides where the fix belongs: is the DSP expected
> to drive IBIT on the pads from the PRM clock request alone, with the
> endpoint's graph not (yet) started?
> 

IBIT clocks should start clocking once we vote for it using prm.
Do you see any errors while enabling this clock?

This week, I will try to pull some wires out and check that on my
hardware too.

--srini
> - If yes, milos firmware behaves differently here and I am happy to
>   debug - any pointer on what to check would help.
> - If no, the machine-driver clock route cannot cover a codec that
>   needs the bit clock during the DAPM power-up sequence, on any
>   AudioReach platform, and some form of start-before-power-up is
>   still needed for such links.