Re: [PATCH 4/4] media: qcom: camss: Report hardware version via media controller

[Loic Poulain]

On Mon, Jul 20, 2026 at 11:12 AM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 7/17/26 4:20 PM, Loic Poulain wrote:
> > Populate media_dev.hw_revision with the top-level CAMSS hardware version
> > so that user space can query the exact hardware variant through the media
> > controller (e.g. via media-ctl or MEDIA_IOC_DEVICE_INFO). This can help
> > identify the platform variant and adapt behaviour accordingly, for example
> > allowing libcamera to apply quirks or enable features that cannot be
> > discovered through standard V4L2 or media-controller APIs.
>
> [...]
>
> > +static void camss_read_version(struct camss *camss)
> > +{
> > +     u32 hw_version;
> > +
> > +     if (!camss->top_base || !camss->res->pm_clks[0])
> > +             return;
> > +
> > +     if (pm_runtime_resume_and_get(camss->dev))
> > +             return;
> > +
> > +     hw_version = readl_relaxed(camss->top_base + CAMSS_HW_VERSION);
> > +
> > +     pm_runtime_put_sync(camss->dev);
>
> I think non-sync is fine here

Using asynchronous PM may result in the runtime suspend ("work") never
being executed if the probe function fails later (read version called
from probe). From my understanding, a subsequent pm_runtime_disable()
in the error path would cancel the pending suspend request, leaving
the runtime PM state in a non-symmetrical (unbalanced) state.

Regards,
Loic


>
> TOP+0x0 seems to hold on TITAN, MSM8916 and MSM8996
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
>
> Konrad