[PATCH v3 5/5] media: qcom: camss: Add support for Hawi

[Hangxiang Ma]

On 11/2/2026 8:58 PM, Bryan O'Donoghue wrote:
> On 30/10/2026 15:25, Hangxiang Ma wrote:
>>> On 30/10/2026 12:43, Nihal Kumar Gupta wrote:
>>>> +static const struct camss_subdev_resources csid_res_hawi[] = {
>>>> +    /* CSID0 */
>>>> +    {
>>>> +        .clock = { "csid", "csid_csiphy_rx" },
>>>> +        .clock_rate = { { 480000000 },
>>>> +                { 480000000 } },
>>>> +        .reg = { "csid0" },
>>>> +        .interrupt = { "csid0" },
>>>> +        .csid = {
>>>> +            .parent_dev_ops = &vfe_parent_dev_ops,
>>>> +            .hw_ops = &csid_ops_1190,
>>>> +            .formats = &csid_formats_gen2
>>>> +        }
>>>
>>> This looks strange, why is there only one clock rate ?
>>>
>>> ---
>>> bod
>> Hi Bryan, the current CAMSS CSID code always selects the first 
>> frequency listed for each clock in the CAMSS resource table.
>>
>> In camss-csid.c:
>>
>> [...]
>> } else if (clock->nfreqs) {
>>          clk_set_rate(clock->clk, clock->freq[0]);
>> }
>> [...]
>>
>> For the CSID and CSID_CSIPHY_RX clocks, the hardware supports three 
>> clock rates: 200 MHz, 300 MHz, and 480 MHz. If I remember correctly, 
>> 200MHz and 300 MHz is not sufficient for the sensor's output pixel 
>> rate, so we need to use the highest rate, 480 MHz, to meet the 
>> bandwidth requirement. Thanks a lot.
>>
>> ---
>> Best Regards,
>> Hangxiang
> 
> We have a series from Antans to address this though.
> 
> We should list the clocks the SoC supports not constrain that list for 
> one specific sensor on a test-case.
> 
> ---
> bod

Good to know that Antans has a series addressing this. I agree that we 
should list all the clock rates supported by the SoC rather than 
constraining them for a specific sensor.

One additional concern: if the clock selection logic still always picks 
freq[0], listing a lower rate first could leave CAMSS unable to work 
properly with sensors that need higher bandwidth.

Could you please share the link to the series? I'll rebase the next 
revision on top of it.

---
Best Regards,
Hangxiang