Re: [PATCH v6 0/7] media: qcom: camss: Add SM8750 support

[Krzysztof Kozlowski <krzk@kernel.org>]

On 22/07/2026 10:02, Hangxiang Ma wrote:
> On 7/22/2026 3:00 PM, Krzysztof Kozlowski wrote:
>> On Tue, Jul 21, 2026 at 05:45:59AM -0700, Hangxiang Ma wrote:
>>> Add support for the RDI only CAMSS camera driver on SM8750. Enabling
>>> RDI path involves adding the support for a set of CSIPHY, CSID and TFE
>>> modules, with each TFE having multiple RDI ports. This hardware
>>> architecture requires 'qdss_debug_xo' clock for CAMNOC to be functional.
>>>
>>> SM8750 camera subsystem provides:
>>> - 6 x CSIPHY (CSI Physical Layer)
>>> - 3 x TPG (Test Pattern Generator)
>>> - 3 x CSID (CSI Decoder)
>>> - 2 x CSID Lite
>>> - 3 x VFE (Video Front End), 5 RDI per VFE
>>> - 2 x VFE Lite, 4 RDI per VFE Lite
>>>
>>> This series has been tested using the following commands with S5KJN5 sensor.
>>> - media-ctl --reset
>>> - media-ctl -V '"msm_csiphy2":0[fmt:SGBRG10/4096x3072]'
>>> - media-ctl -V '"msm_csid0":0[fmt:SGBRG10/4096x3072]'
>>> - media-ctl -V '"msm_vfe0_rdi0":0[fmt:SGBRG10/4096x3072]'
>>> - media-ctl -l '"msm_csiphy2":1->"msm_csid0":0[1]'
>>> - media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
>>> - yavta  --capture=20 -I -n 5 -f SGBRG10P -s 4096x3072 -F  /dev/video0
>>>
>>> Dependencies:
>>> - https://lore.kernel.org/all/20260720-x1e-csi2-phy-v13-0-160c31958863@linaro.org/
>>> - https://lore.kernel.org/all/20260708-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v12-0-f8588da41f16@linaro.org/
>>> - https://lore.kernel.org/all/20260720-kaanapali-camss-v15-0-c0b1c1167c5d@oss.qualcomm.com/
>>
>> None of these were cleared for merging. IOW, all received comments yet
>> you send work which depends on it.
>>
>> This is exactly something Bjorn said a week ago or so. And then a few
>> other maintainers re-iterated. Exactly the same, nothing learnt.
>>
>> Best regards,
>> Krzysztof
>>
> I understand the concern and agree that posting dependent work before 
> the prerequisite series has been fully reviewed and cleared for merging 
> is not ideal. The reason these series were posted at this stage was due 
> to internal planning requirements and the need to keep work on other 

But upstream open-source community does not care about your internal
planning requirements.

Your internal planning is not a valid reason to do anything here.

> dependent platforms moving in parallel. The early review is aim to 

Then why isn't this marked as early review? How early review of
unfinished unmergeable work is supposed to be called? There is very
clear naming required for such work.

> avoiding blocking them too much. That's a dilemma that I was asked to 
> handle it in this way.

Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy