On Tue 07 Jan 17:38 PST 2020, Rob Clark wrote:
> From: Rob Clark
>
> Since zap firmware can be device specific, allow for a firmware-name
> property in the zap node to specify which firmware to load, similarly to
> the scheme used for dsp/wifi/etc.
>
> Signed-off-by: Rob Clark
> ---
> drivers
On Tue 07 Jan 17:38 PST 2020, Rob Clark wrote:
> From: Rob Clark
>
> The firmware-name property in the zap node can be used to specify a
> device specific zap firmware.
>
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
> ---
> Documentation/devicetree/bindings/display/msm/gpu.txt |
On Tue 07 Jan 17:38 PST 2020, Rob Clark wrote:
> From: Rob Clark
>
> We want to specify per-device firmware-name, so move the zap node into
> the .dts file for individual boards/devices. This lets us get rid of
> the /delete-node/ for cheza, which does not use zap.
>
> Signed-off-by: Rob Clark
From: Rob Clark
For devices which use zap fw to take the GPU out of secure mode on
reset, the firmware is likely to be signed with a device specific key.
Meaning that we can't have a single filesystem (or /lib/firmware) that
works on multiple devices.
So allow a firmware-name to be specified in
From: Rob Clark
We want to specify per-device firmware-name, so move the zap node into
the .dts file for individual boards/devices. This lets us get rid of
the /delete-node/ for cheza, which does not use zap.
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi |
From: Rob Clark
Since zap firmware can be device specific, allow for a firmware-name
property in the zap node to specify which firmware to load, similarly to
the scheme used for dsp/wifi/etc.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 32 ++---
1
From: Rob Clark
The firmware-name property in the zap node can be used to specify a
device specific zap firmware.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/
With the db845c running AOSP, I see the following error on every
frame on the home screen:
[drm:dpu_plane_atomic_check:915] [dpu error]plane33 invalid src
2880x1620+0+470 line:2560
This is due to the error paths in atomic_check using
DPU_ERROR_PLANE(), and the drm_hwcomposer using atomic_check
Add a compatible string to support sc7180 panel version.
Changes in v1:
-Added a compatible string to support sc7180 panel version.
Changes in v2:
-Removed unwanted properties from description.
-Creating source files without execute permissions(Rob Herring).
Signed-off-by:
Add support for Visionox panel driver.
Changes in v1:
-Split out panel driver patch from dsi config changes(Rob Clark).
-Remove unrelated code(Stephen Boyd).
-Remove static arrays to make regulator setup open coded
in probe(Stephen Boyd).
-Remove pre-assigni
Current patchset adds support for rm69299 visionox panel driver used
in MSM reference platforms. The visionox panel driver supports a
resolution of 1080x2248 with 4 lanes and supports only single DSI mode.
Current patchset is tested on actual panel.
Changes in v1:
-add devicetree bindin
Current patchset adds support for rm69299 visionox panel driver used
in MSM reference platforms. The visionox panel driver supports a
resolution of 1080x2248 with 4 lanes and supports only single DSI mode.
Current patchset is tested on actual panel.
Changes in v1:
-add devicetree bindin
Add a compatible string to support sc7180 panel version.
Changes in v1:
-Added a compatible string to support sc7180 panel version.
Changes in v2:
-Removed unwanted properties from description.
-Creating source files without execute permissions(Rob Herring).
Signed-off-by:
Add support for Visionox panel driver.
Changes in v1:
-Split out panel driver patch from dsi config changes(Rob Clark).
-Remove unrelated code(Stephen Boyd).
-Remove static arrays to make regulator setup open coded
in probe(Stephen Boyd).
-Remove pre-assigni
14 matches
Mail list logo
