linux.git/drivers/media/platform/qcom, branch v6.8

media: videobuf2: core: Rename min_buffers_needed field in vb2_queue

2023-12-13T16:31:27+00:00

Rename min_buffers_needed into min_queued_buffers and update
the documentation about it.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Hans Verkuil 
[hverkuil: Drop the change where min_queued_buffers + 1 buffers would be]
[hverkuil: allocated. Now this patch only renames this field instead of making]
[hverkuil: a functional change as well.]
[hverkuil: Renamed 3 remaining min_buffers_needed occurrences.]

media: venus: core: Set up secure memory ranges for SC7280

2023-12-12T07:54:54+00:00

Not all SC7280 devices ship with ChromeOS firmware. Other devices need
PAS for image authentication. That requires the predefined virtual
address ranges to be passed via scm calls. Define them to enable Venus
on non-CrOS SC7280 devices.

Reviewed-by: Konrad Dybcio 
Reviewed-by: Bryan O'Donoghue 
Reviewed-by: Vikash Garodia 
Signed-off-by: Luca Weiss 
Signed-off-by: Stanimir Varbanov 
Signed-off-by: Hans Verkuil

media: qcom: camss: Add sm8250 named power-domain support

2023-12-07T07:31:15+00:00

Declare power-domain names "top", "ife0" and "ife1" eponymously for the
power-domains TITAN_TOP_GDSC, IFE_0_GDSC and IFE_1_GDSC respectively.

Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Hans Verkuil

media: qcom: camss: Flag CSID-lites to support more CSIDs

2023-12-07T07:31:15+00:00

Some platforms such as SC7280 have 3 CSIDs and 2 CSID-lites but current
code has hardcoded 2 as the maximum number of CSIDs. Remove the hardcoded
maximum number of VFEs to handle all possible combinations of CSIDs and
CSID-lites.

Signed-off-by: Matti Lehtimäki 
Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Hans Verkuil

media: qcom: camss: Flag VFE-lites to support more VFEs

2023-12-07T07:31:15+00:00

Some platforms such as SC7280 have three VFEs and two VFE-lites. Current
code has hard-coded two as the maximum number of VFEs. Remove the
hard-coded maximum number of VFEs to handle all possible combinations of
VFEs and VFE-lites.

Signed-off-by: Matti Lehtimäki 
Reviewed-by: Konrad Dybcio 
Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202311200405.h6G4L9oe-lkp@intel.com
Signed-off-by: Bryan O'Donoghue 
Signed-off-by: Hans Verkuil

media: qcom: camss: Add support for named power-domains

2023-12-07T07:31:15+00:00

Right now we use fixed indexes to assign power-domains, with a
requirement for the TOP GDSC to come last in the list.

Adding support for named power-domains means the declaration in the dtsi
can come in any order.

After this change we continue to support the old indexing - if a SoC
resource declaration or the in-use dtb doesn't declare power-domain names
we fall back to the default legacy indexing.

From this point on though new SoC additions should contain named
power-domains, eventually we will drop support for legacy indexing.

Tested-by: Matti Lehtimäki 
Signed-off-by: Bryan O'Donoghue 
Signed-off-by: Hans Verkuil

media: qcom: camss: Move VFE power-domain specifics into vfe.c

2023-12-07T07:31:15+00:00

Moving the location of the hooks to VFE power domains has several
advantages.

1. Separation of concerns and functional decomposition.
   vfe.c should be responsible for and know best how manage
   power-domains for a VFE, excising from camss.c follows this
   principle.

2. Embedding a pointer to genpd in struct camss_vfe{} meas that we can
   dispense with a bunch of kmalloc array inside of camss.c.

3. Splitting up titan top gdsc from vfe/ife gdsc provides a base for
   breaking up magic indexes in dtsi.

Suggested-by: Matti Lehtimäki 
Tested-by: Matti Lehtimäki 
Signed-off-by: Bryan O'Donoghue 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Hans Verkuil

media: qcom: camss: Use common VFE pm_domain_on/pm_domain_off where applicable

2023-12-07T07:31:15+00:00

For the various versions of VFE we have a boiler-plate
pm_domain_on/pm_domain_off callback pair of the general form.

- Error check.
  Not always done but applicable to all.

- device_link_add (DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME |
                   DL_FLAG_RPM_ACTIVE);

- Error check returning -EINVAL on error.

- Return 0

Reduce the pattern down to a common callback. VFE 4.1 is a special case
which to me also indicates that it is worthwhile maintaining an indirection
for the vfe_pm_domain_{on|off} for now.

Otherwise lets chuck out a bunch of needlessly replicated code.

Reviewed-by: Konrad Dybcio 
Suggested-by: Matti Lehtimäki 
Tested-by: Matti Lehtimäki 
Signed-off-by: Bryan O'Donoghue 
Signed-off-by: Hans Verkuil

media: qcom: camss: Convert to per-VFE pointer for power-domain linkages

2023-12-07T07:31:15+00:00

Right now we use the top-level camss structure to provide pointers via
VFE id index back to genpd linkages.

In effect this hard-codes VFE indexes to power-domain indexes in the
dtsi and mandates a very particular ordering of power domains in the
dtsi, which bears no relationship to a real hardware dependency.

As a first step to rationalising the VFE power-domain code and breaking
the magic indexing in dtsi use per-VFE pointers to genpd linkages.

The top-level index in msm_vfe_subdev_init is still used to attain the
initial so no functional or logical change arises from this change.

Reviewed-by: Konrad Dybcio 
Tested-by: Matti Lehtimäki 
Signed-off-by: Bryan O'Donoghue 
Signed-off-by: Hans Verkuil

media: qcom: camss: Flag which VFEs require a power-domain

2023-12-07T07:31:15+00:00

At the moment we have some complex code for determining if a VFE requires a
power-domain attachment. Particularly discordant in this scheme is the
subtle reliance on VFE and VFE Lite declaration ordering in our resources.

VFE id is used to determine if a VFE is lite or not and consequently if a
VFE requires power-domain attachment. VFE Lite though is not a correct
delineation between power-domain and non power-domain state since early
SoCs have neither VFE Lite nor power-domains attached to VFEs.

Introduce has_pd to the VFE resource structure to allow the CAMSS code to
understand if it needs to try to attach a power-domain for a given VFE.

As a side-effect from this we no longer need to care about VFE Lite or
non-Lite or the id number associated with either and which order the
VFE/VFE Lite was declared in.

Reviewed-by: Konrad Dybcio 
Tested-by: Matti Lehtimäki 
Signed-off-by: Bryan O'Donoghue 
Signed-off-by: Hans Verkuil