[PATCH v19 08/12] media: qcom: camss: vfe: Add support for VFE 1080
Hangxiang Ma
hangxiang.ma at oss.qualcomm.com
Fri Oct 9 04:36:19 PDT 2026
On 10/9/2026 4:39 PM, Bryan O'Donoghue wrote:
> On 09/10/2026 03:59, Hangxiang Ma wrote:
>>>> diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/
>>>> media/platform/qcom/camss/Makefile
>>>> index 218ba3a95939..42a14e8fe1b7 100644
>>>> --- a/drivers/media/platform/qcom/camss/Makefile
>>>> +++ b/drivers/media/platform/qcom/camss/Makefile
>>>> @@ -26,6 +26,7 @@ qcom-camss-objs += \
>>>> camss-vfe-340.o \
>>>> camss-vfe-480.o \
>>>> camss-vfe-680.o \
>>>> + camss-vfe-1080.o \
>>>
>>> Can't say I'm 1000000% clear on when reg_update() is supposed to
>>> happen in
>>> the flow of the logic you have here.
>>>
>>> I'm a bit suspicious of adding a new flag which skips the update but
>>> assumes some other bit of code executes later and does that update.
>>>
>>> Can you explain this some more please.
>>>
>>
>> Thanks for the review. These points were discussed in an earlier
>> revision, but I should have explained them directly in this version.
>>
>> Vijay once clarified that the configuration principle became more
>> strict since Kaanapali. We can back to <https://lore.kernel.org/
>> all/662a21a3- de8b-406f-a15d-b8a572aa79ab at oss.qualcomm.com/> for more
>> details.
>>
>> In short, the hardware guidance asks to issue the REG_UPDATE after all
>> of the CSID configuration registers are written. Kaanapali seems to
>> have very strict dependency in the hardware about this sequence and
>> with the original sequence, no RUP DONE or BUF DONE events are
>> received at all. While other chipsets can work normally.
>
> But how/where are we saying that happens ?
>
> ---
> bod
Hi Bryan,
When reg_update_after_csid_config is set, vfe_enable_output_v2() loads
the buffers but skips reg_update. The RUP is written later from
csid_configure_stream(), after the RX and RDI configuration.
On stream start:
video_start_streaming()
s_stream(1) on VFE <- walked upstream from video node
vfe_enable_output_v2() <- only load buffers, no reg_update
s_stream(1) on CSID
csid_set_stream()
csid_configure_stream() <- if need_vc_update, else not
program RX config
for each VC:
program RDI and RX VC config
AUP + RUP (__csid_reg_update covers both)
RDI_CTRL start
On this path the VFE reg_update is itself a CSID write, CSID_AUP_CMD
and RUP_SET in csid_subdev_reg_update(), not a VFE register write.
RUP goes in after the configuration writes. Only the RDI_CTRL start
command follows it.
The video streaming function walks the pipeline upstream from the video
node and calls s_stream(1) on each subdev in turn, so the VFE is always
started before the CSID. What isn't obvious is that
vfe_enable_output_v2() depends on that order to get its RUP issued at all.
On Kaanapali, REG_UPDATE has to come after the CSID configuration is
written, otherwise no RUP DONE or BUF DONE is seen. I haven't reproduced
the failure case myself as no BUF_DONE count mismatch and frame missing
events are observed. So I think the information get from hardware
guidance should be reliable. Thanks.
---
Best Regards,
Hangxiang
More information about the linux-phy
mailing list