| Age | Commit message (Collapse) | Author |
|---|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_get_bridge_by_endpoint().
As of_drm_get_bridge_by_endpoint() returns a refcounted bridge, take care
of putting the bridge reference by using bridge->next_bridge.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-10-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now a panel_bridge is automatically created for every drm_panel and the
panel-bridge API is just a deprecated wrapper to access it.
Update and simplify the code by just getting a reference to the
already-existing bridge using of_drm_get_bridge_by_endpoint().
As of_drm_get_bridge_by_endpoint() returns a refcounted bridge, take care
of putting the bridge reference by using bridge->next_bridge.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-9-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Now that a drm_bridge is embedded into every drm_panel, the panel_bridge is
not needed anymore. Its APIs are just accessing the embedded drm_bridge
transparently.
Deprecate them all, encouraging to use the drm_bridge API.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-7-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
The deprecated devm_drm_put_bridge() function is not used anymore.
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-6-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Adding a drm_panel does currently not add a panel_bridge wrapping
it. Usually the panel_bridge creation happens later, when some other driver
(e.g. the previous bridge or the encoder) calls *_of_get_bridge() and the
following element in the pipeline is a panel.
This has some drawbacks:
* the bridge API is currently the best practice to access various
components of the pipeline, especially with complex cards where bridges
can be combined in different ways on different hardware
* the panel_bridge is not created in the context of the driver of the
underlying physical device (the panel driver), but of some other driver
* that other driver is not aware of whether the returned drm_bridge
pointer is a panel_bridge created on the fly, a pre-existing
panel_bridge or a non-panel bridge
* removal of a panel_bridge requires calling drm_panel_bridge_remove(),
but that other driver doesn't know whether this is needed because it
doesn't know whether it has created a panel_bridge or not
Other drivers call [a variant of] drm_panel_bridge_add(), which also has
some of the above drawbacks.
So far the current approach was working mostly because devm and drmm ensure
the panel bridge would be dealloacted at some later point. However with the
upcoming implementation of bridge hotplug and dynamic bridge lifetime this
won't happen as needed.
Switch to the new approach: embed a drm_bridge inside every drm_panel,
which behaves just like the current drm_panel_bridge. Do this by adapting
the panel_bridge code, doing the minimal adaptations needed.
Currently drm_bridge and drm_panel have independent refcounted
allocation. As they now become a single struct, just change
drm_panel_get/put() to get/put the bridge. As a result, the refcount for a
drm_bridge embedded in a drm_panel is:
bridge.refcount == number of drm_bridge_get() calls
+ number of drm_panel_get() calls
- number of drm_bridge_put() calls
- number of drm_panel_put() calls
Now drivers should progressively stop using the panel_bridge API. Until
that happens, that API becomes now a wrapper to the new embedded
drm_bridge:
* drm_panel_bridge_add() and derivatives don't create a bridge, they
just drm_bridge_get() and return a pointer to the existing one
* drm_panel_bridge_remove() and devm_drm_panel_bridge_release() don't
remove the bridge, they just drm-bridge_put() it
* The other panel_bridge functions stack on those listed in the previous 2
bullets, so their behaviour is changed correspondingly; they include:
- all drm_panel_bridge_add() variants
- their removal counterparts
- *_of_get_bridge().
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-5-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
Work is in progress for every drm_panel to embed a drm_bridge, replacing
the panel_bridge entirely. However most of the panel_bridge code will be
reused for the drm_bridge embedded into the drm_panel, so just move the
code there.
Adapt users of the moved functions to include drm_panel.h when necessary.
No functional changes, just moving code around.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-4-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver stores struct th1520_hdmi * in platform drvdata, but
th1520_dw_hdmi_remove() was reading it back as struct dw_hdmi *
and passing it to dw_hdmi_remove(), so teardown runs on the wrong
pointer.
Retrieve struct th1520_hdmi * from platform drvdata and pass
hdmi->dw_hdmi to dw_hdmi_remove().
Fixes: 96f30ee0fb9d ("drm/bridge: add a driver for T-Head TH1520 HDMI controller")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Link: https://patch.msgid.link/20260321-th1520-v1-2-ec877197770d@gmail.com
|
|
The error check after calling dw_hdmi_probe() was incorrectly checking
the struct pointer hdmi instead of the probe result hdmi->dw_hdmi.
Fix this by checking the correct variable.
Fixes: 96f30ee0fb9d ("drm/bridge: add a driver for T-Head TH1520 HDMI controller")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Link: https://patch.msgid.link/20260321-th1520-v1-1-ec877197770d@gmail.com
|
|
Work is in progress for every drm_panel to embed a drm_bridge, which will
make the drm_panel code (currently in the drm module) depend on the
drm_kms_helper module.
To avoid the main drm module to depend on other drm modules and create a
depepdency loop, move drm_panel.o to a new drm_panel module, so the module
dependency will be drm_panel -> drm_kms_helper instead.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-3-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
We want to move drm_panel.o from the main drm module to a new drm_panel
module, but there is one function in the drm module that calls into
drm_panel.c code:
drm_of_find_panel_or_bridge() (drm_of.c, drm module)
-> calls of_drm_find_panel (drm_panel.c, future drm_panel module)
Avoid this issue by moving drm_of_find_panel_or_bridge() to drm_panel.c.
Update Kconfig symbols of drivers calling drm_of_find_panel_or_bridge() to
select DRM_PANEL when this is not done already.
No functional changes, just moving code around.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260916-drm-bridge-every-panel-v3-1-83afb4f1a707@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver uses devm_drm_of_get_bridge(), which is enabled by
DRM_PANEL_BRIDGE.
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Suggested-by: sashiko-bot@kernel.org
Link: https://lore.kernel.org/all/20260825103234.3F2B71F000E9@smtp.kernel.org/
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-9-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver uses drm_panel_bridge_add_typed() and
drm_panel_bridge_remove(), which are enabled by DRM_PANEL_BRIDGE.
Leave the 'select DRM_PANEL' because it is needed for drm_panel_put() and
drm_panel_enable() which the driver uses.
Cc: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-8-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver uses drm_panel_bridge_add_typed() and
drm_panel_bridge_remove(), which are enabled by DRM_PANEL_BRIDGE.
Leave the 'select DRM_PANEL' because it is needed for drm_panel_put() which
the driver uses.
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-7-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver uses devm_drm_panel_bridge_add(), which is enabled by
DRM_PANEL_BRIDGE.
Leave the 'select DRM_PANEL' because it is needed for drm_panel_put() which
the driver uses.
Cc: Maoyi Xie <maoyixie.tju@gmail.com>
Cc: Andy Yan <andy.yan@rock-chips.com>
Cc: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-6-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver does not use the drm_panel APIs at all, so no need to select
DRM_PANEL.
But it uses devm_drm_of_get_bridge(), which is enabled by DRM_PANEL_BRIDGE.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Michael Walle <mwalle@kernel.org>
Cc: Vinay Simha BN <simhavcs@gmail.com>
Reviewed-by: Michael Walle <mwalle@kernel.org>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-5-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver does not use the drm_panel APIs at all, so no need to select
DRM_PANEL.
But it uses devm_drm_of_get_bridge(), which is enabled by DRM_PANEL_BRIDGE.
Cc: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-4-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver does not use the drm_panel APIs at all, so no need to select
DRM_PANEL.
But it uses devm_drm_of_get_bridge(), which is enabled by DRM_PANEL_BRIDGE.
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-3-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver does not use the drm_panel APIs at all, so no need to select
DRM_PANEL.
But it uses devm_drm_of_get_bridge(), which is enabled by DRM_PANEL_BRIDGE.
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Christopher Vollo <chris@renewoutreach.org>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-2-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
This driver does not use the drm_panel APIs at all, so no need to select
DRM_PANEL.
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Cercueil <paul.cercueil@bootlin.com>
Link: https://patch.msgid.link/20260915-drm-bridge-drm_panel-cleanup-v4-1-30401d9406f3@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
|
|
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Normally if we are under enough memory pressure, the shrinker will
eventually start waiting for BOs to become idle. In some very latency
sensitive use-cases this is undesirable.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/753011/
Message-ID: <20260912145922.24115-2-robin.clark@oss.qualcomm.com>
|
|
More than 2x speedup on darktable benchmark which was bottlenecked on
page allocation/pinning.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/753009/
Message-ID: <20260912145922.24115-1-robin.clark@oss.qualcomm.com>
|
|
A306 and A306A implement only three VBIF XIN halt request bits.
Consequently, waiting for the full 6-bit A3xx mask times out and
prevents runtime suspend.
This issue was reproduced on a DragonBoard 410c: the request reads back
as 0x7 and the acknowledgment as 0x00070007 - the poll eventually
returns -ETIMEDOUT, and a3xx_pm_suspend fails with -EBUSY.
The downstream kgsl driver corroborates this (see link). Since the
single-character difference between A3XX_VBIF_XIN_HALT_CTRL0_MASK and
A30X_VBIF_XIN_HALT_CTRL0_MASK could be confusing to read, the narrowed
GENMASK is instead defined inline in a3xx_vbif_halt().
Fixes: be0e82b8e0c9 ("drm/msm/a3xx: Drain VBIF before GPU suspend")
Link: https://android.googlesource.com/kernel/msm/+/c90c7feeca2f5839ad6824f816c0bd207602a2f4/drivers/gpu/msm/adreno_a3xx.c#637
Assisted-by: LLM
Signed-off-by: Sam Day <me@samcday.com>
Patchwork: https://patchwork.freedesktop.org/patch/756513/
Message-ID: <20260926-a306-vbif-mask-v1-1-2bae5e81c05a@samcday.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
The unwind loop drops the vm_bo reference taken while locking before
advancing to the next entry. drm_gpuvm_bo_put() may drop the last
reference, removing and freeing the vm_bo, after which the plain list
iterator dereferences freed memory to advance.
Use the safe iterator, which saves the next entry before the body runs.
Fixes: fe4952b5f27cca5d ("drm/msm: Convert vm locking")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Patchwork: https://patchwork.freedesktop.org/patch/754331/
Message-ID: <20260916175548.2089821-1-vulab@iscas.ac.cn>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Adreno 845 GPU is present in the Maili SoC. It is very similar to Hawi GPU
(A850), except that it doesn't have a MALU unit. Add the necessary
register lists and a catalog entry to support this GPU.
Signed-off-by: Bhaskar Reddy Valluru <bvalluru@qti.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755606/
Message-ID: <20260923-hawi-gpu-v1-9-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Add HFI support for the GMU THINMEM_CFG feature and provide the
configuration value used by the Adreno 850 GPU in the catalog.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755603/
Message-ID: <20260923-hawi-gpu-v1-8-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Adreno 850 is the next generation of A8x GPU present in Hawi SoC. It shares
the ADRENO_8XX_GEN2 family and slice architecture with A840, but has many
architectural improvements. There is a new block Matrix ALU (MALU) which
helps to accelerate certain compute workloads. Also, there is a new Bx rail
that powers a part of the GPU IP. GMU is now powered by a dedicated GDSC
powered by MxG rail.
Add a new catalog entry along with the necessary register lists and
additional changes to support the aforementioned new features.
Hawi SoC support UBWC v7.0, but GPU is unaffected by this upgrade.
Assisted-by: LLM
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755601/
Message-ID: <20260923-hawi-gpu-v1-7-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
In some chipsets like Hawi, the GPU arc level can exceed the highest
available MX corner. In that case, use the highest non-zero MX vote instead
of failing GMU initialization.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755599/
Message-ID: <20260923-hawi-gpu-v1-6-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Some A8x targets have a third memory rail (BX) in addition to GX and MX.
On these targets the GMU dependency vote carries a per-corner BX vote in
bits 25:20, which otherwise default to all-ones (no BX constraint).
Prepare BX vote field to pass this new voltage recommendation to GMU.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755597/
Message-ID: <20260923-hawi-gpu-v1-5-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
The GMU RPMh vote construction repeats two patterns across
a6xx_gmu_rpmh_arc_votes_init() and a6xx_gmu_rpmh_dep_votes_init():
reading a cmd-db aux-data resource (with the same "halve the byte count
and reject empty" handling), and scanning an arc level array for the
first corner that satisfies a target level.
Refactor out a6xx_gmu_rpmh_read_arc() and a6xx_gmu_rpmh_arc_index() to
reduce code duplication and improve code readability.
Assisted-by: LLM
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755595/
Message-ID: <20260923-hawi-gpu-v1-4-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
a6xx_gmu_rpmh_dep_votes_init() iterates the GPU frequency list
(gmu->gpu_freqs) but was passed gmu->dev to resolve each frequency to an
arc level. This results in generation of incorrect dependency votes
table. To fix this, pass gpu->pdev->dev, which owns the GPU OPP table.
Also, reorder the dependency vote init to improve clarity.
Fixes: 06cfbca0e1c6 ("drm/msm/a6xx: Share dependency vote table with GMU")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755593/
Message-ID: <20260923-hawi-gpu-v1-3-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Using the requested level can pick a secondary corner lower than the one
required to support the chosen primary corner, under-voting the
dependent rail. To fix this, match against the selected primary voltage
instead.
Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755592/
Message-ID: <20260923-hawi-gpu-v1-2-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Instead of voting ACV for all bw corners for A8x GPU, restrict it to BW
votes above the perfmode_bw threshold, similar to the A7x GPUs.
Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support")
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/755589/
Message-ID: <20260923-hawi-gpu-v1-1-0c3c79a1a470@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Add support for Adreno X2-85 GPU present in Mahua SoC. This GPU is a
smaller version of Glymur GPU with fewer slices and smaller internal
memories, but shares the same register layout. Also, the GMU chipid is
different when compared to Glymur's GPU. Add a new catalog entry to
support this GPU.
Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/756256/
Message-ID: <20260925-mahua-gpu-v1-3-0fa0bfd8d315@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
Add the GPU GID to the reported GPU info. This is the 16-byte SHA-1
based identifier GSP-RM reports for the GPU.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-14-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add the short GPU name to the GPU info structure. As with the full name
it is copied from a validated, NUL-terminated string extracted by
nova-core rather than from the raw firmware bytes.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-13-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add the full GPU name to the GPU info structure. The name is copied from
the validated, NUL-terminated string nova-core already extracts from the
GSP static info rather than from the raw firmware bytes.
GpuInfo::new() is deliberately fallible here. A malformed name string
from the GSP is unexpected and is reported to userspace as an error
rather than being silently replaced with an empty name.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-12-apopple@nvidia.com
[ Use ..pin_init::zeroed() instead of ..default::Default(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
nova-drm currently only exposes a primary node even though all of its
ioctls are already marked DRM_RENDER_ALLOW. Set the DRIVER_RENDER
feature so that a render node (/dev/dri/renderDXX) is created as well.
This is required to allow render and compute clients to interact with
nova-drm.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-11-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently nova-drm reads the VRAM BAR size directly from the PCIe device
which requires trying to cast the parent device into a PCIe device. This
obviously requires the parent device to actually be a PCIe bus device.
Whilst that is true today it may not always be the case, and there
is no reason to make this assumption now that NovaCoreApi can hold a
reference to the bound PCIe device.
So convert nova-drm to using nova-core to obtain the VRAM_BAR_SIZE
parameter.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-10-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add a field to the GPU info structure containing the total usable
framebuffer size. The usable framebuffer excludes GSP carveouts and
other protected regions, so it may differ from the BAR size and total
physical VRAM.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-9-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add an extensible info ioctl and use it to report basic GPU information.
One of the first things userspace needs to know about a GPU is its
architecture and which chip it is, so add those as the first fields in
the GPU info result. The chip identifier is opaque to userspace and is
only meaningful when compared against the values of enum
drm_nova_chipid.
The ioctl selects an information type by ID and writes the result through
a sized userspace buffer. The kernel truncates results to the supplied
size, allowing information structures to grow and new logical information
groups to be added without introducing new ioctls. Passing a NULL data
pointer returns the size of the requested information structure instead.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-8-apopple@nvidia.com
[ Avoid 'as' casts (add From<Chipset> for u32, From<Architecture> for
u32 and use IntoSafeCast, IntoSafeCastArch); improve / simplify a few
comments. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The chip identifier uniquely identifies a GPU chip and needs to be
exposed to user-space so it can look up chip specific properties that
cannot be derived from the architecture alone. This adds a public enum
to the userspace headers for each chip ID. Nova-core can then use this
enum to define its chipsets.
The values are opaque to user-space. They may be compared against the
enum to identify a chip but user-space must not assume the values carry
any particular meaning or encoding.
This does create a coupling between nova-drm and nova-core whereby
nova-core depends on the values defined by the user-space API for
nova-drm. However this is entirely appropriate as nova-core must be
bound by the UAPI headers as the enum values are read by nova-core and
passed through to user-space.
Note that nova-core currently refers to the chipid as a chipset. This
isn't ideal given that chipid is the preferred and more accurate term
and is what should be exposed via the uAPI. Therefore a future patch
series will be posted that aligns nova-core internals to using chipid
rather than chipset.
Assisted-by: LLM
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-6-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The GPU architecture to be exposed to user-space. This adds a public
enum to the userspace headers for each chip architecture. Nova-core can
then use this enum to define its architectures.
This does create a coupling between nova-drm and nova-core whereby
nova-core depends on the values defined by the user-space API for
nova-drm. However this is entirely appropriate as nova-core must be
bound by the UAPI headers as the enum values are read by nova-core and
passed through to user-space.
It also requires a minor change to the bounded_enum! macro to match the
architecture values in an expression context.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-5-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently the nova-drm stub driver doesn't really interact with a real
device, so it doesn't have any registration data and has no way to call
into nova-core.
To allow for this add a DrmRegData type which will hold a
NovaCoreApiHandle for the NovaCoreApi associated with the auxbus device.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260909064506.910162-4-apopple@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Nova core will be used to export core functionality to other drivers
which will bind to it via auxiliary bus devices. Add a NovaCoreApi type
which drivers can use to call nova-core methods.
Auxiliary bus drivers obtain a NovaCoreApiHandle for a particular GPU
using NovaCoreApi::of(). This takes a reference to a bound auxiliary bus
device and checks that its registration data is a NovaCoreApi. The
NovaCoreApi itself is then accessed by passing a closure to
NovaCoreApiHandle::with().
Closure based access is used because NovaCoreApi cannot be assumed to be
covariant over its lifetime. It references the Gpu, which will carry
locks around types holding device resources, making it invariant.
Covariant sub-fields can still be returned directly from the closure
thanks to the lifetime bound on registration_data_with().
Signed-off-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260909064506.910162-3-apopple@nvidia.com
[ Rebase and use pin_chain() for Gpu::run_selftests(). - Danilo ]
Co-developed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
BarUser should not use 'gpu as a name for its lifetime; stick to a
generic 'a until we need pin-init selfref for this struct.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
There is no need for a reference count here. BarUserAccess can just
borrow from BarUser.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-4-dakr@kernel.org
[ Update stale comment in run_self_test(). - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Remove the unnecessary Arc around BarUser and get rid of
Result<impl PinInit<T>> in favor of impl PinInit<T, Error>.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-3-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Make Bar1 an alias for a borrowed pci::Bar in order to match the Bar0
type alias.
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260926124405.604707-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add support for the Adreno 830 GPU present in SM8750 SoC. Adreno 830 GPU
belongs to the A8x Gen 1 family and it is architecturally close Adreno 840.
Add a new catalog entry along with the register list to enable support
for this GPU.
Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/745127/
Message-ID: <20260809-pakala-gpu-v1-1-207ad1fac1c7@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
