Skip to content

FROMLIST: media: iris: Add support for glymur platform#1040

Open
bvisredd wants to merge 7 commits intoqualcomm-linux:tech/mm/videofrom
bvisredd:glymur_support
Open

FROMLIST: media: iris: Add support for glymur platform#1040
bvisredd wants to merge 7 commits intoqualcomm-linux:tech/mm/videofrom
bvisredd:glymur_support

Conversation

@bvisredd
Copy link
Copy Markdown

@bvisredd bvisredd commented Apr 29, 2026

Glymur support to enable the Iris video driver on the Glymur platform.

Exception JIRA: https://jira-dc.qualcomm.com/jira/browse/QLIJIRA-109

@qcomlnxci qcomlnxci requested review from a team, dikshita-agarwal and vgarodia and removed request for a team April 29, 2026 06:35
@bvisredd bvisredd changed the title Glymur support FROMLIST: media: iris: Add support for glymur platform Apr 29, 2026
@qcomlnxci qcomlnxci requested a review from a team April 29, 2026 11:08
Vishnu Reddy added 7 commits April 30, 2026 10:18
On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
the number of virtual machines (VMs) and internally adds 1 to it. Writing
1 causes firmware to treat it as 2 VMs. Since only one VM is required,
remove this write to leave the register at its reset value of 0. This does
not affect other platforms as only Glymur firmware uses this register,
earlier platform firmwares ignore it.

Link: https://lore.kernel.org/all/20260428-glymur-v3-1-8f28930f47d3@oss.qualcomm.com/
Fixes: abf5bac ("media: iris: implement the boot sequence of the firmware")
Cc: stable@vger.kernel.org
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Add device tree binding for the Qualcomm Glymur Iris video codec. Glymur
is a new generation of video IP that introduces a dual-core architecture.
The second core brings its own power domain, clocks, and reset lines,
requiring additional power domains and clocks in the power sequence.

To accommodate glymur clock and power resources requirement, the maxItems
constraints in qcom,venus-common.yaml are relaxed. This allows the glymur
binding to inherit from the common venus schema without duplicating shared
properties.

Link: https://lore.kernel.org/all/20260428-glymur-v3-2-8f28930f47d3@oss.qualcomm.com/
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…odec prefix

The current clock and power domain enum names are too generic. Rename
them with a vcodec prefix to make the names more meaningful and to easily
accommodate vcodec1 enums for the secondary core for glymur platform.

No functional changes intended.

Link: https://lore.kernel.org/all/20260428-glymur-v3-7-8f28930f47d3@oss.qualcomm.com/
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
The pmdomain_tbl was a array of strings holding only the power domain
names. Callers had to pass a pd_devs[] pointer indexed directly by the
platform_pm_domain_type enum value to iris_enable_power_domains() and
iris_disable_power_domains().

A future platform may need to introduce a new enum value that aliases
an existing one (e.g. IRIS_VCODEC1_POWER_DOMAIN aliasing the
IRIS_VPP0_HW_POWER_DOMAIN on Glymur), which would break the assumption
that enum values map 1:1 to pd_devs[] indices.

To fix this, replace the string array with a new struct platform_pd_data
that pairs each power domain name with its platform_pm_domain_type. Add
a helper iris_get_pd_index_by_type() that walks this table and returns
the correct pd_devs[] index for a given type.

Update iris_enable_power_domains() and iris_disable_power_domains()
to accept a platform_pm_domain_type instead of a struct device pointer.
They now call the helper internally to resolve the index, removing the
need for callers to do the index lookup themselves.

This prepares the driver for adding new platforms where power domain enum
values cannot be used directly as pd_devs[] indices.

Link: https://lore.kernel.org/all/20260428-glymur-v3-8-8f28930f47d3@oss.qualcomm.com/
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Glymur has a secondary video codec core (vcodec1), equivalent to the
primary core (vcodec0), but with independent power domains, clocks,
and reset lines. Reuse the existing code wherever possible and add
power sequence for vcodec1.

Link: https://lore.kernel.org/all/20260428-glymur-v3-9-8f28930f47d3@oss.qualcomm.com/
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…orms

On platforms with dual vcodec cores, select the hardware core for a
session based on current load. Assign the session to vcodec0 if its
MBPF/MBPS capacity allows it, otherwise assign to vcodec1. Communicate
the selected core to firmware using the new HFI_PROP_CORE_ID property.

Link: https://lore.kernel.org/all/20260428-glymur-v3-10-8f28930f47d3@oss.qualcomm.com/
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
On glymur platform, the iris core shares most properties with the
iris core on the SM8550 platform. The major difference is that glymur
integrates two codec cores (vcodec0 and vcodec1), while SM8550 has only
one. Add glymur specific platform data, reusing SM8550 definitions
wherever applicable.

Link: https://lore.kernel.org/all/20260428-glymur-v3-11-8f28930f47d3@oss.qualcomm.com/
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant