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

[Loic Poulain]

On Thu, Jul 9, 2026 at 12:30 AM Bryan O'Donoghue
<bryan.odonoghue@xxxxxxxxxx> wrote:
>
> On 06/07/2026 08:11, Atanas Filipov wrote:
> > From: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
> > Reviewed-by: Loic Poulain <loic.poulain@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Atanas Filipov <atanas.filipov@xxxxxxxxxxxxxxxx>
>
> 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