Re: [PATCH v4 1/5] media: qcom: camss: Populate CAMSS child devices via DT

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 09/07/2026 08:45, Loic Poulain wrote:
> On Thu, Jul 9, 2026 at 12:30 AM Bryan O'Donoghue
> <bryan.odonoghue@linaro.org> wrote:
>>
>> On 06/07/2026 08:11, Atanas Filipov wrote:
>>> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>
>>> Use devm_of_platform_populate() so that child nodes declared under the
>>> CAMSS device tree node (e.g. OPE) are automatically instantiated as
>>> platform devices. This is required now that CAMSS is modelled as a
>>> simple-bus and ISP blocks such as OPE are described as child nodes.
>>>
>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
>>> Signed-off-by: Atanas Filipov <atanas.filipov@oss.qualcomm.com>
>>
>> Looking at my commit logs I see this isn't my commit message ..
>>
>> Anyway.
>>
>>> ---
>>>    drivers/media/platform/qcom/camss/camss.c | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
>>> index 2123f6388e3d..95e655a8b6aa 100644
>>> --- a/drivers/media/platform/qcom/camss/camss.c
>>> +++ b/drivers/media/platform/qcom/camss/camss.c
>>> @@ -16,6 +16,7 @@
>>>    #include <linux/of.h>
>>>    #include <linux/of_device.h>
>>>    #include <linux/of_graph.h>
>>> +#include <linux/of_platform.h>
>>>    #include <linux/pm_runtime.h>
>>>    #include <linux/pm_domain.h>
>>>    #include <linux/slab.h>
>>> @@ -5362,6 +5363,8 @@ static int camss_probe(struct platform_device *pdev)
>>>        if (!camss)
>>>                return -ENOMEM;
>>>
>>> +     devm_of_platform_populate(dev);
>>> +
>>>        camss->res = of_device_get_match_data(dev);
>>>
>>>        atomic_set(&camss->ref_count, 0);
>>
>> Just drop this patch entirely and model JPEG as a peer of CAMSS. I'll do
>> the same with the CSIPHY and Loic the OPE.
>>
>> Modelling for subnodes is nice if you have the idea the camera block
>> should be a bus.
>>
>> But for what reason ? As you pointed out it should be possible to both
>> compile and run JPEG without the compat=camss node on sm8250.
>>
>> Making the camera block a bus is a nice idea for "reasons" as this
>> thread has shown, its a problem to implement with an upside we struggle
>> to define.
>>
>> When the facts change, I change my mind.
>>
>> You were right to argue to have this as a peer node. Lets do that.
> 
> Having a camera-subsystem bus/parent still makes sense, especially
> when dealing with shared resources. Whether that should be the
> existing camss node is indeed the question. Today, camss effectively
> describes only the VFE (including the CSID) and CSIPHY, so using it as
> the subsystem parent would introduce incorrect layering unless the
> node is significantly reworked/broken. So yes, for now, keeping the
> components as peers appears to be the simpler and more scalable
> approach.
> 
> Regards,
> Loic

I would _like_ a bus but the question is how do you mutate the existing 
IFE only node to a bus - without a big bang integration ?

There doesn't seem to be support with colleagues to gradually transition 
so we're best off making individual nodes - why BTW isn't wrong and has 
upsides - like clear separation of JPEG and IFE in this example.

---
bod