Re: [PATCH 3/4] clk: qcom: Add Audio Core clock controller support on Qualcomm Shikra SoC

[Imran Shaik <imran.shaik@oss.qualcomm.com>]

On 11-06-2026 04:57 pm, Konrad Dybcio wrote:
> On 6/5/26 1:26 PM, Imran Shaik wrote:
>> Add support for Audio Core Clock Controller (AUDIOCORECC) on Qualcomm
>> Shikra SoC. The  AUDIOCORECC clocks and resets support differs based on
>> Audio subsystem enablement. In the CQM variant, both clocks and resets
>> are required as Audio is on APPS, while in the CQS variant only reset
>> control is required since Audio is handled on Modem. Handle these
>> requirements using variant specific compatibles.
>>
>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>> ---
> 
> [...]
> 
>> +static const struct qcom_reset_map audio_core_cc_shikra_resets[] = {
>> +	[AUDIO_CORE_CSR_RX_SWR_CGCR] = { 0x1c },
>> +	[AUDIO_CORE_CSR_TX_SWR_CGCR] = { 0x30 },
> 

My bad, this also should be controlling the BIT(1) only from SW side, 
similar to existing drivers. I will update in the next series.

> So these are not "real resets", but for the sake of existing art, we
> can keep pretending they are
> 
> bit 1 is HW_CTL (1->hw controlled) and bit 0 is taken into account only
> if 1 is cleared
> 
> existing drivers toggle the HW_CTRL bit (meaning it's an
> maybe-on/surely-on switch rather than off/on).. do we need to rectify
> that somehow?
> 

No changes are needed to the existing logic, as Audio SW only needs to 
control the HW_CTL bit.

By default (PoR), HW_CTL is asserted, so the CGCRs are controlled by 
hardware. For the audio use case, where HW gating isn’t required, 
software de-asserts HW_CTL, after which control shifts to bit 0 (set to 
1 by default).

Thanks,
Imran