Re: [PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
Hi Maíra,
Am 16.04.24 um 03:02 schrieb Maíra Canal:
On 4/15/24 13:54, Andre Przywara wrote:
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
the RPi. Currently, the downstream kernel uses an overlay to enable the
GPU and use GPU hardware acceleration. When deploying a mainline kernel
to the RPi 0-3, we end up without any GPU hardware acceleration
(essentially, we can't use the OpenGL driver).
Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel.
So I think Krzysztof's initial comment still stands: What does that
patch
actually change? If I build those DTBs as of now, none of them has a
status property in the v3d node. Which means it's enabled:
https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status
So adding an explicit 'status = "okay";' doesn't make a difference.
What do I miss here?
As mentioned by Stefan in the last version, in Raspberry Pi OS, there is
a systemd script which is trying to check for the V3D driver (/usr/lib
/systemd/scripts/gldriver_test.sh). Within the first check, "raspi-
config nonint is_kms" is called, which always seems to fail. What
"raspi-config" does is check if
/proc/device-tree/soc/v3d@7ec0/status is equal to "okay". As
/proc/device-tree/soc/v3d@7ec0/status doesn't exists, it returns
false.
yes, but i also mention that the V3D driver starts without this patch.
The commit message of this patch suggests this is a DT issue, which is not.
I hadn't the time to update my SD card to Bookworm yet. Does the issue
still exists with this version?
I'll send if I can improve the userspace tool by just checking if the
folder /proc/device-tree/soc/v3d@7ec0/ exists.
Thanks for the explanation!
Best Regards,
- Maíra
Cheers,
Andre
Signed-off-by: Maíra Canal
---
v1 -> v2:
https://lore.kernel.org/dri-devel/41694292-af1f-4760-a7b6-101ed5dd6...@gmx.net/T/
* As mentioned by Krzysztof, enabling should be done in last place of
override/extend. Therefore, I'm disabling V3D in the common dtsi
and enabling in the last place of extend, i.e. the RPi DTS files.
arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 +
arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-zero.dts | 4
arch/arm/boot/dts/broadcom/bcm2836-rpi-2-b.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-a-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-cm3-io3.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-zero-2-w.dts | 4
15 files changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
index 9261b67dbee1..69e34831de51 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
@@ -139,6 +139,7 @@ v3d: v3d@7ec0 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec0 0x1000>;
interrupts = <1 10>;
+ status = "disabled";
};
vc4: gpu {
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
index 069b48272aa5..495ab1dfd2ce 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
@@ -128,3 +128,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
index 2726c00431e8..4634d88ce3af 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
@@ -121,3 +121,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
index c57b999a4520..45fa0f6851fc 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
@@ -130,3 +130,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
index ae6d3a9586ab..c1dac5d704aa 100644
--- a/arch
Re: [PATCH v5, 19/23] media: mediatek: vcodec: disable wait interrupt for svp mode
Re: [PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
On Tue, Apr 16, 2024 at 03:52:40AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
> category: bugfix
> bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> CVE: CVE-2023-52624
>
> Reference:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
>
>
>
> [ Upstream commit e5ffd1263dd5b44929c676171802e7b6af483f21 ]
>
> [Why]
> DMCUB can be in idle when we attempt to interface with the HW through
> the GPINT mailbox resulting in a system hang.
>
> [How]
> Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
> sequence.
>
> If the GPINT executes successfully then DMCUB will be put back into
> sleep after the optional response is returned.
>
> It functions similar to the inbox command interface.
>
> Cc: Mario Limonciello
> Cc: Alex Deucher
> Cc: sta...@vger.kernel.org
> Reviewed-by: Hansen Dsouza
> Acked-by: Wayne Lin
> Signed-off-by: Nicholas Kazlauskas
> Tested-by: Daniel Wheeler
> Signed-off-by: Alex Deucher
>
> This commit comes from following commits:
>
> 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR")
> 65138eb72e1f ("drm/amd/display: Add DCN35 DMUB")
> dc01c4b79bfe ("drm/amd/display: Update driver and IPS interop")
> 820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle interface")
> 2ef98c6d753a ("drm/amd/display: Wake DMCUB before executing GPINT commands")
Why are you putting multiple commits together and not just submitting
the individual ones? And what is this for?
confused,
greg k-h
Re: [PATCH v5.10] drm/amd/display: Wake DMCUB before executing GPINT commands
On Tue, Apr 16, 2024 at 02:43:47AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit2ef98c6d753a7 ("drm/amd/display: Wake DMCUB before executing
> GPINT commands")
> category: bugfix
> bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> CVE: CVE-2023-52624
>
> Reference:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
>
>
>
> [ Upstream commit e5ffd1263dd5b ("drm/amd/display: Wake DMCUB before
> executing GPINT commands") ]
>
> [Why]
> DMCUB can be in idle when we attempt to interface with the HW through
> the GPINT mailbox resulting in a system hang.
>
> [How]
> Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
> sequence.
>
> If the GPINT executes successfully then DMCUB will be put back into
> sleep after the optional response is returned.
>
> It functions similar to the inbox command interface.
>
> Cc: Mario Limonciello
> Cc: Alex Deucher
> Cc: sta...@vger.kernel.org
> Reviewed-by: Hansen Dsouza
> Acked-by: Wayne Lin
> Signed-off-by: Nicholas Kazlauskas
> Tested-by: Daniel Wheeler
> Signed-off-by: Alex Deucher
>
> This patch comes from following commits:
>
> 115c7e7f0501 ("drm/amd/display: Add psr get_state call")
> 1d496907f1c5 ("drm/amd/display: Engage PSR synchronously")
> 34ba432c946d ("drm/amd/display: [FW Promotion] Release 0.0.44")
> 672251b223c1 ("drm/amd/display: [FW Promotion] Release 0.0.40")
> 04f3c88f0955 ("drm/amd/display: Retry getting PSR state if command times
> out")
> b30eda8d416c ("drm/amd/display: Add ETW log to dmub_psr_get_state")
> f59a66c1915e ("drm/amd/display: use do-while-0 for DC_TRACE_LEVEL_MESSAGE()")
> e97cc04fe0fb ("drm/amd/display: refactor dmub commands into single function")
> 522b9a5d5852 ("drm/amd/display: drain dmub inbox if queue is full")
> 9dce8c2a5f1b ("drm/amd/display: [FW Promotion] Release 0.0.161.0")
> 276641775848 ("drm/amd/display: [FW Promotion] Release 0.0.162.0")
> 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR")
> 65138eb72e1f ("drm/amd/display: Add DCN35 DMUB")
> dc01c4b79bfe ("drm/amd/display: Update driver and IPS interop")
> 5b7954272ae9 ("drm/amd/display: [FW Promotion] Release 0.0.183.0")
> da2d16fcdda3 ("drm/amd/display: Fix IPS handshake for idle optimizations")
> 5e8a0d3598b4 ("drm/amd/display: Negate IPS allow and commit bits")
> 820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle interface")
> 2ef98c6d753a ("drm/amd/display: Wake DMCUB before executing GPINT commands")
>
> Signed-off-by: Zhu Wang
I'm confused, what are we supposed to do with this?
greg k-h
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
On Mon, 15 Apr 2024 16:35:02 -0700, Armin Wolf wrote:
>
Hi Armin,
> Am 16.04.24 um 00:36 schrieb Ashutosh Dixit:
> > @@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private
> > *i915)
> > hwm_get_preregistration_info(i915);
> >
> > /* hwmon_dev points to device hwmon */
> > - hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
> > -ddat,
> > -&hwm_chip_info,
> > -hwm_groups);
> > + hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
> > + ddat,
> > + &hwm_chip_info,
> > + hwm_groups);
> > if (IS_ERR(hwmon_dev)) {
> > i915->hwmon = NULL;
>
> you need to free hwmon here, since it is not managed by devres anymore.
Thanks a lot for catching this, I had missed it in v2, it's fixed in v3. I
am actually reusing i915_hwmon_unregister() for error unwinding in v3.
>
> > return;
> > @@ -838,10 +838,10 @@ void i915_hwmon_register(struct drm_i915_private
> > *i915)
> > if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
> > hwmon_energy_input, 0))
> > continue;
> >
> > - hwmon_dev = devm_hwmon_device_register_with_info(dev,
> > ddat_gt->name,
> > -ddat_gt,
> > -
> > &hwm_gt_chip_info,
> > -NULL);
> > + hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
> > + ddat_gt,
> > + &hwm_gt_chip_info,
> > + NULL);
> > if (!IS_ERR(hwmon_dev))
> > ddat_gt->hwmon_dev = hwmon_dev;
> > }
> > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> >
> > void i915_hwmon_unregister(struct drm_i915_private *i915)
> > {
> > - fetch_and_zero(&i915->hwmon);
> > + struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
>
> Why is fetch_and_zero() necessary here?
As mentioned, in v3 i915_hwmon_unregister() itself is used for error
unwinding so we need to prevent multiple device_unregister's etc. That is
the purpose of setting i915->hwmon to NULL. But even earlier, though it is
not obvious, i915_hwmon_unregister() is called multiple times. So e.g. it
will be called at device unbind as well as module unload. So once again we
prevent multiple device_unregister's by setting and checking for NULL
i915->hwmon.
>
> > + struct hwm_drvdata *ddat = &hwmon->ddat;
> > + struct intel_gt *gt;
> > + int i;
> > +
> > + if (!hwmon)
> > + return;
> > +
> > + for_each_gt(gt, i915, i) {
> > + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> > +
> > + if (ddat_gt->hwmon_dev) {
> > + hwmon_device_unregister(ddat_gt->hwmon_dev);
> > + ddat_gt->hwmon_dev = NULL;
> > + }
> > + }
> > +
> > + if (ddat->hwmon_dev)
> > + hwmon_device_unregister(ddat->hwmon_dev);
> > +
> > + mutex_destroy(&hwmon->hwmon_lock);
> > + kfree(hwmon);
> > }
Thanks.
--
Ashutosh
[PATCH v6.6] drm/amd/display: Wake DMCUB before executing GPINT commands
From: Nicholas Kazlauskas
stable inclusion
from stable-v6.7.3
commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
CVE: CVE-2023-52624
Reference:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
[ Upstream commit e5ffd1263dd5b44929c676171802e7b6af483f21 ]
[Why]
DMCUB can be in idle when we attempt to interface with the HW through
the GPINT mailbox resulting in a system hang.
[How]
Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
sequence.
If the GPINT executes successfully then DMCUB will be put back into
sleep after the optional response is returned.
It functions similar to the inbox command interface.
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Reviewed-by: Hansen Dsouza
Acked-by: Wayne Lin
Signed-off-by: Nicholas Kazlauskas
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
This commit comes from following commits:
8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR")
65138eb72e1f ("drm/amd/display: Add DCN35 DMUB")
dc01c4b79bfe ("drm/amd/display: Update driver and IPS interop")
820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle interface")
2ef98c6d753a ("drm/amd/display: Wake DMCUB before executing GPINT commands")
Signed-off-by: Zhu Wang
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 173 --
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h | 18 ++
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 19 +-
.../gpu/drm/amd/display/dc/inc/hw/clk_mgr.h | 1 +
drivers/gpu/drm/amd/display/dmub/dmub_srv.h | 20 ++
.../gpu/drm/amd/display/dmub/src/dmub_srv.c | 33 +++-
6 files changed, 232 insertions(+), 32 deletions(-)
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 4c5ef3ef8dbd..003b2d3d1750 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -32,6 +32,7 @@
#include "../basics/conversion.h"
#include "cursor_reg_cache.h"
#include "resource.h"
+#include "clk_mgr.h"
#define CTX dc_dmub_srv->ctx
#define DC_LOGGER CTX->logger
@@ -207,17 +208,11 @@ bool dc_dmub_srv_optimized_init_done(struct dc_dmub_srv
*dc_dmub_srv)
bool dc_dmub_srv_notify_stream_mask(struct dc_dmub_srv *dc_dmub_srv,
unsigned int stream_mask)
{
- struct dmub_srv *dmub;
- const uint32_t timeout = 30;
-
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
return false;
- dmub = dc_dmub_srv->dmub;
-
- return dmub_srv_send_gpint_command(
- dmub, DMUB_GPINT__IDLE_OPT_NOTIFY_STREAM_MASK,
- stream_mask, timeout) == DMUB_STATUS_OK;
+ return dc_wake_and_execute_gpint(dc_dmub_srv->ctx,
DMUB_GPINT__IDLE_OPT_NOTIFY_STREAM_MASK,
+stream_mask, NULL,
DM_DMUB_WAIT_TYPE_WAIT);
}
bool dc_dmub_srv_is_restore_required(struct dc_dmub_srv *dc_dmub_srv)
@@ -1030,28 +1025,170 @@ bool dc_dmub_check_min_version(struct dmub_srv *srv)
void dc_dmub_srv_enable_dpia_trace(const struct dc *dc)
{
struct dc_dmub_srv *dc_dmub_srv = dc->ctx->dmub_srv;
- struct dmub_srv *dmub;
- enum dmub_status status;
- static const uint32_t timeout_us = 30;
if (!dc_dmub_srv || !dc_dmub_srv->dmub) {
DC_LOG_ERROR("%s: invalid parameters.", __func__);
return;
}
- dmub = dc_dmub_srv->dmub;
-
- status = dmub_srv_send_gpint_command(dmub,
DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD1, 0x0010, timeout_us);
- if (status != DMUB_STATUS_OK) {
+ if (!dc_wake_and_execute_gpint(dc->ctx,
DMUB_GPINT__SET_TRACE_BUFFER_MASK_WORD1,
+ 0x0010, NULL, DM_DMUB_WAIT_TYPE_WAIT)) {
DC_LOG_ERROR("timeout updating trace buffer mask word\n");
return;
}
- status = dmub_srv_send_gpint_command(dmub,
DMUB_GPINT__UPDATE_TRACE_BUFFER_MASK, 0x, timeout_us);
- if (status != DMUB_STATUS_OK) {
+ if (!dc_wake_and_execute_gpint(dc->ctx,
DMUB_GPINT__UPDATE_TRACE_BUFFER_MASK,
+ 0x, NULL, DM_DMUB_WAIT_TYPE_WAIT)) {
DC_LOG_ERROR("timeout updating trace buffer mask word\n");
return;
}
DC_LOG_DEBUG("Enabled DPIA trace\n");
-}
\ No newline at end of file
+}
+
+bool dc_dmub_srv_is_hw_pwr_up(struct dc_dmub_srv *dc_dmub_srv, bool wait)
+{
+ struct dc_context *dc_ctx = dc_dmub_srv->ctx;
+ enum dmub_status status;
+
+ if (!dc_dmub_srv || !dc_dmub_srv->dmub)
+ return true;
+
+ if (dc_dmub_srv->ctx->dc->debug.dmcub_emulation)
+ return true;
+
+ if (wait) {
+ status = dmub_srv_wait_for_hw_pwr_up(dc_dmub_srv->dmub, 500
[PATCH v3] drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 54 ++-
1 file changed, 38 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b758fd110c20..8cebf6f5b101 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -793,7 +793,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!IS_DGFX(i915))
return;
- hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return;
@@ -819,14 +819,12 @@ void i915_hwmon_register(struct drm_i915_private *i915)
hwm_get_preregistration_info(i915);
/* hwmon_dev points to device hwmon */
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
-ddat,
-&hwm_chip_info,
-hwm_groups);
- if (IS_ERR(hwmon_dev)) {
- i915->hwmon = NULL;
- return;
- }
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ &hwm_chip_info,
+ hwm_groups);
+ if (IS_ERR(hwmon_dev))
+ goto err;
ddat->hwmon_dev = hwmon_dev;
@@ -839,16 +837,40 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
hwmon_energy_input, 0))
continue;
- hwmon_dev = devm_hwmon_device_register_with_info(dev,
ddat_gt->name,
-ddat_gt,
-
&hwm_gt_chip_info,
-NULL);
- if (!IS_ERR(hwmon_dev))
- ddat_gt->hwmon_dev = hwmon_dev;
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
+ ddat_gt,
+ &hwm_gt_chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev))
+ goto err;
+
+ ddat_gt->hwmon_dev = hwmon_dev;
}
+ return;
+err:
+ i915_hwmon_unregister(i915);
}
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(&i915->hwmon);
+ struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
+ struct hwm_drvdata *ddat = &hwmon->ddat;
+ struct intel_gt *gt;
+ int i;
+
+ if (!hwmon)
+ return;
+
+ for_each_gt(gt, i915, i) {
+ struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
+
+ if (ddat_gt->hwmon_dev)
+ hwmon_device_unregister(ddat_gt->hwmon_dev);
+ }
+
+ if (ddat->hwmon_dev)
+ hwmon_device_unregister(ddat->hwmon_dev);
+
+ mutex_destroy(&hwmon->hwmon_lock);
+ kfree(hwmon);
}
--
2.41.0
[PATCH] drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 54 ++-
1 file changed, 38 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b758fd110c20..8cebf6f5b101 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -793,7 +793,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!IS_DGFX(i915))
return;
- hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return;
@@ -819,14 +819,12 @@ void i915_hwmon_register(struct drm_i915_private *i915)
hwm_get_preregistration_info(i915);
/* hwmon_dev points to device hwmon */
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
-ddat,
-&hwm_chip_info,
-hwm_groups);
- if (IS_ERR(hwmon_dev)) {
- i915->hwmon = NULL;
- return;
- }
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ &hwm_chip_info,
+ hwm_groups);
+ if (IS_ERR(hwmon_dev))
+ goto err;
ddat->hwmon_dev = hwmon_dev;
@@ -839,16 +837,40 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
hwmon_energy_input, 0))
continue;
- hwmon_dev = devm_hwmon_device_register_with_info(dev,
ddat_gt->name,
-ddat_gt,
-
&hwm_gt_chip_info,
-NULL);
- if (!IS_ERR(hwmon_dev))
- ddat_gt->hwmon_dev = hwmon_dev;
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
+ ddat_gt,
+ &hwm_gt_chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev))
+ goto err;
+
+ ddat_gt->hwmon_dev = hwmon_dev;
}
+ return;
+err:
+ i915_hwmon_unregister(i915);
}
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(&i915->hwmon);
+ struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
+ struct hwm_drvdata *ddat = &hwmon->ddat;
+ struct intel_gt *gt;
+ int i;
+
+ if (!hwmon)
+ return;
+
+ for_each_gt(gt, i915, i) {
+ struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
+
+ if (ddat_gt->hwmon_dev)
+ hwmon_device_unregister(ddat_gt->hwmon_dev);
+ }
+
+ if (ddat->hwmon_dev)
+ hwmon_device_unregister(ddat->hwmon_dev);
+
+ mutex_destroy(&hwmon->hwmon_lock);
+ kfree(hwmon);
}
--
2.41.0
[PATCH v5.10] drm/amd/display: Wake DMCUB before executing GPINT commands
From: Nicholas Kazlauskas
stable inclusion
from stable-v6.7.3
commit 2ef98c6d753a7 ("drm/amd/display: Wake DMCUB before executing GPINT
commands")
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
CVE: CVE-2023-52624
Reference:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ef98c6d753a744e333b7e34b9cf687040fba57d
[ Upstream commit e5ffd1263dd5b ("drm/amd/display: Wake DMCUB before executing
GPINT commands") ]
[Why]
DMCUB can be in idle when we attempt to interface with the HW through
the GPINT mailbox resulting in a system hang.
[How]
Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
sequence.
If the GPINT executes successfully then DMCUB will be put back into
sleep after the optional response is returned.
It functions similar to the inbox command interface.
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Reviewed-by: Hansen Dsouza
Acked-by: Wayne Lin
Signed-off-by: Nicholas Kazlauskas
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
This patch comes from following commits:
115c7e7f0501 ("drm/amd/display: Add psr get_state call")
1d496907f1c5 ("drm/amd/display: Engage PSR synchronously")
34ba432c946d ("drm/amd/display: [FW Promotion] Release 0.0.44")
672251b223c1 ("drm/amd/display: [FW Promotion] Release 0.0.40")
04f3c88f0955 ("drm/amd/display: Retry getting PSR state if command times out")
b30eda8d416c ("drm/amd/display: Add ETW log to dmub_psr_get_state")
f59a66c1915e ("drm/amd/display: use do-while-0 for DC_TRACE_LEVEL_MESSAGE()")
e97cc04fe0fb ("drm/amd/display: refactor dmub commands into single function")
522b9a5d5852 ("drm/amd/display: drain dmub inbox if queue is full")
9dce8c2a5f1b ("drm/amd/display: [FW Promotion] Release 0.0.161.0")
276641775848 ("drm/amd/display: [FW Promotion] Release 0.0.162.0")
8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR")
65138eb72e1f ("drm/amd/display: Add DCN35 DMUB")
dc01c4b79bfe ("drm/amd/display: Update driver and IPS interop")
5b7954272ae9 ("drm/amd/display: [FW Promotion] Release 0.0.183.0")
da2d16fcdda3 ("drm/amd/display: Fix IPS handshake for idle optimizations")
5e8a0d3598b4 ("drm/amd/display: Negate IPS allow and commit bits")
820c3870c491 ("drm/amd/display: Refactor DMCUB enter/exit idle interface")
2ef98c6d753a ("drm/amd/display: Wake DMCUB before executing GPINT commands")
Signed-off-by: Zhu Wang
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 +-
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +-
.../gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c | 5 +-
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +-
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 20 +-
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 +-
drivers/gpu/drm/amd/display/dc/dc.h | 4 +-
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 265 +-
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h | 31 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 5 +-
drivers/gpu/drm/amd/display/dc/dc_types.h | 20 ++
drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 24 +-
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 140 +
drivers/gpu/drm/amd/display/dc/dce/dmub_psr.h | 3 +-
drivers/gpu/drm/amd/display/dc/dm_services.h | 9 +
.../drm/amd/display/dc/dm_services_types.h| 6 +
.../gpu/drm/amd/display/dc/inc/hw/clk_mgr.h | 1 +
drivers/gpu/drm/amd/display/dc/inc/hw/dmcu.h | 2 +-
.../gpu/drm/amd/display/dc/inc/hw_sequencer.h | 3 +-
drivers/gpu/drm/amd/display/dmub/dmub_srv.h | 20 ++
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 100 ++-
.../gpu/drm/amd/display/dmub/src/dmub_srv.c | 27 ++
22 files changed, 616 insertions(+), 99 deletions(-)
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 652ddec18838..924d643a37ae 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9308,7 +9308,7 @@ bool amdgpu_dm_psr_enable(struct dc_stream_state *stream)
&stream, 1,
¶ms);
- return dc_link_set_psr_allow_active(link, true, false);
+ return dc_link_set_psr_allow_active(link, true, false, false);
}
/*
@@ -9322,7 +9322,7 @@ static bool amdgpu_dm_psr_disable(struct dc_stream_state
*stream)
DRM_DEBUG_DRIVER("Disabling psr...\n");
- return dc_link_set_psr_allow_active(stream->link, false, true);
+ return dc_link_set_psr_allow_active(stream->link, false, true, false);
}
/*
@@ -9355,3 +9355,15 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device
*dev)
}
mutex_unlock(&adev->dm.dc_lock);
}
+
+bool dm_execute_dmub_cmd(const struct dc_context *ctx, union dmub_rb_cmd *cmd,
+enum dm_dmub_wait_type wait_type)
+{
+ return dc_dmub_srv_cmd_run(ctx
Re: [PATCH] drm/amdkfd: fix NULL pointer dereference
This patch does not apply to amd-staging-drm-next. This is against a
DKMS branch and should be reviewed on our internal mailing list.
However, I suspect that part of the problem is, that the DKMS branch has
diverged quite a bit in this area, and is missing at least one patch
from me that was reverted, probably because of an improper port. The
proper solution should involve getting the DKMS branch back in sync with
upstream. I'll look into that.
Regards,
Felix
On 2024-04-13 14:07, vitaly.pros...@amd.com wrote:
From: Vitaly Prosyak
[ +0.006038] BUG: kernel NULL pointer dereference, address: 0028
[ +0.006969] #PF: supervisor read access in kernel mode
[ +0.005139] #PF: error_code(0x) - not-present page
[ +0.005139] PGD 0 P4D 0
[ +0.002530] Oops: [#1] PREEMPT SMP NOPTI
[ +0.004356] CPU: 11 PID: 12625 Comm: kworker/11:0 Tainted: GW
6.7.0+ #2
[ +0.008097] Hardware name: ASUS System Product Name/Pro WS WRX80E-SAGE SE
WIFI II, BIOS 1302 12/08/2023
[ +0.009398] Workqueue: events evict_process_worker [amdgpu]
[ +0.005750] RIP: 0010:evict_process_worker+0x2f/0x460 [amdgpu]
[ +0.005991] Code: 55 48 89 e5 41 57 41 56 4c 8d b7 a8 fc ff ff 41 55 41 54 53 48 89
fb 48 83 ec 10 0f 1f 44 00 00 48 8b 43 f8 8b 93 b0 00 00 00 <48> 3b 50 28 0f 85
50 03 00 00 48 8d 7b 58 e8 ee be cb bf 48 8b 05
[ +0.018791] RSP: 0018:c90009a2be10 EFLAGS: 00010282
[ +0.005226] RAX: RBX: 888197ffc358 RCX:
[ +0.007140] RDX: 0a1b RSI: RDI: 888197ffc358
[ +0.007139] RBP: c90009a2be48 R08: R09:
[ +0.007139] R10: R11: R12: 888197ffc358
[ +0.007139] R13: 888100153a00 R14: 888197ffc000 R15: 888100153a05
[ +0.007137] FS: () GS:889facac()
knlGS:
[ +0.008094] CS: 0010 DS: ES: CR0: 80050033
[ +0.005747] CR2: 0028 CR3: 00010d1fc001 CR4: 00770ef0
[ +0.007138] PKRU: 5554
[ +0.002702] Call Trace:
[ +0.002443]
[ +0.002096] ? show_regs+0x72/0x90
[ +0.003402] ? __die+0x25/0x80
[ +0.003052] ? page_fault_oops+0x154/0x4c0
[ +0.004099] ? do_user_addr_fault+0x30e/0x6e0
[ +0.004357] ? psi_group_change+0x237/0x520
[ +0.004185] ? exc_page_fault+0x84/0x1b0
[ +0.003926] ? asm_exc_page_fault+0x27/0x30
[ +0.004187] ? evict_process_worker+0x2f/0x460 [amdgpu]
[ +0.005377] process_one_work+0x17b/0x360
[ +0.004011] ? __pfx_worker_thread+0x10/0x10
[ +0.004269] worker_thread+0x307/0x430
[ +0.003748] ? __pfx_worker_thread+0x10/0x10
[ +0.004268] kthread+0xf7/0x130
[ +0.003142] ? __pfx_kthread+0x10/0x10
[ +0.003749] ret_from_fork+0x46/0x70
[ +0.003573] ? __pfx_kthread+0x10/0x10
[ +0.003747] ret_from_fork_asm+0x1b/0x30
[ +0.003924]
When we run stressful tests, the eviction fence could be zero and not match
to last_eviction_seqno.
Avoid calling dma_fence_signal and dma_fence_put with zero fences to rely
on checking parameters in DMA API.
Cc: Alex Deucher
Cc: Christian Koenig
Cc: Xiaogang Chen
Cc: Felix Kuehling
Signed-off-by: Vitaly Prosyak
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index eb380296017d..a15fae1c398a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -2118,7 +2118,7 @@ static void evict_process_worker(struct work_struct *work)
*/
p = container_of(dwork, struct kfd_process, eviction_work);
trace_kfd_evict_process_worker_start(p);
- WARN_ONCE(p->last_eviction_seqno != p->ef->seqno,
+ WARN_ONCE(p->ef && p->last_eviction_seqno != p->ef->seqno,
"Eviction fence mismatch\n");
/* Narrow window of overlap between restore and evict work
@@ -2134,9 +2134,11 @@ static void evict_process_worker(struct work_struct
*work)
pr_debug("Started evicting pasid 0x%x\n", p->pasid);
ret = kfd_process_evict_queues(p, false,
KFD_QUEUE_EVICTION_TRIGGER_TTM);
if (!ret) {
- dma_fence_signal(p->ef);
- dma_fence_put(p->ef);
- p->ef = NULL;
+ if (p->ef) {
+ dma_fence_signal(p->ef);
+ dma_fence_put(p->ef);
+ p->ef = NULL;
+ }
if (!kfd_process_unmap_doorbells_if_idle(p))
kfd_process_schedule_restore(p);
Re: [PATCH v3 5/9] drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
On Mon, Apr 15, 2024 at 05:49:33PM -0400, Nícolas F. R. A. Prado wrote:
> Given that failing to find a DSI host causes the driver to defer probe,
> make use of dev_err_probe() to log the reason. This makes the defer
> probe reason available and avoids alerting userspace about something
> that is not necessarily an error.
>
> Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
> Suggested-by: AngeloGioacchino Del Regno
>
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Nícolas F. R. A. Prado
> ---
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v3 4/9] drm/bridge: lt9611: Don't log an error when DSI host can't be found
On Mon, Apr 15, 2024 at 05:49:32PM -0400, Nícolas F. R. A. Prado wrote:
> Given that failing to find a DSI host causes the driver to defer probe,
> make use of dev_err_probe() to log the reason. This makes the defer
> probe reason available and avoids alerting userspace about something
> that is not necessarily an error.
>
> Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
> Suggested-by: AngeloGioacchino Del Regno
>
> Reviewed-by: AngeloGioacchino Del Regno
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Nícolas F. R. A. Prado
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
Re: [PATCH v3] drm/i915/vma: Fix UAF on reopen vs destroy race
On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> We defer actually closing, unbinding and destroying a VMA until next idle
> point, or until the object is freed in the meantime. By postponing the
> unbind, we allow for the VMA to be reopened by the client, avoiding the
> work required to rebind the VMA.
>
> It was assumed that as long as a GT is held idle, no VMA would be reopened
> while we destroy them. That assumption is no longer true in multi-GT
> configurations, where a VMA we reopen may be handled by a GT different
> from the one that we already keep active via its engine while we set up
> an execbuf request.
>
> <4> [260.290809] [ cut here ]
> <4> [260.290988] list_del corruption. prev->next should be 888118c5d990,
> but was 888118c5a510. (prev=888118c5a510)
> <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
> __list_del_entry_valid_or_report+0xb7/0xe0
> ..
> <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
> 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
> <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
> ...
> <4> [260.291087] Call Trace:
> <4> [260.291089]
> <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
> <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
> <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
> <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> ...
> <4> [260.292301]
> ...
> <4> [260.292506] ---[ end trace ]---
> <4> [260.292782] general protection fault, probably for non-canonical address
> 0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
> <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
> 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
> Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
> <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
> ...
> <4> [260.428756] Call Trace:
> <4> [260.431192]
> <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
> <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> ...
> <4> [639.411134]
> ...
> <4> [639.449979] ---[ end trace ]---
>
> As soon as we start unbinding and destroying a VMA, marked it as parked,
> and also keep it marked as closed for the rest of its life. When a VMA
> to be opened occurs closed, reopen it only if not yet parked.
>
> v3: Fix misplaced brackets.
> v2: Since we no longer re-init the VMA closed list link on VMA park so it
> looks like still on a list, don't try to delete it from the list again
> after the VMA has been marked as parked.
>
> Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
what about reverting that?
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: sta...@vger.kernel.org # v6.0+
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 --
> drivers/gpu/drm/i915/i915_vma.c | 32 +++
> drivers/gpu/drm/i915/i915_vma.h | 2 +-
> drivers/gpu/drm/i915/i915_vma_types.h | 3 ++
> 4 files changed, 37 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 42619fc05de48..97e014f94002e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -847,9 +847,12 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
> if (unlikely(!lut))
> return -ENOMEM;
>
> + if (!i915_vma_open(vma)) {
> + err = -EEXIST; /* let eb_vma_lookup() retry */
> + goto err_lut_free;
> + }
> +
> i915_vma_get(vma);
> - if (!atomic_fetch_inc(&vma->open_count))
> - i915_vma_reopen(vma);
> lut->handle = handle;
> lut->ctx = ctx;
>
> @@ -880,8 +883,9 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
> return 0;
>
> err:
> - i915_vma_close(vma);
> i915_vma_put(vma);
> + i915_vma_close(vma);
> +err_lut_free:
> i915_lut_handle_free(lut);
> return err;
> }
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index d2f064d2525cc..4435c76f28c8c 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -1735,14 +1735,33 @@ static void __i915_vma_remove_closed(struct i915_vma
> *vma)
> list_del_init(&vma->closed_link);
> }
>
> -void i915_vma_reopen(struct i915_vma *vma)
> +static struct i915_vma *i915_vma_reopen(struct i915_vma *vma)
> +{
> + if (atomic_read(&vma->flags) & I915_VMA_PARKED)
> + retu
Re: [PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
On 4/15/24 13:54, Andre Przywara wrote:
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
the RPi. Currently, the downstream kernel uses an overlay to enable the
GPU and use GPU hardware acceleration. When deploying a mainline kernel
to the RPi 0-3, we end up without any GPU hardware acceleration
(essentially, we can't use the OpenGL driver).
Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel.
So I think Krzysztof's initial comment still stands: What does that patch
actually change? If I build those DTBs as of now, none of them has a
status property in the v3d node. Which means it's enabled:
https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status
So adding an explicit 'status = "okay";' doesn't make a difference.
What do I miss here?
As mentioned by Stefan in the last version, in Raspberry Pi OS, there is
a systemd script which is trying to check for the V3D driver (/usr/lib
/systemd/scripts/gldriver_test.sh). Within the first check, "raspi-
config nonint is_kms" is called, which always seems to fail. What
"raspi-config" does is check if
/proc/device-tree/soc/v3d@7ec0/status is equal to "okay". As
/proc/device-tree/soc/v3d@7ec0/status doesn't exists, it returns false.
I'll send if I can improve the userspace tool by just checking if the
folder /proc/device-tree/soc/v3d@7ec0/ exists.
Thanks for the explanation!
Best Regards,
- Maíra
Cheers,
Andre
Signed-off-by: Maíra Canal
---
v1 -> v2:
https://lore.kernel.org/dri-devel/41694292-af1f-4760-a7b6-101ed5dd6...@gmx.net/T/
* As mentioned by Krzysztof, enabling should be done in last place of
override/extend. Therefore, I'm disabling V3D in the common dtsi
and enabling in the last place of extend, i.e. the RPi DTS files.
arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 +
arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts| 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts| 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-zero.dts | 4
arch/arm/boot/dts/broadcom/bcm2836-rpi-2-b.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-a-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-cm3-io3.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-zero-2-w.dts | 4
15 files changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
index 9261b67dbee1..69e34831de51 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
@@ -139,6 +139,7 @@ v3d: v3d@7ec0 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec0 0x1000>;
interrupts = <1 10>;
+ status = "disabled";
};
vc4: gpu {
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
index 069b48272aa5..495ab1dfd2ce 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
@@ -128,3 +128,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
index 2726c00431e8..4634d88ce3af 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
@@ -121,3 +121,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
index c57b999a4520..45fa0f6851fc 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
@@ -130,3 +130,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
index ae6d3a9586ab..c1dac5d704aa 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
@@ -121,3 +121,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "
Re: [PATCH 0/7] drm/display: Fix display helpers depends on fallouts
On Mon, Apr 15, 2024 at 01:21:47PM +0200, Maxime Ripard wrote: > On Wed, Apr 10, 2024 at 07:06:39PM +0100, Mark Brown wrote: > > Is there any news on getting the rest of this merged? It's been more > > than a week now and the Designware display controllers are all still > > broken in -next, causing widespread breakage in CI. For bisection > > purposes it probably makes sense for the defconfig updates to go along > > with the changes to the Kconfig for the driver... > I was on holidays so I've admittedly hoped that it would be picked up / > reviewed by the relevant maintainers. > Aside from the changes on sunxi_defconfig, I haven't seen any review > from the relevant maintainers so I'm not sure how to merge this. Should > we get an Acked-by from Arnd, Olof, Catalin or Will and merge everything > through drm-misc? Sounds like a reasonable plan to me - usually it'd be the SoC maintainers for stuff like this but they're not on the CC, though TBH it seems sufficiently obvious that I doubt anyone would mind if you just merged things without waiting. signature.asc Description: PGP signature
Re: [PATCH v2 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
On 4/15/2024 9:10 AM, David Wronek wrote:
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 366 ++
3 files changed, 381 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 154f5bf82980..5b3eeb93b1a2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -542,6 +542,20 @@ config DRM_PANEL_RAYDIUM_RM692E5
Say Y here if you want to enable support for Raydium RM692E5-based
display panels, such as the one found in the Fairphone 5 smartphone.
+config DRM_PANEL_RAYDIUM_RM69380
+ tristate "Raydium RM69380-based DSI panel"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on DRM_DISPLAY_DP_HELPER
+ depends on DRM_DISPLAY_HELPER
+ depends on DRM_MIPI_DSI
+ depends on OF
+ help
+ Say Y here if you want to enable support for Raydium RM69380-based
+ display panels.
+
+ This panel controller can be found in the Lenovo Xiaoxin Pad Pro 2021
+ in combination with an EDO OLED panel.
+
config DRM_PANEL_RONBO_RB070D30
tristate "Ronbo Electronics RB070D30 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 24a02655d726..e2a2807d4ef0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
new file mode 100644
index ..253b9a1c2800
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 David Wronek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct rm69380_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+ bool prepared;
Hi David,
IIRC there's no need for a driver-specific panel::prepared after commit
d2aacaf0.
Thanks,
Jessica Zhang
+};
+
+static inline
+struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct rm69380_panel, panel);
+}
+
+static void rm69380_reset(struct rm69380_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(15000, 16000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 11000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(30);
+}
+
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+ mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x53, 0x28);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
+ mipi_dsi_dcs_write_seq(dsi, 0x35, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x51, 0x07, 0xff);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display on: %d\n", ret);
+ return ret;
+ }
+ msleep(36);
+
+ return 0;
+}
+
+static int rm69380_off(struct rm69380_panel *ctx)
+{
+ struct mipi_ds
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
Am 16.04.24 um 00:36 schrieb Ashutosh Dixit:
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 41 +++
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 8c3f443c8347..46c24b1ee6df 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -792,7 +792,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!IS_DGFX(i915))
return;
- hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return;
@@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
hwm_get_preregistration_info(i915);
/* hwmon_dev points to device hwmon */
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
-ddat,
-&hwm_chip_info,
-hwm_groups);
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ &hwm_chip_info,
+ hwm_groups);
if (IS_ERR(hwmon_dev)) {
i915->hwmon = NULL;
Hi,
you need to free hwmon here, since it is not managed by devres anymore.
return;
@@ -838,10 +838,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
hwmon_energy_input, 0))
continue;
- hwmon_dev = devm_hwmon_device_register_with_info(dev,
ddat_gt->name,
-ddat_gt,
-
&hwm_gt_chip_info,
-NULL);
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
+ ddat_gt,
+ &hwm_gt_chip_info,
+ NULL);
if (!IS_ERR(hwmon_dev))
ddat_gt->hwmon_dev = hwmon_dev;
}
@@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(&i915->hwmon);
+ struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
Why is fetch_and_zero() necessary here?
Thanks,
Armin Wolf
+ struct hwm_drvdata *ddat = &hwmon->ddat;
+ struct intel_gt *gt;
+ int i;
+
+ if (!hwmon)
+ return;
+
+ for_each_gt(gt, i915, i) {
+ struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
+
+ if (ddat_gt->hwmon_dev) {
+ hwmon_device_unregister(ddat_gt->hwmon_dev);
+ ddat_gt->hwmon_dev = NULL;
+ }
+ }
+
+ if (ddat->hwmon_dev)
+ hwmon_device_unregister(ddat->hwmon_dev);
+
+ mutex_destroy(&hwmon->hwmon_lock);
+ kfree(hwmon);
}
[drm-misc:for-linux-next 5/9] drivers/gpu/drm/drm_fb_dma_helper.c:164:5: warning: no previous prototype for function 'drm_fb_dma_get_scanout_buffer'
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 7b0062036c3b71b4a69e244ecf0502c06c4cf5f0
commit: 879b3b6511fe92b1b93dfc543961347289a8aeaa [5/9] drm/fb_dma: Add generic
get_scanout_buffer() for drm_panic
config: riscv-defconfig
(https://download.01.org/0day-ci/archive/20240416/202404160702.2kfuk6qq-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
7089c359a3845323f6f30c44a47dd901f2edfe63)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240416/202404160702.2kfuk6qq-...@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/202404160702.2kfuk6qq-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/drm_fb_dma_helper.c:12:
In file included from include/drm/drm_damage_helper.h:35:
In file included from include/drm/drm_atomic_helper.h:31:
In file included from include/drm/drm_crtc.h:32:
In file included from include/drm/drm_modes.h:33:
In file included from include/drm/drm_connector.h:32:
In file included from include/drm/drm_util.h:35:
In file included from include/linux/interrupt.h:21:
In file included from arch/riscv/include/asm/sections.h:9:
In file included from include/linux/mm.h:2208:
include/linux/vmstat.h:522:36: warning: arithmetic between different
enumeration types ('enum node_stat_item' and 'enum lru_list')
[-Wenum-enum-conversion]
522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~ ^ ~~~
>> drivers/gpu/drm/drm_fb_dma_helper.c:164:5: warning: no previous prototype
>> for function 'drm_fb_dma_get_scanout_buffer' [-Wmissing-prototypes]
164 | int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
| ^
drivers/gpu/drm/drm_fb_dma_helper.c:164:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
164 | int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
| ^
| static
2 warnings generated.
--
>> drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Function parameter or
>> struct member 'sb' not described in 'drm_fb_dma_get_scanout_buffer'
>> drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function parameter
>> 'drm_scanout_buffer' description in 'drm_fb_dma_get_scanout_buffer'
vim +/drm_fb_dma_get_scanout_buffer +164 drivers/gpu/drm/drm_fb_dma_helper.c
152
153 /**
154 * drm_fb_dma_get_scanout_buffer - Provide a scanout buffer in case of
panic
155 * @plane: DRM primary plane
156 * @drm_scanout_buffer: scanout buffer for the panic handler
157 * Returns: 0 or negative error code
158 *
159 * Generic get_scanout_buffer() implementation, for drivers that uses
the
160 * drm_fb_dma_helper. It won't call vmap in the panic context, so the
driver
161 * should make sure the primary plane is vmapped, otherwise the panic
screen
162 * won't get displayed.
163 */
> 164 int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
165struct drm_scanout_buffer *sb)
> 166 {
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
[PATCH v2] drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 41 +++
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 8c3f443c8347..46c24b1ee6df 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -792,7 +792,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!IS_DGFX(i915))
return;
- hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return;
@@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
hwm_get_preregistration_info(i915);
/* hwmon_dev points to device hwmon */
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
-ddat,
-&hwm_chip_info,
-hwm_groups);
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ &hwm_chip_info,
+ hwm_groups);
if (IS_ERR(hwmon_dev)) {
i915->hwmon = NULL;
return;
@@ -838,10 +838,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
hwmon_energy_input, 0))
continue;
- hwmon_dev = devm_hwmon_device_register_with_info(dev,
ddat_gt->name,
-ddat_gt,
-
&hwm_gt_chip_info,
-NULL);
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
+ ddat_gt,
+ &hwm_gt_chip_info,
+ NULL);
if (!IS_ERR(hwmon_dev))
ddat_gt->hwmon_dev = hwmon_dev;
}
@@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(&i915->hwmon);
+ struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
+ struct hwm_drvdata *ddat = &hwmon->ddat;
+ struct intel_gt *gt;
+ int i;
+
+ if (!hwmon)
+ return;
+
+ for_each_gt(gt, i915, i) {
+ struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
+
+ if (ddat_gt->hwmon_dev) {
+ hwmon_device_unregister(ddat_gt->hwmon_dev);
+ ddat_gt->hwmon_dev = NULL;
+ }
+ }
+
+ if (ddat->hwmon_dev)
+ hwmon_device_unregister(ddat->hwmon_dev);
+
+ mutex_destroy(&hwmon->hwmon_lock);
+ kfree(hwmon);
}
--
2.41.0
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-15 04:19, Pekka Paalanen wrote: On Fri, 12 Apr 2024 16:14:28 -0400 Leo Li wrote: On 2024-04-12 11:31, Alex Deucher wrote: On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen wrote: On Fri, 12 Apr 2024 10:28:52 -0400 Leo Li wrote: On 2024-04-12 04:03, Pekka Paalanen wrote: On Thu, 11 Apr 2024 16:33:57 -0400 Leo Li wrote: ... That begs the question of what can be nailed down and what can left to independent implementation. I guess things like which plane should be enabled first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed) can be defined. How to handle atomic test failures could be as well. What room is there for the interpretation of zpos values? I thought they are unambiguous already: only the relative numerical order matters, and that uniquely defines the KMS plane ordering. The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way for vendors to communicate overlay, underlay, or mixed-arrangement support. I don't think allowing OVERLAYs to be placed under the PRIMARY is currently documented as a way to support underlay. I always thought it's obvious that the zpos numbers dictate the plane order without any other rules. After all, we have the universal planes concept, where the plane type is only informational to aid heuristics rather than defining anything. Only if the zpos property does not exist, the plane types would come into play. Of course, if there actually exists userspace that fails if zpos allows an overlay type plane to be placed below primary, or fails if primary zpos is not zero, then DRM needs a new client cap. Right, it wasn't immediately clear to me that the API allowed placement of things beneath the PRIMARY. But reading the docs for drm_plane_create_zpos*, there's nothing that forbids it. libliftoff for example, assumes that the PRIMARY has the lowest zpos. So underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY for the underlay view. That's totally ok. It works, right? Plane type does not matter if the KMS driver accepts the configuration. What is a "scanout plane"? Aren't all KMS planes by definition scanout planes? Pardon my terminology, I thought the scanout plane was where weston rendered non-offloadable surfaces to. I guess it's more correct to call it the "render plane". On weston, it seems to be always assigned to the PRIMARY. The assignment restriction is just technical design debt. It is limiting. There is no other good reason for it, than when lighting up a CRTC for the first time, Weston should do it with the renderer FB only, on the plane that is most likely to succeed i.e. PRIMARY. After the CRTC is lit, there should be no built-in limitations in what can go where. The reason for this is that if a CRTC can be activated, it must always be able to show the renderer FB without incurring a modeset. This is important for ensuring that the fallback compositing (renderer) is always possible. So we start with that configuration, and everything else is optional bonus. Genuinely curious - What exactly is limiting with keeping the renderer FB on PRIMARY? IOW, what is the additional benefit of placing the renderer FB on something other than PRIMARY? For libliftoff, using OVERLAYs as the render plane and PRIMARY as the underlay plane would work. But I think keeping the render plane on PRIMARY (a la weston) makes underlay arrangements easier to allocate, and would be nice to incorporate into a shared algorithm. If zpos exists, I don't think such limitation is a good idea. It will just limit the possible configurations for no reason. With zpos, the KMS plane type should be irrelevant for their z-ordering. Underlay vs. overlay completely loses its meaning at the KMS level. Right, the plane types loose their meanings. But at least with the way libliftoff builds the plane arrangement, where we first allocate the renderer fb matters. libliftoff incrementally builds the atomic state by adding a single plane to the atomic state, then testing it. It essentially does a depth-first-search of all possible arrangements, pruning the search on atomic test fail. The state that offloads the most number of FBs will be the arrangement used. Of course, it's unlikely that the entire DFS tree will traversed in time for a frame. So the key is to search the most probable and high-benefit branches first, while minimizing the # of atomic tests needed, before a hard-coded deadline is hit. Following this algorithm, the PRIMARY needs to be enabled first, followed by all the secondary planes. After a plane is enabled, it's not preferred to change it's assigned FB, since that can cause the state to be rejected (in actuality, not just the FB, but also any color and transformation stuffs associated with the surface). It is preferable to build on the state by enabling another fb->plane. This is where changing a plane's zpos to be above/below the PRIMARY is advantageous
Re: [PATCH 0/4] Fix memory limits for STDU
On Thu, Apr 11, 2024 at 10:22 PM Zack Rusin wrote: > > - with stdu what happens when the mode selected is close to our > limits, the guest is using a hardware cursor and we allocate cursor > mobs? With overcommit (cfdc3458db8a1620b1e307e3cb07480a161146ab) it won't be an issue. Before overcommit there may be issues. That's what the original code in patch 3 was trying to solve by increasing the guest memory limit but that variable is also the hard host limit which would invalidate fixes made by patch 1. Regardless it will be broken in one way or another. We'd have to backport overcommit or multiply by that constant factor from patch 3 when calling vmw_gmrid_man_init in vmwgfx_gmird_manager.c in a separate patch. The only distros that may be problematic would be debian 11 and ubuntu 22.04 without the HWE kernel. Graphical installs of Ubuntu 22.04 LTS will have HWE by default so only Ubuntu server users who installed a GUI and configured the graphics memory to be tiny will be affected but chances are it was already broken.
[PATCH v3 9/9] drm/panel: truly-nt35597: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: Abhinav Kumar
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Neil Armstrong
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
b/drivers/gpu/drm/panel/panel-truly-nt35597.c
index b73448cf349d..d447db912a61 100644
--- a/drivers/gpu/drm/panel/panel-truly-nt35597.c
+++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
@@ -550,10 +550,8 @@ static int truly_nt35597_probe(struct mipi_dsi_device *dsi)
dsi1_host = of_find_mipi_dsi_host_by_node(dsi1);
of_node_put(dsi1);
- if (!dsi1_host) {
- dev_err(dev, "failed to find dsi host\n");
- return -EPROBE_DEFER;
- }
+ if (!dsi1_host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi
host\n");
/* register the second DSI device */
dsi1_device = mipi_dsi_device_register_full(dsi1_host, &info);
--
2.44.0
[PATCH v3 7/9] drm/bridge: dpc3433: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Also move the "failed to attach" error message so that it's only printed
when the devm_mipi_dsi_attach() call fails.
Fixes: 6352cd451ddb ("drm: bridge: Add TI DLPC3433 DSI to DMD bridge")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/ti-dlpc3433.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-dlpc3433.c
b/drivers/gpu/drm/bridge/ti-dlpc3433.c
index ca3348109bcd..6b559e071301 100644
--- a/drivers/gpu/drm/bridge/ti-dlpc3433.c
+++ b/drivers/gpu/drm/bridge/ti-dlpc3433.c
@@ -319,12 +319,11 @@ static int dlpc_host_attach(struct dlpc *dlpc)
.channel = 0,
.node = NULL,
};
+ int ret;
host = of_find_mipi_dsi_host_by_node(dlpc->host_node);
- if (!host) {
- DRM_DEV_ERROR(dev, "failed to find dsi host\n");
- return -EPROBE_DEFER;
- }
+ if (!host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi
host\n");
dlpc->dsi = mipi_dsi_device_register_full(host, &info);
if (IS_ERR(dlpc->dsi)) {
@@ -336,7 +335,11 @@ static int dlpc_host_attach(struct dlpc *dlpc)
dlpc->dsi->format = MIPI_DSI_FMT_RGB565;
dlpc->dsi->lanes = dlpc->dsi_lanes;
- return devm_mipi_dsi_attach(dev, dlpc->dsi);
+ ret = devm_mipi_dsi_attach(dev, dlpc->dsi);
+ if (ret)
+ DRM_DEV_ERROR(dev, "failed to attach dsi host\n");
+
+ return ret;
}
static int dlpc3433_probe(struct i2c_client *client)
@@ -367,10 +370,8 @@ static int dlpc3433_probe(struct i2c_client *client)
drm_bridge_add(&dlpc->bridge);
ret = dlpc_host_attach(dlpc);
- if (ret) {
- DRM_DEV_ERROR(dev, "failed to attach dsi host\n");
+ if (ret)
goto err_remove_bridge;
- }
return 0;
--
2.44.0
[PATCH v3 8/9] drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
panels")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35950.c
b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
index 648ce9201426..028fdac293f7 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35950.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
@@ -556,10 +556,8 @@ static int nt35950_probe(struct mipi_dsi_device *dsi)
}
dsi_r_host = of_find_mipi_dsi_host_by_node(dsi_r);
of_node_put(dsi_r);
- if (!dsi_r_host) {
- dev_err(dev, "Cannot get secondary DSI host\n");
- return -EPROBE_DEFER;
- }
+ if (!dsi_r_host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "Cannot get
secondary DSI host\n");
nt->dsi[1] = mipi_dsi_device_register_full(dsi_r_host, info);
if (!nt->dsi[1]) {
--
2.44.0
[PATCH v3 6/9] drm/bridge: tc358775: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/tc358775.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index 90a89d70d832..fea4f00a20f8 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -610,10 +610,8 @@ static int tc_attach_host(struct tc_data *tc)
};
host = of_find_mipi_dsi_host_by_node(tc->host_node);
- if (!host) {
- dev_err(dev, "failed to find dsi host\n");
- return -EPROBE_DEFER;
- }
+ if (!host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi
host\n");
dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
if (IS_ERR(dsi)) {
--
2.44.0
[PATCH v3 5/9] drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index f4f593ad8f79..ab702471f3ab 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -266,10 +266,8 @@ static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct
lt9611uxc *lt9611uxc,
int ret;
host = of_find_mipi_dsi_host_by_node(dsi_node);
- if (!host) {
- dev_err(dev, "failed to find dsi host\n");
- return ERR_PTR(-EPROBE_DEFER);
- }
+ if (!host)
+ return ERR_PTR(dev_err_probe(dev, -EPROBE_DEFER, "failed to
find dsi host\n"));
dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
if (IS_ERR(dsi)) {
--
2.44.0
[PATCH v3 4/9] drm/bridge: lt9611: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index a9c7e2b07ea1..b99fe87ec738 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -761,10 +761,8 @@ static struct mipi_dsi_device *lt9611_attach_dsi(struct
lt9611 *lt9611,
int ret;
host = of_find_mipi_dsi_host_by_node(dsi_node);
- if (!host) {
- dev_err(lt9611->dev, "failed to find dsi host\n");
- return ERR_PTR(-EPROBE_DEFER);
- }
+ if (!host)
+ return ERR_PTR(dev_err_probe(lt9611->dev, -EPROBE_DEFER,
"failed to find dsi host\n"));
dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
if (IS_ERR(dsi)) {
--
2.44.0
[PATCH v3 3/9] drm/bridge: lt8912b: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 4b2ae27f0a57..1a9defa15663 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -494,10 +494,8 @@ static int lt8912_attach_dsi(struct lt8912 *lt)
};
host = of_find_mipi_dsi_host_by_node(lt->host_node);
- if (!host) {
- dev_err(dev, "failed to find dsi host\n");
- return -EPROBE_DEFER;
- }
+ if (!host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi
host\n");
dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
if (IS_ERR(dsi)) {
--
2.44.0
[PATCH v3 2/9] drm/bridge: icn6211: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/chipone-icn6211.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
b/drivers/gpu/drm/bridge/chipone-icn6211.c
index 82d23e4df09e..ff3284b6b1a3 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -563,10 +563,8 @@ static int chipone_dsi_host_attach(struct chipone *icn)
host = of_find_mipi_dsi_host_by_node(host_node);
of_node_put(host_node);
- if (!host) {
- dev_err(dev, "failed to find dsi host\n");
- return -EPROBE_DEFER;
- }
+ if (!host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi
host\n");
dsi = mipi_dsi_device_register_full(host, &info);
if (IS_ERR(dsi)) {
--
2.44.0
[PATCH v3 0/9] drm: Switch from dev_err to dev_err_probe for missing DSI host error path
This series changes every occurrence of the following pattern:
dsi_host = of_find_mipi_dsi_host_by_node(dsi);
if (!dsi_host) {
dev_err(dev, "failed to find dsi host\n");
return -EPROBE_DEFER;
}
into
dsi_host = of_find_mipi_dsi_host_by_node(dsi);
if (!dsi_host)
return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi
host\n");
This registers the defer probe reason (so it can later be printed by the
driver core or checked on demand through the devices_deferred file in
debugfs) and prevents errors to be spammed in the kernel log every time
the driver retries to probe, unnecessarily alerting userspace about
something that is a normal part of the boot process.
I have omitted a Fixes: tag in the last patch, for the truly-nt35597
panel, because it predates the dev_err_probe() helper.
Changes in v3:
- Added trailers
- Rebased on next-20240415
- Link to v2:
https://lore.kernel.org/r/20240229-anx7625-defer-log-no-dsi-host-v2-0-005069410...@collabora.com
Changes in v2:
- Added patches 2 onwards to fix all occurences of this pattern instead
of just for the anx7625 driver
- Link to v1:
https://lore.kernel.org/r/20240226-anx7625-defer-log-no-dsi-host-v1-1-242b1af31...@collabora.com
---
Nícolas F. R. A. Prado (9):
drm/bridge: anx7625: Don't log an error when DSI host can't be found
drm/bridge: icn6211: Don't log an error when DSI host can't be found
drm/bridge: lt8912b: Don't log an error when DSI host can't be found
drm/bridge: lt9611: Don't log an error when DSI host can't be found
drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
drm/bridge: tc358775: Don't log an error when DSI host can't be found
drm/bridge: dpc3433: Don't log an error when DSI host can't be found
drm/panel: novatek-nt35950: Don't log an error when DSI host can't be
found
drm/panel: truly-nt35597: Don't log an error when DSI host can't be found
drivers/gpu/drm/bridge/analogix/anx7625.c | 6 ++
drivers/gpu/drm/bridge/chipone-icn6211.c | 6 ++
drivers/gpu/drm/bridge/lontium-lt8912b.c | 6 ++
drivers/gpu/drm/bridge/lontium-lt9611.c | 6 ++
drivers/gpu/drm/bridge/lontium-lt9611uxc.c| 6 ++
drivers/gpu/drm/bridge/tc358775.c | 6 ++
drivers/gpu/drm/bridge/ti-dlpc3433.c | 17 +
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 6 ++
drivers/gpu/drm/panel/panel-truly-nt35597.c | 6 ++
9 files changed, 25 insertions(+), 40 deletions(-)
---
base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e
change-id: 20240226-anx7625-defer-log-no-dsi-host-c3f9ccbcb287
Best regards,
--
Nícolas F. R. A. Prado
[PATCH v3 1/9] drm/bridge: anx7625: Don't log an error when DSI host can't be found
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 269332997a16 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host
was not found")
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Neil Armstrong
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 9d96d28d6fe8..02bf45005307 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2066,10 +2066,8 @@ static int anx7625_setup_dsi_device(struct anx7625_data
*ctx)
};
host = of_find_mipi_dsi_host_by_node(ctx->pdata.mipi_host_node);
- if (!host) {
- DRM_DEV_ERROR(dev, "fail to find dsi host.\n");
- return -EPROBE_DEFER;
- }
+ if (!host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "fail to find dsi
host.\n");
dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
if (IS_ERR(dsi)) {
--
2.44.0
Re: [PATCH 5/7] ARM: configs: sunxi: Enable DRM_DW_HDMI
Dne sreda, 3. april 2024 ob 12:56:23 GMT +2 je Maxime Ripard napisal(a):
> Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
> module") turned the DRM_DW_HDMI dependency of DRM_SUN8I_DW_HDMI into a
> depends on which ended up disabling the driver in the defconfig. Make
> sure it's still enabled.
>
> Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
> module")
> Reported-by: Mark Brown
> Reported-by: Alexander Stein
> Signed-off-by: Maxime Ripard
Applied, thanks!
Best regards,
Jernej
Re: [PATCH v4 0/5] Pinephone video out fixes (flipping between two frames)
Dne sreda, 3. april 2024 ob 17:31:47 GMT +2 je Frank Oltmanns napisal(a): > Dear clk and sunxi-ng maintainers, > > Patches 1-4 have been reviewed and there are no pending issues. If there > is something else you need me to do to get this applied, please let me > know. Sorry for late patch merge. Patch 1-2 are applied as a fix to 6.9, the rest will go to 6.10. Best regards, Jernej > > Thanks, > Frank > > On 2024-03-10 at 14:21:10 +0100, Frank Oltmanns wrote: > > On some pinephones the video output sometimes freezes (flips between two > > frames) [1]. It seems to be that the reason for this behaviour is that > > PLL-MIPI is outside its limits, and the GPU is not running at a fixed > > rate. > > > > In this patch series I propose the following changes: > > 1. sunxi-ng: Adhere to the following constraints given in the > > Allwinner A64 Manual regarding PLL-MIPI: > > * M/N <= 3 > > * (PLL_VIDEO0)/M >= 24MHz > > * 500MHz <= clockrate <= 1400MHz > > > > 2. Remove two operating points from the A64 DTS OPPs, so that the GPU > > runs at a fixed rate of 432 MHz. > > > > Note, that when pinning the GPU to 432 MHz the issue [1] completely > > disappears for me. I've searched the BSP and could not find any > > indication that supports the idea of having the three OPPs. The only > > frequency I found in the BPSs for A64 is 432 MHz, which has also proven > > stable for me. > > > > I very much appreciate your feedback! > > > > [1] https://gitlab.com/postmarketOS/pmaports/-/issues/805 > > > > Signed-off-by: Frank Oltmanns > > --- > > Changes in v4: > > - sunxi-ng: common: Address review comments. > > - Link to v3: > > https://lore.kernel.org/r/20240304-pinephone-pll-fixes-v3-0-94ab828f2...@oltmanns.dev > > > > Changes in v3: > > - dts: Pin GPU to 432 MHz. > > - nkm and a64: Move minimum and maximum rate handling to the common part > > of the sunxi-ng driver. > > - Removed st7703 patch from series. > > - Link to v2: > > https://lore.kernel.org/r/20240205-pinephone-pll-fixes-v2-0-96a46a2d8...@oltmanns.dev > > > > Changes in v2: > > - dts: Increase minimum GPU frequency to 192 MHz. > > - nkm and a64: Add minimum and maximum rate for PLL-MIPI. > > - nkm: Use the same approach for skipping invalid rates in > > ccu_nkm_find_best() as in ccu_nkm_find_best_with_parent_adj(). > > - nkm: Improve names for ratio struct members and hence get rid of > > describing comments. > > - nkm and a64: Correct description in the commit messages: M/N <= 3 > > - Remove patches for nm as they were not needed. > > - st7703: Rework the commit message to cover more background for the > > change. > > - Link to v1: > > https://lore.kernel.org/r/20231218-pinephone-pll-fixes-v1-0-e238b6ed6...@oltmanns.dev > > > > --- > > Frank Oltmanns (5): > > clk: sunxi-ng: common: Support minimum and maximum rate > > clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI > > clk: sunxi-ng: nkm: Support constraints on m/n ratio and parent rate > > clk: sunxi-ng: a64: Add constraints on PLL-MIPI's n/m ratio and > > parent rate > > arm64: dts: allwinner: a64: Run GPU at 432 MHz > > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 > > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +- > > drivers/clk/sunxi-ng/ccu_common.c | 19 +++ > > drivers/clk/sunxi-ng/ccu_common.h | 3 +++ > > drivers/clk/sunxi-ng/ccu_nkm.c| 21 + > > drivers/clk/sunxi-ng/ccu_nkm.h| 2 ++ > > 6 files changed, 54 insertions(+), 13 deletions(-) > > --- > > base-commit: dcb6c8ee6acc6c347caec1e73fb900c0f4ff9806 > > change-id: 20231218-pinephone-pll-fixes-0ccdfde273e4 > > > > Best regards, >
[PATCH v3] drm/i915/vma: Fix UAF on reopen vs destroy race
We defer actually closing, unbinding and destroying a VMA until next idle
point, or until the object is freed in the meantime. By postponing the
unbind, we allow for the VMA to be reopened by the client, avoiding the
work required to rebind the VMA.
It was assumed that as long as a GT is held idle, no VMA would be reopened
while we destroy them. That assumption is no longer true in multi-GT
configurations, where a VMA we reopen may be handled by a GT different
from the one that we already keep active via its engine while we set up
an execbuf request.
<4> [260.290809] [ cut here ]
<4> [260.290988] list_del corruption. prev->next should be 888118c5d990,
but was 888118c5a510. (prev=888118c5a510)
<4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
__list_del_entry_valid_or_report+0xb7/0xe0
..
<4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
<4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
<4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
...
<4> [260.291087] Call Trace:
<4> [260.291089]
<4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
<4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
<4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
<4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
...
<4> [260.292301]
...
<4> [260.292506] ---[ end trace ]---
<4> [260.292782] general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
<4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
<4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
<4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
...
<4> [260.428756] Call Trace:
<4> [260.431192]
<4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
<4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
...
<4> [639.411134]
...
<4> [639.449979] ---[ end trace ]---
As soon as we start unbinding and destroying a VMA, marked it as parked,
and also keep it marked as closed for the rest of its life. When a VMA
to be opened occurs closed, reopen it only if not yet parked.
v3: Fix misplaced brackets.
v2: Since we no longer re-init the VMA closed list link on VMA park so it
looks like still on a list, don't try to delete it from the list again
after the VMA has been marked as parked.
Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org # v6.0+
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 --
drivers/gpu/drm/i915/i915_vma.c | 32 +++
drivers/gpu/drm/i915/i915_vma.h | 2 +-
drivers/gpu/drm/i915/i915_vma_types.h | 3 ++
4 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 42619fc05de48..97e014f94002e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -847,9 +847,12 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
if (unlikely(!lut))
return -ENOMEM;
+ if (!i915_vma_open(vma)) {
+ err = -EEXIST; /* let eb_vma_lookup() retry */
+ goto err_lut_free;
+ }
+
i915_vma_get(vma);
- if (!atomic_fetch_inc(&vma->open_count))
- i915_vma_reopen(vma);
lut->handle = handle;
lut->ctx = ctx;
@@ -880,8 +883,9 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
return 0;
err:
- i915_vma_close(vma);
i915_vma_put(vma);
+ i915_vma_close(vma);
+err_lut_free:
i915_lut_handle_free(lut);
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d2f064d2525cc..4435c76f28c8c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1735,14 +1735,33 @@ static void __i915_vma_remove_closed(struct i915_vma
*vma)
list_del_init(&vma->closed_link);
}
-void i915_vma_reopen(struct i915_vma *vma)
+static struct i915_vma *i915_vma_reopen(struct i915_vma *vma)
+{
+ if (atomic_read(&vma->flags) & I915_VMA_PARKED)
+ return NULL;
+
+ __i915_vma_remove_closed(vma);
+ return vma;
+}
+
+struct i915_vma *i915_vma_open(struct i915_vma *vma)
{
struct intel_gt *gt = vma->vm->gt;
+ if (atomic_inc_not_zero(&vma->open_count))
+ return vma;
+
spin_lock_irq(>->closed_l
[linux-next:master] BUILD REGRESSION 6bd343537461b57f3efe5dfc5fc193a232dfef1e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 6bd343537461b57f3efe5dfc5fc193a232dfef1e Add linux-next specific files for 20240415 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404151720.ha4kzy01-...@intel.com https://lore.kernel.org/oe-kbuild-all/202404160020.38y5ribw-...@intel.com Error/Warning: (recently discovered and may have been fixed) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_chroot+0xd0 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_inotify_add_watch+0x12a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_landlock_add_rule+0x1b0 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ___se_sys_open_by_handle_at+0x1ea (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __dev_queue_xmit+0x1d4 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __do_sys_fsmount+0xf2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __do_sys_pivot_root+0x28a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __hw_addr_del_entry+0x44 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __hw_addr_flush+0x48 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: __u64_stats_update_begin+0x16 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ahci_platform_get_resources+0x84 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: altera_msi_probe+0x80 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: armada8k_pcie_probe+0x144 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: atmel_sha_probe+0x36a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: btrfs_init_new_device+0x14e (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: cqhci_pltfm_init+0x1a (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: default_device_exit_net+0x128 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: do_coredump+0x454 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: do_utimes+0xea (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: dpm_suspend+0xa2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: dpm_suspend_late+0x86 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: dpm_suspend_noirq+0xa2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: edma_probe+0xf2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: free_filters_list+0x3c (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: img_hash_probe+0x3a0 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ipv6_icmp_error+0x20 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: kernel_read_file_from_path_initns+0xe6 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: kmb_ocs_aes_probe+0x1c2 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: kmb_ocs_ecc_probe+0x172 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: ks_pcie_probe+0xb0 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: lpc18xx_eeprom_probe+0x3e (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: mntns_install+0xd4 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: mobiveil_pcie_host_probe+0x36 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinux: section mismatch in reference: mptcp_pm_nl_get_addr+0x112 (section: .text) -> .L0 (section: .init.text) WARNING: modpost: vmlinu
[PATCH v2] drm/i915/vma: Fix UAF on reopen vs destroy race
We defer actually closing, unbinding and destroying a VMA until next idle
point, or until the object is freed in the meantime. By postponing the
unbind, we allow for the VMA to be reopened by the client, avoiding the
work required to rebind the VMA.
It was assumed that as long as a GT is held idle, no VMA would be reopened
while we destroy them. That assumption is no longer true in multi-GT
configurations, where a VMA we reopen may be handled by a GT different
from the one that we already keep active via its engine while we set up
an execbuf request.
<4> [260.290809] [ cut here ]
<4> [260.290988] list_del corruption. prev->next should be 888118c5d990,
but was 888118c5a510. (prev=888118c5a510)
<4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
__list_del_entry_valid_or_report+0xb7/0xe0
..
<4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
<4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
<4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
...
<4> [260.291087] Call Trace:
<4> [260.291089]
<4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
<4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
<4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
<4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
...
<4> [260.292301]
...
<4> [260.292506] ---[ end trace ]---
<4> [260.292782] general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
<4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
<4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024
<4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
...
<4> [260.428756] Call Trace:
<4> [260.431192]
<4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
<4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
...
<4> [639.411134]
...
<4> [639.449979] ---[ end trace ]---
As soon as we start unbinding and destroying a VMA, marked it as parked,
and also keep it marked as closed for the rest of its life. When a VMA
to be opened occurs closed, reopen it only if not yet parked.
v2: Since we no longer re-init the VMA closed list link on VMA park so it
looks like still on a list, don't try to delete it from the list again
after the VMA has been marked as parked.
Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org # v6.0+
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 --
drivers/gpu/drm/i915/i915_vma.c | 32 +++
drivers/gpu/drm/i915/i915_vma.h | 2 +-
drivers/gpu/drm/i915/i915_vma_types.h | 3 ++
4 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 42619fc05de48..97e014f94002e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -847,9 +847,12 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
if (unlikely(!lut))
return -ENOMEM;
+ if (!i915_vma_open(vma)) {
+ err = -EEXIST; /* let eb_vma_lookup() retry */
+ goto err_lut_free;
+ }
+
i915_vma_get(vma);
- if (!atomic_fetch_inc(&vma->open_count))
- i915_vma_reopen(vma);
lut->handle = handle;
lut->ctx = ctx;
@@ -880,8 +883,9 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
return 0;
err:
- i915_vma_close(vma);
i915_vma_put(vma);
+ i915_vma_close(vma);
+err_lut_free:
i915_lut_handle_free(lut);
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d2f064d2525cc..072c2c02edc22 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1735,14 +1735,33 @@ static void __i915_vma_remove_closed(struct i915_vma
*vma)
list_del_init(&vma->closed_link);
}
-void i915_vma_reopen(struct i915_vma *vma)
+static struct i915_vma *i915_vma_reopen(struct i915_vma *vma)
+{
+ if (atomic_read(&vma->flags) & I915_VMA_PARKED)
+ return NULL;
+
+ __i915_vma_remove_closed(vma);
+ return vma;
+}
+
+struct i915_vma *i915_vma_open(struct i915_vma *vma)
{
struct intel_gt *gt = vma->vm->gt;
+ if (atomic_inc_not_zero(&vma->open_count))
+ return vma;
+
spin_lock_irq(>->closed_lock);
- if (i915_vma_i
Re: [PATCH 1/5] drm/v3d: Don't increment `enabled_ns` twice
On 4/3/24 17:24, Maíra Canal wrote:
The commit 509433d8146c ("drm/v3d: Expose the total GPU usage stats on sysfs")
introduced the calculation of global GPU stats. For the regards, it used
the already existing infrastructure provided by commit 09a93cc4f7d1 ("drm/v3d:
Implement show_fdinfo() callback for GPU usage stats"). While adding
global GPU stats calculation ability, the author forgot to delete the
existing one.
Currently, the value of `enabled_ns` is incremented twice by the end of
the job, when it should be added just once. Therefore, delete the
leftovers from commit 509433d8146c ("drm/v3d: Expose the total GPU usage
stats on sysfs").
Fixes: 509433d8146c ("drm/v3d: Expose the total GPU usage stats on sysfs")
Reported-by: Tvrtko Ursulin
Signed-off-by: Maíra Canal
As this patch is a isolated bugfix and it was reviewed by two
developers, I'm applying it to drm-misc/drm-misc-fixes.
I'll address the feedback for the rest of the series later and send a
v2.
Best Regards,
- Maíra
---
drivers/gpu/drm/v3d/v3d_irq.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
index 2e04f6cb661e..ce6b2fb341d1 100644
--- a/drivers/gpu/drm/v3d/v3d_irq.c
+++ b/drivers/gpu/drm/v3d/v3d_irq.c
@@ -105,7 +105,6 @@ v3d_irq(int irq, void *arg)
struct v3d_file_priv *file =
v3d->bin_job->base.file->driver_priv;
u64 runtime = local_clock() - file->start_ns[V3D_BIN];
- file->enabled_ns[V3D_BIN] += local_clock() - file->start_ns[V3D_BIN];
file->jobs_sent[V3D_BIN]++;
v3d->queue[V3D_BIN].jobs_sent++;
@@ -126,7 +125,6 @@ v3d_irq(int irq, void *arg)
struct v3d_file_priv *file =
v3d->render_job->base.file->driver_priv;
u64 runtime = local_clock() - file->start_ns[V3D_RENDER];
- file->enabled_ns[V3D_RENDER] += local_clock() - file->start_ns[V3D_RENDER];
file->jobs_sent[V3D_RENDER]++;
v3d->queue[V3D_RENDER].jobs_sent++;
@@ -147,7 +145,6 @@ v3d_irq(int irq, void *arg)
struct v3d_file_priv *file =
v3d->csd_job->base.file->driver_priv;
u64 runtime = local_clock() - file->start_ns[V3D_CSD];
- file->enabled_ns[V3D_CSD] += local_clock() - file->start_ns[V3D_CSD];
file->jobs_sent[V3D_CSD]++;
v3d->queue[V3D_CSD].jobs_sent++;
@@ -195,7 +192,6 @@ v3d_hub_irq(int irq, void *arg)
struct v3d_file_priv *file =
v3d->tfu_job->base.file->driver_priv;
u64 runtime = local_clock() - file->start_ns[V3D_TFU];
- file->enabled_ns[V3D_TFU] += local_clock() - file->start_ns[V3D_TFU];
file->jobs_sent[V3D_TFU]++;
v3d->queue[V3D_TFU].jobs_sent++;
Re: [PATCH v2 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
Le 15/04/2024 à 18:10, David Wronek a écrit :
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 366 ++
3 files changed, 381 insertions(+)
...
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+ mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x53, 0x28);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
+ mipi_dsi_dcs_write_seq(dsi, 0x35, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x51, 0x07, 0xff);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display on: %d\n", ret);
+ return ret;
+ }
+ msleep(36);
36 and 35 below are un-usual values for msleep.
Why 2 different values?
Would using a #define for this(these) value(s) make sense here?
+
+ return 0;
+}
+
+static int rm69380_off(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+ ret = mipi_dsi_dcs_set_display_off(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display off: %d\n", ret);
+ return ret;
+ }
+ msleep(35);
(here)
+
+ ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enter sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ return 0;
+}
...
+static int rm69380_probe(struct mipi_dsi_device *dsi)
+{
+ struct mipi_dsi_host *dsi_sec_host;
+ struct rm69380_panel *ctx;
+ struct device *dev = &dsi->dev;
+ struct device_node *dsi_sec;
+ int ret, i;
+
+ ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ ctx->supplies[0].supply = "vddio";
+ ctx->supplies[1].supply = "avdd";
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get regulators\n");
+
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
+"Failed to get reset-gpios\n");
+
+ dsi_sec = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
+
+ if (dsi_sec) {
+ dev_dbg(dev, "Using Dual-DSI\n");
This should be after de 'info' variable below, so...
+
+ const struct mipi_dsi_device_info info = { "RM69380", 0,
+ dsi_sec };
+
+ dev_dbg(dev, "Found second DSI `%s`\n", dsi_sec->name);
... maybe merge the 2 messages into something like:
dev_dbg(dev, "Using Dual-DSI: found `%s`\n", dsi_sec->name);
+
+ dsi_sec_host = of_find_mipi_dsi_host_by_node(dsi_sec);
+ of_node_put(dsi_sec);
+ if (!dsi_sec_host) {
+ return dev_err_probe(dev, -EPROBE_DEFER,
+"Cannot get secondary DSI host\n");
+ }
+
Nit: unneeded { }
+ ctx->dsi[1] =
+ mipi_dsi_device_register_full(dsi_sec_host, &info);
+ if (IS_ERR(ctx->dsi[1])) {
+ return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
+"Cannot get secondary DSI node\n");
+ }
Nit: unneeded { }
+
+ dev_dbg(dev, "Second DSI name `%s`\n", ctx->dsi[1]->name);
+ mipi_dsi_set_drvdata(ctx->dsi[1], ctx);
+ } else {
+ dev_dbg(dev, "Using Single-DSI\n");
+
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Mon, 15 Apr 2024 18:10:41 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240415-raydium-rm69380-driver-v2-1-524216461...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH RFC 2/2] pmdomain: ti-sci: Support retaining PD boot time state
On 15/04/2024 19:00, Tomi Valkeinen wrote: Add a new flag, TI_SCI_PD_KEEP_BOOT_STATE, which can be set in the dts when referring to power domains. When this flag is set, the ti-sci driver will check if the PD is currently enabled in the HW, and if so, set the GENPD_FLAG_ALWAYS_ON flag so that the PD will stay enabled. The main issue I'm trying to solve here is this: If the Display Subsystem (DSS) has been enabled by the bootloader, the related PD has also been enabled in the HW. When the tidss driver probes, the driver framework will automatically enable the PD. While executing the probe function it is very common for the probe to return EPROBE_DEFER, and, in rarer cases, an actual error. When this happens (probe() returns an error), the driver framework will automatically disable the related PD. Powering off the PD while the DSS is enabled and displaying a picture will cause the DSS HW to enter a bad state, from which (afaik) it can't be woken up except with full power-cycle. Trying to access the DSS in this state (e.g. when retrying the probe) will usually cause the board to hang sooner or later. Even if we wouldn't have this board-hangs issue, it's nice to be able to keep the DSS PD enabled: we want to keep the DSS enabled when the bootloader has enabled the screen. If, instead, we disable the PD at the first EPROBE_DEFER, the screen will (probably) go black. A few things occurred to me. The driver is supposed to clear the GENPD_FLAG_ALWAYS_ON when the driver has probed successfully. There are two possible issues with that: - Afaics, there's no API to do that, and currently I just clear the bit in genpd->flags. There's a clear race there, so some locking would be required. - This uses the GENPD_FLAG_ALWAYS_ON flag to say "PD is always on, until the driver has started". If the PD would have GENPD_FLAG_ALWAYS_ON set for other reasons, the driver would still go and clear the flag, which might break things. Also, unrelated to the above and not a problem in practice at the very moment, but I think clocks should also be dealt with somehow. Something, at early-ish boot stage, should mark the relevant clocks as in use, so that there's no chance they would be turned off when the main kernel has started (the main display driver is often a module). It would be nice to deal with all the above in a single place. I wonder if the tidss driver itself could somehow be split into two parts, an early part that would probe with minimal dependencies, mainly to reserve the core resources without doing any kind of DRM init. And a main part which would (somehow) finish the initialization at a later point, when we have the filesystem (for firmware) and the other bridge/panel drivers have probed. That can be somewhat achieved with simplefb or simpledrm, though, but we can't do any TI DSS specific things there, and it also creates a requirement to have either of those drivers built-in, and the related DT nodes to be added. Tomi Another option here would perhaps be to change the driver framework (drivers/base/platform.c) which attaches and detaches the PD, and make it somehow optional, allowing the driver the manage the PD. That option has two downsides: 1) the driver _has_ to manage the PD, which would rule out the use of simplefb and simpledrm, and 2) it would leave the PD in off state from Linux's perspective until a driver enables the PD, and that might mean that the PD gets actually disabled as part of normal system wide power management (disabling unused resources). Yet another option would be to do this outside the ti_sci_pm_domains driver: a piece of code that would somehow be ran after the ti_sci_pm_domains driver has probed (so that we have the PDs), but before tidss/simplefb/simpledrm probes. The problem here is the "somehow" part. Also, this would partly have the same issue 2) as mentioned above. TODO: If this approach is ok, sci-pm-domain.yaml needs to be extended. Also, it sounds a bit like the cell value is not a bit-mask, so maybe adding TI_SCI_PD_KEEP_BOOT_STATE flag this way is not fine. Signed-off-by: Tomi Valkeinen --- drivers/pmdomain/ti/ti_sci_pm_domains.c| 27 +-- include/dt-bindings/soc/ti,sci_pm_domain.h | 1 + 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c index 1510d5ddae3d..b71b390aaa39 100644 --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c @@ -103,7 +103,7 @@ static struct generic_pm_domain *ti_sci_pd_xlate( return ERR_PTR(-ENOENT); genpd_to_ti_sci_pd(genpd_data->domains[idx])->exclusive = - genpdspec->args[1]; + genpdspec->args[1] & TI_SCI_PD_EXCLUSIVE; return genpd_data->domains[idx]; } @@ -161,6 +161,8 @@ static int ti_sci_pm_domain_probe(struct platform_device *pdev) break; if (a
Re: [PATCH] dma-buf: Do not build debugfs related code when !CONFIG_DEBUG_FS
Hi Tvrtko, On 4/1/24 10:21, Tvrtko Ursulin wrote: On 01/04/2024 13:45, Christian König wrote: Am 01.04.24 um 14:39 schrieb Tvrtko Ursulin: On 29/03/2024 00:00, T.J. Mercier wrote: On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin wrote: From: Tvrtko Ursulin There is no point in compiling in the list and mutex operations which are only used from the dma-buf debugfs code, if debugfs is not compiled in. Put the code in questions behind some kconfig guards and so save some text and maybe even a pointer per object at runtime when not enabled. Signed-off-by: Tvrtko Ursulin Reviewed-by: T.J. Mercier Thanks! How would patches to dma-buf be typically landed? Via what tree I mean? drm-misc-next? That should go through drm-misc-next. And feel free to add Reviewed-by: Christian König as well. Thanks! Maarten if I got it right you are handling the next drm-misc-next pull - could you merge this one please? Applied to drm-misc/drm-misc-next! Best Regards, - Maíra Regards, Tvrtko
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Mon, Apr 15, 2024 at 06:10:41PM +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> new file mode 100644
> index ..0ac7d033cbe0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Raydium RM6380-based DSI display panels
> +
> +maintainers:
> + - David Wronek
> +
> +description:
> + The Raydium RM69380 is a generic DSI panel IC used to control
> + OLED panels.
> +
> +allOf:
> + - $ref: panel-common-dual.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - lenovo,j716f-edo-rm69380
> + - const: raydium,rm69380
> +description: This indicates the panel manufacturer of the panel
> + that is in turn using the RM69380 panel driver. The compatible
> + string determines how the RM69380 panel driver shall be configured
> + to work with the indicated panel. The raydium,rm69380 compatible shall
> + always be provided as a fallback.
> +
> + avdd-supply:
> +description: Analog voltage rail
> +
> + vddio-supply:
> +description: I/O voltage rail
> +
> + reset-gpios:
> +maxItems: 1
> +description: phandle of gpio for reset line - This should be active low
> +
> + ports: true
> + reg: true
Where is reg defined? I briefly checked the two panel-common bindings
and didn't see it.
Cheers,
Conor.
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - vddio-supply
> + - reset-gpios
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "lenovo,j716f-edo-rm69380", "raydium,rm69380";
> +reg = <0>;
> +
> +avdd-supply = <&panel_avdd_regulator>;
> +vddio-supply = <&vreg_l14a>;
> +reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +panel_in_0: endpoint {
> +remote-endpoint = <&mdss_dsi0_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +panel_in_1: endpoint {
> +remote-endpoint = <&mdss_dsi1_out>;
> +};
> +};
> +};
> +};
> +};
> +
> +...
>
> --
> 2.44.0
>
signature.asc
Description: PGP signature
Re: [PATCH] drm/fb_dma: s/drm_panic_gem_get_scanout_buffer/drm_fb_dma_get_scanout_buffer
On 4/15/24 12:19, Jocelyn Falempe wrote: Hi, You're right, I messed up the rename, and I mostly test on x86, where I don't build the imx driver. Reviewed-by: Jocelyn Falempe Best regards, Applied to drm-misc/drm-misc-next! Best Regards, - Maíra
Re: [PATCH v2 1/2] drm/nouveau/disp: add backlight for ada lovelace
Hm. Could you share some logs with drm.debug=0x116? I'm a bit confused
because I would have thought that we were already probing for eDP
backlights seeing as I added support for them at one point?
(I hope this isn't the point I learn I actually forgot to add support
for them :P)
On Fri, 2024-04-12 at 21:49 +0200, Angelo Dureghello wrote:
> Add working backlight for "ada lovelace" missing case.
>
> The nvif method is actually not working for this chipset so
> used the drm apis. Also, by dpcd, drm layer is calculating a
> max brightness of 255, but to get a real correct max brightnes
> the maximum must be multiplied by a factor of 16.
>
> Tested to work properly in Legion Lenovo Pro 5
>
> Lenovo Legion 5 Pro 16ARX8
> Bios ver LPCN49WW
>LPEC49WW
> SN PF4T63AZ
> Nvidia RTX4060 MaxQ/Mobile rev a1 (ADA LOVELACE AD107M)
> AMD Ryzen 9 7945HX + Radeon
>
> and wayland.
>
> ---
> Changes for v2:
> - add some comments
> - remove x16 multiplication (hack)
> - remove forgot debug printk
>
> Signed-off-by: Angelo Dureghello
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 54
> +
> 1 file changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index d47442125fa1..7b7306d18ad7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -286,6 +286,56 @@ nv50_backlight_init(struct nouveau_backlight
> *bl,
> return 0;
> }
>
> +static int
> +nv19x_backlight_init(struct nouveau_backlight *bl,
> + struct nouveau_connector *nv_conn,
> + struct nouveau_encoder *nv_encoder,
> + struct backlight_properties *props,
> + const struct backlight_ops **ops)
> +{
> + int ret;
> + u16 current_level;
> + u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
> + u8 current_mode;
> + struct nouveau_drm *drm = nouveau_drm(nv_encoder-
> >base.base.dev);
> +
> + /*
> + * nvif functions, so also nvif_outp_bl_get, are not working
> with this
> + * connector (return -22), using only drm layer.
> + */
> + if (nv_conn->type == DCB_CONNECTOR_eDP) {
> +
> + ret = drm_dp_dpcd_read(&nv_conn->aux,
> DP_EDP_DPCD_REV, edp_dpcd,
> + EDP_DISPLAY_CTL_CAP_SIZE);
> + if (ret < 0)
> + return ret;
> + if (!drm_edp_backlight_supported(edp_dpcd))
> + return -ENODEV;
> +
> + ret = drm_edp_backlight_init(&nv_conn->aux, &bl-
> >edp_info, 0, edp_dpcd,
> + ¤t_level,
> ¤t_mode);
> + if (ret < 0)
> + return ret;
> +
> + ret = drm_edp_backlight_enable(&nv_conn->aux, &bl-
> >edp_info, current_level);
> + if (ret < 0) {
> + NV_ERROR(drm, "Failed to enable backlight on
> %s: %d\n",
> + nv_conn->base.name, ret);
> + return ret;
> + }
> +
> + *ops = &nv50_edp_bl_ops;
> +
> + props->max_brightness = bl->edp_info.max;
> + props->brightness = current_level;
> + bl->uses_dpcd = true;
> +
> + return 0;
> + }
> +
> + return -ENODEV;
> +}
> +
> int
> nouveau_backlight_init(struct drm_connector *connector)
> {
> @@ -332,6 +382,10 @@ nouveau_backlight_init(struct drm_connector
> *connector)
> ret = nv50_backlight_init(bl,
> nouveau_connector(connector),
> nv_encoder, &props, &ops);
> break;
> + case NV_DEVICE_INFO_V0_ADA:
> + ret = nv19x_backlight_init(bl,
> nouveau_connector(connector),
> + nv_encoder, &props,
> &ops);
> + break;
> default:
> ret = 0;
> goto fail_alloc;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
On Mon, 15 Apr 2024 13:00:39 -0300
Maíra Canal wrote:
Hi,
> RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
> the RPi. Currently, the downstream kernel uses an overlay to enable the
> GPU and use GPU hardware acceleration. When deploying a mainline kernel
> to the RPi 0-3, we end up without any GPU hardware acceleration
> (essentially, we can't use the OpenGL driver).
>
> Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel.
So I think Krzysztof's initial comment still stands: What does that patch
actually change? If I build those DTBs as of now, none of them has a
status property in the v3d node. Which means it's enabled:
https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status
So adding an explicit 'status = "okay";' doesn't make a difference.
What do I miss here?
Cheers,
Andre
> Signed-off-by: Maíra Canal
> ---
>
> v1 -> v2:
> https://lore.kernel.org/dri-devel/41694292-af1f-4760-a7b6-101ed5dd6...@gmx.net/T/
>
> * As mentioned by Krzysztof, enabling should be done in last place of
> override/extend. Therefore, I'm disabling V3D in the common dtsi
> and enabling in the last place of extend, i.e. the RPi DTS files.
>
> arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 +
> arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts| 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts| 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts | 4
> arch/arm/boot/dts/broadcom/bcm2835-rpi-zero.dts | 4
> arch/arm/boot/dts/broadcom/bcm2836-rpi-2-b.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-3-a-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-cm3-io3.dts | 4
> arch/arm/boot/dts/broadcom/bcm2837-rpi-zero-2-w.dts | 4
> 15 files changed, 57 insertions(+)
>
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> index 9261b67dbee1..69e34831de51 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
> @@ -139,6 +139,7 @@ v3d: v3d@7ec0 {
> compatible = "brcm,bcm2835-v3d";
> reg = <0x7ec0 0x1000>;
> interrupts = <1 10>;
> + status = "disabled";
> };
>
> vc4: gpu {
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> index 069b48272aa5..495ab1dfd2ce 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
> @@ -128,3 +128,7 @@ &uart0 {
> pinctrl-0 = <&uart0_gpio14>;
> status = "okay";
> };
> +
> +&v3d {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> index 2726c00431e8..4634d88ce3af 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
> @@ -121,3 +121,7 @@ &uart0 {
> pinctrl-0 = <&uart0_gpio14>;
> status = "okay";
> };
> +
> +&v3d {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> index c57b999a4520..45fa0f6851fc 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
> @@ -130,3 +130,7 @@ &uart0 {
> pinctrl-0 = <&uart0_gpio14>;
> status = "okay";
> };
> +
> +&v3d {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> index ae6d3a9586ab..c1dac5d704aa 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
> @@ -121,3 +121,7 @@ &uart0 {
> pinctrl-0 = <&uart0_gpio14>;
> status = "okay";
> };
> +
> +&v3d {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> index 72764be75a79..72ca31f2a7d6 100644
> --- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
> @@ -115,3 +115,7 @@ &uart0 {
> pinctrl-0 = <&uart0_gpio14>;
> status = "okay";
> };
> +
> +&v3d {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts
> b/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1
Re: [PATCH v2 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
On Mon, Apr 15, 2024 at 06:10:42PM +0200, David Wronek wrote:
> Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
> Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
>
> Signed-off-by: David Wronek
> ---
> drivers/gpu/drm/panel/Kconfig | 14 +
> drivers/gpu/drm/panel/Makefile| 1 +
> drivers/gpu/drm/panel/panel-raydium-rm69380.c | 366
> ++
> 3 files changed, 381 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 154f5bf82980..5b3eeb93b1a2 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -542,6 +542,20 @@ config DRM_PANEL_RAYDIUM_RM692E5
> Say Y here if you want to enable support for Raydium RM692E5-based
> display panels, such as the one found in the Fairphone 5 smartphone.
>
> +config DRM_PANEL_RAYDIUM_RM69380
> + tristate "Raydium RM69380-based DSI panel"
> + depends on BACKLIGHT_CLASS_DEVICE
> + depends on DRM_DISPLAY_DP_HELPER
> + depends on DRM_DISPLAY_HELPER
> + depends on DRM_MIPI_DSI
> + depends on OF
> + help
> + Say Y here if you want to enable support for Raydium RM69380-based
> + display panels.
> +
> + This panel controller can be found in the Lenovo Xiaoxin Pad Pro 2021
> + in combination with an EDO OLED panel.
> +
> config DRM_PANEL_RONBO_RB070D30
> tristate "Ronbo Electronics RB070D30 panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 24a02655d726..e2a2807d4ef0 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
> panel-raspberrypi-touchscreen
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
> +obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
> obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
> b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
> new file mode 100644
> index ..253b9a1c2800
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
> @@ -0,0 +1,366 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
> tree.
> + * Copyright (c) 2024 David Wronek
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct rm69380_panel {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi[2];
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> + bool prepared;
> +};
> +
> +static inline
> +struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct rm69380_panel, panel);
> +}
> +
> +static void rm69380_reset(struct rm69380_panel *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(15000, 16000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(1, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + msleep(30);
> +}
> +
> +static int rm69380_on(struct rm69380_panel *ctx)
> +{
> + struct mipi_dsi_device *dsi = ctx->dsi[0];
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> + if (ctx->dsi[1])
> + ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
> + mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
> + mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
> + mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
> + mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, 0x53, 0x28);
> + mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
> + mipi_dsi_dcs_write_seq(dsi, 0x35, 0x00);
mipi_dsi_dcs_set_tear_on(dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
> + mipi_dsi_dcs_write_seq(dsi, 0x51, 0x07, 0xff);
ret = mipi_dsi_dcs_set_display_brightness_large(dsi, 0x7ff);
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0) {
> + dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> + return ret;
> + }
> + msleep(20);
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set display on: %d\n"
Re: [PATCH v1 1/3] dt-bindings: display: add #sound-dai-cells property to rockchip dw hdmi
On Sat, Apr 13, 2024 at 05:38:05PM +0200, Johan Jonker wrote: > The Rockchip DWC HDMI TX Encoder can take one I2S input and transmit it > over the HDMI output. Add #sound-dai-cells (= 0) to the binding for it. > > Signed-off-by: Johan Jonker Please send cover letters for multi-patch series, for all 3: Acked-by: Conor Dooley Chees, Conor. signature.asc Description: PGP signature
[PATCH v2 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 366 ++
3 files changed, 381 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 154f5bf82980..5b3eeb93b1a2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -542,6 +542,20 @@ config DRM_PANEL_RAYDIUM_RM692E5
Say Y here if you want to enable support for Raydium RM692E5-based
display panels, such as the one found in the Fairphone 5 smartphone.
+config DRM_PANEL_RAYDIUM_RM69380
+ tristate "Raydium RM69380-based DSI panel"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on DRM_DISPLAY_DP_HELPER
+ depends on DRM_DISPLAY_HELPER
+ depends on DRM_MIPI_DSI
+ depends on OF
+ help
+ Say Y here if you want to enable support for Raydium RM69380-based
+ display panels.
+
+ This panel controller can be found in the Lenovo Xiaoxin Pad Pro 2021
+ in combination with an EDO OLED panel.
+
config DRM_PANEL_RONBO_RB070D30
tristate "Ronbo Electronics RB070D30 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 24a02655d726..e2a2807d4ef0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
new file mode 100644
index ..253b9a1c2800
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 David Wronek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct rm69380_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+ bool prepared;
+};
+
+static inline
+struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct rm69380_panel, panel);
+}
+
+static void rm69380_reset(struct rm69380_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(15000, 16000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 11000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(30);
+}
+
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+ mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x53, 0x28);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
+ mipi_dsi_dcs_write_seq(dsi, 0x35, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x51, 0x07, 0xff);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display on: %d\n", ret);
+ return ret;
+ }
+ msleep(36);
+
+ return 0;
+}
+
+static int rm69380_off(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->ds
[PATCH v2 0/2] Add driver for Raydium RM69380-based DSI panels
This patch adds support the 2560x1600@90Hz dual DSI command mode panel by EDO in combination with a Raydium RM69380 driver IC. This driver IC can be found in the following devices: * Lenovo Xiaoxin Pad Pro 2021 (TB-J716F) with EDO panel * Lenovo Tab P11 Pro (TB-J706F) with EDO panel * Robo & Kala 2-in-1 Laptop with Sharp panel Signed-off-by: David Wronek --- Changes in v2: - Fixed typo in Kconfig - Removed ctx->prepared = true; in prepare function - Switched to drm_connector_helper_get_modes_fixed in get_modes function - Changed dev_notice() to dev_dbg() - Add description for compatible and reset-gpio in the dt-binding - Always require 'ports' node in the dt-binding regardless of compatible - Link to v1: https://lore.kernel.org/r/20240414-raydium-rm69380-driver-v1-0-5e86ba249...@mainlining.org --- David Wronek (2): dt-bindings: display: panel: Add Raydium RM69380 drm/panel: Add driver for EDO RM69380 OLED panel .../bindings/display/panel/raydium,rm69380.yaml| 91 + drivers/gpu/drm/panel/Kconfig | 14 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-raydium-rm69380.c | 366 + 4 files changed, 472 insertions(+) --- base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e change-id: 20240414-raydium-rm69380-driver-47f22b6f24fe Best regards, -- David Wronek
[PATCH v2 1/2] dt-bindings: display: panel: Add Raydium RM69380
Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
Add a dt-binding for it.
Signed-off-by: David Wronek
---
.../bindings/display/panel/raydium,rm69380.yaml| 91 ++
1 file changed, 91 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
new file mode 100644
index ..0ac7d033cbe0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raydium RM6380-based DSI display panels
+
+maintainers:
+ - David Wronek
+
+description:
+ The Raydium RM69380 is a generic DSI panel IC used to control
+ OLED panels.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - lenovo,j716f-edo-rm69380
+ - const: raydium,rm69380
+description: This indicates the panel manufacturer of the panel
+ that is in turn using the RM69380 panel driver. The compatible
+ string determines how the RM69380 panel driver shall be configured
+ to work with the indicated panel. The raydium,rm69380 compatible shall
+ always be provided as a fallback.
+
+ avdd-supply:
+description: Analog voltage rail
+
+ vddio-supply:
+description: I/O voltage rail
+
+ reset-gpios:
+maxItems: 1
+description: phandle of gpio for reset line - This should be active low
+
+ ports: true
+ reg: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - vddio-supply
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "lenovo,j716f-edo-rm69380", "raydium,rm69380";
+reg = <0>;
+
+avdd-supply = <&panel_avdd_regulator>;
+vddio-supply = <&vreg_l14a>;
+reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+panel_in_0: endpoint {
+remote-endpoint = <&mdss_dsi0_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+panel_in_1: endpoint {
+remote-endpoint = <&mdss_dsi1_out>;
+};
+};
+};
+};
+};
+
+...
--
2.44.0
Re: [PATCH v11 1/3] drm/buddy: Implement tracking clear page feature
Hi Christian,
Could you please push these patches into drm branch.
Thanks,
Arun.
On 4/15/2024 2:53 AM, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared memory
but fallback to uncleared if we can't find the cleared blocks.
when driver requests uncleared memory we try to use uncleared but
fallback to cleared memory if necessary.
- When a block gets freed we clear it and mark the freed block as cleared,
when there are buddies which are cleared as well we can merge them.
Otherwise, we prefer to keep the blocks as separated.
- Add a function to support defragmentation.
v1:
- Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
cleared. Else, reset the clear flag for each block in the list(Christian)
- For merging the 2 cleared blocks compare as below,
drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)(Christian)
- Defragment the memory beginning from min_order
till the required memory space is available.
v2: (Matthew)
- Add a wrapper drm_buddy_free_list_internal for the freeing of blocks
operation within drm buddy.
- Write a macro block_incompatible() to allocate the required blocks.
- Update the xe driver for the drm_buddy_free_list change in arguments.
- add a warning if the two blocks are incompatible on
defragmentation
- call full defragmentation in the fini() function
- place a condition to test if min_order is equal to 0
- replace the list with safe_reverse() variant as we might
remove the block from the list.
v3:
- fix Gitlab user reported lockup issue.
- Keep DRM_BUDDY_HEADER_CLEAR define sorted(Matthew)
- modify to pass the root order instead max_order in fini()
function(Matthew)
- change bool 1 to true(Matthew)
- add check if min_block_size is power of 2(Matthew)
- modify the min_block_size datatype to u64(Matthew)
v4:
- rename the function drm_buddy_defrag with __force_merge.
- Include __force_merge directly in drm buddy file and remove
the defrag use in amdgpu driver.
- Remove list_empty() check(Matthew)
- Remove unnecessary space, headers and placement of new variables(Matthew)
- Add a unit test case(Matthew)
v5:
- remove force merge support to actual range allocation and not to bail
out when contains && split(Matthew)
- add range support to force merge function.
v6:
- modify the alloc_range() function clear page non merged blocks
allocation(Matthew)
- correct the list_insert function name(Matthew).
Signed-off-by: Arunpravin Paneer Selvam
Signed-off-by: Matthew Auld
Suggested-by: Christian König
Suggested-by: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +-
drivers/gpu/drm/drm_buddy.c | 427 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 6 +-
drivers/gpu/drm/tests/drm_buddy_test.c| 28 +-
drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 4 +-
include/drm/drm_buddy.h | 16 +-
6 files changed, 363 insertions(+), 124 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
return 0;
error_free_blocks:
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
error_fini:
ttm_resource_fini(man, &vres->base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct ttm_resource_manager
*man,
amdgpu_vram_mgr_do_reserve(man);
- drm_buddy_free_list(mm, &vres->blocks);
+ drm_buddy_free_list(mm, &vres->blocks, 0);
mutex_unlock(&mgr->lock);
atomic64_sub(vis_usage, &mgr->vis_usage);
@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
kfree(rsv);
list_for_each_entry_safe(rsv, temp, &mgr->reserved_pages, blocks) {
- drm_buddy_free_list(&mgr->mm, &rsv->allocated);
+ drm_buddy_free_list(&mgr->mm, &rsv->allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 5ebdd6f8f36e..284ebae71cc4 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(&block->link, node->link.prev, &node->link);
}
+static void clear_reset(struct drm_buddy_blo
[PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to
the RPi. Currently, the downstream kernel uses an overlay to enable the
GPU and use GPU hardware acceleration. When deploying a mainline kernel
to the RPi 0-3, we end up without any GPU hardware acceleration
(essentially, we can't use the OpenGL driver).
Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel.
Signed-off-by: Maíra Canal
---
v1 -> v2:
https://lore.kernel.org/dri-devel/41694292-af1f-4760-a7b6-101ed5dd6...@gmx.net/T/
* As mentioned by Krzysztof, enabling should be done in last place of
override/extend. Therefore, I'm disabling V3D in the common dtsi
and enabling in the last place of extend, i.e. the RPi DTS files.
arch/arm/boot/dts/broadcom/bcm2835-common.dtsi | 1 +
arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts| 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts| 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts | 4
arch/arm/boot/dts/broadcom/bcm2835-rpi-zero.dts | 4
arch/arm/boot/dts/broadcom/bcm2836-rpi-2-b.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-a-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-cm3-io3.dts | 4
arch/arm/boot/dts/broadcom/bcm2837-rpi-zero-2-w.dts | 4
15 files changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
index 9261b67dbee1..69e34831de51 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm2835-common.dtsi
@@ -139,6 +139,7 @@ v3d: v3d@7ec0 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec0 0x1000>;
interrupts = <1 10>;
+ status = "disabled";
};
vc4: gpu {
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
index 069b48272aa5..495ab1dfd2ce 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a-plus.dts
@@ -128,3 +128,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
index 2726c00431e8..4634d88ce3af 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-a.dts
@@ -121,3 +121,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
index c57b999a4520..45fa0f6851fc 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-plus.dts
@@ -130,3 +130,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
index ae6d3a9586ab..c1dac5d704aa 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b-rev2.dts
@@ -121,3 +121,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
index 72764be75a79..72ca31f2a7d6 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-b.dts
@@ -115,3 +115,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts
index 3f9d198ac3ab..881a07d2f28f 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-cm1-io1.dts
@@ -95,3 +95,7 @@ &uart0 {
pinctrl-0 = <&uart0_gpio14>;
status = "okay";
};
+
+&v3d {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts
b/arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts
index 1f0b163e400c..1c7324067442 100644
--- a/arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts
+++ b/arch/arm/boot/dts/broadcom/bcm2835-rpi-zero-w.dts
@@ -134,6 +134,10 @@ &uart1 {
status = "okay";
};
+&v3d {
+ status = "okay";
+};
+
&wifi
[PATCH RFC 0/2] pmdomain: ti-sci: Handling DSS boot splash
The first patch here is a fix for ti_sci_pm_domains to handle the case where the dts has two nodes which refer to the same PD. The second is the interesting one, and very much an RFC. Tomi Signed-off-by: Tomi Valkeinen --- Tomi Valkeinen (2): pmdomain: ti-sci: Fix duplicate PD referrals pmdomain: ti-sci: Support retaining PD boot time state drivers/pmdomain/ti/ti_sci_pm_domains.c| 47 -- include/dt-bindings/soc/ti,sci_pm_domain.h | 1 + 2 files changed, 45 insertions(+), 3 deletions(-) --- base-commit: 0bbac3facb5d6cc0171c45c9873a2dc96bea9680 change-id: 20240415-ti-sci-pd-33b39f6b0586 Best regards, -- Tomi Valkeinen
[PATCH RFC 1/2] pmdomain: ti-sci: Fix duplicate PD referrals
When the dts file has multiple referrers to a single PD (e.g.
simple-framebuffer and dss nodes both point to the DSS power-domain) the
ti-sci driver will create two power domains, both with the same ID, and
that will cause problems as one of the power domains will hide the other
one.
Fix this checking if a PD with the ID has already been created, and only
create a PD for new IDs.
Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds
instead of one")
Signed-off-by: Tomi Valkeinen
---
drivers/pmdomain/ti/ti_sci_pm_domains.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c
b/drivers/pmdomain/ti/ti_sci_pm_domains.c
index 9dddf227a3a6..1510d5ddae3d 100644
--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
+++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
@@ -114,6 +114,18 @@ static const struct of_device_id
ti_sci_pm_domain_matches[] = {
};
MODULE_DEVICE_TABLE(of, ti_sci_pm_domain_matches);
+static bool ti_sci_pm_idx_exists(struct ti_sci_genpd_provider *pd_provider,
u32 idx)
+{
+ struct ti_sci_pm_domain *pd;
+
+ list_for_each_entry(pd, &pd_provider->pd_list, node) {
+ if (pd->idx == idx)
+ return true;
+ }
+
+ return false;
+}
+
static int ti_sci_pm_domain_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -149,8 +161,14 @@ static int ti_sci_pm_domain_probe(struct platform_device
*pdev)
break;
if (args.args_count >= 1 && args.np == dev->of_node) {
- if (args.args[0] > max_id)
+ if (args.args[0] > max_id) {
max_id = args.args[0];
+ } else {
+ if (ti_sci_pm_idx_exists(pd_provider,
args.args[0])) {
+ index++;
+ continue;
+ }
+ }
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd) {
--
2.34.1
[PATCH RFC 2/2] pmdomain: ti-sci: Support retaining PD boot time state
Add a new flag, TI_SCI_PD_KEEP_BOOT_STATE, which can be set in the dts
when referring to power domains. When this flag is set, the ti-sci
driver will check if the PD is currently enabled in the HW, and if so,
set the GENPD_FLAG_ALWAYS_ON flag so that the PD will stay enabled.
The main issue I'm trying to solve here is this:
If the Display Subsystem (DSS) has been enabled by the bootloader, the
related PD has also been enabled in the HW. When the tidss driver
probes, the driver framework will automatically enable the PD. While
executing the probe function it is very common for the probe to return
EPROBE_DEFER, and, in rarer cases, an actual error. When this happens
(probe() returns an error), the driver framework will automatically
disable the related PD.
Powering off the PD while the DSS is enabled and displaying a picture
will cause the DSS HW to enter a bad state, from which (afaik) it can't
be woken up except with full power-cycle. Trying to access the DSS in
this state (e.g. when retrying the probe) will usually cause the board
to hang sooner or later.
Even if we wouldn't have this board-hangs issue, it's nice to be able to
keep the DSS PD enabled: we want to keep the DSS enabled when the
bootloader has enabled the screen. If, instead, we disable the PD at the
first EPROBE_DEFER, the screen will (probably) go black.
Another option here would perhaps be to change the driver framework
(drivers/base/platform.c) which attaches and detaches the PD, and make
it somehow optional, allowing the driver the manage the PD. That option
has two downsides: 1) the driver _has_ to manage the PD, which would
rule out the use of simplefb and simpledrm, and 2) it would leave the PD
in off state from Linux's perspective until a driver enables the PD, and
that might mean that the PD gets actually disabled as part of normal
system wide power management (disabling unused resources).
Yet another option would be to do this outside the ti_sci_pm_domains
driver: a piece of code that would somehow be ran after the
ti_sci_pm_domains driver has probed (so that we have the PDs), but
before tidss/simplefb/simpledrm probes. The problem here is the
"somehow" part. Also, this would partly have the same issue 2) as
mentioned above.
TODO: If this approach is ok, sci-pm-domain.yaml needs to be extended.
Also, it sounds a bit like the cell value is not a bit-mask, so maybe
adding TI_SCI_PD_KEEP_BOOT_STATE flag this way is not fine.
Signed-off-by: Tomi Valkeinen
---
drivers/pmdomain/ti/ti_sci_pm_domains.c| 27 +--
include/dt-bindings/soc/ti,sci_pm_domain.h | 1 +
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c
b/drivers/pmdomain/ti/ti_sci_pm_domains.c
index 1510d5ddae3d..b71b390aaa39 100644
--- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
+++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
@@ -103,7 +103,7 @@ static struct generic_pm_domain *ti_sci_pd_xlate(
return ERR_PTR(-ENOENT);
genpd_to_ti_sci_pd(genpd_data->domains[idx])->exclusive =
- genpdspec->args[1];
+ genpdspec->args[1] & TI_SCI_PD_EXCLUSIVE;
return genpd_data->domains[idx];
}
@@ -161,6 +161,8 @@ static int ti_sci_pm_domain_probe(struct platform_device
*pdev)
break;
if (args.args_count >= 1 && args.np == dev->of_node) {
+ bool is_on = false;
+
if (args.args[0] > max_id) {
max_id = args.args[0];
} else {
@@ -189,7 +191,28 @@ static int ti_sci_pm_domain_probe(struct platform_device
*pdev)
pd->idx = args.args[0];
pd->parent = pd_provider;
- pm_genpd_init(&pd->pd, NULL, true);
+ /*
+* If TI_SCI_PD_KEEP_BOOT_STATE is set and the
+* PD has been enabled by the bootloader, set
+* the PD to GENPD_FLAG_ALWAYS_ON. This will
+* make sure the PD stays enabled until a driver
+* takes over and clears the
GENPD_FLAG_ALWAYS_ON
+* flag.
+*/
+ if (args.args_count > 1 &&
+ args.args[1] & TI_SCI_PD_KEEP_BOOT_STATE) {
+ /*
+* We ignore any error here, and in case
+* of error just assume the PD is off.
+*/
+
pd_provider->ti_sci->ops.dev_ops.is_on(pd_provider->ti_sci,
+ pd->idx, NULL, &is_on);
+
+
Re: [PATCH] doc: dma-buf: fix grammar typo
Hi Christian,
On Mon, Apr 15 2024, Christian König wrote:
> Am 14.04.24 um 15:07 schrieb Baruch Siach:
>> Signed-off-by: Baruch Siach
>> ---
>> Documentation/driver-api/dma-buf.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/driver-api/dma-buf.rst
>> b/Documentation/driver-api/dma-buf.rst
>> index 0c153d79ccc4..29abf1eebf9f 100644
>> --- a/Documentation/driver-api/dma-buf.rst
>> +++ b/Documentation/driver-api/dma-buf.rst
>> @@ -77,7 +77,7 @@ consider though:
>> the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every
>> other
>> llseek operation will report -EINVAL.
>> - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE
>> for all
>> + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE
>> for all
>
> Looks valid of hand, but checkpatch.pl complains about 2 errors (missing
> commit message for example) and a warning.
>
> Please fix and resend.
I only get the checkpatch.pl output listed below with one warning. What
parameters do you use?
WARNING: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 8 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
Commit d242a446258e ("doc: dma-buf: fix grammar typo") has style problems,
please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Thanks,
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH 3/5] drm/v3d: Create a struct to store the GPU stats
El 3/4/24 a las 22:24, Maíra Canal escribió:
This will make it easier to instantiate the GPU stats variables and it
will create a structure where we can store all the variables that refer
to GPU stats.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c | 14 ++
drivers/gpu/drm/v3d/v3d_drv.h | 18 ++
drivers/gpu/drm/v3d/v3d_gem.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 20
drivers/gpu/drm/v3d/v3d_sysfs.c | 10 ++
5 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 3debf37e7d9b..cbb62be18aa5 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -115,14 +115,11 @@ v3d_open(struct drm_device *dev, struct drm_file *file)
v3d_priv->v3d = v3d;
for (i = 0; i < V3D_MAX_QUEUES; i++) {
- v3d_priv->enabled_ns[i] = 0;
- v3d_priv->start_ns[i] = 0;
- v3d_priv->jobs_sent[i] = 0;
-
sched = &v3d->queue[i].sched;
drm_sched_entity_init(&v3d_priv->sched_entity[i],
DRM_SCHED_PRIORITY_NORMAL, &sched,
1, NULL);
+ memset(&v3d_priv->stats[i], 0, sizeof(v3d_priv->stats[i]));
}
v3d_perfmon_open_file(v3d_priv);
@@ -151,20 +148,21 @@ static void v3d_show_fdinfo(struct drm_printer *p, struct
drm_file *file)
enum v3d_queue queue;
for (queue = 0; queue < V3D_MAX_QUEUES; queue++) {
+ struct v3d_stats *stats = &file_priv->stats[queue];
+
/* Note that, in case of a GPU reset, the time spent during an
* attempt of executing the job is not computed in the runtime.
*/
drm_printf(p, "drm-engine-%s: \t%llu ns\n",
v3d_queue_to_string(queue),
- file_priv->start_ns[queue] ?
file_priv->enabled_ns[queue]
- + timestamp -
file_priv->start_ns[queue]
- :
file_priv->enabled_ns[queue]);
+ stats->start_ns ? stats->enabled_ns + timestamp -
stats->start_ns
+ : stats->enabled_ns);
/* Note that we only count jobs that completed. Therefore, jobs
* that were resubmitted due to a GPU reset are not computed.
*/
drm_printf(p, "v3d-jobs-%s: \t%llu jobs\n",
- v3d_queue_to_string(queue),
file_priv->jobs_sent[queue]);
+ v3d_queue_to_string(queue), stats->jobs_sent);
}
}
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index ee3545226d7f..0117593976ed 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -36,15 +36,20 @@ static inline char *v3d_queue_to_string(enum v3d_queue
queue)
return "UNKNOWN";
}
+struct v3d_stats {
+ u64 start_ns;
+ u64 enabled_ns;
+ u64 jobs_sent;
As currently, we are only accounting jobs that have been completed. What
do you think of renaming jobs_sent to jobs_completed?
+};
+
struct v3d_queue_state {
struct drm_gpu_scheduler sched;
u64 fence_context;
u64 emit_seqno;
- u64 start_ns;
- u64 enabled_ns;
- u64 jobs_sent;
+ /* Stores the GPU stats for this queue in the global context. */
+ struct v3d_stats stats;
};
/* Performance monitor object. The perform lifetime is controlled by userspace
@@ -188,11 +193,8 @@ struct v3d_file_priv {
struct drm_sched_entity sched_entity[V3D_MAX_QUEUES];
- u64 start_ns[V3D_MAX_QUEUES];
-
- u64 enabled_ns[V3D_MAX_QUEUES];
-
- u64 jobs_sent[V3D_MAX_QUEUES];
+ /* Stores the GPU stats for a specific queue for this fd. */
+ struct v3d_stats stats[V3D_MAX_QUEUES];
};
struct v3d_bo {
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index afc565078c78..d14589d3ae6c 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -248,9 +248,7 @@ v3d_gem_init(struct drm_device *dev)
for (i = 0; i < V3D_MAX_QUEUES; i++) {
v3d->queue[i].fence_context = dma_fence_context_alloc(1);
- v3d->queue[i].start_ns = 0;
- v3d->queue[i].enabled_ns = 0;
- v3d->queue[i].jobs_sent = 0;
+ memset(&v3d->queue[i].stats, 0, sizeof(v3d->queue[i].stats));
}
spin_lock_init(&v3d->mm_lock);
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 8ca61bcd4b1c..ea5f5a84b55b 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -110,10 +110,12 @@ v3d_job_start_stats(struct v3d_job *job, enum v3d_queue
queue)
{
struct v3d_dev *v3d = job->v3
Re: [PATCH] drm/fb_dma: s/drm_panic_gem_get_scanout_buffer/drm_fb_dma_get_scanout_buffer
Hi,
You're right, I messed up the rename, and I mostly test on x86, where I
don't build the imx driver.
Reviewed-by: Jocelyn Falempe
Best regards,
--
Jocelyn
On 15/04/2024 17:09, Maíra Canal wrote:
On version 11, Thomas suggested to change the name of the function and
this request was applied on version 12, which is the version that
landed. Although the name of the function changed on the C file, it
didn't changed on the header file, leading to a compilation error as
such:
drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c:780:24: error: use of undeclared
identifier 'drm_fb_dma_get_scanout_buffer'; did you mean
'drm_panic_gem_get_scanout_buffer'?
780 | .get_scanout_buffer = drm_fb_dma_get_scanout_buffer,
| ^
| drm_panic_gem_get_scanout_buffer
./include/drm/drm_fb_dma_helper.h:23:5: note: 'drm_panic_gem_get_scanout_buffer'
declared here
23 | int drm_panic_gem_get_scanout_buffer(struct drm_plane *plane,
| ^
1 error generated.
Best Regards,
- Maíra
Fixes: 879b3b6511fe ("drm/fb_dma: Add generic get_scanout_buffer() for
drm_panic"
Signed-off-by: Maíra Canal
---
include/drm/drm_fb_dma_helper.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_fb_dma_helper.h b/include/drm/drm_fb_dma_helper.h
index 61f24c2aba2f..c950732c6d36 100644
--- a/include/drm/drm_fb_dma_helper.h
+++ b/include/drm/drm_fb_dma_helper.h
@@ -6,6 +6,7 @@
struct drm_device;
struct drm_framebuffer;
+struct drm_plane;
struct drm_plane_state;
struct drm_scanout_buffer;
@@ -20,8 +21,8 @@ void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
struct drm_plane_state *old_state,
struct drm_plane_state *state);
-int drm_panic_gem_get_scanout_buffer(struct drm_plane *plane,
-struct drm_scanout_buffer *sb);
+int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
+ struct drm_scanout_buffer *sb);
#endif
[PATCH] drm/fb_dma: s/drm_panic_gem_get_scanout_buffer/drm_fb_dma_get_scanout_buffer
On version 11, Thomas suggested to change the name of the function and
this request was applied on version 12, which is the version that
landed. Although the name of the function changed on the C file, it
didn't changed on the header file, leading to a compilation error as
such:
drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c:780:24: error: use of undeclared
identifier 'drm_fb_dma_get_scanout_buffer'; did you mean
'drm_panic_gem_get_scanout_buffer'?
780 | .get_scanout_buffer = drm_fb_dma_get_scanout_buffer,
| ^
| drm_panic_gem_get_scanout_buffer
./include/drm/drm_fb_dma_helper.h:23:5: note: 'drm_panic_gem_get_scanout_buffer'
declared here
23 | int drm_panic_gem_get_scanout_buffer(struct drm_plane *plane,
| ^
1 error generated.
Best Regards,
- Maíra
Fixes: 879b3b6511fe ("drm/fb_dma: Add generic get_scanout_buffer() for
drm_panic"
Signed-off-by: Maíra Canal
---
include/drm/drm_fb_dma_helper.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_fb_dma_helper.h b/include/drm/drm_fb_dma_helper.h
index 61f24c2aba2f..c950732c6d36 100644
--- a/include/drm/drm_fb_dma_helper.h
+++ b/include/drm/drm_fb_dma_helper.h
@@ -6,6 +6,7 @@
struct drm_device;
struct drm_framebuffer;
+struct drm_plane;
struct drm_plane_state;
struct drm_scanout_buffer;
@@ -20,8 +21,8 @@ void drm_fb_dma_sync_non_coherent(struct drm_device *drm,
struct drm_plane_state *old_state,
struct drm_plane_state *state);
-int drm_panic_gem_get_scanout_buffer(struct drm_plane *plane,
-struct drm_scanout_buffer *sb);
+int drm_fb_dma_get_scanout_buffer(struct drm_plane *plane,
+ struct drm_scanout_buffer *sb);
#endif
--
2.44.0
Re: [PATCH v12 0/9] drm/panic: Add a drm panic handler
On 10/04/2024 10:12, Daniel Vetter wrote: On Tue, Apr 09, 2024 at 06:30:39PM +0200, Jocelyn Falempe wrote: drm/panic: Add a drm panic handler This introduces a new drm panic handler, which displays a message when a panic occurs. So when fbcon is disabled, you can still see a kernel panic. This is one of the missing feature, when disabling VT/fbcon in the kernel: https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/ Fbcon can be replaced by a userspace kms console, but the panic screen must be done in the kernel. It works with simpledrm, mgag200, ast, and imx. To test it, make sure you're using one of the supported driver, and trigger a panic: echo c > /proc/sysrq-trigger or you can enable CONFIG_DRM_PANIC_DEBUG and echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0 Even if this is not yet useful, it will allows to work on more driver support, and better debug information to be added. v2: * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann) * Add the panic reason to the panic message (Nerdopolis) * Add an exclamation mark (Nerdopolis) v3: * Rework the drawing functions, to write the pixels line by line and to use the drm conversion helper to support other formats. (Thomas Zimmermann) v4: * Fully support all simpledrm formats using drm conversion helpers * Rename dpanic_* to drm_panic_*, and have more coherent function name. (Thomas Zimmermann) * Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann) * Remove the default y to DRM_PANIC config option (Thomas Zimmermann) * Add foreground/background color config option * Fix the bottom lines not painted if the framebuffer height is not a multiple of the font height. * Automatically register the driver to drm_panic, if the function get_scanout_buffer() exists. (Thomas Zimmermann) * Add mgag200 support. v5: * Change the drawing API, use drm_fb_blit_from_r1() to draw the font. (Thomas Zimmermann) * Also add drm_fb_fill() to fill area with background color. * Add draw_pixel_xy() API for drivers that can't provide a linear buffer. * Add a flush() callback for drivers that needs to synchronize the buffer. * Add a void *private field, so drivers can pass private data to draw_pixel_xy() and flush(). * Add ast support. * Add experimental imx/ipuv3 support, to test on an ARM hw. (Maxime Ripard) v6: * Fix sparse and __le32 warnings * Drop the IMX/IPUV3 experiment, it was just to show that it works also on ARM devices. v7: * Add a check to see if the 4cc format is supported by drm_panic. * Add a drm/plane helper to loop over all visible primary buffer, simplifying the get_scanout_buffer implementations * Add a generic implementation for drivers that uses drm_fb_dma. (Maxime Ripard) * Add back the IMX/IPUV3 support, and use the generic implementation. (Maxime Ripard) v8: * Directly register each plane to the panic notifier (Sima) * Replace get_scanout_buffer() with set_scanout_buffer() to simplify the locking. (Thomas Zimmermann) * Add a debugfs entry, to trigger the drm_panic without a real panic (Sima) * Fix the drm_panic Documentation, and include it in drm-kms.rst v9: * Revert to using get_scanout_buffer() (Sima) * Move get_scanout_buffer() and panic_flush() to the plane helper functions (Thomas Zimmermann) * Register all planes with get_scanout_buffer() to the panic notifier * Use drm_panic_lock() to protect against race (Sima) * Create a debugfs file for each plane in the device's debugfs directory. This allows to test for each plane of each GPU independently. v10: * Move blit and fill functions back in drm_panic (Thomas Zimmermann). * Simplify the text drawing functions. * Use kmsg_dumper instead of panic_notifier (Sima). * Use spinlock_irqsave/restore (John Ogness) v11: * Use macro instead of inline functions for drm_panic_lock/unlock (John Ogness) v12: * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) * Rename drm_panic_gem_get_scanout_buffer to drm_fb_dma_get_scanout_buffer and build it unconditionally (Thomas Zimmermann) * Better indent struct drm_scanout_buffer declaration. (Thomas Zimmermann) On the series: Acked-by: Daniel Vetter And apologies for the detours this patch set took and my part in the (too many) revisions. I think we should land this and do anything more once it's merged and we extend the panic support to more drivers. Thanks for your help, I just pushed it to drm-misc-next. Best regards, -- Jocelyn Thanks a lot to you for seeing this through! Cheers, Sima Best regards, Daniel Vetter (1): drm/panic: Add drm panic locking Jocelyn Falempe (8): drm/panic: Add a drm panic handler drm/panic: Add support for color format conversion drm/panic: Add debugfs entry to test without triggering panic. drm/fb_dma: Add generic get_scanout_buffer() for d
[PATCH 6.1 48/69] drm/ast: Fix soft lockup
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.
These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.
DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.
Signed-off-by: Jammy Huang
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory
Display-Port")
Reviewed-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Cc: KuoHsiang Chou
Cc: Thomas Zimmermann
Cc: Dave Airlie
Cc: Jocelyn Falempe
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_dp.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -190,6 +190,7 @@ void ast_dp_set_on_off(struct drm_device
{
struct ast_private *ast = to_ast_private(dev);
u8 video_on_off = on;
+ u32 i = 0;
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE3, (u8)
~AST_DP_VIDEO_ENABLE, on);
@@ -202,6 +203,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) !=
video_on_off) {
// wait 1 ms
mdelay(1);
+ if (++i > 200)
+ break;
}
}
}
[bug report] drm/nouveau/disp/r535: initial support
Hello Nouveau Devs,
Commit 9e999023 ("drm/nouveau/disp/r535: initial support") from
Sep 19, 2023 (linux-next), leads to the following Smatch static
checker warning:
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c:1482 r535_disp_oneinit() error:
potential NULL/IS_ERR bug 'ctrl'
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c:1582 r535_disp_oneinit() error:
potential NULL/IS_ERR bug 'ctrl'
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c:1596 r535_disp_oneinit() error:
potential NULL/IS_ERR bug 'ctrl'
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c:1625 r535_disp_oneinit() error:
potential NULL/IS_ERR bug 'ctrl'
drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c:519 r535_fifo_ectx_size()
error: potential NULL/IS_ERR bug 'ctrl'
drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c:556 r535_fifo_runl_ctor()
error: potential NULL/IS_ERR bug 'ctrl'
drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c:631 r535_fifo_runl_ctor()
error: potential NULL/IS_ERR bug 'ctrl'
drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
1432 static int
1433 r535_disp_oneinit(struct nvkm_disp *disp)
1434 {
1435 struct nvkm_device *device = disp->engine.subdev.device;
1436 struct nvkm_gsp *gsp = device->gsp;
1437 NV2080_CTRL_INTERNAL_DISPLAY_WRITE_INST_MEM_PARAMS *ctrl;
1438 int ret, i;
1439
1440 /* RAMIN. */
1441 ret = nvkm_gpuobj_new(device, 0x1, 0x1, false, NULL,
&disp->inst);
1442 if (ret)
1443 return ret;
1444
1445 if (WARN_ON(nvkm_memory_target(disp->inst->memory) !=
NVKM_MEM_TARGET_VRAM))
1446 return -EINVAL;
1447
1448 ctrl = nvkm_gsp_rm_ctrl_get(&gsp->internal.device.subdevice,
1449
NV2080_CTRL_CMD_INTERNAL_DISPLAY_WRITE_INST_MEM,
1450 sizeof(*ctrl));
1451 if (IS_ERR(ctrl))
1452 return PTR_ERR(ctrl);
1453
1454 ctrl->instMemPhysAddr = nvkm_memory_addr(disp->inst->memory);
1455 ctrl->instMemSize = nvkm_memory_size(disp->inst->memory);
1456 ctrl->instMemAddrSpace = ADDR_FBMEM;
1457 ctrl->instMemCpuCacheAttr = NV_MEMORY_WRITECOMBINED;
1458
1459 ret = nvkm_gsp_rm_ctrl_wr(&gsp->internal.device.subdevice,
ctrl);
1460 if (ret)
1461 return ret;
1462
1463 /* OBJs. */
1464 ret = nvkm_gsp_client_device_ctor(gsp, &disp->rm.client,
&disp->rm.device);
1465 if (ret)
1466 return ret;
1467
1468 ret = nvkm_gsp_rm_alloc(&disp->rm.device.object, 0x0073,
NV04_DISPLAY_COMMON, 0,
1469 &disp->rm.objcom);
1470 if (ret)
1471 return ret;
1472
1473 {
1474 NV2080_CTRL_INTERNAL_DISPLAY_GET_STATIC_INFO_PARAMS
*ctrl;
1475
1476 ctrl =
nvkm_gsp_rm_ctrl_rd(&gsp->internal.device.subdevice,
1477
NV2080_CTRL_CMD_INTERNAL_DISPLAY_GET_STATIC_INFO,
1478sizeof(*ctrl));
1479 if (IS_ERR(ctrl))
The problem here is that r535_gsp_rpc_push() returns a mix of error
pointers and NULL. I've written a blog about how mixing error pointers
and NULL normally works and I think there is some kind of similar logic
here but I forget what it is...
https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/
1480 return PTR_ERR(ctrl);
1481
--> 1482 disp->wndw.mask = ctrl->windowPresentMask;
^^
Potential NULL dereference.
1483 disp->wndw.nr = fls(disp->wndw.mask);
1484 nvkm_gsp_rm_ctrl_done(&gsp->internal.device.subdevice,
ctrl);
1485 }
1486
1487 /* */
1488 {
1489 #if defined(CONFIG_ACPI) && defined(CONFIG_X86)
1490 NV2080_CTRL_INTERNAL_INIT_BRIGHTC_STATE_LOAD_PARAMS
*ctrl;
1491 struct nvkm_gsp_object *subdevice =
&disp->rm.client.gsp->internal.device.subdevice;
1492
1493 ctrl = nvkm_gsp_rm_ctrl_get(subdevice,
1494
NV2080_CTRL_CMD_INTERNAL_INIT_BRIGHTC_STATE_LOAD,
1495 sizeof(*ctrl));
1496 if (IS_ERR(ctrl))
regards,
dan carpenter
Re: [PATCH] drm/ttm: stop pooling cached NUMA pages v2
Am 15.04.24 um 16:32 schrieb Felix Kuehling:
On 2024-04-15 10:08, Christian König wrote:
Am 15.04.24 um 15:53 schrieb Felix Kuehling:
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory pressure it can happen that
pages from the wrong NUMA node enters the pool and are re-used
over and over again.
This can lead to performance reduction after running into memory
pressure.
v2: restructure and cleanup the code a bit from the internal hack to
test this.
Signed-off-by: Christian König
Fixes: 4482d3c94d7f ("drm/ttm: add NUMA node id to the pool")
CC: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_pool.c | 38
+-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
b/drivers/gpu/drm/ttm/ttm_pool.c
index 112438d965ff..6e1fd6985ffc 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -288,17 +288,23 @@ static struct ttm_pool_type
*ttm_pool_select_type(struct ttm_pool *pool,
enum ttm_caching caching,
unsigned int order)
{
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
+ if (pool->use_dma_alloc)
return &pool->caching[caching].orders[order];
#ifdef CONFIG_X86
switch (caching) {
case ttm_write_combined:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
Doesn't this break USWC allocations on NUMA systems, where we set a
NUMA node for the default pool (at least we were planning to at some
point)?
I don't think so, but I might have missed something. Why do you think
that would break?
I mean the idea is basically if the pool is associated with a NUMA id
we should rather use this pool instead of the global one.
And that is true for both cases, the default pool and the specialized
ones.
OK, I think I misunderstood what I was reading. It looked to me like
it would always use a "caching" pool if nid was set. But caching here
is a variable; each node still has specialized pools for write
combining etc.
Then the concern you stated in the commit message "under memory
pressure it can happen that pages from the wrong NUMA node enters the
pool and are re-used over and over again" is still possible for
uncached and wc pages. Anyway, it's better than not having NUMA, I guess.
Yes, correct. But since KFD doesn't use USWC that much I don't think
this will cause an issue.
If we really start to see issues with that we can always re-consider
using __GFP_THIS_NODE.
The patch is
Reviewed-by: Felix Kuehling
Thanks, going to push to drm-misc-fixes now.
Regards,
Christian.
Regards,
Christian.
Regards,
Felix
+
if (pool->use_dma32)
return &global_dma32_write_combined[order];
return &global_write_combined[order];
case ttm_uncached:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
+
if (pool->use_dma32)
return &global_dma32_uncached[order];
@@ -566,11 +572,17 @@ void ttm_pool_init(struct ttm_pool *pool,
struct device *dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- if (use_dma_alloc || nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_init(&pool->caching[i].orders[j],
- pool, i, j);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ /* Initialize only pool types which are actually used */
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_init(pt, pool, i, j);
+ }
}
}
EXPORT_SYMBOL(ttm_pool_init);
@@ -599,10 +611,16 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_fini(pt);
+ }
}
/* We removed the pool types from the LRU, but we need to
also make sure
[PATCH 6.6 091/122] drm/ast: Fix soft lockup
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.
These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.
DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.
Signed-off-by: Jammy Huang
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory
Display-Port")
Reviewed-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Cc: KuoHsiang Chou
Cc: Thomas Zimmermann
Cc: Dave Airlie
Cc: Jocelyn Falempe
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_dp.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -180,6 +180,7 @@ void ast_dp_set_on_off(struct drm_device
{
struct ast_device *ast = to_ast_device(dev);
u8 video_on_off = on;
+ u32 i = 0;
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE3, (u8)
~AST_DP_VIDEO_ENABLE, on);
@@ -192,6 +193,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) !=
video_on_off) {
// wait 1 ms
mdelay(1);
+ if (++i > 200)
+ break;
}
}
}
[PATCH 6.6 088/122] drm/vmwgfx: Enable DMA mappings with SEV
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.
Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.
Signed-off-by: Zack Rusin
Reported-by: Ye Li
Tested-by: Ye Li
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is
active")
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.6+
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -666,11 +666,12 @@ static int vmw_dma_select_mode(struct vm
[vmw_dma_map_populate] = "Caching DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
- /* TTM currently doesn't fully support SEV encryption. */
- if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
- return -EINVAL;
-
- if (vmw_force_coherent)
+ /*
+* When running with SEV we always want dma mappings, because
+* otherwise ttm tt pool pages will bounce through swiotlb running
+* out of available space.
+*/
+ if (vmw_force_coherent || cc_platform_has(CC_ATTR_MEM_ENCRYPT))
dev_priv->map_mode = vmw_dma_alloc_coherent;
else if (vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;
Re: [PATCH] doc: dma-buf: fix grammar typo
Am 14.04.24 um 15:07 schrieb Baruch Siach: Signed-off-by: Baruch Siach --- Documentation/driver-api/dma-buf.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 0c153d79ccc4..29abf1eebf9f 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -77,7 +77,7 @@ consider though: the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other llseek operation will report -EINVAL. - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all Looks valid of hand, but checkpatch.pl complains about 2 errors (missing commit message for example) and a warning. Please fix and resend. Thanks, Christian. cases. Userspace can use this to detect support for discovering the dma-buf size using llseek.
Re: [PATCH] drm/ttm: stop pooling cached NUMA pages v2
On 2024-04-15 10:08, Christian König wrote:
Am 15.04.24 um 15:53 schrieb Felix Kuehling:
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory pressure it can happen that
pages from the wrong NUMA node enters the pool and are re-used
over and over again.
This can lead to performance reduction after running into memory
pressure.
v2: restructure and cleanup the code a bit from the internal hack to
test this.
Signed-off-by: Christian König
Fixes: 4482d3c94d7f ("drm/ttm: add NUMA node id to the pool")
CC: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_pool.c | 38
+-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
b/drivers/gpu/drm/ttm/ttm_pool.c
index 112438d965ff..6e1fd6985ffc 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -288,17 +288,23 @@ static struct ttm_pool_type
*ttm_pool_select_type(struct ttm_pool *pool,
enum ttm_caching caching,
unsigned int order)
{
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
+ if (pool->use_dma_alloc)
return &pool->caching[caching].orders[order];
#ifdef CONFIG_X86
switch (caching) {
case ttm_write_combined:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
Doesn't this break USWC allocations on NUMA systems, where we set a
NUMA node for the default pool (at least we were planning to at some
point)?
I don't think so, but I might have missed something. Why do you think
that would break?
I mean the idea is basically if the pool is associated with a NUMA id
we should rather use this pool instead of the global one.
And that is true for both cases, the default pool and the specialized
ones.
OK, I think I misunderstood what I was reading. It looked to me like it
would always use a "caching" pool if nid was set. But caching here is a
variable; each node still has specialized pools for write combining etc.
Then the concern you stated in the commit message "under memory pressure
it can happen that pages from the wrong NUMA node enters the pool and
are re-used over and over again" is still possible for uncached and wc
pages. Anyway, it's better than not having NUMA, I guess.
The patch is
Reviewed-by: Felix Kuehling
Regards,
Christian.
Regards,
Felix
+
if (pool->use_dma32)
return &global_dma32_write_combined[order];
return &global_write_combined[order];
case ttm_uncached:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
+
if (pool->use_dma32)
return &global_dma32_uncached[order];
@@ -566,11 +572,17 @@ void ttm_pool_init(struct ttm_pool *pool,
struct device *dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- if (use_dma_alloc || nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_init(&pool->caching[i].orders[j],
- pool, i, j);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ /* Initialize only pool types which are actually used */
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_init(pt, pool, i, j);
+ }
}
}
EXPORT_SYMBOL(ttm_pool_init);
@@ -599,10 +611,16 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_fini(pt);
+ }
}
/* We removed the pool types from the LRU, but we need to
also make sure
Re: [PATCH 1/3] drm: drm_blend.c: Add precision in drm_rotation_simplify kernel doc
On Tue, Apr 09, 2024 at 12:04:05PM +0200, Louis Chauvet wrote: > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index 6e74de833466..8d4b317eb9d7 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -321,6 +321,11 @@ EXPORT_SYMBOL(drm_plane_create_rotation_property); > * transforms the hardware supports, this function may not > * be able to produce a supported transform, so the caller should > * check the result afterwards. > + * > + * If the rotation is not fully supported, this function will add a rotation > of 180 > + * (ROTATE_90 would become ROTATE_270) and add a reflection on X and Y. > + * The resulting transformation is the same (REFLECT_X | REFLECT_Y | > ROTATE_180 > + * is a no-op), but some unsupported flags are removed. > */ > unsigned int drm_rotation_simplify(unsigned int rotation, > unsigned int supported_rotations) > The wording LGTM, thanks! Reviewed-by: Bagas Sanjaya -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature
[PATCH 6.8 126/172] drm/ast: Fix soft lockup
6.8-stable review patch. If anyone has any objections, please let me know.
--
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.
These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.
DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.
Signed-off-by: Jammy Huang
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory
Display-Port")
Reviewed-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Cc: KuoHsiang Chou
Cc: Thomas Zimmermann
Cc: Dave Airlie
Cc: Jocelyn Falempe
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_dp.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -180,6 +180,7 @@ void ast_dp_set_on_off(struct drm_device
{
struct ast_device *ast = to_ast_device(dev);
u8 video_on_off = on;
+ u32 i = 0;
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xE3, (u8)
~AST_DP_VIDEO_ENABLE, on);
@@ -192,6 +193,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) !=
video_on_off) {
// wait 1 ms
mdelay(1);
+ if (++i > 200)
+ break;
}
}
}
[PATCH 6.8 123/172] drm/vmwgfx: Enable DMA mappings with SEV
6.8-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.
Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.
Signed-off-by: Zack Rusin
Reported-by: Ye Li
Tested-by: Ye Li
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is
active")
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.6+
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -666,11 +666,12 @@ static int vmw_dma_select_mode(struct vm
[vmw_dma_map_populate] = "Caching DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
- /* TTM currently doesn't fully support SEV encryption. */
- if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
- return -EINVAL;
-
- if (vmw_force_coherent)
+ /*
+* When running with SEV we always want dma mappings, because
+* otherwise ttm tt pool pages will bounce through swiotlb running
+* out of available space.
+*/
+ if (vmw_force_coherent || cc_platform_has(CC_ATTR_MEM_ENCRYPT))
dev_priv->map_mode = vmw_dma_alloc_coherent;
else if (vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;
Re: [PATCH 2/3] drm: drm_blend.c: Improve drm_plane_create_rotation_property kernel doc
On Tue, Apr 09, 2024 at 12:04:06PM +0200, Louis Chauvet wrote: > @@ -266,8 +257,41 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property); > * > * Rotation is the specified amount in degrees in counter clockwise > direction, > * the X and Y axis are within the source rectangle, i.e. the X/Y axis > before > - * rotation. After reflection, the rotation is applied to the image sampled > from > - * the source rectangle, before scaling it to fit the destination rectangle. > + * rotation. > + * > + * Here are some examples of rotation and reflections: > + * > + * |o +| REFLECT_X |+ o| > + * || > || > + * || || > + * > + * |o | REFLECT_Y |+ | > + * || > || > + * |+ | |o | > + * > + * |o +| ROTATE_90 |+ | > + * || > || > + * || |o | > + * > + * |o | ROTATE_180 | +| > + * || > || > + * |+ | | o| > + * > + * |o | ROTATE_270 |+ o| > + * || > || > + * |+ | || > + * > + * Rotation and reflection can be combined to handle more situations. In > this condition, the > + * reflection is applied first and the rotation in second. > + * > + * For example the expected result for DRM_MODE_ROTATE_90 | > DRM_MODE_REFLECT_X is: > + * > + * |o +| REFLECT_X |+ o| ROTATE_90 |o | > + * || > || > || > + * || || |+ | > + * > + * It is not possible to pass multiple rotation at the same time. (i.e > ROTATE_90 | ROTATE_180 is > + * not the same as ROTATE_270 and is not accepted). Sphinx reports htmldocs warnings on these transformation diagrams: Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:265: ERROR: Undefined substitution referenced: "o +". Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:265: ERROR: Undefined substitution referenced: "+ o". Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:273: ERROR: Undefined substitution referenced: "o +". Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:277: ERROR: Undefined substitution referenced: "o | ROTATE_180 | +". Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:277: ERROR: Undefined substitution referenced: "+ | | o". Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:281: ERROR: Undefined substitution referenced: "o | ROTATE_270 |+ o". Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:290: ERROR: Undefined substitution referenced: "o +". Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:290: ERROR: Undefined substitution referenced: "+ o". I have to wrap them in literal blocks: >8 diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index 6fbb8730d8b022..f2cbf8d8efbbbc 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -259,36 +259,36 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property); * the X and Y axis are within the source rectangle, i.e. the X/Y axis before * rotation. * - * Here are some examples of rotation and reflections: + * Here are some examples of rotation and reflections:: * - * |o +| REFLECT_X |+ o| - * || > || - * || || + * |o +| REFLECT_X |+ o| + * || > || + * || || * - * |o | REFLECT_Y |+ | - * || > || - * |+ | |o | + * |o | REFLECT_Y |+ | + * || > || + * |+ | |o | * - * |o +| ROTATE_90 |+ | - * || > || - * || |o | + * |o +| ROTATE_90 |+ | + * || > || + * || |o | * - * |o | ROTATE_180 | +| - * || > || - * |+ | | o| + * |o | ROTATE_180 | +| + * || > || + * |+ | | o| * - * |o | ROTATE_270 |+ o| - * || > || - * |+ | || + * |o | ROTATE_270 |+ o| + * || > || + * |+ | || * * Rotation and reflection can be combined to handle more situations. In this condition, the * reflection is applied first and the rotation in second. * - * For example the expected result for DRM_MODE_ROTATE_90 | DRM_MODE_REFLECT_X is: + * For example the expected result for DRM_MODE_ROTATE_90 | DRM_MODE_REFLECT_X is:: * - * |o +| REFLECT_X |+ o| ROTATE_90 |o | - * || > || > || - * || || |+ | + * |o +| REFLECT_X |+ o| ROTATE_90 |o | + * || > || > || + * || || |+ | * * It is not possible to pass multiple rotation at the same time. (i.e ROTATE_90 | ROTATE_180 is * not the same as ROTATE_270 and is not accepted). Thanks. -- An
Re: Re: [PATCH 1/2] drm/print: drop include debugfs.h and include where needed
On Mon, 15 Apr 2024 16:09:22 +0300, Jani Nikula wrote: > On Wed, 10 Apr 2024, Jani Nikula wrote: > > Surprisingly many places depend on debugfs.h to be included via > > drm_print.h. Fix them. > > While all of this is trivial, merely adding some includes, please > > [ ... ] Acked-by: Maxime Ripard Thanks! Maxime
Re: [PATCH 3/3] drm/fourcc: Add documentation around drm_format_info
On Tue, Apr 09, 2024 at 12:04:07PM +0200, Louis Chauvet wrote:
> /**
> * struct drm_format_info - information about a DRM format
> + *
> + * A drm_format_info describes how planes and pixels are stored in memory.
> + *
> + * Some format like YUV can have multiple planes, counted in @num_planes. It
> + * means that a full pixel can be stored in multiple non-continuous buffers.
> + * For example, NV12 is a YUV format using two planes: one for the Y values
> and
> + * one for the UV values.
> + *
> + * On each plane, the "pixel" unit can be different in case of subsampling.
> For
> + * example with the NV12 format, a pixel in the UV plane is used for four
> pixels
> + * in the Y plane.
> + * The fields @hsub and @vsub are the relation between the size of the main
> + * plane and the size of the subsampled planes in pixels:
> + * plane[0] width = hsub * plane[1] width
> + * plane[0] height = vsub * plane[1] height
> + *
> + * In some formats, pixels are not independent in memory. It can be a packed
> + * representation to store more pixels per byte (for example P030 uses 4
> bytes
> + * for three 10 bit pixels). It can also be used to represent tiled formats,
> + * where a continuous buffer in memory can represent a rectangle of pixels
> (for
> + * example, in DRM_FORMAT_Y0L0, a buffer of 8 bytes represents a 2x2 pixel
> + * region of the picture).
> + * The field @char_per_block is the size of a block on a specific plane, in
> + * bytes.
> + * The fields @block_w and @block_h are the size of a block in pixels.
> + *
> + * The older format representation (which only uses @cpp, kept for historical
> + * reasons because there are a lot of places in drivers where it's used) is
> + * assuming that a block is always 1x1 pixel.
> + *
> + * To keep the compatibility with older format representations and treat
> block
> + * and non-block formats in the same way one should use:
> + * - @char_per_block to access the size of a block on a specific plane, in
> + * bytes.
> + * - drm_format_info_block_width() to access the width of a block of a
> + * specific plane, in pixels.
> + * - drm_format_info_block_height() to access the height of a block of a
> + * specific plane, in pixels.
> */
> struct drm_format_info {
> /** @format: 4CC format identifier (DRM_FORMAT_*) */
> @@ -97,13 +135,6 @@ struct drm_format_info {
>* formats for which the memory needed for a single pixel is not
>* byte aligned.
>*
> - * @cpp has been kept for historical reasons because there are
> - * a lot of places in drivers where it's used. In drm core for
> - * generic code paths the preferred way is to use
> - * @char_per_block, drm_format_info_block_width() and
> - * drm_format_info_block_height() which allows handling both
> - * block and non-block formats in the same way.
> - *
>* For formats that are intended to be used only with non-linear
>* modifiers both @cpp and @char_per_block must be 0 in the
>* generic format table. Drivers could supply accurate
>
Sphinx reports htmldocs warnings:
Documentation/gpu/drm-kms:357: ./include/drm/drm_fourcc.h:74: ERROR: Unexpected
indentation.
Documentation/gpu/drm-kms:357: ./include/drm/drm_fourcc.h:83: ERROR: Unexpected
indentation.
Documentation/gpu/drm-kms:357: ./include/drm/drm_fourcc.h:93: ERROR: Unexpected
indentation.
Documentation/gpu/drm-kms:357: ./include/drm/drm_fourcc.h:94: WARNING: Bullet
list ends without a blank line; unexpected unindent.
I have to fix up the lists:
>8
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 66cc30e28f794a..10ee74fa46d21e 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -71,8 +71,9 @@ struct drm_mode_fb_cmd2;
* in the Y plane.
* The fields @hsub and @vsub are the relation between the size of the main
* plane and the size of the subsampled planes in pixels:
- * plane[0] width = hsub * plane[1] width
- * plane[0] height = vsub * plane[1] height
+ *
+ * - plane[0] width = hsub * plane[1] width
+ * - plane[0] height = vsub * plane[1] height
*
* In some formats, pixels are not independent in memory. It can be a packed
* representation to store more pixels per byte (for example P030 uses 4 bytes
@@ -80,9 +81,10 @@ struct drm_mode_fb_cmd2;
* where a continuous buffer in memory can represent a rectangle of pixels (for
* example, in DRM_FORMAT_Y0L0, a buffer of 8 bytes represents a 2x2 pixel
* region of the picture).
- * The field @char_per_block is the size of a block on a specific plane, in
- * bytes.
- * The fields @block_w and @block_h are the size of a block in pixels.
+ *
+ * - The field @char_per_block is the size of a block on a specific plane,
+ * in bytes.
+ * - The fields @block_w and @block_h are the size of a block in pi
Re: [PATCH] drm/ttm: stop pooling cached NUMA pages v2
Am 15.04.24 um 15:53 schrieb Felix Kuehling:
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory pressure it can happen that
pages from the wrong NUMA node enters the pool and are re-used
over and over again.
This can lead to performance reduction after running into memory
pressure.
v2: restructure and cleanup the code a bit from the internal hack to
test this.
Signed-off-by: Christian König
Fixes: 4482d3c94d7f ("drm/ttm: add NUMA node id to the pool")
CC: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_pool.c | 38 +-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
b/drivers/gpu/drm/ttm/ttm_pool.c
index 112438d965ff..6e1fd6985ffc 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -288,17 +288,23 @@ static struct ttm_pool_type
*ttm_pool_select_type(struct ttm_pool *pool,
enum ttm_caching caching,
unsigned int order)
{
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
+ if (pool->use_dma_alloc)
return &pool->caching[caching].orders[order];
#ifdef CONFIG_X86
switch (caching) {
case ttm_write_combined:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
Doesn't this break USWC allocations on NUMA systems, where we set a
NUMA node for the default pool (at least we were planning to at some
point)?
I don't think so, but I might have missed something. Why do you think
that would break?
I mean the idea is basically if the pool is associated with a NUMA id we
should rather use this pool instead of the global one.
And that is true for both cases, the default pool and the specialized ones.
Regards,
Christian.
Regards,
Felix
+
if (pool->use_dma32)
return &global_dma32_write_combined[order];
return &global_write_combined[order];
case ttm_uncached:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
+
if (pool->use_dma32)
return &global_dma32_uncached[order];
@@ -566,11 +572,17 @@ void ttm_pool_init(struct ttm_pool *pool,
struct device *dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- if (use_dma_alloc || nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_init(&pool->caching[i].orders[j],
- pool, i, j);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ /* Initialize only pool types which are actually used */
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_init(pt, pool, i, j);
+ }
}
}
EXPORT_SYMBOL(ttm_pool_init);
@@ -599,10 +611,16 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_fini(pt);
+ }
}
/* We removed the pool types from the LRU, but we need to
also make sure
2024 X.Org Foundation Election Results
The Board of Directors election concluded on 08 April 2024. There were 81 Members of the X.Org Foundation eligible to vote, and 61 Members cast votes. This is a 75.3% turn out. In the election of the Directors to the Board of the X.Org Foundation, the results were that Erik Faye-Lund, Simon Ser, Mark Filion and Neal Gompa were elected for two-year terms. The old full board is: * Emma Anholt * Mark Filion * Ricardo Garcia * Arkadiusz Hiler * Christopher Michael * Lyude Paul * Alyssa Rosenzweig * Sima Vetter The new full board is: * Erik Faye-Lund * Mark Filion * Neal Gompa * Arkadiusz Hiler * Christopher Michael * Lyude Paul * Simon Ser * Sima Vetter -Ricardo Garcia, on behalf of the X.Org elections committee
Re: [PATCH] drm/amdgpu: Add missing space to DRM_WARN() message
On Mon, Apr 15, 2024 at 4:40 AM Thorsten Blum wrote:
>
> s/,please/, please/
>
> Signed-off-by: Thorsten Blum
Reviewed-by: Alex Deucher
And applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 7753a2e64d41..3cba0e196ca8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1455,7 +1455,7 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
> *adev)
>
> /* PCI_EXT_CAP_ID_VNDR extended capability is located at 0x100 */
> if (!pci_find_ext_capability(adev->pdev, PCI_EXT_CAP_ID_VNDR))
> - DRM_WARN("System can't access extended configuration
> space,please check!!\n");
> + DRM_WARN("System can't access extended configuration space,
> please check!!\n");
>
> /* skip if the bios has already enabled large BAR */
> if (adev->gmc.real_vram_size &&
> --
> 2.39.2
>
Re: [PATCH] drm/ttm: stop pooling cached NUMA pages v2
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory pressure it can happen that
pages from the wrong NUMA node enters the pool and are re-used
over and over again.
This can lead to performance reduction after running into memory
pressure.
v2: restructure and cleanup the code a bit from the internal hack to
test this.
Signed-off-by: Christian König
Fixes: 4482d3c94d7f ("drm/ttm: add NUMA node id to the pool")
CC: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_pool.c | 38 +-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 112438d965ff..6e1fd6985ffc 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -288,17 +288,23 @@ static struct ttm_pool_type *ttm_pool_select_type(struct
ttm_pool *pool,
enum ttm_caching caching,
unsigned int order)
{
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
+ if (pool->use_dma_alloc)
return &pool->caching[caching].orders[order];
#ifdef CONFIG_X86
switch (caching) {
case ttm_write_combined:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
Doesn't this break USWC allocations on NUMA systems, where we set a NUMA
node for the default pool (at least we were planning to at some point)?
Regards,
Felix
+
if (pool->use_dma32)
return &global_dma32_write_combined[order];
return &global_write_combined[order];
case ttm_uncached:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
+
if (pool->use_dma32)
return &global_dma32_uncached[order];
@@ -566,11 +572,17 @@ void ttm_pool_init(struct ttm_pool *pool, struct device *dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- if (use_dma_alloc || nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_init(&pool->caching[i].orders[j],
- pool, i, j);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ /* Initialize only pool types which are actually used */
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_init(pt, pool, i, j);
+ }
}
}
EXPORT_SYMBOL(ttm_pool_init);
@@ -599,10 +611,16 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_fini(pt);
+ }
}
/* We removed the pool types from the LRU, but we need to also make sure
[PATCH] drm/ttm: stop pooling cached NUMA pages v2
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory pressure it can happen that
pages from the wrong NUMA node enters the pool and are re-used
over and over again.
This can lead to performance reduction after running into memory
pressure.
v2: restructure and cleanup the code a bit from the internal hack to
test this.
Signed-off-by: Christian König
Fixes: 4482d3c94d7f ("drm/ttm: add NUMA node id to the pool")
CC: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_pool.c | 38 +-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 112438d965ff..6e1fd6985ffc 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -288,17 +288,23 @@ static struct ttm_pool_type *ttm_pool_select_type(struct
ttm_pool *pool,
enum ttm_caching caching,
unsigned int order)
{
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE)
+ if (pool->use_dma_alloc)
return &pool->caching[caching].orders[order];
#ifdef CONFIG_X86
switch (caching) {
case ttm_write_combined:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
+
if (pool->use_dma32)
return &global_dma32_write_combined[order];
return &global_write_combined[order];
case ttm_uncached:
+ if (pool->nid != NUMA_NO_NODE)
+ return &pool->caching[caching].orders[order];
+
if (pool->use_dma32)
return &global_dma32_uncached[order];
@@ -566,11 +572,17 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
*dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- if (use_dma_alloc || nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_init(&pool->caching[i].orders[j],
- pool, i, j);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ /* Initialize only pool types which are actually used */
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_init(pt, pool, i, j);
+ }
}
}
EXPORT_SYMBOL(ttm_pool_init);
@@ -599,10 +611,16 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- if (pool->use_dma_alloc || pool->nid != NUMA_NO_NODE) {
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < NR_PAGE_ORDERS; ++j)
- ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i) {
+ for (j = 0; j < NR_PAGE_ORDERS; ++j) {
+ struct ttm_pool_type *pt;
+
+ pt = ttm_pool_select_type(pool, i, j);
+ if (pt != &pool->caching[i].orders[j])
+ continue;
+
+ ttm_pool_type_fini(pt);
+ }
}
/* We removed the pool types from the LRU, but we need to also make sure
--
2.34.1
Re: [PATCH v2 0/7] drm: debug logging improvements
On Mon, 08 Apr 2024, Jani Nikula wrote: > v2 of [1], dropping drm_mode_print() stuff altogether, and switching to > DRM_MODE_FMT/DRM_MODE_ARG() in a separate patch. Also add a few more drm > device based logging conversion patches, so the last patch makes more sense. Thanks for the reviews, pushed the lot to drm-misc-next. BR, Jani. > > BR, > Jani. > > [1] https://patchwork.freedesktop.org/series/130881/ > > Jani Nikula (7): > drm/probe-helper: switch to drm device based logging > drm/modes: switch to drm device based error logging > drm/sysfs: switch to drm device based logging > drm/client: switch to drm device based logging, and more > drm/crtc: switch to drm device based logging > drm/crtc-helper: switch to drm device based logging and warns > drm: prefer DRM_MODE_FMT/ARG over drm_mode_debug_printmodeline() > > drivers/gpu/drm/drm_atomic_uapi.c| 6 +- > drivers/gpu/drm/drm_client_modeset.c | 129 +++ > drivers/gpu/drm/drm_crtc.c | 38 > drivers/gpu/drm/drm_crtc_helper.c| 100 +++-- > drivers/gpu/drm/drm_modes.c | 40 - > drivers/gpu/drm/drm_probe_helper.c | 39 > drivers/gpu/drm/drm_sysfs.c | 20 ++--- > 7 files changed, 193 insertions(+), 179 deletions(-) -- Jani Nikula, Intel
Re: [PATCH 00/10] drm: move Intel drm headers to a subdirectory
On Wed, 10 Apr 2024, Jani Nikula wrote:
> We've accumulated enough Intel specific header files under include/drm
> that they warrant a subdirectory of their own. Clean up the top drm
> header directory by moving the Intel files under include/drm/intel.
>
> Since i915 is most impacted, I suggest merging the lot via
> drm-intel-next. Please ack if this is fine for you.
While all of this is trivial, merely changing some includes, please
consider acking the changes to your corner of the kernel.
Thanks,
Jani.
>
> BR,
> Jani.
>
>
> Cc: Bjorn Helgaas
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Hans de Goede
> Cc: Ilpo Järvinen
> Cc: Jaroslav Kysela
> Cc: Lucas De Marchi
> Cc: Takashi Iwai
> Cc: Tomas Winkler
>
> Jani Nikula (10):
> drm/i915: use system include for drm headers
> drm: move intel-gtt.h under include/drm/intel
> drm: move i915_gsc_proxy_mei_interface.h under include/drm/intel
> drm: move i915_component.h under include/drm/intel
> drm: move intel_lpe_audio.h under include/drm/intel
> drm: move i915_drm.h under include/drm/intel
> drm: move i915_pxp_tee_interface.h under include/drm/intel
> drm: move i915_pciids.h under include/drm/intel
> drm: move xe_pciids.h under include/drm/intel
> drm: move i915_hdcp_interface.h under include/drm/intel
>
> arch/x86/kernel/early-quirks.c | 4 ++--
> drivers/char/agp/intel-agp.c | 2 +-
> drivers/char/agp/intel-gtt.c | 2 +-
> drivers/gpu/drm/i915/display/intel_audio.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display_device.c| 2 +-
> drivers/gpu/drm/i915/display/intel_display_types.h | 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_lpe_audio.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_rps.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 4 ++--
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 ++--
> drivers/gpu/drm/i915/soc/intel_gmch.c | 2 +-
> drivers/gpu/drm/xe/display/xe_hdcp_gsc.c | 2 +-
> drivers/gpu/drm/xe/xe_ggtt.c | 2 +-
> drivers/gpu/drm/xe/xe_gsc_proxy.c | 4 ++--
> drivers/gpu/drm/xe/xe_pci.c| 2 +-
> drivers/misc/mei/gsc_proxy/mei_gsc_proxy.c | 4 ++--
> drivers/misc/mei/hdcp/mei_hdcp.c | 4 ++--
> drivers/misc/mei/pxp/mei_pxp.c | 4 ++--
> drivers/platform/x86/intel_ips.c | 2 +-
> include/drm/{ => intel}/i915_component.h | 2 +-
> include/drm/{ => intel}/i915_drm.h | 0
> include/drm/{ => intel}/i915_gsc_proxy_mei_interface.h | 0
> include/drm/{ => intel}/i915_hdcp_interface.h | 0
> include/drm/{ => intel}/i915_pciids.h | 0
> include/drm/{ => intel}/i915_pxp_tee_interface.h | 0
> include/drm/{ => intel}/intel-gtt.h| 0
> include/drm/{ => intel}/intel_lpe_audio.h | 0
> include/drm/{ => intel}/xe_pciids.h| 0
> include/sound/hdaudio.h| 2 +-
> sound/x86/intel_hdmi_audio.c | 2 +-
> 40 files changed, 40 insertions(+), 40 deletions(-)
> rename include/drm/{ => intel}/i915_component.h (98%)
> rename include/drm/{ => intel}/i915_drm.h (100%)
> rename include/drm/{ => intel}/i915_gsc_proxy_mei_interface.h (100%)
> rename include/drm/{ => intel}/i915_hdcp_interface.h (100%)
> rename include/drm/{ => intel}/i915_pciids.h (100%)
> rename include/drm/{ => intel}/i915_pxp_tee_interface.h (100%)
> rename include/drm/{ => intel}/intel-gtt.h (100%)
> rename include/drm/{ => intel}/intel_lpe_audio.h (100%)
> rename include/drm/{ => intel}/xe_pciids.h (100%)
--
Jani Nikula, Intel
Re: [PATCH 1/2] drm/print: drop include debugfs.h and include where needed
On Wed, 10 Apr 2024, Jani Nikula wrote: > Surprisingly many places depend on debugfs.h to be included via > drm_print.h. Fix them. While all of this is trivial, merely adding some includes, please consider acking the changes to your corner of the kernel. Thanks, Jani. > > Signed-off-by: Jani Nikula > > --- > > Cc: Andrzej Hajda > Cc: Neil Armstrong > Cc: Robert Foss > Cc: Laurent Pinchart > Cc: Jonas Karlman > Cc: Jernej Skrabec > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Jani Nikula > Cc: Karol Herbst > Cc: Lyude Paul > Cc: Danilo Krummrich > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: Huang Rui > Cc: dri-devel@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > --- > drivers/gpu/drm/bridge/panel.c | 2 ++ > drivers/gpu/drm/drm_print.c | 6 +++--- > drivers/gpu/drm/i915/display/intel_dmc.c | 1 + > drivers/gpu/drm/nouveau/dispnv50/crc.c | 2 ++ > drivers/gpu/drm/radeon/r100.c| 1 + > drivers/gpu/drm/radeon/r300.c| 1 + > drivers/gpu/drm/radeon/r420.c| 1 + > drivers/gpu/drm/radeon/r600.c| 3 ++- > drivers/gpu/drm/radeon/radeon_fence.c| 1 + > drivers/gpu/drm/radeon/radeon_gem.c | 1 + > drivers/gpu/drm/radeon/radeon_ib.c | 2 ++ > drivers/gpu/drm/radeon/radeon_pm.c | 1 + > drivers/gpu/drm/radeon/radeon_ring.c | 2 ++ > drivers/gpu/drm/radeon/radeon_ttm.c | 1 + > drivers/gpu/drm/radeon/rs400.c | 1 + > drivers/gpu/drm/radeon/rv515.c | 1 + > drivers/gpu/drm/ttm/ttm_device.c | 1 + > drivers/gpu/drm/ttm/ttm_resource.c | 3 ++- > drivers/gpu/drm/ttm/ttm_tt.c | 5 +++-- > include/drm/drm_print.h | 2 +- > 20 files changed, 30 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c > index 7f41525f7a6e..32506524d9a2 100644 > --- a/drivers/gpu/drm/bridge/panel.c > +++ b/drivers/gpu/drm/bridge/panel.c > @@ -4,6 +4,8 @@ > * Copyright (C) 2017 Broadcom > */ > > +#include > + > #include > #include > #include > diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c > index 699b7dbffd7b..cf2efb44722c 100644 > --- a/drivers/gpu/drm/drm_print.c > +++ b/drivers/gpu/drm/drm_print.c > @@ -23,13 +23,13 @@ > * Rob Clark > */ > > -#include > - > +#include > +#include > #include > #include > #include > #include > -#include > +#include > > #include > #include > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c > b/drivers/gpu/drm/i915/display/intel_dmc.c > index e61e9c1b8947..84748add186a 100644 > --- a/drivers/gpu/drm/i915/display/intel_dmc.c > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c > @@ -22,6 +22,7 @@ > * > */ > > +#include > #include > > #include "i915_drv.h" > diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c > b/drivers/gpu/drm/nouveau/dispnv50/crc.c > index 9c942fbd836d..5936b6b3b15d 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/crc.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c > @@ -1,5 +1,7 @@ > // SPDX-License-Identifier: MIT > +#include > #include > + > #include > #include > #include > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c > index 86b8b770af19..0b1e19345f43 100644 > --- a/drivers/gpu/drm/radeon/r100.c > +++ b/drivers/gpu/drm/radeon/r100.c > @@ -26,6 +26,7 @@ > * Jerome Glisse > */ > > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c > index 25201b9a5aae..1620f534f55f 100644 > --- a/drivers/gpu/drm/radeon/r300.c > +++ b/drivers/gpu/drm/radeon/r300.c > @@ -26,6 +26,7 @@ > * Jerome Glisse > */ > > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c > index eae8a6389f5e..a979662eaa73 100644 > --- a/drivers/gpu/drm/radeon/r420.c > +++ b/drivers/gpu/drm/radeon/r420.c > @@ -26,6 +26,7 @@ > * Jerome Glisse > */ > > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c > index b5e97d95a19f..087d41e370fd 100644 > --- a/drivers/gpu/drm/radeon/r600.c > +++ b/drivers/gpu/drm/radeon/r600.c > @@ -26,11 +26,12 @@ > * Jerome Glisse > */ > > +#include > #include > #include > #include > -#include > #include > +#include > > #include > #include > diff --git a/drivers/gpu/drm/radeon/radeon_fence.c > b/drivers/gpu/drm/radeon/radeon_fence.c > index 9ebe4a0b9a6c..4fb780d96f32 100644 > --- a/drivers/gpu/drm/radeon/radeon_fence.c > +++ b/drivers/gpu/drm/radeon/radeon_fence.c > @@ -30,6 +30,7 @@ > */ > > #include > +#include > #include > #include > #in
Re: [PATCH 00/18] backlight: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:35:58PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Dependencies > > All further patches depend on the first patch. Therefore everything > could go via backlight tree (please ack) or via cross-tree pulls. Or > whatever maintainer choose, just coordinate this with backlight. Thanks for the tidy up. I've added my Reviewed-by: to all the backlight patches (for Lee) and I'm happy with the other patches too... but I didn't want my R-b on the HID and fbdev patches to be confused for an ack. Daniel. > --- > Krzysztof Kozlowski (18): > backlight: Constify lcd_ops > backlight: ams369fg06: Constify lcd_ops > backlight: corgi_lcd: Constify lcd_ops > backlight: hx8357: Constify lcd_ops > backlight: ili922x: Constify lcd_ops > backlight: ili9320: Constify lcd_ops > backlight: jornada720_lcd: Constify lcd_ops > backlight: l4f00242t03: Constify lcd_ops > backlight: lms283gf05: Constify lcd_ops > backlight: lms501kf03: Constify lcd_ops > backlight: ltv350qv: Constify lcd_ops > backlight: otm3225a: Constify lcd_ops > backlight: platform_lcd: Constify lcd_ops > backlight: tdo24m: Constify lcd_ops > HID: picoLCD: Constify lcd_ops > fbdev: clps711x: Constify lcd_ops > fbdev: imx: Constify lcd_ops > fbdev: omap: lcd_ams_delta: Constify lcd_ops > > drivers/hid/hid-picolcd_lcd.c| 2 +- > drivers/video/backlight/ams369fg06.c | 2 +- > drivers/video/backlight/corgi_lcd.c | 2 +- > drivers/video/backlight/hx8357.c | 2 +- > drivers/video/backlight/ili922x.c| 2 +- > drivers/video/backlight/ili9320.c| 2 +- > drivers/video/backlight/jornada720_lcd.c | 2 +- > drivers/video/backlight/l4f00242t03.c| 2 +- > drivers/video/backlight/lcd.c| 4 ++-- > drivers/video/backlight/lms283gf05.c | 2 +- > drivers/video/backlight/lms501kf03.c | 2 +- > drivers/video/backlight/ltv350qv.c | 2 +- > drivers/video/backlight/otm3225a.c | 2 +- > drivers/video/backlight/platform_lcd.c | 2 +- > drivers/video/backlight/tdo24m.c | 2 +- > drivers/video/fbdev/clps711x-fb.c| 2 +- > drivers/video/fbdev/imxfb.c | 2 +- > drivers/video/fbdev/omap/lcd_ams_delta.c | 2 +- > include/linux/lcd.h | 6 +++--- > 19 files changed, 22 insertions(+), 22 deletions(-) > --- > base-commit: 9ed46da14b9b9b2ad4edb3b0c545b6dbe5c00d39 > change-id: 20240414-video-backlight-lcd-ops-276d8439ffb8 > > Best regards, > -- > Krzysztof Kozlowski >
Re: [PATCH 14/18] backlight: tdo24m: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:12PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 13/18] backlight: platform_lcd: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:11PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 12/18] backlight: otm3225a: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:10PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH v2 3/4] drm/i915/bios: switch to struct drm_edid and struct drm_edid_product_id
On Tue, 09 Apr 2024, Ville Syrjälä wrote:
> On Tue, Apr 09, 2024 at 12:46:11PM +0300, Jani Nikula wrote:
>> To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch
>> to the struct drm_edid based function to extract product id, and use the
>> drm printer function to debug log it.
>>
>> The underlying assumption is that struct drm_edid_product_id and struct
>> lvds_pnp_id describe identical data, albeit with slightly different
>> member definitions.
>>
>> Cc: Ville Syrjälä
>> Acked-by: Melissa Wen
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_bios.c | 43 ++-
>> 1 file changed, 18 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index 2abd2d7ceda2..3d89e4b39fed 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -600,6 +600,9 @@ get_lvds_pnp_id(const struct bdb_lvds_lfp_data *data,
>> const struct bdb_lvds_lfp_data_ptrs *ptrs,
>> int index)
>> {
>> +/* These two are supposed to have the same layout in memory. */
>> +BUILD_BUG_ON(sizeof(struct lvds_pnp_id) != sizeof(struct
>> drm_edid_product_id));
>> +
>> return (const void *)data + ptrs->ptr[index].panel_pnp_id.offset;
>> }
>>
>> @@ -613,19 +616,6 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
>> return NULL;
>> }
>>
>> -static void dump_pnp_id(struct drm_i915_private *i915,
>> -const struct lvds_pnp_id *pnp_id,
>> -const char *name)
>> -{
>> -u16 mfg_name = be16_to_cpu((__force __be16)pnp_id->mfg_name);
>> -char vend[4];
>> -
>> -drm_dbg_kms(&i915->drm, "%s PNPID mfg: %s (0x%x), prod: %u, serial: %u,
>> week: %d, year: %d\n",
>> -name, drm_edid_decode_mfg_id(mfg_name, vend),
>> -pnp_id->mfg_name, pnp_id->product_code, pnp_id->serial,
>> -pnp_id->mfg_week, pnp_id->mfg_year + 1990);
>> -}
>> -
>> static int opregion_get_panel_type(struct drm_i915_private *i915,
>> const struct intel_bios_encoder_data
>> *devdata,
>> const struct drm_edid *drm_edid, bool
>> use_fallback)
>> @@ -664,21 +654,21 @@ static int pnpid_get_panel_type(struct
>> drm_i915_private *i915,
>> {
>> const struct bdb_lvds_lfp_data *data;
>> const struct bdb_lvds_lfp_data_ptrs *ptrs;
>> -const struct lvds_pnp_id *edid_id;
>> -struct lvds_pnp_id edid_id_nodate;
>> -const struct edid *edid = drm_edid_raw(drm_edid); /* FIXME */
>> +struct drm_edid_product_id product_id, product_id_nodate;
>> +struct drm_printer p;
>> int i, best = -1;
>>
>> -if (!edid)
>> +if (!drm_edid)
>> return -1;
>>
>> -edid_id = (const void *)&edid->mfg_id[0];
>> +drm_edid_get_product_id(drm_edid, &product_id);
>
> I don't really like s/edid_id/product_id/ rename.
> The variable names were trying to convey the source of
> the data (EDID vs. VBT).
>
> But not a huge deal wither way. Series is
> Reviewed-by: Ville Syrjälä
Thanks, pushed the lot to drm-misc-next.
BR,
Jani.
--
Jani Nikula, Intel
Re: [PATCH 11/18] backlight: ltv350qv: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:09PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 10/18] backlight: lms501kf03: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:08PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 09/18] backlight: lms283gf05: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:07PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 08/18] backlight: l4f00242t03: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:06PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 07/18] backlight: jornada720_lcd: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:05PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH] drm/sysfs: Add drm class-wide attribute to get active device clients
On 05/04/2024 18:59, Rob Clark wrote:
On Wed, Apr 3, 2024 at 11:37 AM Adrián Larumbe
wrote:
Up to this day, all fdinfo-based GPU profilers must traverse the entire
/proc directory structure to find open DRM clients with fdinfo file
descriptors. This is inefficient and time-consuming.
This patch adds a new device class attribute that will install a sysfs file
per DRM device, which can be queried by profilers to get a list of PIDs for
their open clients. This file isn't human-readable, and it's meant to be
queried only by GPU profilers like gputop and nvtop.
Cc: Boris Brezillon
Cc: Tvrtko Ursulin
Cc: Christopher Healy
Signed-off-by: Adrián Larumbe
It does seem like a good idea.. idk if there is some precedent to
prefer binary vs ascii in sysfs, but having a way to avoid walking
_all_ processes is a good idea.
I naturally second that it is a needed feature, but I do not think
binary format is justified. AFAIR it should be used for things like
hw/fw standardised tables or firmware images, not when exporting a
simple list of PIDs. It also precludes easy shell/script access and the
benefit of avoiding parsing a short list is I suspect completely dwarfed
by needing to parse all the related fdinfo etc.
---
drivers/gpu/drm/drm_internal.h | 2 +-
drivers/gpu/drm/drm_privacy_screen.c | 2 +-
drivers/gpu/drm/drm_sysfs.c | 89 ++--
3 files changed, 74 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 2215baef9a3e..9a399b03d11c 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -145,7 +145,7 @@ bool drm_master_internal_acquire(struct drm_device *dev);
void drm_master_internal_release(struct drm_device *dev);
/* drm_sysfs.c */
-extern struct class *drm_class;
+extern struct class drm_class;
int drm_sysfs_init(void);
void drm_sysfs_destroy(void);
diff --git a/drivers/gpu/drm/drm_privacy_screen.c
b/drivers/gpu/drm/drm_privacy_screen.c
index 6cc39e30781f..2fbd24ba5818 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -401,7 +401,7 @@ struct drm_privacy_screen *drm_privacy_screen_register(
mutex_init(&priv->lock);
BLOCKING_INIT_NOTIFIER_HEAD(&priv->notifier_head);
- priv->dev.class = drm_class;
+ priv->dev.class = &drm_class;
priv->dev.type = &drm_privacy_screen_type;
priv->dev.parent = parent;
priv->dev.release = drm_privacy_screen_device_release;
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index a953f69a34b6..56ca9e22c720 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -58,8 +58,6 @@ static struct device_type drm_sysfs_device_connector = {
.name = "drm_connector",
};
-struct class *drm_class;
-
#ifdef CONFIG_ACPI
static bool drm_connector_acpi_bus_match(struct device *dev)
{
@@ -128,6 +126,62 @@ static const struct component_ops typec_connector_ops = {
static CLASS_ATTR_STRING(version, S_IRUGO, "drm 1.1.0 20060810");
+static ssize_t clients_show(struct device *cd, struct device_attribute *attr,
char *buf)
+{
+ struct drm_minor *minor = cd->driver_data;
+ struct drm_device *ddev = minor->dev;
+ struct drm_file *priv;
+ ssize_t offset = 0;
+ void *pid_buf;
+
+ if (minor->type != DRM_MINOR_RENDER)
+ return 0;
Why this?
+
+ pid_buf = kvmalloc(PAGE_SIZE, GFP_KERNEL);
I don't quite get the kvmalloc for just one page (or why even a temporay
buffer and not write into buf directly?).
+ if (!pid_buf)
+ return 0;
+
+ mutex_lock(&ddev->filelist_mutex);
+ list_for_each_entry_reverse(priv, &ddev->filelist, lhead) {
+ struct pid *pid;
+
+ if (drm_WARN_ON(ddev, (PAGE_SIZE - offset) < sizeof(pid_t)))
+ break;
Feels bad.. I would suggest exploring implementing a read callback
(instead of show) and handling arbitrary size output.
+
+ rcu_read_lock();
+ pid = rcu_dereference(priv->pid);
+ (*(pid_t *)(pid_buf + offset)) = pid_vnr(pid);
+ rcu_read_unlock();
+
+ offset += sizeof(pid_t);
+ }
+ mutex_unlock(&ddev->filelist_mutex);
+
+ if (offset < PAGE_SIZE)
+ (*(pid_t *)(pid_buf + offset)) = 0;
Either NULL terminated or PAGE_SIZE/sizeof(pid) entries and not NULL
terminated feels weird. If I got that right.
For me everything points towards going for text output.
+
+ memcpy(buf, pid_buf, offset);
+
+ kvfree(pid_buf);
+
+ return offset;
+
+}
+static DEVICE_ATTR_RO(clients);
Shouldn't BIN_ATTR_RO be used for binary files in sysfs?
Regards,
Tvrtko
P.S. Or maybe it is time for drmfs? Where each client gets a directory
and drivers can populate files. Such as per client logging streams and
whatnot.
+
+static str
Re: [PATCH 06/18] backlight: ili9320: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:04PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 05/18] backlight: ili922x: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:03PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Re: [PATCH 04/18] backlight: hx8357: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:02PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Patch "drm/ast: Fix soft lockup" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix soft lockup
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-soft-lockup.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From bc004f5038220b1891ef4107134ccae44be55109 Mon Sep 17 00:00:00 2001
From: Jammy Huang
Date: Wed, 3 Apr 2024 17:02:46 +0800
Subject: drm/ast: Fix soft lockup
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.
These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.
DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.
Signed-off-by: Jammy Huang
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory
Display-Port")
Reviewed-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Cc: KuoHsiang Chou
Cc: Thomas Zimmermann
Cc: Dave Airlie
Cc: Jocelyn Falempe
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_dp.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -190,6 +190,7 @@ void ast_dp_set_on_off(struct drm_device
{
struct ast_private *ast = to_ast_private(dev);
u8 video_on_off = on;
+ u32 i = 0;
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE3, (u8)
~AST_DP_VIDEO_ENABLE, on);
@@ -202,6 +203,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) !=
video_on_off) {
// wait 1 ms
mdelay(1);
+ if (++i > 200)
+ break;
}
}
}
Patches currently in stable-queue which might be from
jammy_hu...@aspeedtech.com are
queue-6.1/drm-ast-fix-soft-lockup.patch
Re: [PATCH 03/18] backlight: corgi_lcd: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:01PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
Patch "drm/vmwgfx: Enable DMA mappings with SEV" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm/vmwgfx: Enable DMA mappings with SEV
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-vmwgfx-enable-dma-mappings-with-sev.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd Mon Sep 17 00:00:00 2001
From: Zack Rusin
Date: Sun, 7 Apr 2024 22:28:02 -0400
Subject: drm/vmwgfx: Enable DMA mappings with SEV
From: Zack Rusin
commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.
Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.
Signed-off-by: Zack Rusin
Reported-by: Ye Li
Tested-by: Ye Li
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is
active")
Cc: Broadcom internal kernel review list
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.6+
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -666,11 +666,12 @@ static int vmw_dma_select_mode(struct vm
[vmw_dma_map_populate] = "Caching DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
- /* TTM currently doesn't fully support SEV encryption. */
- if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
- return -EINVAL;
-
- if (vmw_force_coherent)
+ /*
+* When running with SEV we always want dma mappings, because
+* otherwise ttm tt pool pages will bounce through swiotlb running
+* out of available space.
+*/
+ if (vmw_force_coherent || cc_platform_has(CC_ATTR_MEM_ENCRYPT))
dev_priv->map_mode = vmw_dma_alloc_coherent;
else if (vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;
Patches currently in stable-queue which might be from zack.ru...@broadcom.com
are
queue-6.6/drm-vmwgfx-enable-dma-mappings-with-sev.patch
Patch "drm/ast: Fix soft lockup" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm/ast: Fix soft lockup
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-ast-fix-soft-lockup.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From bc004f5038220b1891ef4107134ccae44be55109 Mon Sep 17 00:00:00 2001
From: Jammy Huang
Date: Wed, 3 Apr 2024 17:02:46 +0800
Subject: drm/ast: Fix soft lockup
From: Jammy Huang
commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.
These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.
DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.
Signed-off-by: Jammy Huang
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory
Display-Port")
Reviewed-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Cc: KuoHsiang Chou
Cc: Thomas Zimmermann
Cc: Dave Airlie
Cc: Jocelyn Falempe
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.19+
Link:
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ast/ast_dp.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -180,6 +180,7 @@ void ast_dp_set_on_off(struct drm_device
{
struct ast_device *ast = to_ast_device(dev);
u8 video_on_off = on;
+ u32 i = 0;
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE3, (u8)
~AST_DP_VIDEO_ENABLE, on);
@@ -192,6 +193,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) !=
video_on_off) {
// wait 1 ms
mdelay(1);
+ if (++i > 200)
+ break;
}
}
}
Patches currently in stable-queue which might be from
jammy_hu...@aspeedtech.com are
queue-6.6/drm-ast-fix-soft-lockup.patch
Re: [PATCH 02/18] backlight: ams369fg06: Constify lcd_ops
On Sun, Apr 14, 2024 at 06:36:00PM +0200, Krzysztof Kozlowski wrote: > 'struct lcd_ops' is not modified by core backlight code, so it can be > made const for increased code safety. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Daniel Thompson Daniel.
