[git pull] drm fixes for 6.8-rc5
Hi Linus, Regular weekly fixes, nothing too major, mostly amdgpu, then i915, xe, msm and nouveau with some scattered bits elsewhere. Dave. drm-fixes-2024-02-16: drm fixes for 6.8-rc5 crtc: - fix uninit variable prime: - support > 4GB page arrays buddy: - fix error handling in allocations i915: - fix blankscreen on JSL chromebooks - stable fix to limit DP sst link rates xe: - Fix an out-of-bounds shift. - Fix the display code thinking xe uses shmem - Fix a warning about index out-of-bound - Fix a clang-16 compilation warning amdgpu: - PSR fixes - Suspend/resume fixes - Link training fix - Aspect ratio fix - DCN 3.5 fixes - VCN 4.x fix - GFX 11 fix - Misc display fixes - Misc small fixes amdkfd: - Cache size reporting fix - SIMD distribution fix msm: - GPU: - dmabuf vmap fix - a610 UBWC corruption fix (incorrect hbb) - revert a commit that was making GPU recovery unreliable - tlb invalidation fix ivpu: - suspend/resume fix nouveau: - fix scheduler cleanup path - fix pointless scheduler creation - fix kvalloc argument order rockchip: - vop2 locking fix The following changes since commit 841c35169323cd833294798e58b9bf63fa4fa1de: Linux 6.8-rc4 (2024-02-11 12:18:13 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2024-02-16 for you to fetch changes up to ea69f782d0e37d9658d4b7df241661e651c43af5: Merge tag 'drm-msm-fixes-2024-02-15' of https://gitlab.freedesktop.org/drm/msm into drm-fixes (2024-02-16 15:47:15 +1000) drm fixes for 6.8-rc5 crtc: - fix uninit variable prime: - support > 4GB page arrays buddy: - fix error handling in allocations i915: - fix blankscreen on JSL chromebooks - stable fix to limit DP sst link rates xe: - Fix an out-of-bounds shift. - Fix the display code thinking xe uses shmem - Fix a warning about index out-of-bound - Fix a clang-16 compilation warning amdgpu: - PSR fixes - Suspend/resume fixes - Link training fix - Aspect ratio fix - DCN 3.5 fixes - VCN 4.x fix - GFX 11 fix - Misc display fixes - Misc small fixes amdkfd: - Cache size reporting fix - SIMD distribution fix msm: - GPU: - dmabuf vmap fix - a610 UBWC corruption fix (incorrect hbb) - revert a commit that was making GPU recovery unreliable - tlb invalidation fix ivpu: - suspend/resume fix nouveau: - fix scheduler cleanup path - fix pointless scheduler creation - fix kvalloc argument order rockchip: - vop2 locking fix Arnd Bergmann (2): nouveau/svm: fix kvcalloc() argument order drm/xe: avoid function cast warnings Arunpravin Paneer Selvam (1): drm/buddy: Fix alloc_range() error handling code Dan Carpenter (1): drm/amd/display: Fix && vs || typos Danilo Krummrich (2): drm/nouveau: don't fini scheduler if not initialized drm/nouveau: omit to create schedulers using the legacy uAPI Dave Airlie (5): Merge tag 'drm-misc-fixes-2024-02-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2024-02-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-xe-fixes-2024-02-15' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Merge tag 'amd-drm-fixes-6.8-2024-02-15-2' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-msm-fixes-2024-02-15' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Dmitry Baryshkov (1): drm/msm/a6xx: set highest_bank_bit to 13 for a610 Hamza Mahfooz (1): drm/amdgpu: make damage clips support configurable Harshit Mogalapalli (1): drm/rockchip: vop2: add a missing unlock in vop2_crtc_atomic_enable() Jacek Lawrynowicz (1): accel/ivpu: Fix DevTLB errors on suspend/resume and recovery Kent Russell (1): drm/amdkfd: Fix L2 cache size reporting in GFX9.4.3 Manasi Navare (1): drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg address Mario Limonciello (2): drm/amd: Stop evicting resources on APUs in suspend Revert "drm/amd: flush any delayed gfxoff on suspend entry" Matthew Auld (2): drm/tests/drm_buddy: add alloc_contiguous test drm/xe/display: fix i915_gem_object_is_shmem() wrapper Nicholas Kazlauskas (1): drm/amd/display: Increase ips2_eval delay for DCN35 Philip Yang (1): drm/prime: Support page array >= 4GB Rajneesh Bhardwaj (2): drm/amdkfd: update SIMD distribution algo for GFXIP 9.4.2 onwards drm/amdgpu: Fix implicit assumtion in gfx11 debug flags Rob Clark (4): drm/msm/gem: Fix double resv lock aquire Revert "drm/msm/gpu: Push gpu lock down past runpm" drm/crtc: fix uninitialized variable use even harder drm/msm: Wire up tlb ops Roman Li (1): drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr Sohaib Nadeem (2): Revert "drm/amd/display: increased min_dcfclk_mhz and
Re: [PATCH v13 4/7] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
Hi Sandor,
thanks for the update.
Am Sonntag, 4. Februar 2024, 11:21:49 CET schrieb Sandor Yu:
> Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
> used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
> standards according embedded Firmware running in the uCPU.
>
> For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
> SOC's ROM code. Bootload binary included respective specific firmware
> is required.
>
> Driver will check display connector type and
> then load the corresponding driver.
>
> Signed-off-by: Sandor Yu
> Tested-by: Alexander Stein
> ---
> v12->v13:
> - Explicitly include linux/platform_device.h for cdns-mhdp8501-core.c
> - Fix build warning
> - Order bit bpc and color_space in descending shit.
>
> v11->v12:
> - Replace DRM_INFO with dev_info or dev_warn.
> - Replace DRM_ERROR with dev_err.
> - Return ret when cdns_mhdp_dpcd_read failed in function
> cdns_dp_aux_transferi(). - Remove unused parmeter in function
> cdns_dp_get_msa_misc
> and use two separate variables for color space and bpc.
> - Add year 2024 to copyright.
>
> drivers/gpu/drm/bridge/cadence/Kconfig| 16 +
> drivers/gpu/drm/bridge/cadence/Makefile | 2 +
> .../drm/bridge/cadence/cdns-mhdp8501-core.c | 316
> .../drm/bridge/cadence/cdns-mhdp8501-core.h | 365 +
> .../gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c | 699 ++
> .../drm/bridge/cadence/cdns-mhdp8501-hdmi.c | 679 +
> 6 files changed, 2077 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.h
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
>
> [snip]
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c new file mode 100644
> index 0..0117cddb85694
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
> @@ -0,0 +1,699 @@
> [snip]
> +
> +const struct drm_bridge_funcs cdns_dp_bridge_funcs = {
> + .attach = cdns_dp_bridge_attach,
> + .detect = cdns_dp_bridge_detect,
> + .get_edid = cdns_dp_bridge_get_edid,
Please note that with commits d807ad80d811b ("drm/bridge: add ->edid_read hook
and drm_bridge_edid_read()") and 27b8f91c08d99 ("drm/bridge: remove ->get_edid
callback") the API has slightly changed meanwhile.
> + .mode_valid = cdns_dp_bridge_mode_valid,
> + .atomic_enable = cdns_dp_bridge_atomic_enable,
> + .atomic_disable = cdns_dp_bridge_atomic_disable,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> +};
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c new file mode 100644
> index 0..e6ed13b9f9ca3
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
> @@ -0,0 +1,679 @@
> [snip]
> +
> +const struct drm_bridge_funcs cdns_hdmi_bridge_funcs = {
> + .attach = cdns_hdmi_bridge_attach,
> + .detect = cdns_hdmi_bridge_detect,
> + .get_edid = cdns_hdmi_bridge_get_edid,
Please note that with commits d807ad80d811b ("drm/bridge: add ->edid_read hook
and drm_bridge_edid_read()") and 27b8f91c08d99 ("drm/bridge: remove ->get_edid
callback") the API has slightly changed meanwhile.
> + .mode_valid = cdns_hdmi_bridge_mode_valid,
> + .mode_fixup = cdns_hdmi_bridge_mode_fixup,
> + .atomic_enable = cdns_hdmi_bridge_atomic_enable,
> + .atomic_disable = cdns_hdmi_bridge_atomic_disable,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> +};
Please rebase your patch series, thanks.
Best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
[PATCH] drm/amd/display: fix a possible NULL dereference bug
Smatch warns:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:136
dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced
before check 'dc_dmub_srv' (see line 131)
Fix this by moving the dereference "dc_dmub_srv->ctx" after the NULL check.
Fixes: 028bac583449 ("drm/amd/display: decouple dmcub execution to reduce lock
granularity")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Closes: https://lore.kernel.org/r/202311141141.golapxd5-...@intel.com/
Signed-off-by: Harshit Mogalapalli
---
Only compile tested
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index 0bc32537e2eb..a4bd46ec6da4 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -128,7 +128,7 @@ bool dc_dmub_srv_cmd_list_queue_execute(struct dc_dmub_srv
*dc_dmub_srv,
unsigned int count,
union dmub_rb_cmd *cmd_list)
{
- struct dc_context *dc_ctx = dc_dmub_srv->ctx;
+ struct dc_context *dc_ctx;
struct dmub_srv *dmub;
enum dmub_status status;
int i;
@@ -136,6 +136,7 @@ bool dc_dmub_srv_cmd_list_queue_execute(struct dc_dmub_srv
*dc_dmub_srv,
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
return false;
+ dc_ctx = dc_dmub_srv->ctx;
dmub = dc_dmub_srv->dmub;
for (i = 0 ; i < count; i++) {
--
2.39.3
[PATCH v5 3/4] arm64: dts: ti: Add common1 register space for AM62x SoC
This adds common1 register space for AM62x SoC which is using TI's Keystone
display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
Fixes: 8ccc1073c7bb ("arm64: dts: ti: k3-am62-main: Add node for DSS")
Signed-off-by: Devarsh Thakkar
---
V1->V4 :
- No change (this was part of "arm64: dts: ti: Add common1 register
space for AM62x, AM62A & AM65x SoCs )
V5 :
- Split this as a separate patch from "arm64: dts: ti: Add common1
register space for AM62x, AM62A & AM65x SoCs"
- Remove Reviewed-By tag as patch is split now
---
arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index fe0cc4a9a501..8cee4d94cdd3 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -779,9 +779,10 @@ dss: dss@3020 {
<0x00 0x30207000 0x00 0x1000>, /* ovr1 */
<0x00 0x30208000 0x00 0x1000>, /* ovr2 */
<0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */
- <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */
+ <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI Out */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
reg-names = "common", "vidl1", "vid",
- "ovr1", "ovr2", "vp1", "vp2";
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
power-domains = <_pds 186 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 186 6>,
<_vp1_clk>,
--
2.34.1
[PATCH v5 1/4] dt-bindings: display: ti, am65x-dss: Add support for common1 region
TI keystone display subsystem present in AM65, AM62 and AM62A SoC support
two separate register spaces namely "common" and "common1" which can be
used by two separate hosts to program the display controller as described
in respective Technical Reference Manuals [1].
The common1 register space has similar set of configuration registers as
supported in common register space except the global configuration
registers which are exclusive to common region.
This adds binding for "common1" register region too as supported by the
hardware.
[1]:
AM62x TRM:
https://www.ti.com/lit/pdf/spruiv7 (Section 14.8.9.1 DSS Registers)
AM65x TRM:
https://www.ti.com/lit/pdf/spruid7 (Section 12.6.5 DSS Registers)
AM62A TRM:
https://www.ti.com/lit/pdf/spruj16 (Section 14.9.9 Display Subsystem Registers)
Fixes: 2d8730f1021f ("dt-bindings: display: ti,am65x-dss: Add dt-schema yaml
binding")
Signed-off-by: Devarsh Thakkar
Reviewed-by: Aradhya Bhatia
Acked-by: Conor Dooley
---
V2: Add Acked-by tag
V3: Add Fixes tag
V4: Add Reviewed-by and AM62A TRM link
V5: No change
---
.../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index b6767ef0d24d..55e3e490d0e6 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -37,6 +37,7 @@ properties:
- description: OVR2 overlay manager for vp2
- description: VP1 video port 1
- description: VP2 video port 2
+ - description: common1 DSS register area
reg-names:
items:
@@ -47,6 +48,7 @@ properties:
- const: ovr2
- const: vp1
- const: vp2
+ - const: common1
clocks:
items:
@@ -147,9 +149,10 @@ examples:
<0x04a07000 0x1000>, /* ovr1 */
<0x04a08000 0x1000>, /* ovr2 */
<0x04a0a000 0x1000>, /* vp1 */
-<0x04a0b000 0x1000>; /* vp2 */
+<0x04a0b000 0x1000>, /* vp2 */
+<0x04a01000 0x1000>; /* common1 */
reg-names = "common", "vidl1", "vid",
-"ovr1", "ovr2", "vp1", "vp2";
+"ovr1", "ovr2", "vp1", "vp2", "common1";
ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
power-domains = <_pds 67 TI_SCI_PD_EXCLUSIVE>;
clocks =<_clks 67 1>,
--
2.34.1
[PATCH v5 2/4] arm64: dts: ti: Add common1 register space for AM65x SoC
This adds common1 register space for AM65x SoC which is using TI's Keystone
display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
Signed-off-by: Devarsh Thakkar
---
V1->V4 :
- No change (this was part of "arm64: dts: ti: Add common1 register
space for AM62x, AM62A & AM65x SoCs )
V5 :
- Split this as a separate patch from "arm64: dts: ti: Add common1
register space for AM62x, AM62A & AM65x SoCs"
- Remove Reviewed-By tag as patch is split now
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 07010d31350e..ff857117d719 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -991,9 +991,10 @@ dss: dss@4a0 {
<0x0 0x04a07000 0x0 0x1000>, /* ovr1 */
<0x0 0x04a08000 0x0 0x1000>, /* ovr2 */
<0x0 0x04a0a000 0x0 0x1000>, /* vp1 */
- <0x0 0x04a0b000 0x0 0x1000>; /* vp2 */
+ <0x0 0x04a0b000 0x0 0x1000>, /* vp2 */
+ <0x0 0x04a01000 0x0 0x1000>; /* common1 */
reg-names = "common", "vidl1", "vid",
- "ovr1", "ovr2", "vp1", "vp2";
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
--
2.34.1
[PATCH v5 0/4] Add common1 region for AM62, AM62A & AM65x
This adds DSS common1 region for respective SoCs supporting it. Changelog: V2 : Remove do-not-merge tag and add am62a dss common1 reion V3 : Add Fixes tag to each commit V4 : Add Reviewed-by tag and AM62A SoC TRM Link V5 : Split dts patch to separate patches for each SoC Devarsh Thakkar (4): dt-bindings: display: ti,am65x-dss: Add support for common1 region arm64: dts: ti: Add common1 register space for AM65x SoC arm64: dts: ti: Add common1 register space for AM62x SoC arm64: dts: ti: Add common1 register space for AM62A SoC .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 7 +-- arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++-- arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 5 +++-- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++-- 4 files changed, 14 insertions(+), 8 deletions(-) -- 2.34.1
[PATCH v5 4/4] arm64: dts: ti: Add common1 register space for AM62A SoC
This adds common1 register space for AM62A SoC which is using TI's Keystone
display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
Fixes: 3618811657b3 ("arm64: dts: ti: k3-am62a-main: Add node for Display
SubSystem (DSS)")
Signed-off-by: Devarsh Thakkar
---
V1->V4 :
- No change (this was part of "arm64: dts: ti: Add common1 register
space for AM62x, AM62A & AM65x SoCs )
V5 :
- Split this as a separate patch from "arm64: dts: ti: Add common1
register space for AM62x, AM62A & AM65x SoCs"
- Remove Reviewed-By tag as this is split from older revision
---
arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index 2749533cf4fd..dbdd6bec4667 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -994,9 +994,10 @@ dss: dss@3020 {
<0x00 0x30207000 0x00 0x1000>, /* ovr1 */
<0x00 0x30208000 0x00 0x1000>, /* ovr2 */
<0x00 0x3020a000 0x00 0x1000>, /* vp1: Tied OFF in the
SoC */
- <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */
+ <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI Out */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
reg-names = "common", "vidl1", "vid",
- "ovr1", "ovr2", "vp1", "vp2";
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
power-domains = <_pds 186 TI_SCI_PD_EXCLUSIVE>;
clocks = <_clks 186 6>,
<_clks 186 0>,
--
2.34.1
Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
Hi Mario, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.8-rc4 next-20240215] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_ATY128-0-0 (https://download.01.org/0day-ci/archive/20240216/202402161205.v9d7iypg-...@intel.com/config) reproduce: (https://download.01.org/0day-ci/archive/20240216/202402161205.v9d7iypg-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202402161205.v9d7iypg-...@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when >> selected by FB_ATY128 .config:233:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY .config:335:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK .config:336:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON .config:437:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL .config:511:warning: symbol value 'n' invalid for INPUT_MOUSEDEV_SCREEN_Y .config:613:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN .config:620:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN .config:705:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE .config:719:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET .config:766:warning: symbol value 'n' invalid for XEN_MEMORY_HOTPLUG_LIMIT .config:774:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA .config:791:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT .config:825:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE .config:840:warning: symbol value 'n' invalid for DRM_I915_MAX_REQUEST_BUSYWAIT .config:871:warning: symbol value 'n' invalid for USB_GADGET_STORAGE_NUM_BUFFERS .config:875:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE .config:894:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN .config:903:warning: symbol value 'n' invalid for NET_EMATCH_STACK .config:905:warning: symbol value 'n' invalid for VMCP_CMA_SIZE .config:1160:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE .config:1246:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS .config:1287:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E .config:1411:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT .config:1517:warning: symbol value 'n' invalid for SERIAL_ALTERA_UART_BAUDRATE .config:1543:warning: symbol value 'n' invalid for WATCHDOG_OPEN_TIMEOUT .config:1547:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS .config:1739:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT .config:1833:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT .config:1972:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE .config:2263:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX .config:2304:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH .config:2383:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS .config:2500:warning: symbol value 'n' invalid for SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM .config:2535:warning: symbol value 'n' invalid for PANEL_PARPORT .config:2622:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT .config:2808:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS .config:2904:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE .config:2906:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT .config:2928:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL .config:2945:warning: symbol value 'n' invalid for DEBUG_OBJECTS_ENABLE_DEFAULT .config:2952:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID .config:3033:warning: symbol value 'n' invalid for MTD_REDBOOT_DIRECTORY_BLOCK .config:3058:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY .config:3075:warning: symbol value 'n' invalid for BOOKE_WDT_DEFAULT_TIMEOUT .config:3098:warning: symbol value 'n' invalid for FB_OMAP2_DSS_MIN_FCK_PER_PCK .config:3339:warning: symbol
RE: [RFC 0/5] Introduce drm sharpening property
It is not intel specific and the goal is to have a generic API for configuring Sharpness, accessible to various vendors. Intel currently offers sharpness support through the Display Engine, while other vendors seem to support Sharpness through the GPU using GL shaders (Vulcan/Open GL based). In terms of sharpness intensity adjustment, the plan is to provide users with the ability to customize and regulate sharpness levels. We suggest setting a minimum and maximum strength range from 1 to 255, where a value of 0 signifies that the sharpness feature is disabled, indicated by a u8 data type. For now we have mapped the strength value 0.0 to 14.9375 to 0-239 but as the datatype is u8 user can give value upto 255 which is gets clamped to 239. We are also open to have alternative scales, such as 1-100 or 1-10, as long as a general consensus is reached within the community comprising OEMs and vendors. > -Original Message- > From: Simon Ser > Sent: Thursday, February 15, 2024 2:03 PM > To: Garg, Nemesa > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: Re: [RFC 0/5] Introduce drm sharpening property > > How much of this is Intel-specific? Are there any hardware vendors with a > similar > feature? How much is the "sharpness" knob tied to Intel hardware?
Re: [PULL] drm-intel-gt-next
On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin wrote: > > Hi Dave, Daniel, > > First pull request for 6.9 with probably one more coming in one to two > weeks. > > Nothing to interesting in this one, mostly a sprinkle of small fixes in > GuC, HuC, Perf/OA, a tiny bit of prep work for future platforms and some > code cleanups. > > One new uapi in the form of a GuC submission version query which Mesa > wants for implementing Vulkan async compute queues. > > Regards, > > Tvrtko > > drm-intel-gt-next-2024-02-15: > UAPI Changes: > > - Add GuC submission interface version query (Tvrtko Ursulin) > > Driver Changes: > > Fixes/improvements/new stuff: > > - Atomically invalidate userptr on mmu-notifier (Jonathan Cavitt) I've pulled this, but the above patch is triggering my this seems wrong spider sense. This and probably the preceeding patch that this references seem to move i915 to a long term pinning of userptr in memory with what I can see no accounting, and away from what the desired behaviour for drivers should be. It also feels like the authorship on this might be lies which also worries me. Dave.
Re: [PATCH v5 08/13] drm/mediatek: Support alpha blending in OVL
Re: [PATCH v5 10/13] drm/mediatek: Support CRC in display driver
Re: [PATCH v5 06/13] drm/mediatek: Turn off the layers with zero width or height
Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
Hi Mario, kernel test robot noticed the following build errors: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.8-rc4 next-20240215] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers config: nios2-randconfig-r061-20240215 (https://download.01.org/0day-ci/archive/20240216/202402160847.fdgskgjp-...@intel.com/config) compiler: nios2-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240216/202402160847.fdgskgjp-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202402160847.fdgskgjp-...@intel.com/ All errors (new ones prefixed by >>): nios2-linux-ld: drivers/video/fbdev/ssd1307fb.o: in function `ssd1307fb_remove': ssd1307fb.c:(.text+0x40c): undefined reference to `backlight_device_unregister' >> ssd1307fb.c:(.text+0x40c): relocation truncated to fit: R_NIOS2_CALL26 >> against `backlight_device_unregister' nios2-linux-ld: drivers/video/fbdev/ssd1307fb.o: in function `ssd1307fb_probe': ssd1307fb.c:(.text+0x1d98): undefined reference to `backlight_device_register' >> ssd1307fb.c:(.text+0x1d98): relocation truncated to fit: R_NIOS2_CALL26 >> against `backlight_device_register' Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for FB_BACKLIGHT Depends on [n]: HAS_IOMEM [=y] && FB [=y] && BACKLIGHT_CLASS_DEVICE [=n] Selected by [y]: - FB_SSD1307 [=y] && HAS_IOMEM [=y] && FB [=y] && I2C [=y] && (GPIOLIB [=y] || COMPILE_TEST [=y]) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
Hi Mario, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.8-rc4 next-20240215] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_ATY-0-0 (https://download.01.org/0day-ci/archive/20240216/202402160822.2b7vxnn3-...@intel.com/config) reproduce: (https://download.01.org/0day-ci/archive/20240216/202402160822.2b7vxnn3-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202402160822.2b7vxnn3-...@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when >> selected by FB_ATY .config:163:warning: symbol value 'n' invalid for USB_GADGET_STORAGE_NUM_BUFFERS .config:241:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY .config:343:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON .config:432:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL .config:572:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E .config:596:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK .config:616:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN .config:629:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN .config:738:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET .config:794:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT .config:852:warning: symbol value 'n' invalid for DRM_I915_MAX_REQUEST_BUSYWAIT .config:887:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE .config:902:warning: symbol value 'n' invalid for SERIAL_AR933X_NR_UARTS .config:903:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN .config:911:warning: symbol value 'n' invalid for NET_EMATCH_STACK .config:913:warning: symbol value 'n' invalid for VMCP_CMA_SIZE .config:986:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE .config:1048:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA .config:1170:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE .config:1270:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS .config:1434:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT .config:1578:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS .config:1614:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS .config:1753:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT .config:1867:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT .config:2174:warning: symbol value 'n' invalid for RCU_FANOUT_LEAF .config:2220:warning: symbol value 'n' invalid for MTD_REDBOOT_DIRECTORY_BLOCK .config:2308:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX .config:2320:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH .config:2339:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE .config:2559:warning: symbol value 'n' invalid for PANEL_PARPORT .config:2646:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT .config:2838:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS .config:2936:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT .config:2958:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL .config:2971:warning: symbol value 'n' invalid for SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM .config:2976:warning: symbol value 'n' invalid for DEBUG_OBJECTS_ENABLE_DEFAULT .config:2984:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID .config:3090:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY .config:3124:warning: symbol value 'n' invalid for FB_OMAP2_DSS_MIN_FCK_PER_PCK .config:3301:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE .config:3393:warning: symbol value 'n' invalid for FTRACE_RECORD_RECURSION_SIZE .config:3415:warning: symbol value 'n' invalid for KCSAN_UDELAY_TASK .config:3448:warning: symbol value 'n' invalid for BOOKE_WDT_DEFAULT_TIMEOUT .config:3468:warning: symbol value 'n' invalid for MMC_BLOCK_MINORS .config:3472:warning: symbol value 'n' invalid for INET_TABLE_PERTUR
Re: linux-next: Tree for Feb 15 (drivers/gpu/drm/tests/drm_buddy_test.o)
On 2/14/24 19:52, Stephen Rothwell wrote: > Hi all, > > Changes since 20240214: > on i386: ld: drivers/gpu/drm/tests/drm_buddy_test.o: in function `drm_test_buddy_alloc_contiguous': /work/lnx/next/linux-next-20240215/X32/../drivers/gpu/drm/tests/drm_buddy_test.c:48:(.text+0x94): undefined reference to `__umoddi3' Full randconfig file is attached. -- #Randy config-r7122.gz Description: application/gzip
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Thu, Feb 15, 2024 at 11:22 AM Adam Ford wrote:
>
> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
> >
> > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > wrote:
> > >
> > > Hi Maxime,
> > >
> > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > > proprietary firmware image, which is currently only available for
> > > > > Texas
> > > > > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > > > > prevent asking the user about this driver when configuring a kernel
> > > > > without Texas Instruments K3 Multicore SoC support.
> > > >
> > > > This wasn't making sense the first time you sent it, and now that commit
> > > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> > >
> > > I am so happy to be proven wrong!
> > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> > >
> > > > architectures and 5 platforms. In two months.
> > >
> > > That sounds like great progress, thanks a lot!
> > >
> > Geert,
> >
> > > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > > but the original K3 AM62x one.
> >
> > I think PowerVR has a repo [1], but the last time I checked it, the
> > BVNC for the firmware didn't match what was necessary for the GX6250
> > on the RZ/G2M. I can't remember what the corresponding R-Car3 model
> > is. I haven't tried recently because I was told more documentation
> > for firmware porting would be delayed until everything was pushed into
> > the kernel and Mesa. Maybe there is a better repo and/or newer
> > firmware somewhere else.
> >
> I should have doubled checked the repo contents before I sent my last
> e-mail , but it appears the firmware [2] for the RZ/G2M, might be
> present now. I don't know if there are driver updates necessary. I
> checked my e-mails, but I didn't see any notification, or I would have
> tried it earlier. Either way, thank you Frank for adding it. I'll
> try to test when I have some time.
>
I don't have the proper version of Mesa setup yet, but for what it's
worth, the firmware loads without error, and it doesn't hang.
[9.787836] powervr fd00.gpu: [drm] loaded firmware
powervr/rogue_4.45.2.58_v1.fw
[9.787861] powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
adam
> > adam
> >
> > [1]
> > https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
>
> [2] -
> https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
>
> >
> >
> > >
> > > Thanks again!
> > >
> > > [1]
> > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> > >
> > > Gr{oetje,eeting}s,
> > >
> > > Geert
> > >
> > > --
> > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > > ge...@linux-m68k.org
> > >
> > > In personal conversations with technical people, I call myself a hacker.
> > > But
> > > when I'm talking to journalists I just say "programmer" or something like
> > > that.
> > > -- Linus Torvalds
Re: [PATCH 2/2] drm/i915/gt: Set default CCS mode '1'
On 2/15/2024 14:34, Andi Shyti wrote:
Hi John,
On Thu, Feb 15, 2024 at 01:23:24PM -0800, John Harrison wrote:
On 2/15/2024 05:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS rather than the
actual number. As of now, this change affects only DG2.
These two paragraphs are mutually exclusive. You can't have four CCS engines
'working together' if only one engine exists. I think you are meaning that
we only export 1 CCS engine and that single engine is configured to control
all the EUs. As opposed to running in 4 CCS engine mode where the EUs are
(dynamically or statically) divided amongst those four engines.
The balancing is done statically. The dynamic balancing is
disabled in patch 1.
The 2 or 4 CCS engines will share the same workload.
But they don't.
In i915, we use 'engine' to refer to a command streamer and all the
associated hardware. This is distinct from the EUs which sit behind and
can be driven by one or more command streamers. Saying that multiple
engines are sharing a workload implies that you are submitting the
context to multiple command streamers in parallel. I.e. a similar
process to media frame split where they have a set of LRCA contexts
bound together which are submitted in parallel to two or more video
decode engines (VCS0, VCS1, etc.). That is not what is happening here.
Here, you are submitting a single context with a singe ring buffer to a
single engine - CCS0. That engine is configured to own all EUs. Which
actually means that submitting a compute task to another CCS engine will
achieve nothing because there are no EUs available to those other
engines. They will simply hang when waiting for the walker instruction
to complete.
Because the user won't be able anymore to select the CCS engine
he wants to use, he will see only one CCS.
I think we are saying the same thing using different words :)
But words are important.
John.
I can try in v2 to reword the commit better.
Thanks for looking into this.
Andi
John.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: # v6.2+
---
drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 17 +
drivers/gpu/drm/i915/i915_query.c | 5 +++--
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a425db5ed3a2..e19df4ef47f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
}
}
+static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
+{
+ if (!IS_DG2(gt->i915))
+ return;
+
+ intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
+}
+
int intel_gt_init_hw(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
intel_gt_init_swizzling(gt);
+ /* Configure CCS mode */
+ intel_gt_apply_ccs_mode(gt);
+
/*
* At least 830 can leave some of the unused rings
* "active" (ie. head != tail) after resume which
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index cf709f6c05ae..c148113770ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1605,6 +1605,8 @@
#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
#define GEN12_CAGF_MASKREG_GENMASK(19, 11)
+#define XEHP_CCS_MODE _MMIO(0x14804)
+
#define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN12_HECI_2 (30)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e81b3b2858ac..0853ffd3cb8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -396,6 +396,23 @@ static inline struct intel_gt *to_gt(const struct
drm_i915_private *i915)
(engine__); \
(engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node)))
+/*
+ * Exclude unavailable engines.
+ *
+ * Only the first CCS engine is utilized due to the disabling of CCS auto load
+ * balancing. As a result, all CCS engines operate collectively, functioning
+ * essentially as a single CCS engine, hence the count of active CCS engines is
+ * considered '1'.
+ * Currently, this applies to platforms with more than one CCS engine,
+ * specifically DG2.
+ */
+#define for_each_available_uabi_engine(engine__,
[PATCH][next] agp/amd64: remove redundant assignment to variable i
The variable i is being initialized with a value that is never read,
it is being re-assigned in the next for-loop statement. The
initialization is redundant and can be removed.
Cleans up clang scan build warning:
drivers/char/agp/amd64-agp.c:336:2: warning: Value stored to 'i' is
never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King
---
drivers/char/agp/amd64-agp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index ce8651436609..47bd3b8a54b4 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -333,7 +333,6 @@ static int cache_nbs(struct pci_dev *pdev, u32 cap_ptr)
if (!amd_nb_has_feature(AMD_NB_GART))
return -ENODEV;
- i = 0;
for (i = 0; i < amd_nb_num(); i++) {
struct pci_dev *dev = node_to_amd_nb(i)->misc;
if (fix_northbridge(dev, pdev, cap_ptr) < 0) {
--
2.39.2
[PATCH][next] gpu: host1x: remove redundant assignment to variable space
The variable space is being initialized with a value that is never read, it is being re-assigned later on. The initialization is redundant and can be removed. Also merge two declaration lines together. Cleans up clang scan build warning: drivers/gpu/host1x/cdma.c:628:15: warning: Value stored to 'space' during its initialization is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King --- drivers/gpu/host1x/cdma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c index d1336e438f4f..407ed9b9cf64 100644 --- a/drivers/gpu/host1x/cdma.c +++ b/drivers/gpu/host1x/cdma.c @@ -625,8 +625,7 @@ void host1x_cdma_push_wide(struct host1x_cdma *cdma, u32 op1, u32 op2, struct host1x_channel *channel = cdma_to_channel(cdma); struct host1x *host1x = cdma_to_host1x(cdma); struct push_buffer *pb = >push_buffer; - unsigned int space = cdma->slots_free; - unsigned int needed = 2, extra = 0; + unsigned int space, needed = 2, extra = 0; if (host1x_debug_trace_cmdbuf) trace_host1x_cdma_push_wide(dev_name(channel->dev), op1, op2, -- 2.39.2
Re: [PATCH 2/2] drm/i915/gt: Set default CCS mode '1'
Hi John,
On Thu, Feb 15, 2024 at 01:23:24PM -0800, John Harrison wrote:
> On 2/15/2024 05:59, Andi Shyti wrote:
> > Since CCS automatic load balancing is disabled, we will impose a
> > fixed balancing policy that involves setting all the CCS engines
> > to work together on the same load.
> >
> > Simultaneously, the user will see only 1 CCS rather than the
> > actual number. As of now, this change affects only DG2.
> These two paragraphs are mutually exclusive. You can't have four CCS engines
> 'working together' if only one engine exists. I think you are meaning that
> we only export 1 CCS engine and that single engine is configured to control
> all the EUs. As opposed to running in 4 CCS engine mode where the EUs are
> (dynamically or statically) divided amongst those four engines.
The balancing is done statically. The dynamic balancing is
disabled in patch 1.
The 2 or 4 CCS engines will share the same workload.
Because the user won't be able anymore to select the CCS engine
he wants to use, he will see only one CCS.
I think we are saying the same thing using different words :)
I can try in v2 to reword the commit better.
Thanks for looking into this.
Andi
> John.
>
> >
> > Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> > Signed-off-by: Andi Shyti
> > Cc: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: Matt Roper
> > Cc: # v6.2+
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
> > drivers/gpu/drm/i915/i915_drv.h | 17 +
> > drivers/gpu/drm/i915/i915_query.c | 5 +++--
> > 4 files changed, 33 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> > b/drivers/gpu/drm/i915/gt/intel_gt.c
> > index a425db5ed3a2..e19df4ef47f6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
> > }
> > }
> > +static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> > +{
> > + if (!IS_DG2(gt->i915))
> > + return;
> > +
> > + intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
> > +}
> > +
> > int intel_gt_init_hw(struct intel_gt *gt)
> > {
> > struct drm_i915_private *i915 = gt->i915;
> > @@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
> > intel_gt_init_swizzling(gt);
> > + /* Configure CCS mode */
> > + intel_gt_apply_ccs_mode(gt);
> > +
> > /*
> > * At least 830 can leave some of the unused rings
> > * "active" (ie. head != tail) after resume which
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index cf709f6c05ae..c148113770ea 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1605,6 +1605,8 @@
> > #define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
> > #define GEN12_CAGF_MASK REG_GENMASK(19, 11)
> > +#define XEHP_CCS_MODE _MMIO(0x14804)
> > +
> > #define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) *
> > 4))
> > #define GEN11_CSME (31)
> > #define GEN12_HECI_2(30)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e81b3b2858ac..0853ffd3cb8d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -396,6 +396,23 @@ static inline struct intel_gt *to_gt(const struct
> > drm_i915_private *i915)
> > (engine__); \
> > (engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node)))
> > +/*
> > + * Exclude unavailable engines.
> > + *
> > + * Only the first CCS engine is utilized due to the disabling of CCS auto
> > load
> > + * balancing. As a result, all CCS engines operate collectively,
> > functioning
> > + * essentially as a single CCS engine, hence the count of active CCS
> > engines is
> > + * considered '1'.
> > + * Currently, this applies to platforms with more than one CCS engine,
> > + * specifically DG2.
> > + */
> > +#define for_each_available_uabi_engine(engine__, i915__) \
> > + for_each_uabi_engine(engine__, i915__) \
> > + if ((IS_DG2(i915__)) && \
> > + ((engine__)->uabi_class == I915_ENGINE_CLASS_COMPUTE) && \
> > + ((engine__)->uabi_instance)) { } \
> > + else
> > +
> > #define INTEL_INFO(i915) ((i915)->__info)
> > #define RUNTIME_INFO(i915)(&(i915)->__runtime)
> > #define DRIVER_CAPS(i915) (&(i915)->caps)
> > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > b/drivers/gpu/drm/i915/i915_query.c
> > index fa3e937ed3f5..2d41bda626a6 100644
> > --- a/drivers/gpu/drm/i915/i915_query.c
> > +++ b/drivers/gpu/drm/i915/i915_query.c
> > @@ -124,6 +124,7 @@ static int query_geometry_subslices(struct
> >
[PATCH] drm/meson: Don't remove bridges which are created by other drivers
Stop calling drm_bridge_remove() for bridges allocated/managed by other
drivers in the remove paths of meson_encoder_{cvbs,dsi,hdmi}.
drm_bridge_remove() unregisters the bridge so it cannot be used
anymore. Doing so for bridges we don't own can lead to the video
pipeline not being able to come up after -EPROBE_DEFER of the VPU
because we're unregistering a bridge that's managed by another driver.
The other driver doesn't know that we have unregistered it's bridge
and on subsequent .probe() we're not able to find those bridges anymore
(since nobody re-creates them).
This fixes probe errors on Meson8b boards with the CVBS outputs enabled.
Fixes: 09847723c12f ("drm/meson: remove drm bridges at aggregate driver unbind
time")
Fixes: 42dcf15f901c ("drm/meson: add DSI encoder")
Cc: sta...@vger.kernel.org
Reported-by: Steve Morvai
Signed-off-by: Martin Blumenstingl
---
This issue was reported by Steve off-list to me (thanks again for your
patience and sorry it took so long)!
The Meson8b VPU driver is not upstream, but the problematic code is.
Meaning: This issue can also appear on SoCs which are supported
upstream if the meson DRM driver probe has to be re-tried (with
-EPROBE_DEFER). That's why I chose to Cc the stable list.
drivers/gpu/drm/meson/meson_encoder_cvbs.c | 1 -
drivers/gpu/drm/meson/meson_encoder_dsi.c | 1 -
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
index 3f73b211fa8e..3407450435e2 100644
--- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
@@ -294,6 +294,5 @@ void meson_encoder_cvbs_remove(struct meson_drm *priv)
if (priv->encoders[MESON_ENC_CVBS]) {
meson_encoder_cvbs = priv->encoders[MESON_ENC_CVBS];
drm_bridge_remove(_encoder_cvbs->bridge);
- drm_bridge_remove(meson_encoder_cvbs->next_bridge);
}
}
diff --git a/drivers/gpu/drm/meson/meson_encoder_dsi.c
b/drivers/gpu/drm/meson/meson_encoder_dsi.c
index 3f93c70488ca..311b91630fbe 100644
--- a/drivers/gpu/drm/meson/meson_encoder_dsi.c
+++ b/drivers/gpu/drm/meson/meson_encoder_dsi.c
@@ -168,6 +168,5 @@ void meson_encoder_dsi_remove(struct meson_drm *priv)
if (priv->encoders[MESON_ENC_DSI]) {
meson_encoder_dsi = priv->encoders[MESON_ENC_DSI];
drm_bridge_remove(_encoder_dsi->bridge);
- drm_bridge_remove(meson_encoder_dsi->next_bridge);
}
}
diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
index 25ea76558690..c4686568c9ca 100644
--- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
@@ -474,6 +474,5 @@ void meson_encoder_hdmi_remove(struct meson_drm *priv)
if (priv->encoders[MESON_ENC_HDMI]) {
meson_encoder_hdmi = priv->encoders[MESON_ENC_HDMI];
drm_bridge_remove(_encoder_hdmi->bridge);
- drm_bridge_remove(meson_encoder_hdmi->next_bridge);
}
}
--
2.43.2
Re: [PATCH 2/2] drm/i915/gt: Set default CCS mode '1'
On 2/15/2024 05:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS rather than the
actual number. As of now, this change affects only DG2.
These two paragraphs are mutually exclusive. You can't have four CCS
engines 'working together' if only one engine exists. I think you are
meaning that we only export 1 CCS engine and that single engine is
configured to control all the EUs. As opposed to running in 4 CCS engine
mode where the EUs are (dynamically or statically) divided amongst those
four engines.
John.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: # v6.2+
---
drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 17 +
drivers/gpu/drm/i915/i915_query.c | 5 +++--
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a425db5ed3a2..e19df4ef47f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
}
}
+static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
+{
+ if (!IS_DG2(gt->i915))
+ return;
+
+ intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
+}
+
int intel_gt_init_hw(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
intel_gt_init_swizzling(gt);
+ /* Configure CCS mode */
+ intel_gt_apply_ccs_mode(gt);
+
/*
* At least 830 can leave some of the unused rings
* "active" (ie. head != tail) after resume which
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index cf709f6c05ae..c148113770ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1605,6 +1605,8 @@
#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
#define GEN12_CAGF_MASK REG_GENMASK(19, 11)
+#define XEHP_CCS_MODE _MMIO(0x14804)
+
#define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN12_HECI_2(30)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e81b3b2858ac..0853ffd3cb8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -396,6 +396,23 @@ static inline struct intel_gt *to_gt(const struct
drm_i915_private *i915)
(engine__); \
(engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node)))
+/*
+ * Exclude unavailable engines.
+ *
+ * Only the first CCS engine is utilized due to the disabling of CCS auto load
+ * balancing. As a result, all CCS engines operate collectively, functioning
+ * essentially as a single CCS engine, hence the count of active CCS engines is
+ * considered '1'.
+ * Currently, this applies to platforms with more than one CCS engine,
+ * specifically DG2.
+ */
+#define for_each_available_uabi_engine(engine__, i915__) \
+ for_each_uabi_engine(engine__, i915__) \
+ if ((IS_DG2(i915__)) && \
+ ((engine__)->uabi_class == I915_ENGINE_CLASS_COMPUTE) && \
+ ((engine__)->uabi_instance)) { } \
+ else
+
#define INTEL_INFO(i915) ((i915)->__info)
#define RUNTIME_INFO(i915)(&(i915)->__runtime)
#define DRIVER_CAPS(i915) (&(i915)->caps)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index fa3e937ed3f5..2d41bda626a6 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -124,6 +124,7 @@ static int query_geometry_subslices(struct drm_i915_private
*i915,
return fill_topology_info(sseu, query_item,
sseu->geometry_subslice_mask);
}
+
static int
query_engine_info(struct drm_i915_private *i915,
struct drm_i915_query_item *query_item)
@@ -140,7 +141,7 @@ query_engine_info(struct drm_i915_private *i915,
if (query_item->flags)
return -EINVAL;
- for_each_uabi_engine(engine, i915)
+ for_each_available_uabi_engine(engine, i915)
num_uabi_engines++;
len = struct_size(query_ptr, engines, num_uabi_engines);
@@ -155,7 +156,7 @@ query_engine_info(struct drm_i915_private *i915,
info_ptr = _ptr->engines[0];
- for_each_uabi_engine(engine, i915) {
+ for_each_available_uabi_engine(engine, i915) {
Re: [PATCH 2/3] dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w
Am Donnerstag, 15. Februar 2024, 18:06:06 CET schrieb Conor Dooley: > On Thu, Feb 15, 2024 at 10:05:14AM +0100, Heiko Stuebner wrote: > > From: Heiko Stuebner > > > > Add the compatible for the ltk101b4029w panel, that is really similar > > to the ltk500hd1829. > > Please mention what makes the devices incompatible. "really similar" is > vague and could be used for a device that was only cosmetically > different. ok, I'll modify the paragraph to: === Add the compatible for the ltk101b4029w panel, that has the same manufacturer, general bringup and supplies but a different dsi-init- sequence as the ltk500hd1829 . === > With that, > Acked-by: Conor Dooley > > Cheers, > Conor. > > > > > Signed-off-by: Heiko Stuebner > > --- > > .../bindings/display/panel/leadtek,ltk500hd1829.yaml | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > > index c5944b4d636c5..d589f16772145 100644 > > --- > > a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > > +++ > > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > > @@ -14,7 +14,9 @@ allOf: > > > > properties: > >compatible: > > -const: leadtek,ltk500hd1829 > > +enum: > > + - leadtek,ltk101b4029w > > + - leadtek,ltk500hd1829 > >reg: true > >backlight: true > >reset-gpios: true >
Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
Hi Mario, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.8-rc4 next-20240215] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_ATMEL-0-0 (https://download.01.org/0day-ci/archive/20240216/202402160459.dyhkpajy-...@intel.com/config) reproduce: (https://download.01.org/0day-ci/archive/20240216/202402160459.dyhkpajy-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202402160459.dyhkpajy-...@intel.com/ kismet warnings: (new ones prefixed by >>) >> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when >> selected by FB_ATMEL .config:166:warning: symbol value 'n' invalid for RAPIDIO_DISC_TIMEOUT .config:190:warning: symbol value 'n' invalid for FAT_DEFAULT_CODEPAGE .config:241:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY .config:335:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK .config:344:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON .config:426:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL .config:596:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN .config:618:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN .config:712:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET .config:752:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE .config:770:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT .config:790:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA .config:810:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE .config:823:warning: symbol value 'n' invalid for DRM_I915_MAX_REQUEST_BUSYWAIT .config:860:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE .config:875:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN .config:884:warning: symbol value 'n' invalid for NET_EMATCH_STACK .config:886:warning: symbol value 'n' invalid for VMCP_CMA_SIZE .config:917:warning: symbol value 'n' invalid for INPUT_MOUSEDEV_SCREEN_Y .config:1139:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE .config:1233:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS .config:1245:warning: symbol value 'n' invalid for USB_GADGET_STORAGE_NUM_BUFFERS .config:1403:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT .config:1541:warning: symbol value 'n' invalid for WATCHDOG_OPEN_TIMEOUT .config:1550:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS .config:1686:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E .config:1717:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT .config:1805:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT .config:1972:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE .config:2126:warning: symbol value 'n' invalid for RCU_FANOUT_LEAF .config:2231:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX .config:2274:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH .config:2465:warning: symbol value 'n' invalid for SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM .config:2585:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT .config:2775:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS .config:2836:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS .config:2873:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT .config:2887:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE .config:2896:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL .config:2920:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID .config:3025:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY .config:3062:warning: symbol value 'n' invalid for FB_OMAP2_DSS_MIN_FCK_PER_PCK .config:3074:warning: symbol value 'n' invalid for BOOKE_WDT_DEFAULT_TIMEOUT .config:3302:warning: symbol value 'n' invalid for KCSAN_UDELAY_TASK .config:3394:warning: symbol value 'n' invalid for MTD_REDBOOT_DIRECTORY_BLOCK .config:3401:warning: symbol value 'n' invalid for MMC_BLOCK_MINO
Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
Hi Mario, kernel test robot noticed the following build errors: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.8-rc4 next-20240215] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers config: openrisc-randconfig-r064-20240215 (https://download.01.org/0day-ci/archive/20240216/202402160446.yalmybpi-...@intel.com/config) compiler: or1k-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240216/202402160446.yalmybpi-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202402160446.yalmybpi-...@intel.com/ All errors (new ones prefixed by >>): or1k-linux-ld: drivers/video/fbdev/nvidia/nv_backlight.o: in function `nvidia_bl_init': >> nv_backlight.c:(.text+0x26c): undefined reference to >> `backlight_device_register' >> nv_backlight.c:(.text+0x26c): relocation truncated to fit: >> R_OR1K_INSN_REL_26 against undefined symbol `backlight_device_register' or1k-linux-ld: drivers/video/fbdev/nvidia/nv_backlight.o: in function `nvidia_bl_exit': >> nv_backlight.c:(.text+0x32c): undefined reference to >> `backlight_device_unregister' >> nv_backlight.c:(.text+0x32c): relocation truncated to fit: >> R_OR1K_INSN_REL_26 against undefined symbol `backlight_device_unregister' or1k-linux-ld: drivers/video/fbdev/aty/aty128fb.o: in function `aty128_remove': >> aty128fb.c:(.text+0x14c): undefined reference to >> `backlight_device_unregister' >> aty128fb.c:(.text+0x14c): relocation truncated to fit: R_OR1K_INSN_REL_26 >> against undefined symbol `backlight_device_unregister' or1k-linux-ld: drivers/video/fbdev/aty/aty128fb.o: in function `aty128_init': >> aty128fb.c:(.text.unlikely+0x5bc): undefined reference to >> `backlight_device_register' >> aty128fb.c:(.text.unlikely+0x5bc): relocation truncated to fit: >> R_OR1K_INSN_REL_26 against undefined symbol `backlight_device_register' or1k-linux-ld: drivers/auxdisplay/ht16k33.o: in function `ht16k33_fbdev_probe': >> ht16k33.c:(.text+0x17f4): undefined reference to >> `devm_backlight_device_register' >> ht16k33.c:(.text+0x17f4): relocation truncated to fit: R_OR1K_INSN_REL_26 >> against undefined symbol `devm_backlight_device_register' Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for FB_BACKLIGHT Depends on [n]: HAS_IOMEM [=y] && FB [=y] && BACKLIGHT_CLASS_DEVICE [=n] Selected by [y]: - HT16K33 [=y] && AUXDISPLAY [=y] && FB [=y] && I2C [=y] && INPUT [=y] - FB_ATMEL [=y] && FB [=y] && OF [=y] && HAVE_CLK [=y] && HAS_IOMEM [=y] && (HAVE_FB_ATMEL [=n] || COMPILE_TEST [=y]) - FB_NVIDIA [=y] && HAS_IOMEM [=y] && FB [=y] && PCI [=y] && FB_NVIDIA_BACKLIGHT [=y] - FB_ATY128 [=y] && HAS_IOMEM [=y] && FB [=y] && PCI [=y] && FB_ATY128_BACKLIGHT [=y] -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v3 2/2] fbcon: Defer console takeover for splash screens to first switch
On 2/13/2024 23:24, Daniel van Vugt wrote:
Until now, deferred console takeover only meant defer until there is
output. But that risks stepping on the toes of userspace splash screens,
as console messages may appear before the splash screen. So check the
command line for the expectation of userspace splash and if present then
extend the deferral until the first switch.
I think your comment from the earlier version that this can still happen
on simpledrm (albeit less frequently) is very relevant here for the
commit message.
v2: Added Kconfig option instead of hard coding "splash".
v3: Default to disabled, not "splash". If enabled then take over on
switch rather than on first output after switch.
These you'll want below the cutlist (---)
Also I think you should mention in the commit message that the
indication of a userspace splash is set by the Kconfig.
Closes: https://bugs.launchpad.net/bugs/1970069
Cc: Mario Limonciello
Signed-off-by: Daniel van Vugt
---
drivers/video/console/Kconfig| 12 +
drivers/video/fbdev/core/fbcon.c | 44 +---
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index bc31db6ef7..2f9435335f 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -138,6 +138,18 @@ config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
by the firmware in place, rather then replacing the contents with a
black screen as soon as fbcon loads.
+config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
+ string "Command line parameter to defer takeover to first switch"
+ depends on FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+ default ""
+ help
+ If enabled this defers further the framebuffer console taking over
+ until the first console switch has occurred. And even then only if
+ the specified parameter is found on the command line. This ensures
+ fbcon does not interrupt userspace splash screens such as Plymouth
+ which may be yet to start rendering at the time of the first console
+ output.
+
config STI_CONSOLE
bool "STI text console"
depends on PARISC && HAS_IOMEM
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 1183e7a871..e5d841ab03 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -76,6 +76,7 @@
#include /* For counting font checksums */
#include
#include
+#include
#include "fbcon.h"
#include "fb_internal.h"
@@ -3348,7 +3349,7 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
{
WARN_CONSOLE_UNLOCKED();
- pr_info("fbcon: Taking over console\n");
+ pr_info("fbcon: Taking over console for output\n");
dummycon_unregister_output_notifier(_output_nb);
@@ -3357,6 +3358,27 @@ static int fbcon_output_notifier(struct notifier_block *nb,
return NOTIFY_OK;
}
+
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
+static int initial_console;
+static struct notifier_block fbcon_switch_nb;
+
+static int fbcon_switch_notifier(struct notifier_block *nb,
+unsigned long action, void *data)
+{
+ struct vc_data *vc = data;
+
+ WARN_CONSOLE_UNLOCKED();
+
+ if (vc->vc_num != initial_console) {
+ pr_info("fbcon: Taking over console for switch\n");
+ dummycon_unregister_switch_notifier(_switch_nb);
+ schedule_work(_deferred_takeover_work);
+ }
+
+ return NOTIFY_OK;
+}
+#endif
#endif
Once you start adding nested #ifdef, I think it's very useful to add a
comment on the #endif to make it easier to follow the code.
IE
#endif /* CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION */
static void fbcon_start(void)
@@ -3368,8 +3390,18 @@ static void fbcon_start(void)
deferred_takeover = false;
if (deferred_takeover) {
- fbcon_output_nb.notifier_call = fbcon_output_notifier;
- dummycon_register_output_notifier(_output_nb);
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION
+ if (cmdline_find_option_bool(boot_command_line,
+ CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER_CONDITION)) {
+ initial_console = fg_console;
+ fbcon_switch_nb.notifier_call = fbcon_switch_notifier;
+ dummycon_register_switch_notifier(_switch_nb);
+ } else
+#endif
+ {
+ fbcon_output_nb.notifier_call = fbcon_output_notifier;
+ dummycon_register_output_notifier(_output_nb);
+ }
return;
}
#endif
@@ -3416,8 +3448,12 @@ void __exit fb_console_exit(void)
{
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
console_lock();
- if (deferred_takeover)
+
[pull v2] amdgpu, amdkfd drm-fixes-6.8
Hi Dave, Daniel, Same PR as earlier today, but drop the panel power saving debugging patches for now at Harry's request. The following changes since commit 841c35169323cd833294798e58b9bf63fa4fa1de: Linux 6.8-rc4 (2024-02-11 12:18:13 -0800) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.8-2024-02-15-2 for you to fetch changes up to a8ac4bcaeb660c5eeb273507e8dbf713ba56de44: drm/amdgpu: Fix implicit assumtion in gfx11 debug flags (2024-02-15 14:18:44 -0500) amd-drm-fixes-6.8-2024-02-15-2: amdgpu: - PSR fixes - Suspend/resume fixes - Link training fix - Aspect ratio fix - DCN 3.5 fixes - VCN 4.x fix - GFX 11 fix - Misc display fixes - Misc small fixes amdkfd: - Cache size reporting fix - SIMD distribution fix Dan Carpenter (1): drm/amd/display: Fix && vs || typos Hamza Mahfooz (1): drm/amdgpu: make damage clips support configurable Kent Russell (1): drm/amdkfd: Fix L2 cache size reporting in GFX9.4.3 Mario Limonciello (2): drm/amd: Stop evicting resources on APUs in suspend Revert "drm/amd: flush any delayed gfxoff on suspend entry" Nicholas Kazlauskas (1): drm/amd/display: Increase ips2_eval delay for DCN35 Rajneesh Bhardwaj (2): drm/amdkfd: update SIMD distribution algo for GFXIP 9.4.2 onwards drm/amdgpu: Fix implicit assumtion in gfx11 debug flags Roman Li (1): drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr Sohaib Nadeem (2): Revert "drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz" drm/amd/display: fixed integer types and null check locations Srinivasan Shanmugam (5): drm/amd/display: Initialize 'wait_time_microsec' variable in link_dp_training_dpia.c drm/amd/display: Fix possible use of uninitialized 'max_chunks_fbc_mode' in 'calculate_bandwidth()' drm/amd/display: Fix possible buffer overflow in 'find_dcfclk_for_voltage()' drm/amd/display: Fix possible NULL dereference on device remove/driver unload drm/amdgpu/display: Initialize gamma correction mode variable in dcn30_get_gamcor_current() Thong (1): drm/amdgpu/soc21: update VCN 4 max HEVC encoding resolution Tom Chung (1): drm/amd/display: Preserve original aspect ratio in create stream Zhikai Zhai (1): drm/amd/display: Add align done check drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 15 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 + drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 9 - drivers/gpu/drm/amd/amdgpu/soc21.c | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 9 + drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 1 + drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 4 +++- drivers/gpu/drm/amd/amdkfd/kfd_topology.c| 10 -- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 11 ++- drivers/gpu/drm/amd/display/dc/basics/dce_calcs.c| 2 +- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 16 ++-- .../gpu/drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 2 ++ .../gpu/drm/amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 15 +++ drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp_cm.c | 5 + drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 2 +- drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c | 4 ++-- drivers/gpu/drm/amd/display/dc/link/link_validation.c| 2 +- .../drm/amd/display/dc/link/protocols/link_dp_training.c | 5 - .../display/dc/link/protocols/link_dp_training_dpia.c| 2 +- .../drm/amd/display/dc/resource/dcn35/dcn35_resource.c | 2 +- 23 files changed, 114 insertions(+), 38 deletions(-)
[PATCH v5] drm/dp: add an API to indicate if sink supports VSC SDP
From: Paloma Arellano
YUV420 format is supported only in the VSC SDP packet and not through
MSA. Hence add an API which indicates the sink support which can be used
by the rest of the DP programming.
changes in v5:
- rebased on top of drm-tip
changes in v4:
- bail out early if dpcd rev check fails
changes in v3:
- fix the commit title prefix to drm/dp
- get rid of redundant !!
- break out this change from series [1] to get acks from drm core
maintainers
Changes in v2:
- Move VSC SDP support check API from dp_panel.c to
drm_dp_helper.c
[1]: https://patchwork.freedesktop.org/series/129180/
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Paloma Arellano
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 23 +++
include/drm/display/drm_dp_helper.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..61b11cb45245 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,29 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_supported() - check if vsc sdp is supported
+ * @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
+ *
+ * Returns true if vsc sdp is supported, else returns false
+ */
+bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ u8 rx_feature;
+
+ if (dpcd[DP_DPCD_REV] < DP_DPCD_REV_13)
+ return false;
+
+ if (drm_dp_dpcd_readb(aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
_feature) != 1) {
+ drm_dbg_dp(aux->drm_dev, "failed to read
DP_DPRX_FEATURE_ENUMERATION_LIST\n");
+ return false;
+ }
+
+ return (rx_feature & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED);
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_supported);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index d02014a87f12..36351f3cdba9 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -100,6 +100,8 @@ struct drm_dp_vsc_sdp {
void drm_dp_vsc_sdp_log(struct drm_printer *p, const struct drm_dp_vsc_sdp
*vsc);
+bool drm_dp_vsc_sdp_supported(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE]);
+
int drm_dp_psr_setup_time(const u8 psr_cap[EDP_PSR_RECEIVER_CAP_SIZE]);
static inline int
--
2.34.1
[PATCH v2] drm/dp: move intel_dp_vsc_sdp_pack() to generic helper
intel_dp_vsc_sdp_pack() can be re-used by other DRM drivers as well.
Lets move this to drm_dp_helper to achieve this.
changes in v2:
- rebased on top of drm-tip
Acked-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/display/drm_dp_helper.c | 78 +
drivers/gpu/drm/i915/display/intel_dp.c | 71 +-
include/drm/display/drm_dp_helper.h | 3 +
3 files changed, 83 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8d6ce46471ae..6c91f400ecb1 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2913,6 +2913,84 @@ void drm_dp_vsc_sdp_log(struct drm_printer *p, const
struct drm_dp_vsc_sdp *vsc)
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+/**
+ * drm_dp_vsc_sdp_pack() - pack a given vsc sdp into generic dp_sdp
+ * @vsc: vsc sdp initialized according to its purpose as defined in
+ * table 2-118 - table 2-120 in DP 1.4a specification
+ * @sdp: valid handle to the generic dp_sdp which will be packed
+ * @size: valid size of the passed sdp handle
+ *
+ * Returns length of sdp on success and error code on failure
+ */
+ssize_t drm_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
+ struct dp_sdp *sdp, size_t size)
+{
+ size_t length = sizeof(struct dp_sdp);
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(sdp, 0, size);
+
+ /*
+* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
+* VSC SDP Header Bytes
+*/
+ sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
+ sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
+ sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
+ sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+
+ if (vsc->revision == 0x6) {
+ sdp->db[0] = 1;
+ sdp->db[3] = 1;
+ }
+
+ /*
+* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
+* Format as per DP 1.4a spec and DP 2.0 respectively.
+*/
+ if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
+ goto out;
+
+ /* VSC SDP Payload for DB16 through DB18 */
+ /* Pixel Encoding and Colorimetry Formats */
+ sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
+ sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
+
+ switch (vsc->bpc) {
+ case 6:
+ /* 6bpc: 0x0 */
+ break;
+ case 8:
+ sdp->db[17] = 0x1; /* DB17[3:0] */
+ break;
+ case 10:
+ sdp->db[17] = 0x2;
+ break;
+ case 12:
+ sdp->db[17] = 0x3;
+ break;
+ case 16:
+ sdp->db[17] = 0x4;
+ break;
+ default:
+ WARN(1, "Missing case %d\n", vsc->bpc);
+ return -EINVAL;
+ }
+
+ /* Dynamic Range and Component Bit Depth */
+ if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
+ sdp->db[17] |= 0x80; /* DB17[7] */
+
+ /* Content Type */
+ sdp->db[18] = vsc->content_type & 0x7;
+
+out:
+ return length;
+}
+EXPORT_SYMBOL(drm_dp_vsc_sdp_pack);
+
/**
* drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
* @dpcd: DisplayPort configuration data
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 217196196e50..a9458df475e2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4089,73 +4089,6 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
*crtc_state,
return false;
}
-static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
-struct dp_sdp *sdp, size_t size)
-{
- size_t length = sizeof(struct dp_sdp);
-
- if (size < length)
- return -ENOSPC;
-
- memset(sdp, 0, size);
-
- /*
-* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
-* VSC SDP Header Bytes
-*/
- sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
- sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
- sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
- sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
-
- if (vsc->revision == 0x6) {
- sdp->db[0] = 1;
- sdp->db[3] = 1;
- }
-
- /*
-* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
-* Format as per DP 1.4a spec and DP 2.0 respectively.
-*/
- if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
- goto out;
-
- /* VSC SDP Payload for DB16 through DB18 */
- /* Pixel Encoding and Colorimetry Formats */
-
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On 2/15/2024 12:47, Ville Syrjälä wrote:
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
On 2/14/2024 17:13, Ville Syrjälä wrote:
On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_edid.c | 109 +---
include/drm/drm_connector.h | 6 ++
include/drm/drm_edid.h | 1 +
4 files changed, 109 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 872edb47bb53..3db89e6af01d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -8,6 +8,7 @@
menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
+ depends on (ACPI_VIDEO || ACPI_VIDEO=n)
select DRM_PANEL_ORIENTATION_QUIRKS
select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
select FB_CORE if DRM_FBDEV_EMULATION
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 923c4423151c..cdc30c6d05d5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -28,6 +28,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int
block, size_t len)
return ret == xfers ? 0 : -1;
}
+/**
+ * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
+ * @data: struct drm_connector
+ * @buf: EDID data buffer to be filled
+ * @block: 128 byte EDID block to start fetching from
+ * @len: EDID data buffer length to fetch
+ *
+ * Try to fetch EDID information by calling acpi_video_get_edid() function.
+ *
+ * Return: 0 on success or error code on failure.
+ */
+static int
+drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
+{
+ struct drm_connector *connector = data;
+ struct drm_device *ddev = connector->dev;
+ struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
+ unsigned char start = block * EDID_LENGTH;
+ void *edid;
+ int r;
+
+ if (!acpidev)
+ return -ENODEV;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ break;
+ default:
+ return -EINVAL;
+ }
We could have other types of connectors that want this too.
I don't see any real benefit in having this check tbh. Drivers
should simply notset the flag on connectors where it won't work,
and only the driver can really know that.
Ack.
+ /* fetch the entire edid from BIOS */
+ r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
+ if (r < 0) {
+ DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
+ return r;
+ }
+ if (len > r || start > r || start + len > r) {
+ r = -EINVAL;
+ goto cleanup;
+ }
+
+ memcpy(buf, edid + start, len);
+ r = 0;
+
+cleanup:
+ kfree(edid);
+
+ return r;
+}
+
static void connector_bad_edid(struct drm_connector *connector,
const struct edid *edid, int num_blocks)
{
@@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
* @connector: connector we're probing
* @adapter: I2C adapter to use for DDC
*
- * Poke the given I2C channel to grab EDID data if possible. If found,
+ * If the connector allows it, try to fetch EDID data using ACPI. If not found
+ * poke the given I2C channel to grab EDID data if possible. If found,
* attach it to the connector.
*
* Return: Pointer to valid EDID or NULL if we couldn't find any.
@@ -2629,20 +2683,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
- struct edid *edid;
+ struct edid *edid = NULL;
if (connector->force == DRM_FORCE_OFF)
return NULL;
- if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter))
- return NULL;
+ if (connector->acpi_edid_allowed)
+ edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
connector, NULL);
+
+ if (!edid) {
+ if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
+ return NULL;
+ edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
adapter, NULL);
+ }
- edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter, NULL);
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On Thu, Feb 15, 2024 at 12:20:56PM -0600, Mario Limonciello wrote:
> On 2/14/2024 17:13, Ville Syrjälä wrote:
> > On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
> >> Some manufacturers have intentionally put an EDID that differs from
> >> the EDID on the internal panel on laptops. Drivers that prefer to
> >> fetch this EDID can set a bit on the drm_connector to indicate that
> >> the DRM EDID helpers should try to fetch it and it is preferred if
> >> it's present.
> >>
> >> Signed-off-by: Mario Limonciello
> >> ---
> >> drivers/gpu/drm/Kconfig | 1 +
> >> drivers/gpu/drm/drm_edid.c | 109 +---
> >> include/drm/drm_connector.h | 6 ++
> >> include/drm/drm_edid.h | 1 +
> >> 4 files changed, 109 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index 872edb47bb53..3db89e6af01d 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -8,6 +8,7 @@
> >> menuconfig DRM
> >>tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
> >> support)"
> >>depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> >> + depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> >>select DRM_PANEL_ORIENTATION_QUIRKS
> >>select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
> >>select FB_CORE if DRM_FBDEV_EMULATION
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 923c4423151c..cdc30c6d05d5 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -28,6 +28,7 @@
> >>* DEALINGS IN THE SOFTWARE.
> >>*/
> >>
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned
> >> int block, size_t len)
> >>return ret == xfers ? 0 : -1;
> >> }
> >>
> >> +/**
> >> + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
> >> + * @data: struct drm_connector
> >> + * @buf: EDID data buffer to be filled
> >> + * @block: 128 byte EDID block to start fetching from
> >> + * @len: EDID data buffer length to fetch
> >> + *
> >> + * Try to fetch EDID information by calling acpi_video_get_edid()
> >> function.
> >> + *
> >> + * Return: 0 on success or error code on failure.
> >> + */
> >> +static int
> >> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t
> >> len)
> >> +{
> >> + struct drm_connector *connector = data;
> >> + struct drm_device *ddev = connector->dev;
> >> + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
> >> + unsigned char start = block * EDID_LENGTH;
> >> + void *edid;
> >> + int r;
> >> +
> >> + if (!acpidev)
> >> + return -ENODEV;
> >> +
> >> + switch (connector->connector_type) {
> >> + case DRM_MODE_CONNECTOR_LVDS:
> >> + case DRM_MODE_CONNECTOR_eDP:
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >
> > We could have other types of connectors that want this too.
> > I don't see any real benefit in having this check tbh. Drivers
> > should simply notset the flag on connectors where it won't work,
> > and only the driver can really know that.
>
> Ack.
>
> >
> >> + /* fetch the entire edid from BIOS */
> >> + r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
> >> + if (r < 0) {
> >> + DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
> >> + return r;
> >> + }
> >> + if (len > r || start > r || start + len > r) {
> >> + r = -EINVAL;
> >> + goto cleanup;
> >> + }
> >> +
> >> + memcpy(buf, edid + start, len);
> >> + r = 0;
> >> +
> >> +cleanup:
> >> + kfree(edid);
> >> +
> >> + return r;
> >> +}
> >> +
> >> static void connector_bad_edid(struct drm_connector *connector,
> >> const struct edid *edid, int num_blocks)
> >> {
> >> @@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
> >>* @connector: connector we're probing
> >>* @adapter: I2C adapter to use for DDC
> >>*
> >> - * Poke the given I2C channel to grab EDID data if possible. If found,
> >> + * If the connector allows it, try to fetch EDID data using ACPI. If not
> >> found
> >> + * poke the given I2C channel to grab EDID data if possible. If found,
> >>* attach it to the connector.
> >>*
> >>* Return: Pointer to valid EDID or NULL if we couldn't find any.
> >> @@ -2629,20 +2683,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
> >> struct edid *drm_get_edid(struct drm_connector *connector,
> >> struct i2c_adapter *adapter)
> >> {
> >> - struct edid *edid;
> >> + struct edid *edid = NULL;
> >>
> >>if (connector->force == DRM_FORCE_OFF)
> >>return NULL;
> >>
> >> - if (connector->force == DRM_FORCE_UNSPECIFIED &&
> >> !drm_probe_ddc(adapter))
> >> - return NULL;
> >> + if (connector->acpi_edid_allowed)
> >> + edid = _drm_do_get_edid(connector,
Re: (subset) [linux][PATCH v6 3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format
On 15/02/2024 11:02, Uwe Kleine-König wrote: > On Mon, Feb 12, 2024 at 11:23:02AM +0100, Krzysztof Kozlowski wrote: >> On 08/02/2024 11:43, Lee Jones wrote: >>> On Fri, 02 Feb 2024 05:47:33 +0530, Dharma Balasubiramani wrote: Convert the atmel,hlcdc binding to DT schema format. Align clocks and clock-names properties to clearly indicate that the LCD controller expects lvds_pll_clk when interfaced with the lvds display. This alignment with the specific hardware requirements ensures accurate device tree configuration for systems utilizing the HLCDC IP. [...] >>> >>> Applied, thanks! >>> >>> [3/3] dt-bindings: mfd: atmel,hlcdc: Convert to DT schema format >>> commit: cb946db1335b599ece363d33966bf653ed0fa58a >>> >> >> Next is still failing. > > Failing in the sense of dtbs_check, right? No, bindings were failing. dt_binding_check. This must not fail, so kind of bummer... > >> Dharma, >> You must explain and clearly mark dependencies between patches. >> >> Lee, >> Can you pick up two previous patches as well? > > I applied the pwm patch now. If Lee wants to pick up this one via his > tree that would be fine for me, too. If that's the case please tell me, > then I'll drop it from my for-next branch again. Feel free to add > my Acked-by: Uwe Kleine-König for patch > #2 then. At least next is happy. > Best regards, Krzysztof
Re: [PATCH v4 03/10] dt-bindings: display: bridge: tc358775: Add support for tc358765
On 15/02/2024 13:31, Tony Lindgren wrote: > The tc358765 is similar to tc358775. The tc358765 just an earlier version > of the hardware, and it's pin and register compatible with tc358775 for > most part. > > From the binding point of view the only difference is that the tc358765 > does not have stdby-gpios. > > Signed-off-by: Tony Lindgren > --- > .../display/bridge/toshiba,tc358775.yaml | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml > @@ -10,7 +10,7 @@ maintainers: >- Vinay Simha BN > > description: | > - This binding supports DSI to LVDS bridge TC358775 > + This binding supports DSI to LVDS bridges TC358765 and TC358775 > >MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane. >Video frame size: > @@ -21,7 +21,9 @@ description: | > > properties: >compatible: > -const: toshiba,tc358775 > +enum: > + - toshiba,tc358765 > + - toshiba,tc358775 > >reg: > maxItems: 1 > @@ -81,6 +83,16 @@ properties: >- port@0 >- port@1 > > +allOf: If there is going to be new version, please put allOf: block after required: block. Anyway: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v3 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On Thu, 15 Feb 2024 at 19:03, Dmitry Baryshkov
wrote:
>
> On Thu, 15 Feb 2024 at 18:39, Abhinav Kumar wrote:
> >
> >
> >
> > On 2/15/2024 12:40 AM, Dmitry Baryshkov wrote:
> > > On Wed, 14 Feb 2024 at 22:15, Abhinav Kumar
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 2/14/2024 11:39 AM, Dmitry Baryshkov wrote:
> > >>> On Wed, 14 Feb 2024 at 20:04, Paloma Arellano
> > >>> wrote:
> >
> > Add support to pack and send the VSC SDP packet for DP. This therefore
> > allows the transmision of format information to the sinks which is
> > needed for YUV420 support over DP.
> >
> > Changes in v3:
> > - Create a new struct, msm_dp_sdp_with_parity, which holds
> > the
> > packing information for VSC SDP
> > - Use drm_dp_vsc_sdp_pack() to pack the data into the new
> > msm_dp_sdp_with_parity struct instead of specifically
> > packing
> > for YUV420 format
> > - Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
> > data using the new msm_dp_sdp_with_parity struct
> >
> > Changes in v2:
> > - Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
> > - Remove dp_sdp from the dp_catalog struct since this data is
> > being allocated at the point used
> > - Create a new function in dp_utils to pack the VSC SDP data
> > into a buffer
> > - Create a new function that packs the SDP header bytes into
> > a
> > buffer. This function is made generic so that it can be
> > utilized by dp_audio
> > header bytes into a buffer
> > - Create a new function in dp_utils that takes the packed
> > buffer
> > and writes to the DP_GENERIC0_* registers
> > - Split the dp_catalog_panel_config_vsc_sdp() function into
> > two
> > to disable/enable sending VSC SDP packets
> > - Check the DP HW version using the original useage of
> > dp_catalog_hw_revision() and correct the version checking
> > logic
> > - Rename dp_panel_setup_vsc_sdp() to
> > dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
> > currently VSC SDP is only being set up to support YUV420
> > modes
> >
> > Signed-off-by: Paloma Arellano
> > ---
> > drivers/gpu/drm/msm/dp/dp_catalog.c | 113
> >
> > drivers/gpu/drm/msm/dp/dp_catalog.h | 7 ++
> > drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 +
> > drivers/gpu/drm/msm/dp/dp_panel.c | 55 ++
> > drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
> > drivers/gpu/drm/msm/dp/dp_utils.c | 48
> > drivers/gpu/drm/msm/dp/dp_utils.h | 18 +
> > 7 files changed, 248 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > index 5d84c089e520a..61d5317efe683 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > @@ -901,6 +901,119 @@ int dp_catalog_panel_timing_cfg(struct
> > dp_catalog *dp_catalog)
> > return 0;
> > }
> >
> > +static void dp_catalog_panel_send_vsc_sdp(struct dp_catalog
> > *dp_catalog,
> > + struct
> > msm_dp_sdp_with_parity *msm_dp_sdp)
> > +{
> > + struct dp_catalog_private *catalog;
> > + u32 val;
> > +
> > + if (!dp_catalog) {
> > + DRM_ERROR("invalid input\n");
> > + return;
> > + }
> > +
> > + catalog = container_of(dp_catalog, struct dp_catalog_private,
> > dp_catalog);
> > +
> > + val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB0) <<
> > HEADER_BYTE_0_BIT |
> > + (msm_dp_sdp->pb.PB0 << PARITY_BYTE_0_BIT) |
> > + (msm_dp_sdp->vsc_sdp.sdp_header.HB1) <<
> > HEADER_BYTE_1_BIT |
> > + (msm_dp_sdp->pb.PB1 << PARITY_BYTE_1_BIT));
> > + dp_write_link(catalog, MMSS_DP_GENERIC0_0, val);
> > +
> > + val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB2) <<
> > HEADER_BYTE_2_BIT |
> > + (msm_dp_sdp->pb.PB2 << PARITY_BYTE_2_BIT) |
> > + (msm_dp_sdp->vsc_sdp.sdp_header.HB3) <<
> > HEADER_BYTE_3_BIT |
> > + (msm_dp_sdp->pb.PB3 << PARITY_BYTE_3_BIT));
> > + dp_write_link(catalog, MMSS_DP_GENERIC0_1, val);
> > >>>
> > >>> I still think that this is not the way to do it. Could you please
> > >>> extract the function that takes struct dp_sdp_header, calculates
> > >>> padding and
Re: [PATCH v3 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On 2/15/2024 7:47 AM, Abhinav Kumar wrote:
On 2/15/2024 12:45 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano
wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it
only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to
check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35
+++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7e7796561009a..6280c6be6dca9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP &&
phys_enc->hw_cdm &&
+ msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]],
mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder
*drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys
*phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder
requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys
*phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration
helper function
* This helper function may be used by physical encoders to
configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f02411b062c4c..e29bc4bd39208 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -415,8 +415,15 @@ static int
dpu_encoder_phys_vid_control_vblank_irq(
static void dpu_encoder_phys_vid_enable(struct dpu_encoder_phys
*phys_enc)
{
struct dpu_hw_ctl *ctl;
+ struct dpu_hw_cdm *hw_cdm;
+ const struct dpu_format *fmt = NULL;
+ u32 fmt_fourcc = DRM_FORMAT_RGB888;
ctl = phys_enc->hw_ctl;
+ hw_cdm = phys_enc->hw_cdm;
+ if (hw_cdm)
I thought that Abhinav proposed to drop the if(hw_cdm) condition here.
LGTM otherwise.
Yes I did.
This needs to be fixed in v4.
Ack, I must have forgotten to drop it, but I'll do it in the v4
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc);
+ fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VIDENC(phys_enc,
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On 2/14/2024 17:13, Ville Syrjälä wrote:
On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_edid.c | 109 +---
include/drm/drm_connector.h | 6 ++
include/drm/drm_edid.h | 1 +
4 files changed, 109 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 872edb47bb53..3db89e6af01d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -8,6 +8,7 @@
menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
+ depends on (ACPI_VIDEO || ACPI_VIDEO=n)
select DRM_PANEL_ORIENTATION_QUIRKS
select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
select FB_CORE if DRM_FBDEV_EMULATION
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 923c4423151c..cdc30c6d05d5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -28,6 +28,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int
block, size_t len)
return ret == xfers ? 0 : -1;
}
+/**
+ * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
+ * @data: struct drm_connector
+ * @buf: EDID data buffer to be filled
+ * @block: 128 byte EDID block to start fetching from
+ * @len: EDID data buffer length to fetch
+ *
+ * Try to fetch EDID information by calling acpi_video_get_edid() function.
+ *
+ * Return: 0 on success or error code on failure.
+ */
+static int
+drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
+{
+ struct drm_connector *connector = data;
+ struct drm_device *ddev = connector->dev;
+ struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
+ unsigned char start = block * EDID_LENGTH;
+ void *edid;
+ int r;
+
+ if (!acpidev)
+ return -ENODEV;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ break;
+ default:
+ return -EINVAL;
+ }
We could have other types of connectors that want this too.
I don't see any real benefit in having this check tbh. Drivers
should simply notset the flag on connectors where it won't work,
and only the driver can really know that.
Ack.
+ /* fetch the entire edid from BIOS */
+ r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
+ if (r < 0) {
+ DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
+ return r;
+ }
+ if (len > r || start > r || start + len > r) {
+ r = -EINVAL;
+ goto cleanup;
+ }
+
+ memcpy(buf, edid + start, len);
+ r = 0;
+
+cleanup:
+ kfree(edid);
+
+ return r;
+}
+
static void connector_bad_edid(struct drm_connector *connector,
const struct edid *edid, int num_blocks)
{
@@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
* @connector: connector we're probing
* @adapter: I2C adapter to use for DDC
*
- * Poke the given I2C channel to grab EDID data if possible. If found,
+ * If the connector allows it, try to fetch EDID data using ACPI. If not found
+ * poke the given I2C channel to grab EDID data if possible. If found,
* attach it to the connector.
*
* Return: Pointer to valid EDID or NULL if we couldn't find any.
@@ -2629,20 +2683,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
- struct edid *edid;
+ struct edid *edid = NULL;
if (connector->force == DRM_FORCE_OFF)
return NULL;
- if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter))
- return NULL;
+ if (connector->acpi_edid_allowed)
+ edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
connector, NULL);
+
+ if (!edid) {
+ if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
+ return NULL;
+ edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
adapter, NULL);
+ }
- edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter, NULL);
drm_connector_update_edid_property(connector, edid);
return edid;
}
EXPORT_SYMBOL(drm_get_edid);
+/**
+ *
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2/15/2024 11:54, Harry Wentland wrote: On 2024-02-02 11:20, Mario Limonciello wrote: On 2/2/2024 09:28, Hamza Mahfooz wrote: We want programs besides the compositor to be able to enable or disable panel power saving features. However, since they are currently only configurable through DRM properties, that isn't possible. So, to remedy that issue introduce a new "panel_power_savings" sysfs attribute. I've been trying to avoid looking at this too closely, partly because I want ABM enablement by default, with control for users. But the more I think about this the more uncomfortable I get. The key for my discomfort is that we're going around the back of DRM master to set a DRM property. This is apt to create lots of weird behaviors, especially if compositors also decide to implement support for the abm_level property and then potentially fight PPD, or other users of this sysfs. I feel the problem is that specifically both DRM master and sysfs can simultaneously fight over the value for ABM. This isn't a totally new problem because previously the user and DRM master could fight over this (with the user setting it on command line and DRM master overriding that). That was fixed in a follow up patch though in that the DRM property isn't attached if a user sets the value on the command line. I feel the solution to these concerns is that we should make a knob that controls whether the DRM property is created or the sysfs file is created but not let them happen simultaneously. We already have amdgpu.abmlevel=-1 is the only time sysfs is created. I'd say we should drop the drm property in that case and add a case for amdgpu.abmlevel=-2 which will only make the drm property and not the sysfs value. With that done it turns into: -2 : DRM master is in control -1 : sysfs is in control. Software like PPD will tune it as needed. 0-4 : User is in control.
Re: [PATCH v5 1/3] drm: Add support to get EDID from ACPI
On 2/15/2024 08:01, Jani Nikula wrote:
On Sat, 10 Feb 2024, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops. Drivers that prefer to
fetch this EDID can set a bit on the drm_connector to indicate that
the DRM EDID helpers should try to fetch it and it is preferred if
it's present.
Signed-off-by: Mario Limonciello
---
v1->v2:
* Split code from previous amdgpu specific helper to generic drm helper.
v2->v3:
* Add an extra select to fix a variety of randconfig errors found from
LKP robot.
v3->v4:
* Return struct drm_edid
v4->v5:
* Rename to drm_edid_read_acpi
* Drop selects
---
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/drm_edid.c | 113 +---
include/drm/drm_connector.h | 6 ++
include/drm/drm_edid.h | 1 +
4 files changed, 119 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2520db0b776e..a49740c528b9 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -103,6 +103,13 @@ config DRM_KMS_HELPER
help
CRTC helpers for KMS drivers.
+config DRM_ACPI_HELPER
+ tristate "ACPI support in DRM"
+ depends on DRM
+ depends on (ACPI_VIDEO || ACPI_VIDEO=n)
+ help
+ ACPI helpers for DRM drivers.
+
config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
bool "Enable refcount backtrace history in the DP MST helpers"
depends on STACKTRACE_SUPPORT
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 69c68804023f..096c278b6f66 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -28,6 +28,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+#include
#include
#include
#include
@@ -2188,6 +2189,62 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int
block, size_t len)
return ret == xfers ? 0 : -1;
}
+/**
+ * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
+ * @data: struct drm_connector
+ * @buf: EDID data buffer to be filled
+ * @block: 128 byte EDID block to start fetching from
+ * @len: EDID data buffer length to fetch
+ *
+ * Try to fetch EDID information by calling acpi_video_get_edid() function.
+ *
+ * Return: 0 on success or error code on failure.
+ */
+static int
+drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
+{
+ struct drm_connector *connector = data;
+ struct drm_device *ddev = connector->dev;
+ struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
+ unsigned char start = block * EDID_LENGTH;
+ void *edid;
+ int r;
+
+ if (!acpidev)
+ return -ENODEV;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* fetch the entire edid from BIOS */
+ if (IS_REACHABLE(CONFIG_DRM_ACPI_HELPER)) {
+ r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1,
);
+ if (r < 0) {
+ DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
+ return -EINVAL;
+ }
+ } else {
+ r = -EOPNOTSUPP;
+ }
+ if (len > r || start > r || start + len > r) {
+ r = -EINVAL;
+ goto cleanup;
+ }
+
+ memcpy(buf, edid + start, len);
+ r = 0;
+
+cleanup:
+ kfree(edid);
+
+ return r;
+}
+
static void connector_bad_edid(struct drm_connector *connector,
const struct edid *edid, int num_blocks)
{
@@ -2621,7 +2678,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
* @connector: connector we're probing
* @adapter: I2C adapter to use for DDC
*
- * Poke the given I2C channel to grab EDID data if possible. If found,
+ * If the connector allows it, try to fetch EDID data using ACPI. If not found
+ * poke the given I2C channel to grab EDID data if possible. If found,
* attach it to the connector.
*
* Return: Pointer to valid EDID or NULL if we couldn't find any.
@@ -2629,20 +2687,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
- struct edid *edid;
+ struct edid *edid = NULL;
if (connector->force == DRM_FORCE_OFF)
return NULL;
- if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter))
- return NULL;
+ if (connector->acpi_edid_allowed)
+ edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
connector, NULL);
+
+ if (!edid) {
+ if (connector->force == DRM_FORCE_UNSPECIFIED &&
!drm_probe_ddc(adapter))
+ return NULL;
+ edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
adapter,
Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
On 2024-02-02 11:20, Mario Limonciello wrote:
> On 2/2/2024 09:28, Hamza Mahfooz wrote:
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features. However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
>>
I've been trying to avoid looking at this too closely, partly because
I want ABM enablement by default, with control for users. But the
more I think about this the more uncomfortable I get. The key for my
discomfort is that we're going around the back of DRM master to set
a DRM property. This is apt to create lots of weird behaviors,
especially if compositors also decide to implement support for the
abm_level property and then potentially fight PPD, or other users
of this sysfs.
I'm also not sure a new sysfs is a good candidate for drm-fixes.
Harry
>> Cc: Mario Limonciello
>> Signed-off-by: Hamza Mahfooz
>
> Reviewed-by: Mario Limonciello
> Tested-by: Mario Limonciello
>
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>> commit when setting the value, call sysfs_remove_group() in
>> amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
>> 1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct
>> drm_connector *connector,
>> return ret;
>> }
>> +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power
>> savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + * # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct drm_connector *connector = dev_get_drvdata(device);
>> + struct drm_device *dev = connector->dev;
>> + u8 val;
>> +
>> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> + val = to_dm_connector_state(connector->state)->abm_level ==
>> + ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> + to_dm_connector_state(connector->state)->abm_level;
>> + drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> + return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct drm_connector *connector = dev_get_drvdata(device);
>> + struct drm_device *dev = connector->dev;
>> + long val;
>> + int ret;
>> +
>> + ret = kstrtol(buf, 0, );
>> +
>> + if (ret)
>> + return ret;
>> +
>> + if (val < 0 || val > 4)
>> + return -EINVAL;
>> +
>> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> + to_dm_connector_state(connector->state)->abm_level = val ?:
>> + ABM_LEVEL_IMMEDIATE_DISABLE;
>> + drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> + drm_kms_helper_hotplug_event(dev);
>> +
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> + _attr_panel_power_savings.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> + .name = "amdgpu",
>> + .attrs = amdgpu_attrs
>> +};
>> +
>> static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>> {
>> struct amdgpu_dm_connector *amdgpu_dm_connector =
>> to_amdgpu_dm_connector(connector);
>> + sysfs_remove_group(>kdev->kobj, _group);
>> drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
>> }
>> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct
>> drm_connector *connector)
>> to_amdgpu_dm_connector(connector);
>> int r;
>> + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>> + r = sysfs_create_group(>kdev->kobj,
>> + _group);
>> + if (r)
>> + return r;
>> + }
>> +
>> amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>> if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
>
Re: [PATCH v2 4/6] drm/msm: add support for A750 GPU
On 15.02.2024 10:20, Neil Armstrong wrote: > Add support for the A750 GPU found on the SM8650 platform > > Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU > doesn't have an HWCFG block but a separate register set. > > The A750 GPU info are added under the adreno_is_a750() macro and > the ADRENO_7XX_GEN3 family id. > > Signed-off-by: Neil Armstrong > --- Reviewed-by: Konrad Dybcio Konrad
[PATCH 6/6] drm/xe/stolen: ignore first page for FBC
Seems like we can potentially hit underruns if the CFB offset is within the first page of stolen. Just like i915 skip the first page. BSpec: 50214 Reported-by: Matt Roper Signed-off-by: Matthew Auld --- drivers/gpu/drm/xe/compat-i915-headers/i915_gem_stolen.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/xe/compat-i915-headers/i915_gem_stolen.h b/drivers/gpu/drm/xe/compat-i915-headers/i915_gem_stolen.h index bd233007c1b7..003474cfdf31 100644 --- a/drivers/gpu/drm/xe/compat-i915-headers/i915_gem_stolen.h +++ b/drivers/gpu/drm/xe/compat-i915-headers/i915_gem_stolen.h @@ -19,6 +19,9 @@ static inline int i915_gem_stolen_insert_node_in_range(struct xe_device *xe, int err; u32 flags = XE_BO_CREATE_PINNED_BIT | XE_BO_CREATE_STOLEN_BIT; + if (start < SZ_4K) + start = SZ_4K; + if (align) size = ALIGN(size, align); -- 2.43.0
[PATCH 4/6] drm/tests/drm_buddy: add alloc_range_bias test
Sanity check range bias with DRM_BUDDY_RANGE_ALLOCATION.
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Christian König
---
drivers/gpu/drm/tests/drm_buddy_test.c | 218 +
1 file changed, 218 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index edacc1adb28f..3d4b29686132 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -14,11 +14,216 @@
#include "../lib/drm_random.h"
+static unsigned int random_seed;
+
static inline u64 get_size(int order, u64 chunk_size)
{
return (1 << order) * chunk_size;
}
+static void drm_test_buddy_alloc_range_bias(struct kunit *test)
+{
+ u32 mm_size, ps, bias_size, bias_start, bias_end, bias_rem;
+ DRM_RND_STATE(prng, random_seed);
+ unsigned int i, count, *order;
+ struct drm_buddy mm;
+ LIST_HEAD(allocated);
+
+ bias_size = SZ_1M;
+ ps = roundup_pow_of_two(prandom_u32_state() % bias_size);
+ ps = max(SZ_4K, ps);
+ mm_size = (SZ_8M-1) & ~(ps-1); /* Multiple roots */
+
+ kunit_info(test, "mm_size=%u, ps=%u\n", mm_size, ps);
+
+ KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_init(, mm_size, ps),
+ "buddy_init failed\n");
+
+ count = mm_size / bias_size;
+ order = drm_random_order(count, );
+ KUNIT_EXPECT_TRUE(test, order);
+
+ /*
+* Idea is to split the address space into uniform bias ranges, and then
+* in some random order allocate within each bias, using various
+* patterns within. This should detect if allocations leak out from a
+* given bias, for example.
+*/
+
+ for (i = 0; i < count; i++) {
+ LIST_HEAD(tmp);
+ u64 size;
+
+ bias_start = order[i] * bias_size;
+ bias_end = bias_start + bias_size;
+ bias_rem = bias_size;
+
+ /* internal round_up too big */
+ KUNIT_ASSERT_TRUE_MSG(test,
+ drm_buddy_alloc_blocks(, bias_start,
+bias_end,
bias_size + ps, bias_size,
+,
+
DRM_BUDDY_RANGE_ALLOCATION),
+ "buddy_alloc failed with bias(%x-%x),
size=%u, ps=%u\n",
+ bias_start, bias_end, bias_size,
bias_size);
+
+ /* size too big */
+ KUNIT_ASSERT_TRUE_MSG(test,
+ drm_buddy_alloc_blocks(, bias_start,
+bias_end,
bias_size + ps, ps,
+,
+
DRM_BUDDY_RANGE_ALLOCATION),
+ "buddy_alloc didn't fail with
bias(%x-%x), size=%u, ps=%u\n",
+ bias_start, bias_end, bias_size + ps, ps);
+
+ /* bias range too small for size */
+ KUNIT_ASSERT_TRUE_MSG(test,
+ drm_buddy_alloc_blocks(, bias_start +
ps,
+bias_end,
bias_size, ps,
+,
+
DRM_BUDDY_RANGE_ALLOCATION),
+ "buddy_alloc didn't fail with
bias(%x-%x), size=%u, ps=%u\n",
+ bias_start + ps, bias_end, bias_size, ps);
+
+ /* bias misaligned */
+ KUNIT_ASSERT_TRUE_MSG(test,
+ drm_buddy_alloc_blocks(, bias_start +
ps,
+bias_end - ps,
+bias_size >> 1,
bias_size >> 1,
+,
+
DRM_BUDDY_RANGE_ALLOCATION),
+ "buddy_alloc h didn't fail with
bias(%x-%x), size=%u, ps=%u\n",
+ bias_start + ps, bias_end - ps, bias_size
>> 1, bias_size >> 1);
+
+ /* single big page */
+ KUNIT_ASSERT_FALSE_MSG(test,
+ drm_buddy_alloc_blocks(, bias_start,
+ bias_end,
bias_size, bias_size,
+ ,
+
DRM_BUDDY_RANGE_ALLOCATION),
+ "buddy_alloc i failed with bias(%x-%x),
size=%u, ps=%u\n",
+
[PATCH 5/6] drm/xe/stolen: lower the default alignment
No need to be so aggressive here. The upper layers will already apply
the needed alignment, plus some allocations might wish to skip it. Main
issue is that we might want to have start/end bias range which doesn't
match the default alignment which is rejected by the allocator.
Signed-off-by: Matthew Auld
Cc: Matt Roper
---
drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
index 662f1e9bfc65..2e94f90e1018 100644
--- a/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
+++ b/drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c
@@ -203,7 +203,7 @@ void xe_ttm_stolen_mgr_init(struct xe_device *xe)
{
struct xe_ttm_stolen_mgr *mgr = drmm_kzalloc(>drm, sizeof(*mgr),
GFP_KERNEL);
struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
- u64 stolen_size, io_size, pgsize;
+ u64 stolen_size, io_size;
int err;
if (IS_SRIOV_VF(xe))
@@ -220,10 +220,6 @@ void xe_ttm_stolen_mgr_init(struct xe_device *xe)
return;
}
- pgsize = xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K ? SZ_64K : SZ_4K;
- if (pgsize < PAGE_SIZE)
- pgsize = PAGE_SIZE;
-
/*
* We don't try to attempt partial visible support for stolen vram,
* since stolen is always at the end of vram, and the BAR size is pretty
@@ -234,7 +230,7 @@ void xe_ttm_stolen_mgr_init(struct xe_device *xe)
io_size = stolen_size;
err = __xe_ttm_vram_mgr_init(xe, >base, XE_PL_STOLEN, stolen_size,
-io_size, pgsize);
+io_size, SZ_4K);
if (err) {
drm_dbg_kms(>drm, "Stolen mgr init failed: %i\n", err);
return;
--
2.43.0
[PATCH 3/6] drm/buddy: check range allocation matches alignment
Likely not a big deal for real users, but for consistency we should
respect the min_page_size here. Main issue is that bias allocations
turns into normal range allocation if the range and size matches
exactly, and in the next patch we want to add some unit tests for this
part of the api.
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Christian König
---
drivers/gpu/drm/drm_buddy.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index d09540d4065b..ee9913016626 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -771,8 +771,12 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
return -EINVAL;
/* Actual range allocation */
- if (start + size == end)
+ if (start + size == end) {
+ if (!IS_ALIGNED(start | end, min_block_size))
+ return -EINVAL;
+
return __drm_buddy_alloc_range(mm, start, size, NULL, blocks);
+ }
original_size = size;
original_min_size = min_block_size;
--
2.43.0
[PATCH 1/6] drm/tests/drm_buddy: fix 32b build
Doesn't seem to compile on 32b, presumably due to u64 mod/division.
Simplest is to just switch over to u32 here. Also make print modifiers
consistent with that.
Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
Reported-by: Geert Uytterhoeven
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Christian König
Cc: Maxime Ripard
---
drivers/gpu/drm/tests/drm_buddy_test.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index fee6bec757d1..edacc1adb28f 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -21,7 +21,7 @@ static inline u64 get_size(int order, u64 chunk_size)
static void drm_test_buddy_alloc_contiguous(struct kunit *test)
{
- u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ u32 mm_size, ps = SZ_4K, i, n_pages, total;
struct drm_buddy_block *block;
struct drm_buddy mm;
LIST_HEAD(left);
@@ -56,30 +56,30 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
*test)
KUNIT_ASSERT_FALSE_MSG(test,
drm_buddy_alloc_blocks(, 0, mm_size,
ps, ps, list, 0),
- "buddy_alloc hit an error size=%d\n",
+ "buddy_alloc hit an error size=%u\n",
ps);
} while (++i < n_pages);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
3 * ps, ps,
,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%d\n", 3 * ps);
+ "buddy_alloc didn't error size=%u\n", 3 * ps);
drm_buddy_free_list(, );
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
3 * ps, ps,
,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ "buddy_alloc didn't error size=%u\n", 3 * ps);
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
2 * ps, ps,
,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%llu\n", 2 * ps);
+ "buddy_alloc didn't error size=%u\n", 2 * ps);
drm_buddy_free_list(, );
KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
3 * ps, ps,
,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc didn't error size=%llu\n", 3 * ps);
+ "buddy_alloc didn't error size=%u\n", 3 * ps);
/*
* At this point we should have enough contiguous space for 2 blocks,
* however they are never buddies (since we freed middle and right) so
@@ -88,13 +88,13 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
*test)
KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
2 * ps, ps,
,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc hit an error size=%d\n", 2 * ps);
+ "buddy_alloc hit an error size=%u\n", 2 * ps);
drm_buddy_free_list(, );
KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(, 0, mm_size,
3 * ps, ps,
,
DRM_BUDDY_CONTIGUOUS_ALLOCATION),
- "buddy_alloc hit an error size=%d\n", 3 * ps);
+ "buddy_alloc hit an error size=%u\n", 3 * ps);
total = 0;
list_for_each_entry(block, , link)
--
2.43.0
[PATCH 2/6] drm/buddy: fix range bias
There is a corner case here where start/end is after/before the block
range we are currently checking. If so we need to be sure that splitting
the block will eventually give use the block size we need. To do that we
should adjust the block range to account for the start/end, and only
continue with the split if the size/alignment will fit the requested
size. Not doing so can result in leaving split blocks unmerged when it
eventually fails.
Fixes: afea229fe102 ("drm: improve drm_buddy_alloc function")
Signed-off-by: Matthew Auld
Cc: Arunpravin Paneer Selvam
Cc: Christian König
Cc: # v5.18+
---
drivers/gpu/drm/drm_buddy.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index c1a99bf4dffd..d09540d4065b 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -332,6 +332,7 @@ alloc_range_bias(struct drm_buddy *mm,
u64 start, u64 end,
unsigned int order)
{
+ u64 req_size = mm->chunk_size << order;
struct drm_buddy_block *block;
struct drm_buddy_block *buddy;
LIST_HEAD(dfs);
@@ -367,6 +368,15 @@ alloc_range_bias(struct drm_buddy *mm,
if (drm_buddy_block_is_allocated(block))
continue;
+ if (block_start < start || block_end > end) {
+ u64 adjusted_start = max(block_start, start);
+ u64 adjusted_end = min(block_end, end);
+
+ if (round_down(adjusted_end + 1, req_size) <=
+ round_up(adjusted_start, req_size))
+ continue;
+ }
+
if (contains(start, end, block_start, block_end) &&
order == drm_buddy_block_order(block)) {
/*
--
2.43.0
Re: [PATCH 2/2] drm/vkms: Use a simpler composition function
On 08/02/24 06:39, Pekka Paalanen wrote: > On Wed, 7 Feb 2024 16:49:56 +0100 > Louis Chauvet wrote: > >> Hello Pekka, Arthur, Maxime, > > Hi all > >>> Change the composition algorithm to iterate over pixels instead of >>> lines. >>> It allows a simpler management of rotation and pixel access for >>> complex formats. >>> >>> This new algorithm allows read_pixel function to have access to x/y >>> coordinates and make it possible to read the correct thing in a >>> block >>> when block_w and block_h are not 1. >>> The iteration pixel-by-pixel in the same method also allows a >>> simpler >>> management of rotation with drm_rect_* helpers. This way it's not >>> needed >>> anymore to have misterious switch-case distributed in multiple >>> places. >> >> Hi, >> >> there was a very good reason to write this code using lines: >> performance. Before lines, it was indeed operating on individual >> pixels. >> >> Please, include performance measurements before and after this series >> to quantify the impact on the previously already supported pixel >> formats, particularly the 32-bit-per-pixel RGB variants. >> >> VKMS will be used more and more in CI for userspace projects, and >> performance actually matters there. >> >> I'm worrying that this performance degradation here is significant. I >> believe it is possible to keep blending with lines, if you add new >> line >> getters for reading from rotated, sub-sampled etc. images. That way >> you >> don't have to regress the most common formats' performance. >> >> I tested, and yes, it's significant for most of the tests. None of them >> timed out on my machine, but I agree that I have to improve this. Do you >> know which tests are the more "heavy"? > > I don't, but considering that various userspace projects (e.g. Wayland > compositors) want to use VKMS more and more in their own CI, looking > only at IGT is not enough. Every second saved per run is a tiny bit of > data center energy saved, or developers waiting less for results. > > I do have some expectations that for each KMS property, Wayland > compositors tend to use the "normal" property value more than any other > value. So if you test different pixel formats, you probably set > rotation to normal, since it's completely orthogonal in userspace. And > then you would test different rotations with just one pixel format. > > At least I would personally leave it to IGT to test all the possible > combinations of pixel formats + rotations + odd sizes + odd positions. > Wayland compositor CI wants to test the compositor internals, not VKMS > internals. > > While I understand performance is important and should be taken into > account seriously, I cannot understand how broken testing could be > considered better. Fast but inaccurate will always be significantly > less attractive to my eyes. AFAIK, neither the cover letter nor the commit log claimed it was fixing something broken, just that it was "better" (according to what criteria?). >> >> Sorry Maxime for this little missunderstanding, I will improve the commit >> message and cover letter for the v2. >> >>> Today's RGB implementation is only optimized in the line-by-line case >>> when there is no rotation. The logic is bit convoluted and may possibly >>> be slightly clarified with a per-format read_line() implementation, >>> at a very light performance cost. Such an improvement would definitely >>> benefit to the clarity of the code, especially when transformations >>> (especially the rotations) come into play because they would be clearly >>> handled differently instead of being "hidden" in the optimized logic. >>> Performances would not change much as this path is not optimized today >>> anyway (the pixel-oriented logic is already used in the rotation case). >>> >> >> [...] >> >> I think it would, if I understand what you mean. Ever since I proposed >> a line-by-line algorithm to improve the performance, I was thinking of >> per-format read_line() functions that would be selected outside of any >> loops. >> >> [...] >> >> I haven't looked at VKMS in a long time, and I am disappointed to find >> that vkms_compose_row() is calling plane->pixel_read() pixel-by-pixel. >> The reading vfunc should be called with many pixels at a time when the >> source FB layout allows it. The whole point of the line-based functions >> was that they repeat the innermost loop in every function body to make >> the per-pixel overhead as small as possible. The VKMS implementations >>
RE: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2
[Public] > -Original Message- > From: Ilpo Järvinen > Sent: Thursday, February 15, 2024 8:32 AM > To: Deucher, Alexander ; amd- > g...@lists.freedesktop.org; Daniel Vetter ; David Airlie > ; Dennis Dalessandro > ; dri- > de...@lists.freedesktop.org; Jason Gunthorpe ; Leon > Romanovsky ; linux-ker...@vger.kernel.org; linux- > r...@vger.kernel.org; Pan, Xinhui ; Koenig, Christian > > Cc: Ilpo Järvinen ; Lukas Wunner > > Subject: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2 > > Convert open coded RMW accesses for LNKCTL2 to use > pcie_capability_clear_and_set_word() which makes its easier to understand > what the code tries to do. > > LNKCTL2 is not really owned by any driver because it is a collection of > control > bits that PCI core might need to touch. RMW accessors already have support > for proper locking for a selected set of registers > (LNKCTL2 is not yet among them but likely will be in the future) to avoid > losing > concurrent updates. > > Suggested-by: Lukas Wunner > Signed-off-by: Ilpo Järvinen The radeon and amdgpu patches are: Acked-by: Alex Deucher Are you looking for me to pick them up or do you want to land them as part of some larger change? Either way is fine with me. Alex > --- > drivers/gpu/drm/radeon/cik.c | 40 ++-- > drivers/gpu/drm/radeon/si.c | 40 ++-- > 2 files changed, 30 insertions(+), 50 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c > index 10be30366c2b..b5e96a8fc2c1 100644 > --- a/drivers/gpu/drm/radeon/cik.c > +++ b/drivers/gpu/drm/radeon/cik.c > @@ -9592,28 +9592,18 @@ static void cik_pcie_gen3_enable(struct > radeon_device *rdev) > > PCI_EXP_LNKCTL_HAWD); > > /* linkctl2 */ > - pcie_capability_read_word(root, > PCI_EXP_LNKCTL2, > - ); > - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP > | > -PCI_EXP_LNKCTL2_TX_MARGIN); > - tmp16 |= (bridge_cfg2 & > - (PCI_EXP_LNKCTL2_ENTER_COMP | > -PCI_EXP_LNKCTL2_TX_MARGIN)); > - pcie_capability_write_word(root, > -PCI_EXP_LNKCTL2, > -tmp16); > - > - pcie_capability_read_word(rdev->pdev, > - PCI_EXP_LNKCTL2, > - ); > - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP > | > -PCI_EXP_LNKCTL2_TX_MARGIN); > - tmp16 |= (gpu_cfg2 & > - (PCI_EXP_LNKCTL2_ENTER_COMP | > -PCI_EXP_LNKCTL2_TX_MARGIN)); > - pcie_capability_write_word(rdev->pdev, > -PCI_EXP_LNKCTL2, > -tmp16); > + pcie_capability_clear_and_set_word(root, > PCI_EXP_LNKCTL2, > + > PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN, > +bridge_cfg2 > | > + > (PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN)); > + pcie_capability_clear_and_set_word(rdev- > >pdev, PCI_EXP_LNKCTL2, > + > PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN, > +gpu_cfg2 | > + > (PCI_EXP_LNKCTL2_ENTER_COMP | > + > PCI_EXP_LNKCTL2_TX_MARGIN)); > > tmp = RREG32_PCIE_PORT(PCIE_LC_CNTL4); > tmp &= ~LC_SET_QUIESCE; > @@ -9627,15 +9617,15 @@ static void cik_pcie_gen3_enable(struct > radeon_device *rdev) > speed_cntl &= ~LC_FORCE_DIS_SW_SPEED_CHANGE; > WREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL, speed_cntl); > > - pcie_capability_read_word(rdev->pdev, PCI_EXP_LNKCTL2, ); > - tmp16 &= ~PCI_EXP_LNKCTL2_TLS; > + tmp16 = 0; > if (speed_cap == PCIE_SPEED_8_0GT) > tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ > else if (speed_cap == PCIE_SPEED_5_0GT) > tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ > else > tmp16 |= PCI_EXP_LNKCTL2_TLS_2_5GT; /* gen1 */ > - pcie_capability_write_word(rdev->pdev, PCI_EXP_LNKCTL2, tmp16); > + pcie_capability_clear_and_set_word(rdev->pdev, PCI_EXP_LNKCTL2, > +PCI_EXP_LNKCTL2_TLS, tmp16); > > speed_cntl = RREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL); > speed_cntl |= LC_INITIATE_LINK_SPEED_CHANGE; diff --git
Re: [PATCH 7/9] media: dt-bindings: Add Chameleon v3 framebuffer
On Mon, Feb 12, 2024 at 01:13:21PM +, Paweł Anikiel wrote:
> The Chameleon v3 uses the framebuffer IP core to take the video signal
> from different sources and directly write frames into memory.
>
> Signed-off-by: Paweł Anikiel
> ---
> .../bindings/media/google,chv3-fb.yaml| 77 +++
> 1 file changed, 77 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/google,chv3-fb.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/google,chv3-fb.yaml
> b/Documentation/devicetree/bindings/media/google,chv3-fb.yaml
> new file mode 100644
> index ..ba6643cc7232
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/google,chv3-fb.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/google,chv3-fb.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Google Chameleon v3 video framebuffer
> +
> +maintainers:
> + - Paweł Anikiel
> +
> +properties:
> + compatible:
> +const: google,chv3-fb
> +
> + reg:
> +items:
> + - description: core registers
> + - description: irq registers
> +
> + interrupts:
> +maxItems: 1
> +
> + google,legacy-format:
> +type: boolean
> +description: The incoming video stream is in 32-bit padded mode.
> +
> + google,no-endpoint:
> +type: boolean
> +description:
> + The framebuffer isn't connected to a controllable endpoint.
> + The video interface still works, but EDID control is unavailable
> + and DV timing information only reports the active video width/height.
Why does this need a dedicated property? Is it not sufficient to check
that there are no endpoints in the devicetree?
Cheers,
Conor.
> +
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +allOf:
> + - if:
> + not:
> +required:
> + - google,no-endpoint
> +then:
> + required:
> +- port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +video@c0060500 {
> +compatible = "google,chv3-fb";
> +reg = <0xc0060500 0x100>,
> + <0xc0060f20 0x10>;
> +interrupts = ;
> +google,legacy-format;
> +google,no-endpoint;
> +};
> +
> + - |
> +video@c0060600 {
> +compatible = "google,chv3-fb";
> +reg = <0xc0060600 0x100>,
> + <0xc0060f30 0x10>;
> +interrupts = ;
> +
> +port {
> +fb_mst0_0: endpoint {
> +remote-endpoint = <_mst_0>;
> +};
> +};
> +};
> --
> 2.43.0.687.g38aa6559b0-goog
>
signature.asc
Description: PGP signature
Re: [PATCH 8/9] media: dt-bindings: Add Intel Displayport RX IP
Yo,
On Mon, Feb 12, 2024 at 01:13:22PM +, Paweł Anikiel wrote:
> The Intel Displayport RX IP is a part of the DisplayPort Intel FPGA IP
> Core. It implements a DisplayPort 1.4 receiver capable of HBR3 video
> capture and Multi-Stream Transport. The user guide can be found here:
>
> https://www.intel.com/programmable/technical-pdfs/683273.pdf
>
> Signed-off-by: Paweł Anikiel
> ---
> .../devicetree/bindings/media/intel,dprx.yaml | 125 ++
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/intel,dprx.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/intel,dprx.yaml
> b/Documentation/devicetree/bindings/media/intel,dprx.yaml
> new file mode 100644
> index ..3ed37e0a4a94
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/intel,dprx.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/intel,dprx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel DisplayPort RX IP
> +
> +maintainers:
> + - Paweł Anikiel
> +
> +properties:
> + compatible:
> +const: intel,dprx
Please version this compatible, given that is it for an FPGA IP.
I could not find an example of another intel IP that had versioning, but
there's plenty of xilinx stuff you can get inspiration from.
> + reg:
> +items:
> + - description: core registers
> + - description: irq registers
> +
> + interrupts:
> +maxItems: 1
> +
> + intel,has-mst:
Mostly this looks fine, but this property drew my eye.
Firstly, I'd probably call this "intel,multi-stream-support" rather than
"intel,has-mst".
> +type: boolean
> +description: The device supports Multi-Stream Transport
Secondly, there are many many configuration parameters for this IP,
but you have chosen to document just one.
Are all other configuration parameters currently in their default
states or ignored by the driver? If not, please at least document all
configuration settings that you rely on - for example the max stream
count or audio packet encoding.
> +
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: SST main link
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 0 or SST main link
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 1
> +
> + port@2:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 2
> +
> + port@3:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: MST virtual channel 3
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +allOf:
> + - if:
> + required:
> +- intel,has-mst
> +then:
> + required:
> +- ports
> +else:
> + required:
> +- port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +dprx@c0062000 {
"dprx" isn't a class of device, please try to use a generic node name
here.
Thanks,
Conor.
> +compatible = "intel,dprx";
> +reg = <0xc0062000 0x800>,
> + <0xc0060f80 0x10>;
> +interrupts = ;
> +intel,has-mst;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +dprx_mst_0: endpoint {
> +remote-endpoint = <_mst0_0>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +dprx_mst_1: endpoint {
> +remote-endpoint = <_mst1_0>;
> +};
> +};
> +
> +port@2 {
> +reg = <2>;
> +dprx_mst_2: endpoint {
> +remote-endpoint = <_mst2_0>;
> +};
> +};
> +
> +port@3 {
> +reg = <3>;
> +dprx_mst_3: endpoint {
> +remote-endpoint = <_mst3_0>;
> +};
> +};
> +};
> +};
> +
> + - |
> +dprx@c0064000 {
> +compatible = "intel,dprx";
> +reg = <0xc0064000 0x800>,
> + <0xc0060fe0 0x10>;
> +interrupts = ;
> +
> +port {
> +dprx_sst_0: endpoint {
> +remote-endpoint = <_sst_0>;
> +};
> +};
> +};
> --
> 2.43.0.687.g38aa6559b0-goog
>
signature.asc
Description: PGP signature
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
>
> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> wrote:
> >
> > Hi Maxime,
> >
> > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > proprietary firmware image, which is currently only available for Texas
> > > > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > > > prevent asking the user about this driver when configuring a kernel
> > > > without Texas Instruments K3 Multicore SoC support.
> > >
> > > This wasn't making sense the first time you sent it, and now that commit
> > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> >
> > I am so happy to be proven wrong!
> > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> >
> > > architectures and 5 platforms. In two months.
> >
> > That sounds like great progress, thanks a lot!
> >
> Geert,
>
> > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > but the original K3 AM62x one.
>
> I think PowerVR has a repo [1], but the last time I checked it, the
> BVNC for the firmware didn't match what was necessary for the GX6250
> on the RZ/G2M. I can't remember what the corresponding R-Car3 model
> is. I haven't tried recently because I was told more documentation
> for firmware porting would be delayed until everything was pushed into
> the kernel and Mesa. Maybe there is a better repo and/or newer
> firmware somewhere else.
>
I should have doubled checked the repo contents before I sent my last
e-mail , but it appears the firmware [2] for the RZ/G2M, might be
present now. I don't know if there are driver updates necessary. I
checked my e-mails, but I didn't see any notification, or I would have
tried it earlier. Either way, thank you Frank for adding it. I'll
try to test when I have some time.
> adam
>
> [1]
> https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
[2] -
https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
>
>
> >
> > Thanks again!
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > ge...@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like
> > that.
> > -- Linus Torvalds
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
wrote:
>
> Hi Maxime,
>
> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > proprietary firmware image, which is currently only available for Texas
> > > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > > prevent asking the user about this driver when configuring a kernel
> > > without Texas Instruments K3 Multicore SoC support.
> >
> > This wasn't making sense the first time you sent it, and now that commit
> > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
>
> I am so happy to be proven wrong!
> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
>
> > architectures and 5 platforms. In two months.
>
> That sounds like great progress, thanks a lot!
>
Geert,
> Where can I find these firmwares? Linux-firmware[1] seems to lack all
> but the original K3 AM62x one.
I think PowerVR has a repo [1], but the last time I checked it, the
BVNC for the firmware didn't match what was necessary for the GX6250
on the RZ/G2M. I can't remember what the corresponding R-Car3 model
is. I haven't tried recently because I was told more documentation
for firmware porting would be delayed until everything was pushed into
the kernel and Mesa. Maybe there is a better repo and/or newer
firmware somewhere else.
adam
[1]
https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
>
> Thanks again!
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH
On Thu, Feb 15, 2024 at 10:04:41AM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > admatec GmbH is a german supplier for industrial displays. > > Signed-off-by: Heiko Stuebner There's a fair few Admatec's it seems, so a link would be good: Link: https://www.admatec.de/ Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 1a0dc04f1db47..fef2e12b504ee 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -61,6 +61,8 @@ patternProperties: > description: Analog Devices, Inc. >"^adieng,.*": > description: ADI Engineering, Inc. > + "^admatec,.*": > +description: admatec GmbH >"^advantech,.*": > description: Advantech Corporation >"^aeroflexgaisler,.*": > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
Hi, On Thu, Feb 15, 2024 at 8:53 AM Neil Armstrong wrote: > > Hi Doug, > > On 15/02/2024 16:08, Doug Anderson wrote: > > Hi, > > > > On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote: > >> > >> On Wed, 14 Feb 2024, Doug Anderson wrote: > >>> Hi, > >>> > >>> On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote: > > On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson > wrote: > > > > If an eDP panel is not powered on then any attempts to talk to it over > > the DP AUX channel will timeout. Unfortunately these attempts may be > > quite slow. Userspace can initiate these attempts either via a > > /dev/drm_dp_auxN device or via the created i2c device. > > > > Making the DP AUX drivers timeout faster is a difficult proposition. > > In theory we could just poll the panel's HPD line in the AUX transfer > > function and immediately return an error there. However, this is > > easier said than done. For one thing, there's no hard requirement to > > hook the HPD line up for eDP panels and it's OK to just delay a fixed > > amount. For another thing, the HPD line may not be fast to probe. On > > parade-ps8640 we need to wait for the bridge chip's firmware to boot > > before we can get the HPD line and this is a slow process. > > > > The fact that the transfers are taking so long to timeout is causing > > real problems. The open source fwupd daemon sometimes scans DP busses > > looking for devices whose firmware need updating. If it happens to > > scan while a panel is turned off this scan can take a long time. The > > fwupd daemon could try to be smarter and only scan when eDP panels are > > turned on, but we can also improve the behavior in the kernel. > > > > Let's let eDP panels drivers specify that a panel is turned off and > > then modify the common AUX transfer code not to attempt a transfer in > > this case. > > > > Signed-off-by: Douglas Anderson > > --- > > Reviewed-by: Hsin-Yi Wang > >>> > >>> Thanks for the review! > >>> > >>> Given that this touches core DRM code and that I never got > >>> confirmation that Jani's concerns were addressed with my previous > >>> response, I'm still going to wait a little while before applying. I'm > >>> on vacation for most of next week, but if there are no further replies > >>> between now and then I'll plan to apply this to "drm-misc-next" the > >>> week of Feb 26th. If someone else wants to apply this before I do then > >>> I certainly won't object. Jani: if you feel this needs more discussion > >>> or otherwise object to this patch landing then please yell. Likewise > >>> if anyone else in the community wants to throw in their opinion, feel > >>> free. > >> > >> Sorry for dropping the ball after my initial response. I simply have not > >> had the time to look into this. > >> > >> It would be great to get, say, drm-misc maintainer ack on this before > >> merging. It's not fair for me to stall this any longer, I'll trust their > >> judgement. > >> > >> Reasonable? > > > > I'd be more than happy for one of the drm-misc maintainers to Ack. > > I'll move Maxime, Thomas, and Maarten to the "To:" line to see if that > > helps get through their filters. > > I'll like some test reports to be sure it doesn't break anything, > then I'll be happy to give my ack ! Sounds good. I know Eizan (CCed, but also a ChromeOS person) was going to poke at it a bit and seemed willing to provide a Tested-by. I'll let him chime in. ...but perhaps some better evidence that it's not breaking hardware is that we actually landed this into one (but not all) ChromeOS kernel trees [1] and it's rolled out to at least "beta" channel without anyone screaming. Normally we like things to land upstream before picking, but in this case we needed to land another patch to gather in-field data [2] that would have made the problem even worse. The kernel tree we landed on was the v5.15 tree, which is currently serving all Qualcomm sc7180-based Chromebooks, all Mediatek 8173 Chromebooks and all Mediatek 8186 Chromebooks. There are also a pile of x86 Chromebooks running our v5.15 kernel. This code shouldn't affect them because (unless I'm mistaken) they don't use the two affected panel drivers. In any case, I haven't heard any screams from them either. Given my landing plans of "the week of the 26th", this still gives another 1.5 weeks for any screams to reach my ears. ...or are you looking for non-ChromeOS test reports? I'm not sure how to encourage those. I suppose sometimes folks at Red Hat end up stumbling over similar panel problems to those of us in ChromeOS. Maybe +Javier would be interested in providing a Tested-by? [1] https://crrev.com/c/5277322 [2] https://crrev.com/c/5277736
Re: [PATCH 2/2] dt-bindings: display: panel-lvds: Add compatible for admatec 9904370 panel
On Thu, Feb 15, 2024 at 10:04:42AM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > The 9904379 is a 10.1" 1024x600 LVDS display using the standard > lvds properties. > > Signed-off-by: Heiko Stuebner Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/display/panel/panel-lvds.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > index 3fb24393529cd..155d8ffa8f6ef 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml > @@ -39,6 +39,8 @@ properties: >compatible: > items: >- enum: > + # Admatec 9904379 10.1" 1024x600 LVDS panel > + - admatec,9904379 >- auo,b101ew05 ># Chunghwa Picture Tubes Ltd. 7" WXGA (800x1280) TFT LCD LVDS panel >- chunghwa,claa070wp03xg > -- > 2.39.2 > signature.asc Description: PGP signature
[pull] drm/msm: drm-msm-fixes-2024-02-15 for v6.8-rc5
Hi Dave, Another fixes pull, this time actually including the GPU fixes left out of last week's fixes due to miss-applied label, plus addition of a tlb invalidation fix. Description below. The following changes since commit 8d35217149daa33358c284aca6a56d5ab92cfc6c: drm/msm/mdss: specify cfg bandwidth for SDM670 (2024-01-25 14:36:04 -0800) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2024-02-15 for you to fetch changes up to 8c7bfd8262319fd3f127a5380f593ea76f1b88a2: drm/msm: Wire up tlb ops (2024-02-15 08:51:31 -0800) Fixes for v6.8-rc5 GPU: - dmabuf vmap fix - a610 UBWC corruption fix (incorrect hbb) - revert a commit that was making GPU recovery unreliable - tlb invalidation fix Dmitry Baryshkov (1): drm/msm/a6xx: set highest_bank_bit to 13 for a610 Rob Clark (3): drm/msm/gem: Fix double resv lock aquire Revert "drm/msm/gpu: Push gpu lock down past runpm" drm/msm: Wire up tlb ops drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++-- drivers/gpu/drm/msm/msm_gpu.c | 11 +-- drivers/gpu/drm/msm/msm_iommu.c | 32 +--- drivers/gpu/drm/msm/msm_ringbuffer.c | 7 +-- 5 files changed, 42 insertions(+), 14 deletions(-)
Re: [PATCH 2/3] dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w
On Thu, Feb 15, 2024 at 10:05:14AM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > Add the compatible for the ltk101b4029w panel, that is really similar > to the ltk500hd1829. Please mention what makes the devices incompatible. "really similar" is vague and could be used for a device that was only cosmetically different. With that, Acked-by: Conor Dooley Cheers, Conor. > > Signed-off-by: Heiko Stuebner > --- > .../bindings/display/panel/leadtek,ltk500hd1829.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > index c5944b4d636c5..d589f16772145 100644 > --- > a/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.yaml > @@ -14,7 +14,9 @@ allOf: > > properties: >compatible: > -const: leadtek,ltk500hd1829 > +enum: > + - leadtek,ltk101b4029w > + - leadtek,ltk500hd1829 >reg: true >backlight: true >reset-gpios: true > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [PATCH v3 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On Thu, 15 Feb 2024 at 18:39, Abhinav Kumar wrote:
>
>
>
> On 2/15/2024 12:40 AM, Dmitry Baryshkov wrote:
> > On Wed, 14 Feb 2024 at 22:15, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 2/14/2024 11:39 AM, Dmitry Baryshkov wrote:
> >>> On Wed, 14 Feb 2024 at 20:04, Paloma Arellano
> >>> wrote:
>
> Add support to pack and send the VSC SDP packet for DP. This therefore
> allows the transmision of format information to the sinks which is
> needed for YUV420 support over DP.
>
> Changes in v3:
> - Create a new struct, msm_dp_sdp_with_parity, which holds the
> packing information for VSC SDP
> - Use drm_dp_vsc_sdp_pack() to pack the data into the new
> msm_dp_sdp_with_parity struct instead of specifically packing
> for YUV420 format
> - Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
> data using the new msm_dp_sdp_with_parity struct
>
> Changes in v2:
> - Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
> - Remove dp_sdp from the dp_catalog struct since this data is
> being allocated at the point used
> - Create a new function in dp_utils to pack the VSC SDP data
> into a buffer
> - Create a new function that packs the SDP header bytes into a
> buffer. This function is made generic so that it can be
> utilized by dp_audio
> header bytes into a buffer
> - Create a new function in dp_utils that takes the packed
> buffer
> and writes to the DP_GENERIC0_* registers
> - Split the dp_catalog_panel_config_vsc_sdp() function into two
> to disable/enable sending VSC SDP packets
> - Check the DP HW version using the original useage of
> dp_catalog_hw_revision() and correct the version checking
> logic
> - Rename dp_panel_setup_vsc_sdp() to
> dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
> currently VSC SDP is only being set up to support YUV420
> modes
>
> Signed-off-by: Paloma Arellano
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 113
> drivers/gpu/drm/msm/dp/dp_catalog.h | 7 ++
> drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 +
> drivers/gpu/drm/msm/dp/dp_panel.c | 55 ++
> drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
> drivers/gpu/drm/msm/dp/dp_utils.c | 48
> drivers/gpu/drm/msm/dp/dp_utils.h | 18 +
> 7 files changed, 248 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index 5d84c089e520a..61d5317efe683 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -901,6 +901,119 @@ int dp_catalog_panel_timing_cfg(struct dp_catalog
> *dp_catalog)
> return 0;
> }
>
> +static void dp_catalog_panel_send_vsc_sdp(struct dp_catalog *dp_catalog,
> + struct msm_dp_sdp_with_parity
> *msm_dp_sdp)
> +{
> + struct dp_catalog_private *catalog;
> + u32 val;
> +
> + if (!dp_catalog) {
> + DRM_ERROR("invalid input\n");
> + return;
> + }
> +
> + catalog = container_of(dp_catalog, struct dp_catalog_private,
> dp_catalog);
> +
> + val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB0) << HEADER_BYTE_0_BIT
> |
> + (msm_dp_sdp->pb.PB0 << PARITY_BYTE_0_BIT) |
> + (msm_dp_sdp->vsc_sdp.sdp_header.HB1) << HEADER_BYTE_1_BIT
> |
> + (msm_dp_sdp->pb.PB1 << PARITY_BYTE_1_BIT));
> + dp_write_link(catalog, MMSS_DP_GENERIC0_0, val);
> +
> + val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB2) << HEADER_BYTE_2_BIT
> |
> + (msm_dp_sdp->pb.PB2 << PARITY_BYTE_2_BIT) |
> + (msm_dp_sdp->vsc_sdp.sdp_header.HB3) << HEADER_BYTE_3_BIT
> |
> + (msm_dp_sdp->pb.PB3 << PARITY_BYTE_3_BIT));
> + dp_write_link(catalog, MMSS_DP_GENERIC0_1, val);
> >>>
> >>> I still think that this is not the way to do it. Could you please
> >>> extract the function that takes struct dp_sdp_header, calculates
> >>> padding and writes resulting data to the hardware? This way we can
> >>> reuse it later for all the dp_audio stuff.
> >>>
> >>
> >> hmmm ... dp_utils_pack_sdp_header() does that you are asking for right?
> >>
> >> OR are you asking for another function like:
> >>
> >> 1) rename dp_utils_pack_sdp_header() to dp_utils_calc_sdp_parity()
> >>
Re: [PATCH v2 1/6] dt-bindings: display/msm/gmu: Document Adreno 750 GMU
On Thu, Feb 15, 2024 at 10:20:23AM +0100, Neil Armstrong wrote: > Document the Adreno 750 GMU found on the SM8650 platform. > > Reviewed-by: Konrad Dybcio > Signed-off-by: Neil Armstrong Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/display/msm/gmu.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml > b/Documentation/devicetree/bindings/display/msm/gmu.yaml > index 4e1c25b42908..b3837368a260 100644 > --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml > +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml > @@ -224,6 +224,7 @@ allOf: > enum: >- qcom,adreno-gmu-730.1 >- qcom,adreno-gmu-740.1 > + - qcom,adreno-gmu-750.1 > then: >properties: > reg: > > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH 1/2] drm/i915/gt: Disable HW load balancing for CCS
On Thu, Feb 15, 2024 at 02:59:23PM +0100, Andi Shyti wrote:
> The hardware should not dynamically balance the load between CCS
> engines. Wa_16016805146 recommends disabling it across all
Is this the right workaround number? When I check the database, this
workaround was rejected on both DG2-G10 and DG2-G11, and doesn't even
have an entry for DG2-G12.
There are other workarounds that sound somewhat related to load
balancing (e.g., part 3 of Wa_14019159160), but what's asked there is
more involved than just setting one register bit and conflicts a bit
with the second patch of this series.
Matt
> platforms.
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Signed-off-by: Andi Shyti
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Matt Roper
> Cc: # v6.2+
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 50962cfd1353..cf709f6c05ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1478,6 +1478,7 @@
>
> #define GEN12_RCU_MODE _MMIO(0x14800)
> #define GEN12_RCU_MODE_CCS_ENABLE REG_BIT(0)
> +#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
>
> #define CHV_FUSE_GT _MMIO(VLV_GUNIT_BASE + 0x2168)
> #define CHV_FGT_DISABLE_SS0(1 << 10)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d67d44611c28..7f42c8015f71 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2988,6 +2988,12 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1,
>GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
> }
> +
> + /*
> + * Wa_16016805146: disable the CCS load balancing
> + * indiscriminately for all the platforms
> + */
> + wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
> }
>
> static void
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi Maxime,
On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > proprietary firmware image, which is currently only available for Texas
> > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > prevent asking the user about this driver when configuring a kernel
> > without Texas Instruments K3 Multicore SoC support.
>
> This wasn't making sense the first time you sent it, and now that commit
> log is just plain wrong. We have firmwares for the G6110, GX6250,
> GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> Renesas, Mediatek, Rockchip, TI and StarFive, so across three
I am so happy to be proven wrong!
Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> architectures and 5 platforms. In two months.
That sounds like great progress, thanks a lot!
Where can I find these firmwares? Linux-firmware[1] seems to lack all
but the original K3 AM62x one.
Thanks again!
[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
Hi Doug, On 15/02/2024 16:08, Doug Anderson wrote: Hi, On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote: On Wed, 14 Feb 2024, Doug Anderson wrote: Hi, On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote: On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson wrote: If an eDP panel is not powered on then any attempts to talk to it over the DP AUX channel will timeout. Unfortunately these attempts may be quite slow. Userspace can initiate these attempts either via a /dev/drm_dp_auxN device or via the created i2c device. Making the DP AUX drivers timeout faster is a difficult proposition. In theory we could just poll the panel's HPD line in the AUX transfer function and immediately return an error there. However, this is easier said than done. For one thing, there's no hard requirement to hook the HPD line up for eDP panels and it's OK to just delay a fixed amount. For another thing, the HPD line may not be fast to probe. On parade-ps8640 we need to wait for the bridge chip's firmware to boot before we can get the HPD line and this is a slow process. The fact that the transfers are taking so long to timeout is causing real problems. The open source fwupd daemon sometimes scans DP busses looking for devices whose firmware need updating. If it happens to scan while a panel is turned off this scan can take a long time. The fwupd daemon could try to be smarter and only scan when eDP panels are turned on, but we can also improve the behavior in the kernel. Let's let eDP panels drivers specify that a panel is turned off and then modify the common AUX transfer code not to attempt a transfer in this case. Signed-off-by: Douglas Anderson --- Reviewed-by: Hsin-Yi Wang Thanks for the review! Given that this touches core DRM code and that I never got confirmation that Jani's concerns were addressed with my previous response, I'm still going to wait a little while before applying. I'm on vacation for most of next week, but if there are no further replies between now and then I'll plan to apply this to "drm-misc-next" the week of Feb 26th. If someone else wants to apply this before I do then I certainly won't object. Jani: if you feel this needs more discussion or otherwise object to this patch landing then please yell. Likewise if anyone else in the community wants to throw in their opinion, feel free. Sorry for dropping the ball after my initial response. I simply have not had the time to look into this. It would be great to get, say, drm-misc maintainer ack on this before merging. It's not fair for me to stall this any longer, I'll trust their judgement. Reasonable? I'd be more than happy for one of the drm-misc maintainers to Ack. I'll move Maxime, Thomas, and Maarten to the "To:" line to see if that helps get through their filters. I'll like some test reports to be sure it doesn't break anything, then I'll be happy to give my ack ! Thanks, Neil -Doug
Re: [RFC 0/5] Introduce drm sharpening property
On Thu, Feb 15, 2024 at 11:37:54AM -0500, Harry Wentland wrote: > Adding a couple of compositor devs as they might be interested in this. > > On 2024-02-14 06:24, Nemesa Garg wrote: > > Many a times images are blurred or upscaled content is also not as > > crisp as original rendered image. Traditional sharpening techniques often > > apply a uniform level of enhancement across entire image, which sometimes > > result in over-sharpening of some areas and potential loss of natural > > details. > > > > Intel has come up with Display Engine based adaptive sharpening filter > > with minimal power and performance impact. From LNL onwards, the Display > > hardware can use one of the pipe scaler for adaptive sharpness filter. > > This can be used for both gaming and non-gaming use cases like photos, > > image viewing. It works on a region of pixels depending on the tap size. > > > > This RFC is an attempt to introduce an adaptive sharpness solution which > > helps in improving the image quality. For this new CRTC property is added. > > I don't think CRTC is the right place for this. Scaling tends to be more > of a plane thing. Planes can be scaled independently, or is that not the > case for Intel? Or does Intel HW do this sharpening operation independent > of any scaling, on the entire output? We can scale either individual planes, or the entire crtc. > > > The user can set this property with desired sharpness strength value with > > 0-255. A value of 1 representing minimum sharpening strength and 255 > > representing maximum sharpness strength. A strength value of 0 means no > > sharpening or sharpening feature disabled. > > It works on a region of pixels depending on the tap size. The coefficients > > are used to generate an alpha value which is used to blend the sharpened > > image to original image. > > > > Userspace implementation for sharpening feature and IGT implementation > > is in progress. > > It would be very helpful to have an idea how this looks in userspace, and > which compositors will implement this. Someone will probably need to spend some real time thinking how this interacts with the scaling filter propery (eg. if we want to extend that property with new values) and the laptop panel scaling mode property. We also want to implement the margin properties for external displays which also involves scaling. Ie. we need some kind of consistent story how all those things will work together. > > Harry > > > > > Nemesa Garg (5): > > drm: Introduce sharpeness mode property > > drm/i915/display/: Compute the scaler filter coefficients > > drm/i915/dispaly/: Enable the second scaler > > drm/i915/display/: Add registers and compute the strength > > drm/i915/display: Load the lut values and enable sharpness > > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 + > > drivers/gpu/drm/drm_crtc.c| 17 ++ > > drivers/gpu/drm/i915/Makefile | 1 + > > drivers/gpu/drm/i915/display/intel_crtc.c | 3 + > > drivers/gpu/drm/i915/display/intel_display.c | 20 +- > > .../drm/i915/display/intel_display_types.h| 11 + > > .../drm/i915/display/intel_modeset_verify.c | 1 + > > .../drm/i915/display/intel_sharpen_filter.c | 214 ++ > > .../drm/i915/display/intel_sharpen_filter.h | 31 +++ > > drivers/gpu/drm/i915/display/skl_scaler.c | 86 ++- > > drivers/gpu/drm/i915/display/skl_scaler.h | 1 + > > drivers/gpu/drm/i915/i915_reg.h | 19 ++ > > drivers/gpu/drm/xe/Makefile | 1 + > > include/drm/drm_crtc.h| 17 ++ > > 14 files changed, 416 insertions(+), 10 deletions(-) > > create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.c > > create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.h > > -- Ville Syrjälä Intel
Re: Re: [PULL] drm-misc-fixes
Hi Maxime,
On Thu, Feb 15, 2024 at 5:09 PM Maxime Ripard wrote:
On Thu, Feb 15, 2024 at 01:41:24PM +0100, Geert Uytterhoeven wrote:
> > On Thu, 15 Feb 2024, Maxime Ripard wrote:
> > > Matthew Auld (1):
> > > drm/tests/drm_buddy: add alloc_contiguous test
> >
> > Please drop this one.
> >
> > nore...@ellerman.id.au reported a build failure on m68k (and presumably
> > other 32-bit platforms) in next-20240215:
> >
> > ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > undefined!
> > ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > undefined!
> >
> > Reverting commit a64056bb5a3215bd ("drm/tests/drm_buddy: add
> > alloc_contiguous test") fixes the issue.
>
> From a quick cross-compile test with arm(32), it seems to work there
> interestingly:
>
> ./tools/testing/kunit/kunit.py run \
> --kunitconfig=drivers/gpu/drm//tests \
> --cross_compile arm-linux-gnu- --arch arm
shmobile_defconfig + CONFIG_DRM_KUNIT_TEST=y + CONFIG_KUNIT=y:
arm-linux-gnueabihf-ld: drivers/gpu/drm/tests/drm_buddy_test.o: in
function `drm_test_buddy_alloc_contiguous':
drm_buddy_test.c:(.text+0xe0): undefined reference to `__aeabi_uldivmod'
> But I agree, with should wait for a fix or a revert before merging this.
Great, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
On 2/15/2024 12:40 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 22:15, Abhinav Kumar wrote:
On 2/14/2024 11:39 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v3:
- Create a new struct, msm_dp_sdp_with_parity, which holds the
packing information for VSC SDP
- Use drm_dp_vsc_sdp_pack() to pack the data into the new
msm_dp_sdp_with_parity struct instead of specifically packing
for YUV420 format
- Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
data using the new msm_dp_sdp_with_parity struct
Changes in v2:
- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
- Remove dp_sdp from the dp_catalog struct since this data is
being allocated at the point used
- Create a new function in dp_utils to pack the VSC SDP data
into a buffer
- Create a new function that packs the SDP header bytes into a
buffer. This function is made generic so that it can be
utilized by dp_audio
header bytes into a buffer
- Create a new function in dp_utils that takes the packed buffer
and writes to the DP_GENERIC0_* registers
- Split the dp_catalog_panel_config_vsc_sdp() function into two
to disable/enable sending VSC SDP packets
- Check the DP HW version using the original useage of
dp_catalog_hw_revision() and correct the version checking
logic
- Rename dp_panel_setup_vsc_sdp() to
dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
currently VSC SDP is only being set up to support YUV420 modes
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 113
drivers/gpu/drm/msm/dp/dp_catalog.h | 7 ++
drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 +
drivers/gpu/drm/msm/dp/dp_panel.c | 55 ++
drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
drivers/gpu/drm/msm/dp/dp_utils.c | 48
drivers/gpu/drm/msm/dp/dp_utils.h | 18 +
7 files changed, 248 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5d84c089e520a..61d5317efe683 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -901,6 +901,119 @@ int dp_catalog_panel_timing_cfg(struct dp_catalog
*dp_catalog)
return 0;
}
+static void dp_catalog_panel_send_vsc_sdp(struct dp_catalog *dp_catalog,
+ struct msm_dp_sdp_with_parity
*msm_dp_sdp)
+{
+ struct dp_catalog_private *catalog;
+ u32 val;
+
+ if (!dp_catalog) {
+ DRM_ERROR("invalid input\n");
+ return;
+ }
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB0) << HEADER_BYTE_0_BIT |
+ (msm_dp_sdp->pb.PB0 << PARITY_BYTE_0_BIT) |
+ (msm_dp_sdp->vsc_sdp.sdp_header.HB1) << HEADER_BYTE_1_BIT |
+ (msm_dp_sdp->pb.PB1 << PARITY_BYTE_1_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_0, val);
+
+ val = ((msm_dp_sdp->vsc_sdp.sdp_header.HB2) << HEADER_BYTE_2_BIT |
+ (msm_dp_sdp->pb.PB2 << PARITY_BYTE_2_BIT) |
+ (msm_dp_sdp->vsc_sdp.sdp_header.HB3) << HEADER_BYTE_3_BIT |
+ (msm_dp_sdp->pb.PB3 << PARITY_BYTE_3_BIT));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_1, val);
I still think that this is not the way to do it. Could you please
extract the function that takes struct dp_sdp_header, calculates
padding and writes resulting data to the hardware? This way we can
reuse it later for all the dp_audio stuff.
hmmm ... dp_utils_pack_sdp_header() does that you are asking for right?
OR are you asking for another function like:
1) rename dp_utils_pack_sdp_header() to dp_utils_calc_sdp_parity()
2) dp_utils_pack_sdp() takes two u32 to pack the header and parity
together and we move the << HEADER_BYTE_xx | part to it
dp_catalog_panel_send_vsc_sdp() just uses these two u32 to write the
headers.
I'm really looking for the following function:
void dp_catalog_panel_send_vsc_sdp(struct dp_catalog *dp_catalog,
struct dp_sdp *dp_sdp)
{
dp_write_vsc_header(dp_catalog, MMSS_DP_GENERIC0_0, _sdp->sdp_header);
dp_write_vsc_packet(dp_catalog, MMSS_DP_GENERIC0_2, dp_sdp);
}
Then dp_audio functions will be able to fill struct dp_sdp_header and
call dp_write_vsc_header (or whatever other name for that function)
directly.
I think there is some misunderstanding here.
Audio does not write or use generic_0 registers. It uses audio infoframe
SDP
Re: [RFC 0/5] Introduce drm sharpening property
Adding a couple of compositor devs as they might be interested in this. On 2024-02-14 06:24, Nemesa Garg wrote: > Many a times images are blurred or upscaled content is also not as > crisp as original rendered image. Traditional sharpening techniques often > apply a uniform level of enhancement across entire image, which sometimes > result in over-sharpening of some areas and potential loss of natural > details. > > Intel has come up with Display Engine based adaptive sharpening filter > with minimal power and performance impact. From LNL onwards, the Display > hardware can use one of the pipe scaler for adaptive sharpness filter. > This can be used for both gaming and non-gaming use cases like photos, > image viewing. It works on a region of pixels depending on the tap size. > > This RFC is an attempt to introduce an adaptive sharpness solution which > helps in improving the image quality. For this new CRTC property is added. I don't think CRTC is the right place for this. Scaling tends to be more of a plane thing. Planes can be scaled independently, or is that not the case for Intel? Or does Intel HW do this sharpening operation independent of any scaling, on the entire output? > The user can set this property with desired sharpness strength value with > 0-255. A value of 1 representing minimum sharpening strength and 255 > representing maximum sharpness strength. A strength value of 0 means no > sharpening or sharpening feature disabled. > It works on a region of pixels depending on the tap size. The coefficients > are used to generate an alpha value which is used to blend the sharpened > image to original image. > > Userspace implementation for sharpening feature and IGT implementation > is in progress. It would be very helpful to have an idea how this looks in userspace, and which compositors will implement this. Harry > > Nemesa Garg (5): > drm: Introduce sharpeness mode property > drm/i915/display/: Compute the scaler filter coefficients > drm/i915/dispaly/: Enable the second scaler > drm/i915/display/: Add registers and compute the strength > drm/i915/display: Load the lut values and enable sharpness > > drivers/gpu/drm/drm_atomic_uapi.c | 4 + > drivers/gpu/drm/drm_crtc.c| 17 ++ > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_crtc.c | 3 + > drivers/gpu/drm/i915/display/intel_display.c | 20 +- > .../drm/i915/display/intel_display_types.h| 11 + > .../drm/i915/display/intel_modeset_verify.c | 1 + > .../drm/i915/display/intel_sharpen_filter.c | 214 ++ > .../drm/i915/display/intel_sharpen_filter.h | 31 +++ > drivers/gpu/drm/i915/display/skl_scaler.c | 86 ++- > drivers/gpu/drm/i915/display/skl_scaler.h | 1 + > drivers/gpu/drm/i915/i915_reg.h | 19 ++ > drivers/gpu/drm/xe/Makefile | 1 + > include/drm/drm_crtc.h| 17 ++ > 14 files changed, 416 insertions(+), 10 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.c > create mode 100644 drivers/gpu/drm/i915/display/intel_sharpen_filter.h >
Re: [PATCH] Revert "drm/panel-edp: Add auo_b116xa3_mode"
Hi, On Wed, Feb 14, 2024 at 1:41 PM Doug Anderson wrote: > > Hi, > > On Tue, Feb 13, 2024 at 11:24 PM Hsin-Yi Wang wrote: > > > > This reverts commit 70e0d5550f5cec301ad116703b840a539fe985dc. > > > > The overridden mode fixes the panel glitching issue on mt8186 chromebook. > > However, it causes the internal display not working on mt8173 chromebook. > > Revert the overridden mode for now to let mt8173 have a functional display. > > > > Signed-off-by: Hsin-Yi Wang > > --- > > drivers/gpu/drm/panel/panel-edp.c | 19 ++- > > 1 file changed, 2 insertions(+), 17 deletions(-) > > Given that the breakage for affected mt8173 Chromebooks is pretty bad > (black screen), I'll plan to just wait an extra day for any screams > and then I'll apply to drm-misc-fixes. > > Reviewed-by: Douglas Anderson It caused a merge conflict against drm-misc-fixes since other panels have been added in the meantime. I'm going to stick this in drm-misc-next to avoid the merge headache. If someone is affected and really wants this in fixes, please shout and we can figure out how to make it happen. 1a5e81de180e Revert "drm/panel-edp: Add auo_b116xa3_mode" -Doug
Re: [PATCH 3/3] drm/panel: ltk500hd1829: add panel type for ltk101b4029w
On 2/15/2024 1:05 AM, Heiko Stuebner wrote:
From: Heiko Stuebner
The ltk101b4029w ist a 10.1 inch DSI panel and shares the same supplies
and startup timings with the existing ltk500hd1829.
So simply add it as a variant with its own init sequence and display-mode.
Signed-off-by: Heiko Stuebner
Hi Heiko,
Acked-by: Jessica Zhang
Thanks,
Jessica Zhang
---
.../drm/panel/panel-leadtek-ltk500hd1829.c| 196 ++
1 file changed, 196 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
index 42f4e2584af18..7bc538b7c6b7c 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -43,6 +43,198 @@ struct ltk500hd1829 {
bool prepared;
};
+static const struct ltk500hd1829_cmd ltk101b4029w_init[] = {
+ /* Page0 */
+ { 0xE0, 0x00 },
+ /* PASSWORD */
+ { 0xE1, 0x93 },
+ { 0xE2, 0x65 },
+ { 0xE3, 0xF8 },
+ { 0x80, 0x03 }, /* 0X03:4-LANE; 0X02:3-LANE; 0X01:2-LANE */
+ /* Page1 */
+ { 0xE0, 0x01 },
+ /* Set VCOM */
+ { 0x00, 0x00 },
+ { 0x01, 0x6F },
+ /* Set Gamma Power, VGMP,VGMN,VGSP,VGSN */
+ { 0x17, 0x00 },
+ { 0x18, 0xAF }, /* 4.3V */
+ { 0x19, 0x01 }, /* 0.3V */
+ { 0x1A, 0x00 },
+ { 0x1B, 0xAF }, /* 4.3V */
+ { 0x1C, 0x01 }, /* 0.3V */
+ /* Set Gate Power */
+ { 0x1F, 0x3E }, /* VGH_R = 15V */
+ { 0x20, 0x28 }, /* VGL_R = -12V */
+ { 0x21, 0x28 }, /* VGL_R2 = -12V */
+ { 0x22, 0x7E },
+ /* SETPANEL */
+ { 0x35, 0x26 },
+ { 0x37, 0x09 },
+ /* SET RGBCYC */
+ { 0x38, 0x04 },
+ { 0x39, 0x00 },
+ { 0x3A, 0x01 },
+ { 0x3C, 0x7C },
+ { 0x3D, 0xFF },
+ { 0x3E, 0xFF },
+ { 0x3F, 0x7F },
+ /* Set TCON */
+ { 0x40, 0x06 }, /* RSO = 800 RGB */
+ { 0x41, 0xA0 }, /* LN = 640->1280 line */
+ { 0x42, 0x81 },
+ { 0x43, 0x08 }, /* VFP = 8 */
+ { 0x44, 0x0B }, /* VBP = 12 */
+ { 0x45, 0x28 }, /* HBP = 40 */
+ /* power voltage */
+ { 0x55, 0x0F }, /* DCDCM = 0001, JD PWR_IC */
+ { 0x57, 0x69 },
+ { 0x59, 0x0A }, /* VCL = -2.9V */
+ { 0x5A, 0x28 }, /* VGH = 15V */
+ { 0x5B, 0x14 }, /* VGL = -11V */
+ /* Gamma */
+ { 0x5D, 0x7C },
+ { 0x5E, 0x65 },
+ { 0x5F, 0x55 },
+ { 0x60, 0x47 },
+ { 0x61, 0x43 },
+ { 0x62, 0x32 },
+ { 0x63, 0x34 },
+ { 0x64, 0x1C },
+ { 0x65, 0x33 },
+ { 0x66, 0x31 },
+ { 0x67, 0x30 },
+ { 0x68, 0x4E },
+ { 0x69, 0x3C },
+ { 0x6A, 0x44 },
+ { 0x6B, 0x35 },
+ { 0x6C, 0x31 },
+ { 0x6D, 0x23 },
+ { 0x6E, 0x11 },
+ { 0x6F, 0x00 },
+ { 0x70, 0x7C },
+ { 0x71, 0x65 },
+ { 0x72, 0x55 },
+ { 0x73, 0x47 },
+ { 0x74, 0x43 },
+ { 0x75, 0x32 },
+ { 0x76, 0x34 },
+ { 0x77, 0x1C },
+ { 0x78, 0x33 },
+ { 0x79, 0x31 },
+ { 0x7A, 0x30 },
+ { 0x7B, 0x4E },
+ { 0x7C, 0x3C },
+ { 0x7D, 0x44 },
+ { 0x7E, 0x35 },
+ { 0x7F, 0x31 },
+ { 0x80, 0x23 },
+ { 0x81, 0x11 },
+ { 0x82, 0x00 },
+/* Page2, for GIP */
+ { 0xE0, 0x02 },
+ /* GIP_L Pin mapping */
+ { 0x00, 0x1E },
+ { 0x01, 0x1E },
+ { 0x02, 0x41 },
+ { 0x03, 0x41 },
+ { 0x04, 0x43 },
+ { 0x05, 0x43 },
+ { 0x06, 0x1F },
+ { 0x07, 0x1F },
+ { 0x08, 0x35 },
+ { 0x09, 0x1F },
+ { 0x0A, 0x15 },
+ { 0x0B, 0x15 },
+ { 0x0C, 0x1F },
+ { 0x0D, 0x47 },
+ { 0x0E, 0x47 },
+ { 0x0F, 0x45 },
+ { 0x10, 0x45 },
+ { 0x11, 0x4B },
+ { 0x12, 0x4B },
+ { 0x13, 0x49 },
+ { 0x14, 0x49 },
+ { 0x15, 0x1F },
+ /* GIP_R Pin mapping */
+ { 0x16, 0x1E },
+ { 0x17, 0x1E },
+ { 0x18, 0x40 },
+ { 0x19, 0x40 },
+ { 0x1A, 0x42 },
+ { 0x1B, 0x42 },
+ { 0x1C, 0x1F },
+ { 0x1D, 0x1F },
+ { 0x1E, 0x35 },
+ { 0x1F, 0x1F },
+ { 0x20, 0x15 },
+ { 0x21, 0x15 },
+ { 0x22, 0x1f },
+ { 0x23, 0x46 },
+ { 0x24, 0x46 },
+ { 0x25, 0x44 },
+ { 0x26, 0x44 },
+ { 0x27, 0x4A },
+ { 0x28, 0x4A },
+ { 0x29, 0x48 },
+ { 0x2A, 0x48 },
+ { 0x2B, 0x1F },
+ /* GIP Timing */
+ { 0x58, 0x40 },
+ { 0x5B, 0x30 },
+ { 0x5C, 0x03 },
+ { 0x5D, 0x30 },
+ { 0x5E, 0x01 },
+ { 0x5F, 0x02 },
+ { 0x63, 0x14 },
+ { 0x64, 0x6A },
+ { 0x67, 0x73 },
+ { 0x68, 0x05 },
+ { 0x69, 0x14 },
+ { 0x6A, 0x6A },
+ { 0x6B, 0x08 },
+ { 0x6C, 0x00 },
+ { 0x6D, 0x00 },
+ { 0x6E, 0x00 },
+ { 0x6F, 0x88 },
+ { 0x77, 0xDD },
+ { 0x79, 0x0E },
+ { 0x7A, 0x03 },
Re: [PATCH 1/3] drm/panel: ltk500hd1829: make room for more similar panels
On 2/15/2024 1:05 AM, Heiko Stuebner wrote:
From: Heiko Stuebner
There exist more dsi-panels from Leadtek sharing supplies and timings
with only the panel-mode and init commands differing.
So make room in the driver to also keep variants here instead of
requiring additional drivers per panel.
Signed-off-by: Heiko Stuebner
Hi Heiko,
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
.../drm/panel/panel-leadtek-ltk500hd1829.c| 73 ---
1 file changed, 47 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
index 39e408c9f762f..42f4e2584af18 100644
--- a/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
+++ b/drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -21,25 +22,32 @@
#include
#include
+struct ltk500hd1829_cmd {
+ char cmd;
+ char data;
+};
+
+struct ltk500hd1829_desc {
+ const struct drm_display_mode *mode;
+ const struct ltk500hd1829_cmd *init;
+ unsigned int num_init;
+};
+
struct ltk500hd1829 {
struct device *dev;
struct drm_panel panel;
struct gpio_desc *reset_gpio;
struct regulator *vcc;
struct regulator *iovcc;
+ const struct ltk500hd1829_desc *panel_desc;
bool prepared;
};
-struct ltk500hd1829_cmd {
- char cmd;
- char data;
-};
-
/*
* There is no description in the Reference Manual about these commands.
* We received them from the vendor, so just use them as is.
*/
-static const struct ltk500hd1829_cmd init_code[] = {
+static const struct ltk500hd1829_cmd ltk500hd1829_init[] = {
{ 0xE0, 0x00 },
{ 0xE1, 0x93 },
{ 0xE2, 0x65 },
@@ -260,6 +268,26 @@ static const struct ltk500hd1829_cmd init_code[] = {
{ 0x35, 0x00 },
};
+static const struct drm_display_mode ltk500hd1829_mode = {
+ .hdisplay = 720,
+ .hsync_start= 720 + 50,
+ .hsync_end = 720 + 50 + 50,
+ .htotal = 720 + 50 + 50 + 50,
+ .vdisplay = 1280,
+ .vsync_start= 1280 + 30,
+ .vsync_end = 1280 + 30 + 4,
+ .vtotal = 1280 + 30 + 4 + 12,
+ .clock = 69217,
+ .width_mm = 62,
+ .height_mm = 110,
+};
+
+static const struct ltk500hd1829_desc ltk500hd1829_data = {
+ .mode = _mode,
+ .init = ltk500hd1829_init,
+ .num_init = ARRAY_SIZE(ltk500hd1829_init),
+};
+
static inline
struct ltk500hd1829 *panel_to_ltk500hd1829(struct drm_panel *panel)
{
@@ -324,8 +352,8 @@ static int ltk500hd1829_prepare(struct drm_panel *panel)
/* tRT: >= 5ms */
usleep_range(5000, 6000);
- for (i = 0; i < ARRAY_SIZE(init_code); i++) {
- ret = mipi_dsi_generic_write(dsi, _code[i],
+ for (i = 0; i < ctx->panel_desc->num_init; i++) {
+ ret = mipi_dsi_generic_write(dsi, >panel_desc->init[i],
sizeof(struct ltk500hd1829_cmd));
if (ret < 0) {
dev_err(panel->dev, "failed to write init cmds: %d\n",
ret);
@@ -359,31 +387,17 @@ static int ltk500hd1829_prepare(struct drm_panel *panel)
return ret;
}
-static const struct drm_display_mode default_mode = {
- .hdisplay = 720,
- .hsync_start= 720 + 50,
- .hsync_end = 720 + 50 + 50,
- .htotal = 720 + 50 + 50 + 50,
- .vdisplay = 1280,
- .vsync_start= 1280 + 30,
- .vsync_end = 1280 + 30 + 4,
- .vtotal = 1280 + 30 + 4 + 12,
- .clock = 69217,
- .width_mm = 62,
- .height_mm = 110,
-};
-
static int ltk500hd1829_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
struct ltk500hd1829 *ctx = panel_to_ltk500hd1829(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, _mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->panel_desc->mode);
if (!mode) {
dev_err(ctx->dev, "failed to add mode %ux%u@%u\n",
- default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(_mode));
+ ctx->panel_desc->mode->hdisplay,
ctx->panel_desc->mode->vdisplay,
+ drm_mode_vrefresh(ctx->panel_desc->mode));
return -ENOMEM;
}
@@ -413,6 +427,10 @@ static int ltk500hd1829_probe(struct mipi_dsi_device *dsi)
if (!ctx)
return -ENOMEM;
+ ctx->panel_desc = of_device_get_match_data(dev);
+ if (!ctx->panel_desc)
+ return -EINVAL;
+
ctx->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset_gpio)) {
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Hi, On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote: > Using the Imagination Technologies PowerVR Series 6 GPU requires a > proprietary firmware image, which is currently only available for Texas > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to > prevent asking the user about this driver when configuring a kernel > without Texas Instruments K3 Multicore SoC support. This wasn't making sense the first time you sent it, and now that commit log is just plain wrong. We have firmwares for the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least) Renesas, Mediatek, Rockchip, TI and StarFive, so across three architectures and 5 platforms. In two months. We won't keep up, and there's no point in trying to. Especially so when the only benefit is for make defconfig users to hit 'enter' one time less. Maxime signature.asc Description: PGP signature
Re: Re: [PULL] drm-misc-fixes
Hi,
On Thu, Feb 15, 2024 at 01:41:24PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Thu, 15 Feb 2024, Maxime Ripard wrote:
> > Here's this week drm-misc-fixes PR
> >
> > Maxime
> >
> > drm-misc-fixes-2024-02-15:
> > A suspend/resume error fix for ivpu, a couple of scheduler fixes for
> > nouveau, a patch to support large page arrays in prime, a uninitialized
> > variable fix in crtc, a locking fix in rockchip/vop2 and a buddy
> > allocator error reporting fix.
> > The following changes since commit 5f8408aca66772d3aa9b4831577b2ac5ec41bcd9:
> >
> > accel/ivpu: Add job status for jobs aborted by the driver (2024-02-06
> > 13:37:34 +0100)
> >
> > are available in the Git repository at:
> >
> > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2024-02-15
> >
> > for you to fetch changes up to a64056bb5a3215bd31c8ce17d609ba0f4d5c55ea:
> >
> > drm/tests/drm_buddy: add alloc_contiguous test (2024-02-14 15:22:21 +0100)
> >
> >
> > A suspend/resume error fix for ivpu, a couple of scheduler fixes for
> > nouveau, a patch to support large page arrays in prime, a uninitialized
> > variable fix in crtc, a locking fix in rockchip/vop2 and a buddy
> > allocator error reporting fix.
>
> > Matthew Auld (1):
> > drm/tests/drm_buddy: add alloc_contiguous test
>
> Please drop this one.
>
> nore...@ellerman.id.au reported a build failure on m68k (and presumably
> other 32-bit platforms) in next-20240215:
>
> ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> undefined!
> ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> undefined!
>
> Reverting commit a64056bb5a3215bd ("drm/tests/drm_buddy: add
> alloc_contiguous test") fixes the issue.
From a quick cross-compile test with arm(32), it seems to work there
interestingly:
./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm//tests \
--cross_compile arm-linux-gnu- --arch arm
But I agree, with should wait for a fix or a revert before merging this.
Maxime
signature.asc
Description: PGP signature
Re: (subset) [PATCH v2] drm: Spelling s/hardward/hardware/g
On Thu, 15 Feb 2024 14:24:15 +0100, Geert Uytterhoeven wrote: > Fix misspellings of "hardware". > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [PATCH v3 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
On 2/15/2024 12:45 AM, Dmitry Baryshkov wrote:
On Wed, 14 Feb 2024 at 20:04, Paloma Arellano wrote:
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 19 ++
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 7e7796561009a..6280c6be6dca9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -222,6 +222,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP && phys_enc->hw_cdm &&
+
msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
* This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f02411b062c4c..e29bc4bd39208 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -415,8 +415,15 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
static void dpu_encoder_phys_vid_enable(struct dpu_encoder_phys *phys_enc)
{
struct dpu_hw_ctl *ctl;
+ struct dpu_hw_cdm *hw_cdm;
+ const struct dpu_format *fmt = NULL;
+ u32 fmt_fourcc = DRM_FORMAT_RGB888;
ctl = phys_enc->hw_ctl;
+ hw_cdm = phys_enc->hw_cdm;
+ if (hw_cdm)
I thought that Abhinav proposed to drop the if(hw_cdm) condition here.
LGTM otherwise.
Yes I did.
This needs to be fixed in v4.
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc);
+ fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VIDENC(phys_enc, "\n");
@@ -425,6 +432,8 @@ static void dpu_encoder_phys_vid_enable(struct
dpu_encoder_phys *phys_enc)
Re: [PATCH] drm/msm: Wire up tlb ops
On Wed, Feb 14, 2024 at 11:34 PM Johan Hovold wrote:
>
> On Tue, Feb 13, 2024 at 09:23:40AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > The brute force iommu_flush_iotlb_all() was good enough for unmap, but
> > in some cases a map operation could require removing a table pte entry
> > to replace with a block entry. This also requires tlb invalidation.
> > Missing this was resulting an obscure iova fault on what should be a
> > valid buffer address.
> >
> > Thanks to Robin Murphy for helping me understand the cause of the fault.
> >
> > Cc: Robin Murphy
> > Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
>
> Sounds like you're missing a
>
> Cc: sta...@vger.kernel.org
>
> here? Or is there some reason not to backport this fix (to 5.9 and later
> kernels)?
No reason, I just expected the Fixes tag was sufficient
BR,
-R
> > Signed-off-by: Rob Clark
>
> Johan
[PATCH v2] drm/atomic-helpers: fix uaf in drm_atomic_helper_wait_for_vblanks
To briefly summarize the issues reported by syzbot, there are two task call
stacks
as follows:
Task A Task B
--
drm_atomic_commit
drm_atomic_helper_commit
commit_work
commit_tail
drm_atomic_helper_commit_tail commit_tail
drm_atomic_helper_commit_tail
drm_client_modeset_commit_atomic
drm_atomic_state_default_clear
drm_atomic_helper_wait_for_vblanks
When two prerequisites are met simultaneously, the current issue will be
triggered:
1. There is an overlap in the memory range occupied by the crtcs member set
contained
in the instance state of "struct drm_atomic_state" created by Task A and
Task B
2. The context of drm_atomic_helper_commit_tail() has no lock protection,
resulting
in the instance state->crtcs sub item being released by other task
The solution is to add a lock in drm_atomic_helper_commit_tail() to ensure that
there is no other task interference when accessing the instance state.
Reported-and-tested-by: syzbot+0f999d26a4fd79c3a...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis
---
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 39ef0a6addeb..b16ff9020097 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1743,7 +1743,9 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ static DEFINE_MUTEX(lock);
+ mutex_lock();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state, 0);
@@ -1757,6 +1759,7 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
+ mutex_unlock();
}
EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
--
2.43.0
[pull] amdgpu, amdkfd drm-fixes-6.8
Hi Dave, Sima, Fixes for 6.8. The following changes since commit 841c35169323cd833294798e58b9bf63fa4fa1de: Linux 6.8-rc4 (2024-02-11 12:18:13 -0800) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.8-2024-02-15 for you to fetch changes up to 86e8af451be2786482e7ba6556bbb8257c5c7ccf: drm/amdgpu: Fix implicit assumtion in gfx11 debug flags (2024-02-14 18:02:41 -0500) amd-drm-fixes-6.8-2024-02-15: amdgpu: - Add some better debugging support for PSR and panel power saving features - ABM fix - PSR fixes - Suspend/resume fixes - Link training fix - Aspect ratio fix - DCN 3.5 fixes - VCN 4.x fix - GFX 11 fix - Misc display fixes - Misc small fixes amdkfd: - Cache size reporting fix - SIMD distribution fix Dan Carpenter (1): drm/amd/display: Fix && vs || typos Hamza Mahfooz (3): drm/amd/display: add panel_power_savings sysfs entry to eDP connectors drm/amdgpu: respect the abmlevel module parameter value if it is set drm/amdgpu: make damage clips support configurable Kent Russell (1): drm/amdkfd: Fix L2 cache size reporting in GFX9.4.3 Mario Limonciello (2): drm/amd: Stop evicting resources on APUs in suspend Revert "drm/amd: flush any delayed gfxoff on suspend entry" Nicholas Kazlauskas (1): drm/amd/display: Increase ips2_eval delay for DCN35 Rajneesh Bhardwaj (2): drm/amdkfd: update SIMD distribution algo for GFXIP 9.4.2 onwards drm/amdgpu: Fix implicit assumtion in gfx11 debug flags Roman Li (1): drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr Sohaib Nadeem (2): Revert "drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz" drm/amd/display: fixed integer types and null check locations Srinivasan Shanmugam (5): drm/amd/display: Initialize 'wait_time_microsec' variable in link_dp_training_dpia.c drm/amd/display: Fix possible use of uninitialized 'max_chunks_fbc_mode' in 'calculate_bandwidth()' drm/amd/display: Fix possible buffer overflow in 'find_dcfclk_for_voltage()' drm/amd/display: Fix possible NULL dereference on device remove/driver unload drm/amdgpu/display: Initialize gamma correction mode variable in dcn30_get_gamcor_current() Thong (1): drm/amdgpu/soc21: update VCN 4 max HEVC encoding resolution Tom Chung (1): drm/amd/display: Preserve original aspect ratio in create stream Zhikai Zhai (1): drm/amd/display: Add align done check drivers/gpu/drm/amd/amdgpu/amdgpu.h| 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 15 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 24 - drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 9 +- drivers/gpu/drm/amd/amdgpu/soc21.c | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c| 9 ++ drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 + .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 103 - drivers/gpu/drm/amd/display/dc/basics/dce_calcs.c | 2 +- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 16 ++-- .../drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 2 + .../amd/display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 15 ++- .../gpu/drm/amd/display/dc/dcn30/dcn30_dpp_cm.c| 5 +- .../gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 2 +- .../drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c| 4 +- .../gpu/drm/amd/display/dc/link/link_validation.c | 2 +- .../display/dc/link/protocols/link_dp_training.c | 5 +- .../dc/link/protocols/link_dp_training_dpia.c | 2 +- .../amd/display/dc/resource/dcn35/dcn35_resource.c | 2 +- 23 files changed, 209 insertions(+), 48 deletions(-)
Re: [PATCH v2 2/6] drm/i915/mst: improve debug logging of DP MST mode detect
On Thu, Feb 15, 2024 at 01:46:48PM +0200, Jani Nikula wrote:
> On Wed, 14 Feb 2024, Ville Syrjälä wrote:
> > On Tue, Feb 13, 2024 at 01:30:57PM +0200, Jani Nikula wrote:
> >> Rename intel_dp_can_mst() to intel_dp_mst_detect(), and move all DP MST
> >> detect debug logging there. Debug log the sink's MST capability,
> >> including single-stream sideband messaging support, and the decision
> >> whether to enable MST mode or not. Do this regardless of whether we're
> >> actually enabling MST or not.
> >>
> >> Cc: Arun R Murthy
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dp.c | 45 +
> >> 1 file changed, 31 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index a1c304f451bd..944f566525dd 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -4007,31 +4007,48 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >> intel_dp->downstream_ports) == 0;
> >> }
> >>
> >> +static const char *intel_dp_mst_mode_str(enum drm_dp_mst_mode mst_mode)
> >> +{
> >> + if (mst_mode == DRM_DP_SST_SIDEBAND_MSG)
> >> + return "single-stream sideband messaging";
> >> + else
> >> + return str_yes_no(mst_mode == DRM_DP_MST);
> >
> > I wonder if this should also just say "sst"/"mst"/"sst sideband" etc.
> > Shrug.
> >
> > Reviewed-by: Ville Syrjälä
>
> I realize there's an issue here.
>
> intel_dp_detect_dpcd() bails out early for !drm_dp_is_branch(), before
> the intel_dp_can_mst() call. (Renamed intel_dp_mst_detect() here.)
>
> We'll still happily call intel_dp_configure_mst() later also for
> !branch.
>
> We'll need to call intel_dp_mst_detect() earlier and/or somehow combine
> these together. I don't think branch devices need to support MST, but I
> think MST devices need to support branching. And single-stream sideband
> support does not mean branching.
>
> The intention of this patch was to improve MST debug logging, but the
> end result is that it reduces it! Auch.
>
> I wonder if we should branch (eh) the detect earlier for eDP, SST and
> MST/branch paths. Just to make it easier for our poor brains to follow.
Hmm. The sink count check is another case as well. If the device
has a local sink, or somehting connected to its DFP(s) it should
declare sink count >= 1.
--
Ville Syrjälä
Intel
Re: [PATCH] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
Hi, On Thu, Feb 15, 2024 at 2:24 AM Jani Nikula wrote: > > On Wed, 14 Feb 2024, Doug Anderson wrote: > > Hi, > > > > On Tue, Feb 13, 2024 at 10:25 PM Hsin-Yi Wang wrote: > >> > >> On Wed, Feb 14, 2024 at 2:23 PM Douglas Anderson > >> wrote: > >> > > >> > If an eDP panel is not powered on then any attempts to talk to it over > >> > the DP AUX channel will timeout. Unfortunately these attempts may be > >> > quite slow. Userspace can initiate these attempts either via a > >> > /dev/drm_dp_auxN device or via the created i2c device. > >> > > >> > Making the DP AUX drivers timeout faster is a difficult proposition. > >> > In theory we could just poll the panel's HPD line in the AUX transfer > >> > function and immediately return an error there. However, this is > >> > easier said than done. For one thing, there's no hard requirement to > >> > hook the HPD line up for eDP panels and it's OK to just delay a fixed > >> > amount. For another thing, the HPD line may not be fast to probe. On > >> > parade-ps8640 we need to wait for the bridge chip's firmware to boot > >> > before we can get the HPD line and this is a slow process. > >> > > >> > The fact that the transfers are taking so long to timeout is causing > >> > real problems. The open source fwupd daemon sometimes scans DP busses > >> > looking for devices whose firmware need updating. If it happens to > >> > scan while a panel is turned off this scan can take a long time. The > >> > fwupd daemon could try to be smarter and only scan when eDP panels are > >> > turned on, but we can also improve the behavior in the kernel. > >> > > >> > Let's let eDP panels drivers specify that a panel is turned off and > >> > then modify the common AUX transfer code not to attempt a transfer in > >> > this case. > >> > > >> > Signed-off-by: Douglas Anderson > >> > --- > >> > >> Reviewed-by: Hsin-Yi Wang > > > > Thanks for the review! > > > > Given that this touches core DRM code and that I never got > > confirmation that Jani's concerns were addressed with my previous > > response, I'm still going to wait a little while before applying. I'm > > on vacation for most of next week, but if there are no further replies > > between now and then I'll plan to apply this to "drm-misc-next" the > > week of Feb 26th. If someone else wants to apply this before I do then > > I certainly won't object. Jani: if you feel this needs more discussion > > or otherwise object to this patch landing then please yell. Likewise > > if anyone else in the community wants to throw in their opinion, feel > > free. > > Sorry for dropping the ball after my initial response. I simply have not > had the time to look into this. > > It would be great to get, say, drm-misc maintainer ack on this before > merging. It's not fair for me to stall this any longer, I'll trust their > judgement. > > Reasonable? I'd be more than happy for one of the drm-misc maintainers to Ack. I'll move Maxime, Thomas, and Maarten to the "To:" line to see if that helps get through their filters. -Doug
Re: Re: Re: Re: Re: Re: Re: [PATCH v5 08/44] drm/connector: hdmi: Add Broadcast RGB property
On Thu, Feb 15, 2024 at 11:53:17AM +0100, Maxime Ripard wrote: > On Tue, Feb 13, 2024 at 10:38:56AM +0200, Ville Syrjälä wrote: > > On Mon, Feb 12, 2024 at 05:53:48PM +0100, Maxime Ripard wrote: > > > On Mon, Feb 12, 2024 at 05:49:33PM +0200, Ville Syrjälä wrote: > > > > On Mon, Feb 12, 2024 at 11:01:07AM +0100, Maxime Ripard wrote: > > > > > On Fri, Feb 09, 2024 at 09:34:35PM +0100, Sebastian Wick wrote: > > > > > > On Mon, Feb 05, 2024 at 10:39:38AM +0100, Maxime Ripard wrote: > > > > > > > On Fri, Feb 02, 2024 at 06:37:52PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote: > > > > > > > > > On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote: > > > > > > > > > > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard > > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 15, 2024 at 03:37:20PM +0100, Sebastian Wick > > > > > > > > > > > wrote: > > > > > > > > > > > > > > /** > > > > > > > > > > > > > > * DOC: HDMI connector properties > > > > > > > > > > > > > > * > > > > > > > > > > > > > > + * Broadcast RGB > > > > > > > > > > > > > > + * Indicates the RGB Quantization Range (Full > > > > > > > > > > > > > > vs Limited) used. > > > > > > > > > > > > > > + * Infoframes will be generated according to > > > > > > > > > > > > > > that value. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * The value of this property can be one of > > > > > > > > > > > > > > the following: > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Automatic: > > > > > > > > > > > > > > + * RGB Range is selected > > > > > > > > > > > > > > automatically based on the mode > > > > > > > > > > > > > > + * according to the HDMI > > > > > > > > > > > > > > specifications. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Full: > > > > > > > > > > > > > > + * Full RGB Range is forced. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Limited 16:235: > > > > > > > > > > > > > > + * Limited RGB Range is forced. > > > > > > > > > > > > > > Unlike the name suggests, > > > > > > > > > > > > > > + * this works for any number of > > > > > > > > > > > > > > bits-per-component. > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > + * Drivers can set up this property by calling > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > drm_connector_attach_broadcast_rgb_property(). > > > > > > > > > > > > > > + * > > > > > > > > > > > > > > > > > > > > > > > > > > This is a good time to document this in more detail. > > > > > > > > > > > > > There might be two > > > > > > > > > > > > > different things being affected: > > > > > > > > > > > > > > > > > > > > > > > > > > 1. The signalling (InfoFrame/SDP/...) > > > > > > > > > > > > > 2. The color pipeline processing > > > > > > > > > > > > > > > > > > > > > > > > > > All values of Broadcast RGB always affect the color > > > > > > > > > > > > > pipeline processing > > > > > > > > > > > > > such that a full-range input to the CRTC is converted > > > > > > > > > > > > > to either full- or > > > > > > > > > > > > > limited-range, depending on what the monitor is > > > > > > > > > > > > > supposed to accept. > > > > > > > > > > > > > > > > > > > > > > > > > > When automatic is selected, does that mean that there > > > > > > > > > > > > > is no signalling, > > > > > > > > > > > > > or that the signalling matches what the monitor is > > > > > > > > > > > > > supposed to accept > > > > > > > > > > > > > according to the spec? Also, is this really HDMI > > > > > > > > > > > > > specific? > > > > > > > > > > > > > > > > > > > > > > > > > > When full or limited is selected and the monitor > > > > > > > > > > > > > doesn't support the > > > > > > > > > > > > > signalling, what happens? > > > > > > > > > > > > > > > > > > > > > > > > Forgot to mention: user-space still has no control over > > > > > > > > > > > > RGB vs YCbCr on > > > > > > > > > > > > the cable, so is this only affecting RGB? If not, how > > > > > > > > > > > > does it affect > > > > > > > > > > > > YCbCr? > > > > > > > > > > > > > > > > > > > > > > So I dug a bit into both the i915 and vc4 drivers, and it > > > > > > > > > > > looks like if > > > > > > > > > > > we're using a YCbCr format, i915 will always use a > > > > > > > > > > > limited range while > > > > > > > > > > > vc4 will follow the value of the property. > > > > > > > > > > > > > > > > > > > > The property is literally called "Broadcast *RGB*". > > > > > > > > > > That should explain why it's only affecting RGB. > > > > > > > > > > > > > > > > > > Right. And the limited range option is called "Limited > > > > > > > > > 16:235" despite > > > > > > > > > being usable on bpc > 8 bits. Naming errors occurs, and > > > > > > > > > history happens > > > > > > > > >
Re: [PATCH] backlight: ktd2801: depend on GPIOLIB
On Thursday, February 15, 2024 2:31:37 PM CET Linus Walleij wrote:
> On Tue, Feb 13, 2024 at 7:13 PM Duje Mihanović
wrote:
> > LEDS_EXPRESSWIRE depends on GPIOLIB, and so must anything selecting it:
> >
> > WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> >
> > Depends on [n]: NEW_LEDS [=y] && GPIOLIB [=n]
> > Selected by [m]:
> > - BACKLIGHT_KTD2801 [=m] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE
[=m]
> >
> > Fixes: 66c76c1cd984 ("backlight: Add Kinetic KTD2801 backlight support")
> > Signed-off-by: Duje Mihanović
>
> Acked-by: Linus Walleij
>
> Technically you can also select GPIOLIB, because it is available on
> all platforms, so it may be easier for users, but then you never know
> which GPIOs you get in practice.
Now that I think of it, wouldn't that be the better solution? I opted for
"depends on" only because Arnd did the same in his KTD2692 patch, but if
select is better (and it seems to be for users) then I'd go for that in both
patches.
Regards,
--
Duje
Re: [PATCH 0/6 V4] fdinfo shared stats
On Thu, Feb 15, 2024 at 9:18 AM Christian König wrote: > > Am 12.02.24 um 22:04 schrieb Alex Deucher: > > We had a request to add shared buffer stats to fdinfo for amdgpu and > > while implementing that, Christian mentioned that just looking at > > the GEM handle count doesn't take into account buffers shared with other > > subsystems like V4L or RDMA. Those subsystems don't use GEM, so it > > doesn't really matter from a GPU top perspective, but it's more > > correct if you actually want to see shared buffers. > > > > After further discussions, add a helper and update all fdinfo > > implementations to use that helper for consistency. > > > > v4: switch drm_gem_object_is_shared_for_memory_stats() to an inline function > > I'm still not sure if looking at the actual handle count is the right > approach, but it's certainly better than before. Well, it's consistent across drivers. > > So Reviewed-by: Christian König for the > entire series. > > Should I take this through drm-misc-next? Yes, please. Thanks, Alex > > Regards, > Christian. > > > > > Alex Deucher (6): > >Documentation/gpu: Update documentation on drm-shared-* > >drm: add drm_gem_object_is_shared_for_memory_stats() helper > >drm: update drm_show_memory_stats() for dma-bufs > >drm/amdgpu: add shared fdinfo stats > >drm/i915: Update shared stats to use the new gem helper > >drm/xe: Update shared stats to use the new gem helper > > > > Documentation/gpu/drm-usage-stats.rst | 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 4 > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++ > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 6 ++ > > drivers/gpu/drm/drm_file.c | 2 +- > > drivers/gpu/drm/i915/i915_drm_client.c | 2 +- > > drivers/gpu/drm/xe/xe_drm_client.c | 2 +- > > include/drm/drm_gem.h | 13 + > > 8 files changed, 38 insertions(+), 4 deletions(-) > > >
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On Thu, 15 Feb 2024, Ville Syrjälä wrote:
> On Wed, Feb 14, 2024 at 03:57:54PM -0600, Mario Limonciello wrote:
>> +static int
>> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
>> +{
>> +struct drm_connector *connector = data;
>> +struct drm_device *ddev = connector->dev;
>> +struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
>> +unsigned char start = block * EDID_LENGTH;
>> +void *edid;
>> +int r;
>> +
>> +if (!acpidev)
>> +return -ENODEV;
>> +
>> +switch (connector->connector_type) {
>> +case DRM_MODE_CONNECTOR_LVDS:
>> +case DRM_MODE_CONNECTOR_eDP:
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
>
> We could have other types of connectors that want this too.
> I don't see any real benefit in having this check tbh. Drivers
> should simply notset the flag on connectors where it won't work,
> and only the driver can really know that.
Agreed.
>> const struct drm_edid *drm_edid_read(struct drm_connector *connector)
>> {
>> +const struct drm_edid *drm_edid = NULL;
>> +
>> if (drm_WARN_ON(connector->dev, !connector->ddc))
>> return NULL;
>>
>> -return drm_edid_read_ddc(connector, connector->ddc);
>> +if (connector->acpi_edid_allowed)
>
> That should probably be called 'prefer_acpi_edid' or something
> since it's the first choice when the flag is set.
>
> But I'm not so sure there's any real benefit in having this
> flag at all. You anyway have to modify the driver to use this,
> so why not just have the driver do the call directly instead of
> adding this extra detour via the flag?
Heh, round and round we go [1].
BR,
Jani.
[1] https://lore.kernel.org/r/87sf23auxv@intel.com
--
Jani Nikula, Intel
Re: [PATCH 0/6 V4] fdinfo shared stats
Am 12.02.24 um 22:04 schrieb Alex Deucher: We had a request to add shared buffer stats to fdinfo for amdgpu and while implementing that, Christian mentioned that just looking at the GEM handle count doesn't take into account buffers shared with other subsystems like V4L or RDMA. Those subsystems don't use GEM, so it doesn't really matter from a GPU top perspective, but it's more correct if you actually want to see shared buffers. After further discussions, add a helper and update all fdinfo implementations to use that helper for consistency. v4: switch drm_gem_object_is_shared_for_memory_stats() to an inline function I'm still not sure if looking at the actual handle count is the right approach, but it's certainly better than before. So Reviewed-by: Christian König for the entire series. Should I take this through drm-misc-next? Regards, Christian. Alex Deucher (6): Documentation/gpu: Update documentation on drm-shared-* drm: add drm_gem_object_is_shared_for_memory_stats() helper drm: update drm_show_memory_stats() for dma-bufs drm/amdgpu: add shared fdinfo stats drm/i915: Update shared stats to use the new gem helper drm/xe: Update shared stats to use the new gem helper Documentation/gpu/drm-usage-stats.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 6 ++ drivers/gpu/drm/drm_file.c | 2 +- drivers/gpu/drm/i915/i915_drm_client.c | 2 +- drivers/gpu/drm/xe/xe_drm_client.c | 2 +- include/drm/drm_gem.h | 13 + 8 files changed, 38 insertions(+), 4 deletions(-)
Re: [PATCH v6 3/5] drm: Add support to get EDID from ACPI
On Wed, 14 Feb 2024, Mario Limonciello wrote:
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops. Drivers that prefer to
> fetch this EDID can set a bit on the drm_connector to indicate that
> the DRM EDID helpers should try to fetch it and it is preferred if
> it's present.
I just replied to a previous version of the patch [1]. Looks like all
the comments there still hold.
BR,
Jani.
[1] https://lore.kernel.org/r/87eddd6d41@intel.com
>
> Signed-off-by: Mario Limonciello
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/drm_edid.c | 109 +---
> include/drm/drm_connector.h | 6 ++
> include/drm/drm_edid.h | 1 +
> 4 files changed, 109 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 872edb47bb53..3db89e6af01d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -8,6 +8,7 @@
> menuconfig DRM
> tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
> support)"
> depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> + depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> select DRM_PANEL_ORIENTATION_QUIRKS
> select DRM_KMS_HELPER if DRM_FBDEV_EMULATION
> select FB_CORE if DRM_FBDEV_EMULATION
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 923c4423151c..cdc30c6d05d5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -28,6 +28,7 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -2188,6 +2189,58 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned
> int block, size_t len)
> return ret == xfers ? 0 : -1;
> }
>
> +/**
> + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
> + * @data: struct drm_connector
> + * @buf: EDID data buffer to be filled
> + * @block: 128 byte EDID block to start fetching from
> + * @len: EDID data buffer length to fetch
> + *
> + * Try to fetch EDID information by calling acpi_video_get_edid() function.
> + *
> + * Return: 0 on success or error code on failure.
> + */
> +static int
> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
> +{
> + struct drm_connector *connector = data;
> + struct drm_device *ddev = connector->dev;
> + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
> + unsigned char start = block * EDID_LENGTH;
> + void *edid;
> + int r;
> +
> + if (!acpidev)
> + return -ENODEV;
> +
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_LVDS:
> + case DRM_MODE_CONNECTOR_eDP:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /* fetch the entire edid from BIOS */
> + r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1, );
> + if (r < 0) {
> + DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
> + return r;
> + }
> + if (len > r || start > r || start + len > r) {
> + r = -EINVAL;
> + goto cleanup;
> + }
> +
> + memcpy(buf, edid + start, len);
> + r = 0;
> +
> +cleanup:
> + kfree(edid);
> +
> + return r;
> +}
> +
> static void connector_bad_edid(struct drm_connector *connector,
> const struct edid *edid, int num_blocks)
> {
> @@ -2621,7 +2674,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
> * @connector: connector we're probing
> * @adapter: I2C adapter to use for DDC
> *
> - * Poke the given I2C channel to grab EDID data if possible. If found,
> + * If the connector allows it, try to fetch EDID data using ACPI. If not
> found
> + * poke the given I2C channel to grab EDID data if possible. If found,
> * attach it to the connector.
> *
> * Return: Pointer to valid EDID or NULL if we couldn't find any.
> @@ -2629,20 +2683,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
> struct edid *drm_get_edid(struct drm_connector *connector,
> struct i2c_adapter *adapter)
> {
> - struct edid *edid;
> + struct edid *edid = NULL;
>
> if (connector->force == DRM_FORCE_OFF)
> return NULL;
>
> - if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> - return NULL;
> + if (connector->acpi_edid_allowed)
> + edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
> connector, NULL);
> +
> + if (!edid) {
> + if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> + return NULL;
> + edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid,
> adapter, NULL);
> + }
>
> - edid = _drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter,
> NULL);
> drm_connector_update_edid_property(connector, edid);
> return edid;
> }
> EXPORT_SYMBOL(drm_get_edid);
>
Re: [PATCH v5 1/3] drm: Add support to get EDID from ACPI
On Sat, 10 Feb 2024, Mario Limonciello wrote:
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops. Drivers that prefer to
> fetch this EDID can set a bit on the drm_connector to indicate that
> the DRM EDID helpers should try to fetch it and it is preferred if
> it's present.
>
> Signed-off-by: Mario Limonciello
> ---
> v1->v2:
> * Split code from previous amdgpu specific helper to generic drm helper.
> v2->v3:
> * Add an extra select to fix a variety of randconfig errors found from
>LKP robot.
> v3->v4:
> * Return struct drm_edid
> v4->v5:
> * Rename to drm_edid_read_acpi
> * Drop selects
> ---
> drivers/gpu/drm/Kconfig | 7 +++
> drivers/gpu/drm/drm_edid.c | 113 +---
> include/drm/drm_connector.h | 6 ++
> include/drm/drm_edid.h | 1 +
> 4 files changed, 119 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 2520db0b776e..a49740c528b9 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -103,6 +103,13 @@ config DRM_KMS_HELPER
> help
> CRTC helpers for KMS drivers.
>
> +config DRM_ACPI_HELPER
> + tristate "ACPI support in DRM"
> + depends on DRM
> + depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> + help
> + ACPI helpers for DRM drivers.
> +
> config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
> bool "Enable refcount backtrace history in the DP MST helpers"
> depends on STACKTRACE_SUPPORT
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 69c68804023f..096c278b6f66 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -28,6 +28,7 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -2188,6 +2189,62 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned
> int block, size_t len)
> return ret == xfers ? 0 : -1;
> }
>
> +/**
> + * drm_do_probe_acpi_edid() - get EDID information via ACPI _DDC
> + * @data: struct drm_connector
> + * @buf: EDID data buffer to be filled
> + * @block: 128 byte EDID block to start fetching from
> + * @len: EDID data buffer length to fetch
> + *
> + * Try to fetch EDID information by calling acpi_video_get_edid() function.
> + *
> + * Return: 0 on success or error code on failure.
> + */
> +static int
> +drm_do_probe_acpi_edid(void *data, u8 *buf, unsigned int block, size_t len)
> +{
> + struct drm_connector *connector = data;
> + struct drm_device *ddev = connector->dev;
> + struct acpi_device *acpidev = ACPI_COMPANION(ddev->dev);
> + unsigned char start = block * EDID_LENGTH;
> + void *edid;
> + int r;
> +
> + if (!acpidev)
> + return -ENODEV;
> +
> + switch (connector->connector_type) {
> + case DRM_MODE_CONNECTOR_LVDS:
> + case DRM_MODE_CONNECTOR_eDP:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + /* fetch the entire edid from BIOS */
> + if (IS_REACHABLE(CONFIG_DRM_ACPI_HELPER)) {
> + r = acpi_video_get_edid(acpidev, ACPI_VIDEO_DISPLAY_LCD, -1,
> );
> + if (r < 0) {
> + DRM_DEBUG_KMS("Failed to get EDID from ACPI: %d\n", r);
> + return -EINVAL;
> + }
> + } else {
> + r = -EOPNOTSUPP;
> + }
> + if (len > r || start > r || start + len > r) {
> + r = -EINVAL;
> + goto cleanup;
> + }
> +
> + memcpy(buf, edid + start, len);
> + r = 0;
> +
> +cleanup:
> + kfree(edid);
> +
> + return r;
> +}
> +
> static void connector_bad_edid(struct drm_connector *connector,
> const struct edid *edid, int num_blocks)
> {
> @@ -2621,7 +2678,8 @@ EXPORT_SYMBOL(drm_probe_ddc);
> * @connector: connector we're probing
> * @adapter: I2C adapter to use for DDC
> *
> - * Poke the given I2C channel to grab EDID data if possible. If found,
> + * If the connector allows it, try to fetch EDID data using ACPI. If not
> found
> + * poke the given I2C channel to grab EDID data if possible. If found,
> * attach it to the connector.
> *
> * Return: Pointer to valid EDID or NULL if we couldn't find any.
> @@ -2629,20 +2687,50 @@ EXPORT_SYMBOL(drm_probe_ddc);
> struct edid *drm_get_edid(struct drm_connector *connector,
> struct i2c_adapter *adapter)
> {
> - struct edid *edid;
> + struct edid *edid = NULL;
>
> if (connector->force == DRM_FORCE_OFF)
> return NULL;
>
> - if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
> - return NULL;
> + if (connector->acpi_edid_allowed)
> + edid = _drm_do_get_edid(connector, drm_do_probe_acpi_edid,
> connector, NULL);
> +
> + if (!edid) {
> + if (connector->force == DRM_FORCE_UNSPECIFIED &&
> !drm_probe_ddc(adapter))
[PATCH 2/2] drm/i915/gt: Set default CCS mode '1'
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS rather than the
actual number. As of now, this change affects only DG2.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: # v6.2+
---
drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 17 +
drivers/gpu/drm/i915/i915_query.c | 5 +++--
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index a425db5ed3a2..e19df4ef47f6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -168,6 +168,14 @@ static void init_unused_rings(struct intel_gt *gt)
}
}
+static void intel_gt_apply_ccs_mode(struct intel_gt *gt)
+{
+ if (!IS_DG2(gt->i915))
+ return;
+
+ intel_uncore_write(gt->uncore, XEHP_CCS_MODE, 0);
+}
+
int intel_gt_init_hw(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -195,6 +203,9 @@ int intel_gt_init_hw(struct intel_gt *gt)
intel_gt_init_swizzling(gt);
+ /* Configure CCS mode */
+ intel_gt_apply_ccs_mode(gt);
+
/*
* At least 830 can leave some of the unused rings
* "active" (ie. head != tail) after resume which
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index cf709f6c05ae..c148113770ea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1605,6 +1605,8 @@
#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
#define GEN12_CAGF_MASK REG_GENMASK(19, 11)
+#define XEHP_CCS_MODE _MMIO(0x14804)
+
#define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN12_HECI_2 (30)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e81b3b2858ac..0853ffd3cb8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -396,6 +396,23 @@ static inline struct intel_gt *to_gt(const struct
drm_i915_private *i915)
(engine__); \
(engine__) = rb_to_uabi_engine(rb_next(&(engine__)->uabi_node)))
+/*
+ * Exclude unavailable engines.
+ *
+ * Only the first CCS engine is utilized due to the disabling of CCS auto load
+ * balancing. As a result, all CCS engines operate collectively, functioning
+ * essentially as a single CCS engine, hence the count of active CCS engines is
+ * considered '1'.
+ * Currently, this applies to platforms with more than one CCS engine,
+ * specifically DG2.
+ */
+#define for_each_available_uabi_engine(engine__, i915__) \
+ for_each_uabi_engine(engine__, i915__) \
+ if ((IS_DG2(i915__)) && \
+ ((engine__)->uabi_class == I915_ENGINE_CLASS_COMPUTE) && \
+ ((engine__)->uabi_instance)) { } \
+ else
+
#define INTEL_INFO(i915) ((i915)->__info)
#define RUNTIME_INFO(i915) (&(i915)->__runtime)
#define DRIVER_CAPS(i915) (&(i915)->caps)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index fa3e937ed3f5..2d41bda626a6 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -124,6 +124,7 @@ static int query_geometry_subslices(struct drm_i915_private
*i915,
return fill_topology_info(sseu, query_item,
sseu->geometry_subslice_mask);
}
+
static int
query_engine_info(struct drm_i915_private *i915,
struct drm_i915_query_item *query_item)
@@ -140,7 +141,7 @@ query_engine_info(struct drm_i915_private *i915,
if (query_item->flags)
return -EINVAL;
- for_each_uabi_engine(engine, i915)
+ for_each_available_uabi_engine(engine, i915)
num_uabi_engines++;
len = struct_size(query_ptr, engines, num_uabi_engines);
@@ -155,7 +156,7 @@ query_engine_info(struct drm_i915_private *i915,
info_ptr = _ptr->engines[0];
- for_each_uabi_engine(engine, i915) {
+ for_each_available_uabi_engine(engine, i915) {
info.engine.engine_class = engine->uabi_class;
info.engine.engine_instance = engine->uabi_instance;
info.flags = I915_ENGINE_INFO_HAS_LOGICAL_INSTANCE;
--
2.43.0
[PATCH 1/2] drm/i915/gt: Disable HW load balancing for CCS
The hardware should not dynamically balance the load between CCS
engines. Wa_16016805146 recommends disabling it across all
platforms.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Signed-off-by: Andi Shyti
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: # v6.2+
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 50962cfd1353..cf709f6c05ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1478,6 +1478,7 @@
#define GEN12_RCU_MODE _MMIO(0x14800)
#define GEN12_RCU_MODE_CCS_ENABLEREG_BIT(0)
+#define XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE REG_BIT(1)
#define CHV_FUSE_GT_MMIO(VLV_GUNIT_BASE + 0x2168)
#define CHV_FGT_DISABLE_SS0 (1 << 10)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d67d44611c28..7f42c8015f71 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2988,6 +2988,12 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN1,
GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
}
+
+ /*
+* Wa_16016805146: disable the CCS load balancing
+* indiscriminately for all the platforms
+*/
+ wa_masked_en(wal, GEN12_RCU_MODE, XEHP_RCU_MODE_FIXED_SLICE_CCS_MODE);
}
static void
--
2.43.0
[PATCH 0/2] Disable automatic load CCS load balancing
Hi, this series does basically two things: 1. Disables automatic load balancing as adviced by the hardware workaround. 2. Forces the sharing of the load submitted to CCS among all the CCS available (as of now only DG2 has more than one CCS). This way the user, when sending a query, will see only one CCS available. Andi Andi Shyti (2): drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Set default CCS mode '1' drivers/gpu/drm/i915/gt/intel_gt.c | 11 +++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ drivers/gpu/drm/i915/i915_drv.h | 17 + drivers/gpu/drm/i915/i915_query.c | 5 +++-- 5 files changed, 40 insertions(+), 2 deletions(-) -- 2.43.0
Re: [PATCH v2 2/6] dt-bindings: arm-smmu: Document SM8650 GPU SMMU
On 15/02/2024 10:32, Dmitry Baryshkov wrote: On Thu, 15 Feb 2024 at 11:29, Neil Armstrong wrote: On 15/02/2024 10:25, Dmitry Baryshkov wrote: On Thu, 15 Feb 2024 at 11:20, Neil Armstrong wrote: Document the GPU SMMU found on the SM8650 platform. Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index a4042ae24770..3ad5c850f3bf 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -93,6 +93,7 @@ properties: - qcom,sm8350-smmu-500 - qcom,sm8450-smmu-500 - qcom,sm8550-smmu-500 + - qcom,sm8650-smmu-500 - const: qcom,adreno-smmu - const: qcom,smmu-500 - const: arm,mmu-500 @@ -508,7 +509,10 @@ allOf: - if: properties: compatible: - const: qcom,sm8550-smmu-500 + contains: +enum: + - qcom,sm8550-smmu-500 + - qcom,sm8650-smmu-500 Doesn't this cause warnings for non-GPU SMMU on this platform? No because it doesn't add those to required, it simply allows clock the properties. Can we further constrain this branch so that it is applicable only to the Adreno SMMUs (and enforce requirement)? And maybe constrain the second if-branch so that it doesn't apply to the Adreno SMMUs? Indeed, it's done like that for the a6 gpu, I'll send a fix for that Neil then: properties: clock-names: @@ -544,7 +548,6 @@ allOf: - qcom,sdx65-smmu-500 - qcom,sm6350-smmu-500 - qcom,sm6375-smmu-500 - - qcom,sm8650-smmu-500 - qcom,x1e80100-smmu-500 then: properties: -- 2.34.1
[PATCH 3/3] RDMA/hfi1: Use RMW accessors for changing LNKCTL2
Convert open coded RMW accesses for LNKCTL2 to use
pcie_capability_clear_and_set_word() which makes its easier to
understand what the code tries to do.
LNKCTL2 is not really owned by any driver because it is a collection of
control bits that PCI core might need to touch. RMW accessors already
have support for proper locking for a selected set of registers
(LNKCTL2 is not yet among them but likely will be in the future) to
avoid losing concurrent updates.
Suggested-by: Lukas Wunner
Signed-off-by: Ilpo Järvinen
Reviewed-by: Dean Luick
---
drivers/infiniband/hw/hfi1/pcie.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/pcie.c
b/drivers/infiniband/hw/hfi1/pcie.c
index 119ec2f1382b..7133964749f8 100644
--- a/drivers/infiniband/hw/hfi1/pcie.c
+++ b/drivers/infiniband/hw/hfi1/pcie.c
@@ -1207,14 +1207,11 @@ int do_pcie_gen3_transition(struct hfi1_devdata *dd)
(u32)lnkctl2);
/* only write to parent if target is not as high as ours */
if ((lnkctl2 & PCI_EXP_LNKCTL2_TLS) < target_vector) {
- lnkctl2 &= ~PCI_EXP_LNKCTL2_TLS;
- lnkctl2 |= target_vector;
- dd_dev_info(dd, "%s: ..new link control2: 0x%x\n", __func__,
- (u32)lnkctl2);
- ret = pcie_capability_write_word(parent,
-PCI_EXP_LNKCTL2, lnkctl2);
+ ret = pcie_capability_clear_and_set_word(parent,
PCI_EXP_LNKCTL2,
+PCI_EXP_LNKCTL2_TLS,
+target_vector);
if (ret) {
- dd_dev_err(dd, "Unable to write to PCI config\n");
+ dd_dev_err(dd, "Unable to change parent PCI target
speed\n");
return_error = 1;
goto done;
}
@@ -1223,22 +1220,11 @@ int do_pcie_gen3_transition(struct hfi1_devdata *dd)
}
dd_dev_info(dd, "%s: setting target link speed\n", __func__);
- ret = pcie_capability_read_word(dd->pcidev, PCI_EXP_LNKCTL2, );
+ ret = pcie_capability_clear_and_set_word(dd->pcidev, PCI_EXP_LNKCTL2,
+PCI_EXP_LNKCTL2_TLS,
+target_vector);
if (ret) {
- dd_dev_err(dd, "Unable to read from PCI config\n");
- return_error = 1;
- goto done;
- }
-
- dd_dev_info(dd, "%s: ..old link control2: 0x%x\n", __func__,
- (u32)lnkctl2);
- lnkctl2 &= ~PCI_EXP_LNKCTL2_TLS;
- lnkctl2 |= target_vector;
- dd_dev_info(dd, "%s: ..new link control2: 0x%x\n", __func__,
- (u32)lnkctl2);
- ret = pcie_capability_write_word(dd->pcidev, PCI_EXP_LNKCTL2, lnkctl2);
- if (ret) {
- dd_dev_err(dd, "Unable to write to PCI config\n");
+ dd_dev_err(dd, "Unable to change device PCI target speed\n");
return_error = 1;
goto done;
}
--
2.39.2
[PATCH 2/3] drm/amdgpu: Use RMW accessors for changing LNKCTL2
Convert open coded RMW accesses for LNKCTL2 to use pcie_capability_clear_and_set_word() which makes its easier to understand what the code tries to do. LNKCTL2 is not really owned by any driver because it is a collection of control bits that PCI core might need to touch. RMW accessors already have support for proper locking for a selected set of registers (LNKCTL2 is not yet among them but likely will be in the future) to avoid losing concurrent updates. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/amd/amdgpu/cik.c | 41 drivers/gpu/drm/amd/amdgpu/si.c | 41 2 files changed, 30 insertions(+), 52 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c index 4dfaa017cf7f..a3a643254d7a 100644 --- a/drivers/gpu/drm/amd/amdgpu/cik.c +++ b/drivers/gpu/drm/amd/amdgpu/cik.c @@ -1638,28 +1638,18 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev) PCI_EXP_LNKCTL_HAWD); /* linkctl2 */ - pcie_capability_read_word(root, PCI_EXP_LNKCTL2, - ); - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN); - tmp16 |= (bridge_cfg2 & - (PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN)); - pcie_capability_write_word(root, - PCI_EXP_LNKCTL2, - tmp16); - - pcie_capability_read_word(adev->pdev, - PCI_EXP_LNKCTL2, - ); - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN); - tmp16 |= (gpu_cfg2 & - (PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN)); - pcie_capability_write_word(adev->pdev, - PCI_EXP_LNKCTL2, - tmp16); + pcie_capability_clear_and_set_word(root, PCI_EXP_LNKCTL2, + PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN, + bridge_cfg2 & + (PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN)); + pcie_capability_clear_and_set_word(adev->pdev, PCI_EXP_LNKCTL2, + PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN, + gpu_cfg2 & + (PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN)); tmp = RREG32_PCIE(ixPCIE_LC_CNTL4); tmp &= ~PCIE_LC_CNTL4__LC_SET_QUIESCE_MASK; @@ -1674,16 +1664,15 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev) speed_cntl &= ~PCIE_LC_SPEED_CNTL__LC_FORCE_DIS_SW_SPEED_CHANGE_MASK; WREG32_PCIE(ixPCIE_LC_SPEED_CNTL, speed_cntl); - pcie_capability_read_word(adev->pdev, PCI_EXP_LNKCTL2, ); - tmp16 &= ~PCI_EXP_LNKCTL2_TLS; - + tmp16 = 0; if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3) tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ else if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2) tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ else tmp16 |= PCI_EXP_LNKCTL2_TLS_2_5GT; /* gen1 */ - pcie_capability_write_word(adev->pdev, PCI_EXP_LNKCTL2, tmp16); + pcie_capability_clear_and_set_word(adev->pdev, PCI_EXP_LNKCTL2, + PCI_EXP_LNKCTL2_TLS, tmp16); speed_cntl = RREG32_PCIE(ixPCIE_LC_SPEED_CNTL); speed_cntl |= PCIE_LC_SPEED_CNTL__LC_INITIATE_LINK_SPEED_CHANGE_MASK; diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
[PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2
Convert open coded RMW accesses for LNKCTL2 to use pcie_capability_clear_and_set_word() which makes its easier to understand what the code tries to do. LNKCTL2 is not really owned by any driver because it is a collection of control bits that PCI core might need to touch. RMW accessors already have support for proper locking for a selected set of registers (LNKCTL2 is not yet among them but likely will be in the future) to avoid losing concurrent updates. Suggested-by: Lukas Wunner Signed-off-by: Ilpo Järvinen --- drivers/gpu/drm/radeon/cik.c | 40 ++-- drivers/gpu/drm/radeon/si.c | 40 ++-- 2 files changed, 30 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 10be30366c2b..b5e96a8fc2c1 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -9592,28 +9592,18 @@ static void cik_pcie_gen3_enable(struct radeon_device *rdev) PCI_EXP_LNKCTL_HAWD); /* linkctl2 */ - pcie_capability_read_word(root, PCI_EXP_LNKCTL2, - ); - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN); - tmp16 |= (bridge_cfg2 & - (PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN)); - pcie_capability_write_word(root, - PCI_EXP_LNKCTL2, - tmp16); - - pcie_capability_read_word(rdev->pdev, - PCI_EXP_LNKCTL2, - ); - tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN); - tmp16 |= (gpu_cfg2 & - (PCI_EXP_LNKCTL2_ENTER_COMP | - PCI_EXP_LNKCTL2_TX_MARGIN)); - pcie_capability_write_word(rdev->pdev, - PCI_EXP_LNKCTL2, - tmp16); + pcie_capability_clear_and_set_word(root, PCI_EXP_LNKCTL2, + PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN, + bridge_cfg2 | + (PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN)); + pcie_capability_clear_and_set_word(rdev->pdev, PCI_EXP_LNKCTL2, + PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN, + gpu_cfg2 | + (PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN)); tmp = RREG32_PCIE_PORT(PCIE_LC_CNTL4); tmp &= ~LC_SET_QUIESCE; @@ -9627,15 +9617,15 @@ static void cik_pcie_gen3_enable(struct radeon_device *rdev) speed_cntl &= ~LC_FORCE_DIS_SW_SPEED_CHANGE; WREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL, speed_cntl); - pcie_capability_read_word(rdev->pdev, PCI_EXP_LNKCTL2, ); - tmp16 &= ~PCI_EXP_LNKCTL2_TLS; + tmp16 = 0; if (speed_cap == PCIE_SPEED_8_0GT) tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ else if (speed_cap == PCIE_SPEED_5_0GT) tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ else tmp16 |= PCI_EXP_LNKCTL2_TLS_2_5GT; /* gen1 */ - pcie_capability_write_word(rdev->pdev, PCI_EXP_LNKCTL2, tmp16); + pcie_capability_clear_and_set_word(rdev->pdev, PCI_EXP_LNKCTL2, + PCI_EXP_LNKCTL2_TLS, tmp16); speed_cntl = RREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL); speed_cntl |= LC_INITIATE_LINK_SPEED_CHANGE; diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 85e9cba49cec..8eeaea64c75d 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -7193,28 +7193,18 @@ static void
[PATCH 0/3] PCI LNKCTL2 RMW Accessor Cleanup
This series converts open-coded LNKCTL2 RMW accesses to use RMW accessor. These patches used to be part of PCIe BW controller series [1] which will require RMW ops to LNKCTL2 be properly locked. However, since these RMW accessor patches are useful as cleanups on their own I chose to send them now separately to reduce the size of the BW controller series. [1] https://lore.kernel.org/linux-pci/20240105112547.7301-1-ilpo.jarvi...@linux.intel.com/ Ilpo Järvinen (3): drm/radeon: Use RMW accessors for changing LNKCTL2 drm/amdgpu: Use RMW accessors for changing LNKCTL2 RDMA/hfi1: Use RMW accessors for changing LNKCTL2 drivers/gpu/drm/amd/amdgpu/cik.c | 41 +++ drivers/gpu/drm/amd/amdgpu/si.c | 41 +++ drivers/gpu/drm/radeon/cik.c | 40 +++--- drivers/gpu/drm/radeon/si.c | 40 +++--- drivers/infiniband/hw/hfi1/pcie.c | 30 ++ 5 files changed, 68 insertions(+), 124 deletions(-) -- 2.39.2
Re: [PATCH] backlight: ktd2801: depend on GPIOLIB
On Tue, Feb 13, 2024 at 7:13 PM Duje Mihanović wrote:
> LEDS_EXPRESSWIRE depends on GPIOLIB, and so must anything selecting it:
>
> WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> Depends on [n]: NEW_LEDS [=y] && GPIOLIB [=n]
> Selected by [m]:
> - BACKLIGHT_KTD2801 [=m] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=m]
>
> Fixes: 66c76c1cd984 ("backlight: Add Kinetic KTD2801 backlight support")
> Signed-off-by: Duje Mihanović
Acked-by: Linus Walleij
Technically you can also select GPIOLIB, because it is available on
all platforms, so it may be easier for users, but then you never know
which GPIOs you get in practice.
Yours,
Linus Walleij
[PULL] drm-misc-next
Hi Dave, Sima, here's the drm-misc-next PR for this week. The majority of changes comes from Jani's update of the internal EDID callbacks, which the bridge code now uses. There are also stability fixes for lima, improvements to print helpers, correct parent devices for firmware framebuffers, and of course various fixes. Best regards Thomas drm-misc-next-2024-02-15: drm-misc-next for v6.9: UAPI Changes: Cross-subsystem Changes: arch: - powerpc/ps3: select CONFIG_VIDEO Core Changes: ci: - msm: fix apq8016 runner display: - use newer DRM print helpers documentation: - fix typos print: - add device-specific error and debug printers sysfb: - set Linux parent device for firmware framebuffer tests: - mm: use newer DRM print helpers Driver Changes: bridge: - switch to ->read_edid callback throughout the bridge drivers - remove old ->get_edid callback i915: - use newer DRM print helpers lima: - improve stability by fixes to error handling and recovery mediathek: - switch to ->read_edid callback msm: - switch to ->read_edid callback omap: - switch to ->read_edid callback panel: - add Powkiddy RGB10MAX3 plus DT bindings - st7703: support panel rotation plus DT bindings rockchip: - DT bindings: remove port, add power-domains xe: - use newer DRM print helpers xlnx: - switch to ->read_edid callback The following changes since commit 3ce7384048fa1793db0eae013fa377d89256b76f: drm/bridge: remove drm_bridge_get_edid() in favour of drm_bridge_edid_read() (2024-02-08 17:12:33 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2024-02-15 for you to fetch changes up to aa1267e673fe5307cf00d02add4017d2878598b6: drm: ci: use clk_ignore_unused for apq8016 (2024-02-14 11:23:56 -0300) drm-misc-next for v6.9: UAPI Changes: Cross-subsystem Changes: arch: - powerpc/ps3: select CONFIG_VIDEO Core Changes: ci: - msm: fix apq8016 runner display: - use newer DRM print helpers documentation: - fix typos print: - add device-specific error and debug printers sysfb: - set Linux parent device for firmware framebuffer tests: - mm: use newer DRM print helpers Driver Changes: bridge: - switch to ->read_edid callback throughout the bridge drivers - remove old ->get_edid callback i915: - use newer DRM print helpers lima: - improve stability by fixes to error handling and recovery mediathek: - switch to ->read_edid callback msm: - switch to ->read_edid callback omap: - switch to ->read_edid callback panel: - add Powkiddy RGB10MAX3 plus DT bindings - st7703: support panel rotation plus DT bindings rockchip: - DT bindings: remove port, add power-domains xe: - use newer DRM print helpers xlnx: - switch to ->read_edid callback Chris Morgan (4): dt-bindings: display: Add Powkiddy RGB10MAX3 panel drm/panel: st7703: Add Powkiddy RGB10MAX3 Panel Support dt-bindings: display: rocktech,jh057n00900: Document panel rotation drm/panel: st7703: Add Panel Rotation Support Dmitry Baryshkov (1): drm: ci: use clk_ignore_unused for apq8016 Erico Nunes (8): drm/lima: reset async_reset on pp hard reset drm/lima: reset async_reset on gp hard reset drm/lima: set pp bus_stop bit before hard reset drm/lima: set gp bus_stop bit before hard reset drm/lima: handle spurious timeouts due to high irq latency drm/lima: remove guilty drm_sched context handling drm/lima: increase default job timeout to 10s drm/lima: standardize debug messages by ip name Jani Nikula (37): drm/bridge: anx7625: switch to ->edid_read callback drm/bridge: cdns-mhdp8546: switch to ->edid_read callback drm/bridge: cdns-mhdp8546: clear the EDID property on failures drm/bridge: display-connector: switch to ->edid_read callback drm/bridge: it6505: switch to ->edid_read callback drm: bridge: it66121: switch to ->edid_read callback drm/bridge: lt9611: switch to ->edid_read callback drm/bridge: lt9611uxc: switch to ->edid_read callback drm/bridge: megachips: switch to ->edid_read callback drm/bridge: nxp-ptn3460: switch to ->edid_read callback drm/bridge: sii902x: use display info is_hdmi drm/bridge: sii902x: switch to ->edid_read callback drm/mediatek/dp: switch to ->edid_read callback drm/mediatek/hdmi: switch to ->edid_read callback drm/msm/hdmi: fix indent drm/msm/hdmi: switch to ->edid_read callback drm/omap/hdmi4: switch to ->edid_read callback drm/omap/hdmi5: switch to ->edid_read callback drm: xlnx: zynqmp_dpsub: switch to ->edid_read callback drm: adv7511: switch to ->edid_read callback drm: bridge: dw_hdmi: switch to ->edid_read callback drm: bridge: dw_hdmi: clear the EDID property and CEC address on failures drm/bridge: tc358767: update the
[PATCH] drm/atomic-helpers: fix uaf in drm_atomic_helper_wait_for_vblanks
To briefly summarize the issues reported by syzbot, there are two task call
stacks
as follows:
Task A Task B
--
drm_atomic_nonblocking_commit drm_atomic_commit
drm_atomic_helper_commit drm_atomic_helper_commit
commit_work
commit_tail
drm_atomic_helper_commit_tail commit_tail
drm_atomic_helper_commit_tail
drm_client_modeset_commit_atomic
drm_atomic_state_default_clear
drm_atomic_helper_wait_for_vblanks
When two prerequisites are met simultaneously, the current issue will be
triggered:
1. There is an overlap in the memory range occupied by the crtcs member set
contained
in the instance state of "struct drm_atomic_state" created by Task A and
Task B
2. The context of drm_atomic_helper_commit_tail() has no lock protection,
resulting
in the instance state->crtcs sub item being released by other task
The solution is to add a lock in drm_atomic_helper_commit_tail() to ensure that
there is no other task interference when accessing the instance state.
Reported-and-tested-by: syzbot+0f999d26a4fd79c3a...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis
---
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 39ef0a6addeb..b16ff9020097 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1743,7 +1743,9 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ static DEFINE_MUTEX(lock);
+ mutex_lock();
drm_atomic_helper_commit_modeset_disables(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state, 0);
@@ -1757,6 +1759,7 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
+ mutex_unlock();
}
EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
--
2.43.0
[PATCH v2] drm: Spelling s/hardward/hardware/g
Fix misspellings of "hardware".
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Neil Armstrong
Reviewed-by: Thomas Zimmermann
---
v2:
- Add Reviewed-by.
---
include/drm/drm_bridge.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index e39da5807ba71c2d..57d647722cf79704 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -107,7 +107,7 @@ struct drm_bridge_funcs {
* Since this function is both called from the check phase of an atomic
* commit, and the mode validation in the probe paths it is not allowed
* to look at anything else but the passed-in mode, and validate it
-* against configuration-invariant hardward constraints. Any further
+* against configuration-invariant hardware constraints. Any further
* limits which depend upon the configuration can only be checked in
* @mode_fixup.
*
--
2.34.1
[PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
Using the Imagination Technologies PowerVR Series 6 GPU requires a
proprietary firmware image, which is currently only available for Texas
Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
prevent asking the user about this driver when configuring a kernel
without Texas Instruments K3 Multicore SoC support.
Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR driver")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Nishanth Menon
---
v2:
- Add Reviewed-by,
- Clarify the firmware dependency.
---
drivers/gpu/drm/imagination/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/imagination/Kconfig
b/drivers/gpu/drm/imagination/Kconfig
index 3bfa2ac212dccb73..af492dbd9afd4ed9 100644
--- a/drivers/gpu/drm/imagination/Kconfig
+++ b/drivers/gpu/drm/imagination/Kconfig
@@ -6,6 +6,7 @@ config DRM_POWERVR
depends on ARM64
depends on DRM
depends on PM
+ depends on ARCH_K3 || COMPILE_TEST
select DRM_EXEC
select DRM_GEM_SHMEM_HELPER
select DRM_SCHED
--
2.34.1
