Re: [PATCH 1/2] drm/sched: Rename priority MIN to LOW
Am 24.11.23 um 06:27 schrieb Luben Tuikov:
Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW.
This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler priorities
in ascending order,
DRM_SCHED_PRIORITY_LOW,
DRM_SCHED_PRIORITY_NORMAL,
DRM_SCHED_PRIORITY_HIGH,
DRM_SCHED_PRIORITY_KERNEL.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 10 +-
include/drm/gpu_scheduler.h | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index e2ae9ba147ba97..5cb33ac99f7089 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -73,10 +73,10 @@ amdgpu_ctx_to_drm_sched_prio(int32_t ctx_prio)
return DRM_SCHED_PRIORITY_NORMAL;
case AMDGPU_CTX_PRIORITY_VERY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_NORMAL:
return DRM_SCHED_PRIORITY_NORMAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 62bb7fc7448ad9..1a25931607c514 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 4252e3839fbc83..eb0c97433e5f8a 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_MIN)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 20c9c561843ce1..cb7445be3cbb4e 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -88,7 +88,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
-(s32) DRM_SCHED_PRIORITY_MIN);
+(s32) DRM_SCHED_PRIORITY_LOW);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 044a8c4875ba64..b6d7bc49ff6ef4 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1052,7 +1052,7 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
int i;
/* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
drm_sched_rq_select_entity_rr(sched,
sched->sched_rq[i]);
@@ -1291,7 +1291,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
if (!sched->sched_rq)
goto Out_free;
sched->num_rqs = num_rqs;
- for (i = DRM_SCHED_PRIORITY_MIN; i < sched->num_rqs; i++) {
+ for (i = DRM_SCHED_PRIORITY_LOW; i < sched->num_rqs; i++) {
sched->sched_rq[i] = kzalloc(sizeof(*sched->sched_rq[i]),
RE: [Intel-gfx] [PATCH] drm/i915/irq: Improve error logging for unexpected DE Misc interrupts
> -Original Message- > From: Intel-gfx On Behalf Of Rahul > Rameshbabu > Sent: Thursday, November 23, 2023 11:27 PM > To: intel-...@lists.freedesktop.org > Cc: Nikula, Jani ; dri-devel@lists.freedesktop.org; > Rahul Rameshbabu > Subject: [Intel-gfx] [PATCH] drm/i915/irq: Improve error logging for > unexpected DE Misc interrupts > > Dump the iir value in hex when the interrupt is unexpected. > > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9652#note_2178501 > Cc: Jani Nikula > Signed-off-by: Rahul Rameshbabu > --- > drivers/gpu/drm/i915/display/intel_display_irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c > b/drivers/gpu/drm/i915/display/intel_display_irq.c > index bff4a76310c0..1a5a9e0fc01e 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_irq.c > +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c > @@ -896,7 +896,7 @@ gen8_de_misc_irq_handler(struct drm_i915_private > *dev_priv, u32 iir) > } > > if (!found) > - drm_err(_priv->drm, "Unexpected DE Misc > interrupt\n"); > + drm_err(_priv->drm, "Unexpected DE Misc interrupt: > %#x\n", iir); Nit: It could use a format specifier like "0x%08x" (like other instances in the file) to maintain uniform width. Other than that. LGTM. Reviewed-by: Chaitanya Kumar Borah > } > > static void gen11_dsi_te_interrupt_handler(struct drm_i915_private > *dev_priv, > -- > 2.40.1 >
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi, On 2023/11/24 15:38, Maxime Ripard wrote: On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote: On 2023/11/23 16:08, Dmitry Baryshkov wrote: I'm agree with the idea that drm bridges drivers involved toward to a direction that support more complex design, but I think we should also leave a way for the most frequent use case. Make it straight-forward as a canonical design. Not having anything connector-related in the drm_bridge driver is a canonical design. What you said is just for the more complex uses case. I can't agree, sorry. By choosing the word "canonical design", I means that the most frequently used cases in practice are the canonical design, 95+% motherboards I have seen has only one *onboard* display bridges chip. For my driver, I abstract the internal (inside of the chip) encoder as drm_encoder and abstract the external TX chip as drm_bridge, this design still works very well. Originally, I means that this is a concept of the hardware design. You are wrong even through in the software design context, the transparent simple drm bridge drivers(simple-bridge.c) also *allow* to create drm connector manually. I don't think I need to emulate more example, please read the code by youself. 'emulate' -> 'enumerate' Ok. That's it. We've been patient long enough. You have been given a review and a list of things to fix for your driver to be merged. This series is not relevant to my driver, can we please *limit* the discussion to this series? Whether you follow them or not is your decision. I'm not saying that I will not follow, just to make sure what's solution is you want. I need discussion to figure out. We won't tolerate insulting comments though. There is *no* insulting, please don't misunderstanding before *sufficient* communication, OK? Originally, I thought Dmitry may ignore(or overlook) what is the current status. Maxime
Re: [PATCH v2 0/4] eventfd: simplify signal helpers
On Wed, 22 Nov 2023 13:48:21 +0100, Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> significantly. They can be made void and not take any unnecessary
> arguments.
>
> I've added a few more simplifications based on Sean's suggestion.
>
> [...]
Applied to the vfs.misc branch of the vfs/vfs.git tree.
Patches in the vfs.misc branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.misc
[1/4] i915: make inject_virtual_interrupt() void
https://git.kernel.org/vfs/vfs/c/858848719210
[2/4] eventfd: simplify eventfd_signal()
https://git.kernel.org/vfs/vfs/c/ded0f31f825f
[3/4] eventfd: simplify eventfd_signal_mask()
https://git.kernel.org/vfs/vfs/c/45ee1c990e88
[4/4] eventfd: make eventfd_signal{_mask}() void
https://git.kernel.org/vfs/vfs/c/37d5d473e749
Re: [PATCH v5 9/9] drm: ci: Update xfails
Hi Daniel, On 19/10/23 13:55, Daniel Stone wrote: By the time we get this error, it indicates that there was previously memory corruption, but it is only being noticed at a later point. The skip lists here are way too big - stuff like drm_read is common testing not affected by virtio at all - so we really need to isolate the test which is actually breaking things. The way to do this would be to use valgrind to detect where the memory corruption is. VirtIO can be run locally so this is something you can do on your machine. Thank you for the hints and suggestions. This is now fixed in igt-gpu-tools, and the patches are merged. I will uprev igt in drm-ci and rerun the tests. Also will drop the tests from virtio_gpu-none-skips.txt and send an updated version. Regards, Vignesh
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote: > On 2023/11/23 16:08, Dmitry Baryshkov wrote: > > > I'm agree with the idea that drm bridges drivers involved toward to a > > > direction > > > that support more complex design, but I think we should also leave a way > > > for the > > > most frequent use case. Make it straight-forward as a canonical design. > > Not having anything connector-related in the drm_bridge driver is a > > canonical design. > > What you said is just for the more complex uses case. I can't agree, sorry. > > By choosing the word "canonical design", I means that the most frequently used > cases in practice are the canonical design, 95+% motherboards I have seen has > only one *onboard* display bridges chip. For my driver, I abstract the > internal > (inside of the chip) encoder as drm_encoder and abstract the external TX chip > as > drm_bridge, this design still works very well. > > > Originally, I means that this is a concept of the hardware design. > You are wrong even through in the software design context, the > transparent simple drm bridge drivers(simple-bridge.c) also *allow* > to create drm connector manually. I don't think I need to emulate > more example, please read the code by youself. Ok. That's it. We've been patient long enough. You have been given a review and a list of things to fix for your driver to be merged. Whether you follow them or not is your decision. We won't tolerate insulting comments though. Maxime signature.asc Description: PGP signature
Re: [PATCH v5 08/20] drivers/gpu/drm/loongson/lsdc_i2c.c: remove I2C_CLASS_DDC support
Hi, On 2023/11/23 17:40, Heiner Kallweit wrote: After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can remove this class completely now. Preferably this series should be applied via the i2c tree. Acked-by: Thomas Zimmermann Signed-off-by: Heiner Kallweit Reviewed-by: Sui Jingfeng Thanks.
[PATCH RESEND 0/3] Update STM DSI PHY driver
This patch series aims to add several features of the dw-mipi-dsi phy driver that are missing or need to be updated. First patch adds runtime PM functionality to the driver. Second patch adds a clock provider generated by the PHY itself. As explained in the commit log of the second patch, a clock declaration is missing. Since this clock is parent of 'dsi_k', it leads to an orphan clock. Most importantly this patch is an anticipation for future versions of the DSI PHY, and its inclusion within the display subsystem and the DRM framework. Last patch fixes a corner effect introduced previously. Since 'dsi' and 'dsi_k' are gated by the same bit on the same register, both reference work as peripheral clock in the device-tree. Raphael Gallais-Pou (2): drm/stm: dsi: expose DSI PHY internal clock arm: dts: st: fix DSI peripheral clock on stm32mp15 boards Yannick Fertre (1): drm/stm: dsi: add pm runtime ops arch/arm/boot/dts/st/stm32mp157.dtsi | 2 +- arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 2 +- arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 2 +- arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 2 +- arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 2 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 274 +++--- 6 files changed, 240 insertions(+), 44 deletions(-) -- 2.25.1
[PATCH RESEND 2/3] drm/stm: dsi: expose DSI PHY internal clock
DSISRC __
__\_
|\
pll4_p_ck ->| 1 |dsi_k
ck_dsi_phy ->| 0 |
|/
A DSI clock is missing in the clock framework. Looking at the
clk_summary, it appears that 'ck_dsi_phy' is not implemented. Since the
DSI kernel clock is based on the internal DSI pll. The common clock
driver can not directly expose this 'ck_dsi_phy' clock because it does
not contain any common registers with the DSI. Thus it needs to be done
directly within the DSI phy driver.
Signed-off-by: Raphael Gallais-Pou
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 246 ++
1 file changed, 215 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index a0ca4d7f3b8a..1a4a88ecffe0 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -7,7 +7,9 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
@@ -77,9 +79,12 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
+ struct device *dev;
struct clk *pllref_clk;
struct clk *pclk;
+ struct clk_hw txbyte_clk;
struct dw_mipi_dsi *dsi;
+ struct dw_mipi_dsi_plat_data pdata;
u32 hw_version;
int lane_min_kbps;
int lane_max_kbps;
@@ -196,29 +201,198 @@ static int dsi_pll_get_params(struct dw_mipi_dsi_stm
*dsi,
return 0;
}
-static int dw_mipi_dsi_phy_init(void *priv_data)
+#define clk_to_dw_mipi_dsi_stm(clk) \
+ container_of(clk, struct dw_mipi_dsi_stm, txbyte_clk)
+
+static void dw_mipi_dsi_clk_disable(struct clk_hw *clk)
{
- struct dw_mipi_dsi_stm *dsi = priv_data;
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(clk);
+
+ DRM_DEBUG_DRIVER("\n");
+
+ /* Disable the DSI PLL */
+ dsi_clear(dsi, DSI_WRPCR, WRPCR_PLLEN);
+
+ /* Disable the regulator */
+ dsi_clear(dsi, DSI_WRPCR, WRPCR_REGEN | WRPCR_BGREN);
+}
+
+static int dw_mipi_dsi_clk_enable(struct clk_hw *clk)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(clk);
u32 val;
int ret;
+ DRM_DEBUG_DRIVER("\n");
+
/* Enable the regulator */
dsi_set(dsi, DSI_WRPCR, WRPCR_REGEN | WRPCR_BGREN);
- ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
-SLEEP_US, TIMEOUT_US);
+ ret = readl_poll_timeout_atomic(dsi->base + DSI_WISR, val, val &
WISR_RRS,
+ SLEEP_US, TIMEOUT_US);
if (ret)
DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
/* Enable the DSI PLL & wait for its lock */
dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
- ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
-SLEEP_US, TIMEOUT_US);
+ ret = readl_poll_timeout_atomic(dsi->base + DSI_WISR, val, val &
WISR_PLLLS,
+ SLEEP_US, TIMEOUT_US);
if (ret)
DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
return 0;
}
+static int dw_mipi_dsi_clk_is_enabled(struct clk_hw *hw)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+
+ return dsi_read(dsi, DSI_WRPCR) & WRPCR_PLLEN;
+}
+
+static unsigned long dw_mipi_dsi_clk_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+ unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+ u32 val;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ pll_in_khz = (unsigned int)(parent_rate / 1000);
+
+ val = dsi_read(dsi, DSI_WRPCR);
+
+ idf = (val & WRPCR_IDF) >> 11;
+ if (!idf)
+ idf = 1;
+ ndiv = (val & WRPCR_NDIV) >> 2;
+ odf = int_pow(2, (val & WRPCR_ODF) >> 16);
+
+ /* Get the adjusted pll out value */
+ pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
+
+ return (unsigned long)pll_out_khz * 1000;
+}
+
+static long dw_mipi_dsi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+ unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+ int ret;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ pll_in_khz = (unsigned int)(*parent_rate / 1000);
+
+ /* Compute best pll parameters */
+ idf = 0;
+ ndiv = 0;
+ odf = 0;
+
+ ret = dsi_pll_get_params(dsi, pll_in_khz, rate / 1000,
+, , );
+ if (ret)
+ DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
+
+ /* Get the adjusted pll out value */
+ pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf,
[PATCH RESEND 3/3] arm: dts: st: fix DSI peripheral clock on stm32mp15 boards
In RCC driver, 'DSI_K' is a kernel clock while 'DSI' has pclk4 as parent
clock, which means that it is an APB peripheral clock. Swap the clocks
in the DSI peripheral clock reference.
Signed-off-by: Raphael Gallais-Pou
---
arch/arm/boot/dts/st/stm32mp157.dtsi | 2 +-
arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts | 2 +-
arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts | 2 +-
arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts | 2 +-
arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/st/stm32mp157.dtsi
b/arch/arm/boot/dts/st/stm32mp157.dtsi
index 6197d878894d..97cd24227cef 100644
--- a/arch/arm/boot/dts/st/stm32mp157.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp157.dtsi
@@ -20,7 +20,7 @@ gpu: gpu@5900 {
dsi: dsi@5a00 {
compatible = "st,stm32-dsi";
reg = <0x5a00 0x800>;
- clocks = < DSI_K>, <_hse>, < DSI_PX>;
+ clocks = < DSI>, <_hse>, < DSI_PX>;
clock-names = "pclk", "ref", "px_clk";
phy-dsi-supply = <>;
resets = < DSI_R>;
diff --git a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
index afcd6285890c..8634699cc65e 100644
--- a/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157a-dk1-scmi.dts
@@ -30,7 +30,7 @@ {
};
{
- clocks = < DSI_K>, <_clk CK_SCMI_HSE>, < DSI_PX>;
+ clocks = < DSI>, <_clk CK_SCMI_HSE>, < DSI_PX>;
};
{
diff --git a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
index 39358d902000..3a897fa7e167 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-dk2-scmi.dts
@@ -36,7 +36,7 @@ {
{
phy-dsi-supply = <_reg18>;
- clocks = < DSI_K>, <_clk CK_SCMI_HSE>, < DSI_PX>;
+ clocks = < DSI>, <_clk CK_SCMI_HSE>, < DSI_PX>;
};
{
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
index 07ea765a4553..29d6465b1fe6 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ed1-scmi.dts
@@ -35,7 +35,7 @@ {
};
{
- clocks = < DSI_K>, <_clk CK_SCMI_HSE>, < DSI_PX>;
+ clocks = < DSI>, <_clk CK_SCMI_HSE>, < DSI_PX>;
};
{
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
index 813086ec2489..5acb78f0a084 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ev1-scmi.dts
@@ -37,7 +37,7 @@ {
{
phy-dsi-supply = <_reg18>;
- clocks = < DSI_K>, <_clk CK_SCMI_HSE>, < DSI_PX>;
+ clocks = < DSI>, <_clk CK_SCMI_HSE>, < DSI_PX>;
};
{
--
2.25.1
[PATCH RESEND 1/3] drm/stm: dsi: add pm runtime ops
From: Yannick Fertre
Update control of clocks and supply thanks to the PM runtime
mechanism to avoid kernel crash during a system suspend.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 28 +++
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index d5f8c923d7bc..a0ca4d7f3b8a 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -77,6 +78,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
struct clk *pllref_clk;
+ struct clk *pclk;
struct dw_mipi_dsi *dsi;
u32 hw_version;
int lane_min_kbps;
@@ -443,7 +445,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
{
struct device *dev = >dev;
struct dw_mipi_dsi_stm *dsi;
- struct clk *pclk;
int ret;
dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
@@ -483,21 +484,21 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
goto err_clk_get;
}
- pclk = devm_clk_get(dev, "pclk");
- if (IS_ERR(pclk)) {
- ret = PTR_ERR(pclk);
+ dsi->pclk = devm_clk_get(dev, "pclk");
+ if (IS_ERR(dsi->pclk)) {
+ ret = PTR_ERR(dsi->pclk);
DRM_ERROR("Unable to get peripheral clock: %d\n", ret);
goto err_dsi_probe;
}
- ret = clk_prepare_enable(pclk);
+ ret = clk_prepare_enable(dsi->pclk);
if (ret) {
DRM_ERROR("%s: Failed to enable peripheral clk\n", __func__);
goto err_dsi_probe;
}
dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
- clk_disable_unprepare(pclk);
+ clk_disable_unprepare(dsi->pclk);
if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
ret = -ENODEV;
@@ -551,6 +552,7 @@ static int __maybe_unused dw_mipi_dsi_stm_suspend(struct
device *dev)
DRM_DEBUG_DRIVER("\n");
clk_disable_unprepare(dsi->pllref_clk);
+ clk_disable_unprepare(dsi->pclk);
regulator_disable(dsi->vdd_supply);
return 0;
@@ -569,8 +571,16 @@ static int __maybe_unused dw_mipi_dsi_stm_resume(struct
device *dev)
return ret;
}
+ ret = clk_prepare_enable(dsi->pclk);
+ if (ret) {
+ regulator_disable(dsi->vdd_supply);
+ DRM_ERROR("Failed to enable pclk: %d\n", ret);
+ return ret;
+ }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
+ clk_disable_unprepare(dsi->pclk);
regulator_disable(dsi->vdd_supply);
DRM_ERROR("Failed to enable pllref_clk: %d\n", ret);
return ret;
@@ -580,8 +590,10 @@ static int __maybe_unused dw_mipi_dsi_stm_resume(struct
device *dev)
}
static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
- dw_mipi_dsi_stm_resume)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(dw_mipi_dsi_stm_suspend,
+ dw_mipi_dsi_stm_resume, NULL)
};
static struct platform_driver dw_mipi_dsi_stm_driver = {
--
2.25.1
Re: [PATCH 1/3] Revert "drm/prime: Unexport helpers for fd/handle conversion"
Am 23.11.23 um 20:36 schrieb Felix Kuehling:
[+Alex]
On 2023-11-17 16:44, Felix Kuehling wrote:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated
with
GEM objects while ensuring that move notifier callbacks are working as
intended.
CC: Christian König
CC: Thomas Zimmermann
Signed-off-by: Felix Kuehling
Re: our discussion about v2 of this patch: If this version is
acceptable, can I get an R-b or A-b?
From my side feel free to add my Acked-by, I don't see how else you
want to cleanly export DMA-bufs.
Regards,
Christian.
I would like to get this patch into drm-next as a prerequisite for
patches 2 and 3. I cannot submit it to the current
amd-staging-drm-next because the patch I'm reverting doesn't exist
there yet.
Patch 2 and 3 could go into drm-next as well, or go through Alex's
amd-staging-drm-next branch once patch 1 is in drm-next. Alex, how do
you prefer to coordinate this?
Regards,
Felix
---
drivers/gpu/drm/drm_prime.c | 33 ++---
include/drm/drm_prime.h | 7 +++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 63b709a67471..834a5e28abbe 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -278,7 +278,7 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
}
EXPORT_SYMBOL(drm_gem_dmabuf_release);
-/*
+/**
* drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
* @dev: drm_device to import into
* @file_priv: drm file-private structure
@@ -292,9 +292,9 @@ EXPORT_SYMBOL(drm_gem_dmabuf_release);
*
* Returns 0 on success or a negative error code on failure.
*/
-static int drm_gem_prime_fd_to_handle(struct drm_device *dev,
- struct drm_file *file_priv, int prime_fd,
- uint32_t *handle)
+int drm_gem_prime_fd_to_handle(struct drm_device *dev,
+ struct drm_file *file_priv, int prime_fd,
+ uint32_t *handle)
{
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
@@ -360,6 +360,7 @@ static int drm_gem_prime_fd_to_handle(struct
drm_device *dev,
dma_buf_put(dma_buf);
return ret;
}
+EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -408,7 +409,7 @@ static struct dma_buf
*export_and_register_object(struct drm_device *dev,
return dmabuf;
}
-/*
+/**
* drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
* @dev: dev to export the buffer from
* @file_priv: drm file-private structure
@@ -421,10 +422,10 @@ static struct dma_buf
*export_and_register_object(struct drm_device *dev,
* The actual exporting from GEM object to a dma-buf is done
through the
* _gem_object_funcs.export callback.
*/
-static int drm_gem_prime_handle_to_fd(struct drm_device *dev,
- struct drm_file *file_priv, uint32_t handle,
- uint32_t flags,
- int *prime_fd)
+int drm_gem_prime_handle_to_fd(struct drm_device *dev,
+ struct drm_file *file_priv, uint32_t handle,
+ uint32_t flags,
+ int *prime_fd)
{
struct drm_gem_object *obj;
int ret = 0;
@@ -506,6 +507,7 @@ static int drm_gem_prime_handle_to_fd(struct
drm_device *dev,
return ret;
}
+EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -864,9 +866,9 @@ EXPORT_SYMBOL(drm_prime_get_contiguous_size);
* @obj: GEM object to export
* @flags: flags like DRM_CLOEXEC and DRM_RDWR
*
- * This is the implementation of the _gem_object_funcs.export
functions
- * for GEM drivers using the PRIME helpers. It is used as the
default for
- * drivers that do not set their own.
+ * This is the implementation of the _gem_object_funcs.export
functions for GEM drivers
+ * using the PRIME helpers. It is used as the default in
+ * drm_gem_prime_handle_to_fd().
*/
struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
int flags)
@@ -962,9 +964,10 @@ EXPORT_SYMBOL(drm_gem_prime_import_dev);
* @dev: drm_device to import into
* @dma_buf: dma-buf object to import
*
- * This is the implementation of the gem_prime_import functions for GEM
- * drivers using the PRIME helpers. It is the default for drivers
that do
- * not set their own _driver.gem_prime_import.
+ * This is the implementation of the gem_prime_import functions for
GEM drivers
+ * using the PRIME helpers. Drivers can use this as their
+ * _driver.gem_prime_import implementation. It is used as the
default
+ * implementation in
Re: [PATCH v3 08/11] drm/mediatek: Support alpha blending in VDOSYS1
[PATCH 1/2] drm/sched: Rename priority MIN to LOW
Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW.
This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler priorities
in ascending order,
DRM_SCHED_PRIORITY_LOW,
DRM_SCHED_PRIORITY_NORMAL,
DRM_SCHED_PRIORITY_HIGH,
DRM_SCHED_PRIORITY_KERNEL.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 10 +-
include/drm/gpu_scheduler.h | 2 +-
6 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index e2ae9ba147ba97..5cb33ac99f7089 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -73,10 +73,10 @@ amdgpu_ctx_to_drm_sched_prio(int32_t ctx_prio)
return DRM_SCHED_PRIORITY_NORMAL;
case AMDGPU_CTX_PRIORITY_VERY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_LOW:
- return DRM_SCHED_PRIORITY_MIN;
+ return DRM_SCHED_PRIORITY_LOW;
case AMDGPU_CTX_PRIORITY_NORMAL:
return DRM_SCHED_PRIORITY_NORMAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 62bb7fc7448ad9..1a25931607c514 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 4252e3839fbc83..eb0c97433e5f8a 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_MIN)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 20c9c561843ce1..cb7445be3cbb4e 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -88,7 +88,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
-(s32) DRM_SCHED_PRIORITY_MIN);
+(s32) DRM_SCHED_PRIORITY_LOW);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 044a8c4875ba64..b6d7bc49ff6ef4 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1052,7 +1052,7 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
int i;
/* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_MIN; i--) {
+ for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
drm_sched_rq_select_entity_rr(sched,
sched->sched_rq[i]);
@@ -1291,7 +1291,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
if (!sched->sched_rq)
goto Out_free;
sched->num_rqs = num_rqs;
- for (i = DRM_SCHED_PRIORITY_MIN; i < sched->num_rqs; i++) {
+ for (i = DRM_SCHED_PRIORITY_LOW; i < sched->num_rqs; i++) {
sched->sched_rq[i] = kzalloc(sizeof(*sched->sched_rq[i]),
GFP_KERNEL);
if (!sched->sched_rq[i])
goto
[PATCH 2/2] drm/sched: Reverse run-queue priority enumeration
Reverse run-queue priority enumeration such that the higest priority is now 0,
and for each consecutive integer the prioirty diminishes.
Run-queues correspond to priorities. To an external observer a scheduler
created with a single run-queue, and another created with
DRM_SCHED_PRIORITY_COUNT number of run-queues, should always schedule
sched->sched_rq[0] with the same "priority", as that index run-queue exists in
both schedulers, i.e. a scheduler with one run-queue or many. This patch makes
it so.
In other words, the "priority" of sched->sched_rq[n], n >= 0, is the same for
any scheduler created with any allowable number of run-queues (priorities), 0
to DRM_SCHED_PRIORITY_COUNT.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Danilo Krummrich
Cc: Alex Deucher
Cc: Christian König
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/msm/msm_gpu.h| 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 7 ---
drivers/gpu/drm/scheduler/sched_main.c | 15 +++
include/drm/gpu_scheduler.h | 6 +++---
5 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 1a25931607c514..71a5cf37b472d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -325,7 +325,7 @@ void amdgpu_job_stop_all_jobs_on_sched(struct
drm_gpu_scheduler *sched)
int i;
/* Signal all jobs not yet scheduled */
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
+ for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++) {
struct drm_sched_rq *rq = sched->sched_rq[i];
spin_lock(>lock);
list_for_each_entry(s_entity, >entities, list) {
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index eb0c97433e5f8a..2bfcb222e35338 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -347,7 +347,7 @@ struct msm_gpu_perfcntr {
* DRM_SCHED_PRIORITY_KERNEL priority level is treated specially in some
* cases, so we don't use it (no need for kernel generated jobs).
*/
-#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_HIGH -
DRM_SCHED_PRIORITY_LOW)
+#define NR_SCHED_PRIORITIES (1 + DRM_SCHED_PRIORITY_LOW -
DRM_SCHED_PRIORITY_HIGH)
/**
* struct msm_file_private - per-drm_file context
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index cb7445be3cbb4e..6e2b02e45e3a32 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -81,14 +81,15 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
*/
pr_warn("%s: called with uninitialized scheduler\n", __func__);
} else if (num_sched_list) {
- /* The "priority" of an entity cannot exceed the number
-* of run-queues of a scheduler.
+ /* The "priority" of an entity cannot exceed the number of
+* run-queues of a scheduler. Choose the lowest priority
+* available.
*/
if (entity->priority >= sched_list[0]->num_rqs) {
drm_err(sched_list[0], "entity with out-of-bounds
priority:%u num_rqs:%u\n",
entity->priority, sched_list[0]->num_rqs);
entity->priority = max_t(s32, (s32)
sched_list[0]->num_rqs - 1,
-(s32) DRM_SCHED_PRIORITY_LOW);
+(s32)
DRM_SCHED_PRIORITY_KERNEL);
}
entity->rq = sched_list[0]->sched_rq[entity->priority];
}
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index b6d7bc49ff6ef4..682aebe96db781 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -1051,8 +1051,9 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
struct drm_sched_entity *entity;
int i;
- /* Kernel run queue has higher priority than normal run queue*/
- for (i = sched->num_rqs - 1; i >= DRM_SCHED_PRIORITY_LOW; i--) {
+ /* Start with the highest priority.
+*/
+ for (i = DRM_SCHED_PRIORITY_KERNEL; i < sched->num_rqs; i++) {
entity = drm_sched_policy == DRM_SCHED_POLICY_FIFO ?
drm_sched_rq_select_entity_fifo(sched,
sched->sched_rq[i]) :
drm_sched_rq_select_entity_rr(sched,
sched->sched_rq[i]);
@@ -1291,7 +1292,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
if (!sched->sched_rq)
goto Out_free;
sched->num_rqs = num_rqs;
-
[PATCH 0/2] Make scheduling of the same index, the same
The first patch renames priority MIN to LOW. The second patch makes the "priority" of the same run-queue index in any two schedulers, the same. This series sits on top on this fix https://patchwork.freedesktop.org/patch/568723/ which I sent yesterday. Luben Tuikov (2): drm/sched: Rename priority MIN to LOW drm/sched: Reverse run-queue priority enumeration drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +- drivers/gpu/drm/msm/msm_gpu.h| 2 +- drivers/gpu/drm/scheduler/sched_entity.c | 7 --- drivers/gpu/drm/scheduler/sched_main.c | 15 +++ include/drm/gpu_scheduler.h | 6 +++--- 6 files changed, 18 insertions(+), 18 deletions(-) Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Danilo Krummrich Cc: Alex Deucher Cc: Christian König Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org base-commit: e4d983ac270ccee417445a69b9ed198658b1 prerequisite-patch-id: d0fec7c91768937b5e22ce9508017e5b9d462000 -- 2.43.0
Re: [PATCH v2] drm/mediatek: Add spinlock for setting vblank event in atomic_begin
On Wed, Nov 8, 2023 at 3:27 PM CK Hu (胡俊光) wrote:
>
> Hi, Jason:
>
> On Wed, 2023-09-20 at 17:06 +0800, Jason-JH.Lin wrote:
> > Add spinlock protection to avoid race condition on vblank event
> > between mtk_drm_crtc_atomic_begin() and mtk_drm_finish_page_flip().
>
> Reviewed-by: CK Hu
Please also merge this for fixes so it lands sooner.
> >
> > Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
> > MT8173.")
> > Signed-off-by: Jason-JH.Lin
> > Suggested-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delre...@collabora.com>
> > Reviewed-by: Alexandre Mergnat
> > Reviewed-by: Fei Shao
> > Tested-by: Fei Shao
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index b6fa4ad2f94d..cab4fe092f13 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -744,6 +744,7 @@ static void mtk_drm_crtc_atomic_begin(struct
> > drm_crtc *crtc,
> >
> > crtc);
> > struct mtk_crtc_state *mtk_crtc_state =
> > to_mtk_crtc_state(crtc_state);
> > struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > + unsigned long flags;
> >
> > if (mtk_crtc->event && mtk_crtc_state->base.event)
> > DRM_ERROR("new event while there is still a pending
> > event\n");
> > @@ -751,7 +752,11 @@ static void mtk_drm_crtc_atomic_begin(struct
> > drm_crtc *crtc,
> > if (mtk_crtc_state->base.event) {
> > mtk_crtc_state->base.event->pipe =
> > drm_crtc_index(crtc);
> > WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > +
> > + spin_lock_irqsave(>dev->event_lock, flags);
> > mtk_crtc->event = mtk_crtc_state->base.event;
> > + spin_unlock_irqrestore(>dev->event_lock, flags);
> > +
> > mtk_crtc_state->base.event = NULL;
> > }
> > }
Re: [PATCH 3/4] arm64: dts: mediatek: mt8195: add DSI and MIPI DPHY nodes
On Thu, Nov 23, 2023 at 9:38 PM Michael Walle wrote: > > Add the two DSI controller node and the associated DPHY nodes. > Individual boards have to enable them in the board device tree. > > Signed-off-by: Michael Walle Reviewed-by: Chen-Yu Tsai I checked all the address ranges and interrupt values and they are all correct. The other bits seem to be correct, extrapolating from previous chips such as MT8183 and MT8192.
Re: [PATCH v1 3/4] drm/rockchip: rk3066_hdmi: Remove useless output format
Hi Johan:
some information bellow hope can help a bit.
On 11/23/23 20:54, Johan Jonker wrote:
On 11/20/23 18:06, Heiko Stuebner wrote:
Hi Johan,
Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker:
The Rk3066 hdmi output format is hard coded to RGB. Remove
all useless code related to colorimetry and enc_out_format.
Signed-off-by: Johan Jonker
I guess my first question is, is the hardcoding happening just because
of missing functionality in the driver, or does the hardware only
support RGB?
This driver can do so much more..., but is crippled by various causes.
If in need for a full functional rk3066 driver a little bit help/advise/action
from other people is needed.
1:
Missing rk3066 TRM HDMI register info.
Could Rockchip (= Sandy Huang) disclose this info to the open source community?
The HDMI on rk3066 is from a IP vendor, so the detail of this IP are not even
include in the TRM.
As it is a chip which is more than 10 yeas old, I contacted the author of the
bsp
driver, got some information bellow:
This IP is almost the same with sh_mobile_hdmi, unfortunately, SH-Mobile HDMI
drivers
is removed out of mainline in 2015[0], but with a quick look at it, the
register definition
is the same as rk3066 hdmi and with more detail description.
[0]https://lkml.kernel.org/stable/20191122100825.930987...@linuxfoundation.org/
As a way around we can look at older driver code and port to mainline.
More info gives better results.
rk30_hdmi_config_csc() function:
https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L315
2:
Could DRM people show us examples for:
- How to advertise to the VOP driver what data formats (RGB, YCBCR) it can send
to the HDMI driver or any other Rockchip DRM sub driver other then RGB.
- Advertise EDID data monitor modes RGB444, YCBCR444 and YCBCR422 to the HDMI
driver.
https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/rk_hdmi_edid.c#L217C1-L218C41
RK3066 vop can only output RGB full range to HDMI, so the full to limit rgb to
yuv conversion is done by rk30_hdmi_config_csc.
3:
Advise when what Infoframe is needed for only RGB vs. the rest according to the
specification.
https://engineering.purdue.edu/ece477/Archive/2012/Spring/S12-Grp10/Datasheets/CEC_HDMI_Specification.pdf
rk3066 currently only sends avi info. Does it need vsi as well? Can anyone give
some clarity here?
inno_hdime sends avi and vsi info.
vsi is used for 3d and hdmi 1.4 format(4K24/25/30, not support by rk3066), or
vendor specific data like timecode, dolby,
so as a basic function, we don't need it.
4:
rk3066_hdmi and inno_hdmi are HDMI 1.4a drivers for DVI and HDMI.
Validated by drm_match_cea_mode() this function only gives us both HDMI + HDMI2
focus, but nothing for old DVI monitors.
How to improve?
5:
Sound support was submitted:
Re: [PATCH v6 2/5] drm: rockchip: add sound support to rk3066 hdmi driver
https://lore.kernel.org/linux-rockchip/48dbe9b7-0aa0-f459-301f-f380e2b7f...@gmail.com/
No reply was given (by Heiko or others) on why it wasn't applied or what needs
to be improved.
Without reply no improvement.
Johan
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 0e7aae341960..f2b1b2faa096 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -23,8 +23,6 @@
struct hdmi_data_info {
int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
- unsigned int enc_out_format;
- unsigned int colorimetry;
};
struct rk3066_hdmi_i2c {
@@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi,
rc = drm_hdmi_avi_infoframe_from_display_mode(,
>connector, mode);
- if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
- frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
- else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
- frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
- else
- frame.avi.colorspace = HDMI_COLORSPACE_RGB;
-
- frame.avi.colorimetry = hdmi->hdmi_data.colorimetry;
+ frame.avi.colorspace = HDMI_COLORSPACE_RGB;
frame.avi.scan_mode = HDMI_SCAN_MODE_NONE;
return rk3066_hdmi_upload_frame(hdmi, rc, ,
@@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
struct drm_display_info *display = >connector.display_info;
hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
- hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
-
- if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 ||
- hdmi->hdmi_data.vic == 21 ||
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
include/uapi/drm/pvr_drm.h:1: warning: 'Flags for
DRM_PVR_DEV_QUERY_HEAP_INFO_GET.' not found
Introduced by commit
1088d89e5515 ("drm/imagination/uapi: Add PowerVR driver UAPI")
--
Cheers,
Stephen Rothwell
pgpHIpIc35sRE.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
drivers/gpu/drm/imagination/pvr_drv.c:1: warning: 'PowerVR Graphics Driver' not
found
Introduced by commit
815d8b0425ad ("drm/imagination: Add driver documentation")
--
Cheers,
Stephen Rothwell
pgpaShaqaFamI.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
Documentation/gpu/imagination/uapi.rst:124: WARNING: Title underline too short.
CREATE_HWRT_DATASET and DESTROY_HWRT_DATASET
--
Introduced by commit
815d8b0425ad ("drm/imagination: Add driver documentation")
--
Cheers,
Stephen Rothwell
pgp5UWgUAY5pj.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 2/4] eventfd: simplify eventfd_signal()
On Wed, 2023-11-22 at 13:48 +0100, Christian Brauner wrote:
> Ever since the evenfd type was introduced back in 2007 in commit
> e1ad7468c77d ("signal/timer/event: eventfd core") the
> eventfd_signal()
> function only ever passed 1 as a value for @n. There's no point in
> keeping that additional argument.
>
> Signed-off-by: Christian Brauner
Acked-by: Andrew Donnellan # ocxl
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
[git pull] drm fixes for 6.7-rc3
Hi Linus, Back to regular scheduled fixes pull request, mainly a bunch of msm, some i915 and otherwise a few scattered, one memory crasher in the nouveau GSP paths is helping stabilise that work. Regards, Dave. drm-fixes-2023-11-24: drm fixes for 6.7-rc3 msm: - Fix the VREG_CTRL_1 for 4nm CPHY to match downstream - Remove duplicate call to drm_kms_helper_poll_init() in msm_drm_init() - Fix the safe_lut_tbl[] for sc8280xp to match downstream - Don't attach the drm_dp_set_subconnector_property() for eDP - Fix to attach drm_dp_set_subconnector_property() for DP. Otherwise there is a bootup crash on multiple targets - Remove unnecessary NULL check left behind during cleanup i915: - Fix race between DP MST connectore registration and setup - Fix GT memory leak on probe error path panel: - Fixes for innolux and auo,b101uan08.3 panel. - Fix Himax83102-j02 timings. ivpu: - Fix ivpu MMIO reset. ast: - AST fix on connetor disconnection. nouveau: - gsp memory corruption fix. rockchip: - color fix. The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-11-24 for you to fetch changes up to b3ca8a08d8ed0dc8a9e236d9294efd58554a7b05: Merge tag 'drm-intel-fixes-2023-11-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2023-11-24 11:18:29 +1000) drm fixes for 6.7-rc3 msm: - Fix the VREG_CTRL_1 for 4nm CPHY to match downstream - Remove duplicate call to drm_kms_helper_poll_init() in msm_drm_init() - Fix the safe_lut_tbl[] for sc8280xp to match downstream - Don't attach the drm_dp_set_subconnector_property() for eDP - Fix to attach drm_dp_set_subconnector_property() for DP. Otherwise there is a bootup crash on multiple targets - Remove unnecessary NULL check left behind during cleanup i915: - Fix race between DP MST connectore registration and setup - Fix GT memory leak on probe error path panel: - Fixes for innolux and auo,b101uan08.3 panel. - Fix Himax83102-j02 timings. ivpu: - Fix ivpu MMIO reset. ast: - AST fix on connetor disconnection. nouveau: - gsp memory corruption fix. rockchip: - color fix. Abel Vesa (1): drm/msm/dp: don't touch DP subconnector property in eDP case Andrzej Hajda (1): drm/i915: do not clean GT table on error path Bjorn Andersson (1): drm/msm/dpu: Add missing safe_lut_tbl in sc8280xp catalog Cong Yang (1): drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBP Dan Carpenter (1): drm/msm: remove unnecessary NULL check Dave Airlie (4): nouveau/gsp: allocate enough space for all channel ids. Merge tag 'drm-msm-fixes-2023-11-21' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Merge tag 'drm-misc-fixes-2023-11-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2023-11-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Dmitry Baryshkov (2): drm/msm: remove exra drm_kms_helper_poll_init() call drm/msm/dp: attach the DP subconnector property Imre Deak (1): drm/i915/dp_mst: Fix race between connector registration and setup Jacek Lawrynowicz (1): accel/ivpu/37xx: Fix hangs related to MMIO reset Jonas Karlman (1): drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full Jonathan Marek (1): drm/msm/dsi: use the correct VREG_CTRL_1 value for 4nm cphy Marek Vasut (2): drm/panel: simple: Fix Innolux G101ICE-L01 bus flags drm/panel: simple: Fix Innolux G101ICE-L01 timings Thomas Zimmermann (1): drm/ast: Disconnect BMC if physical connector is connected Xuxin Xiong (1): drm/panel: auo,b101uan08.3: Fine tune the panel power sequence drivers/accel/ivpu/ivpu_hw_37xx.c | 46 drivers/gpu/drm/ast/ast_drv.h | 13 - drivers/gpu/drm/ast/ast_mode.c | 62 +++--- drivers/gpu/drm/i915/display/intel_dp_mst.c| 16 +++--- drivers/gpu/drm/i915/gt/intel_gt.c | 11 drivers/gpu/drm/i915/i915_driver.c | 4 +- .../drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 3 +- drivers/gpu/drm/msm/dp/dp_display.c| 15 -- drivers/gpu/drm/msm/dp/dp_drm.c| 3 ++ drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 2 - drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c| 2 +- drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 9 ++-- drivers/gpu/drm/panel/panel-simple.c | 13 ++--- drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 14 +++-- 16 files changed, 138 insertions(+), 78
[PATCH v2 17/17] drm/v3d: Create a CPU job extension for the copy performance query job
A CPU job is a type of job that performs operations that requires CPU
intervention. A copy performance query job is a job that copy the complete
or partial result of a query to a buffer. In order to copy the result of
a performance query to a buffer, we need to get the values from the
performance monitors.
So, create a user extension for the CPU job that enables the creation
of a copy performance query job. This user extension will allow the creation
of a CPU job that copy the results of a performance query to a BO with the
possibility to indicate the availability with a availability bit.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h| 1 +
drivers/gpu/drm/v3d/v3d_sched.c | 66 ++
drivers/gpu/drm/v3d/v3d_submit.c | 81
include/uapi/drm/v3d_drm.h | 47 ++
4 files changed, 195 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 77854581d348..6254db0482f4 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -322,6 +322,7 @@ enum v3d_cpu_job_type {
V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY,
V3D_CPU_JOB_TYPE_COPY_TIMESTAMP_QUERY,
V3D_CPU_JOB_TYPE_RESET_PERFORMANCE_QUERY,
+ V3D_CPU_JOB_TYPE_COPY_PERFORMANCE_QUERY,
};
struct v3d_timestamp_query {
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 8ebb1f3567f6..f1a8a6dc5436 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -450,6 +450,71 @@ v3d_reset_performance_queries(struct v3d_cpu_job *job)
}
}
+static void
+v3d_write_performance_query_result(struct v3d_cpu_job *job, void *data, u32
query)
+{
+ struct v3d_performance_query_info *performance_query =
>performance_query;
+ struct v3d_copy_query_results_info *copy = >copy;
+ struct v3d_file_priv *v3d_priv = job->base.file->driver_priv;
+ struct v3d_dev *v3d = job->base.v3d;
+ struct v3d_perfmon *perfmon;
+ u64 counter_values[V3D_PERFCNT_NUM];
+
+ for (int i = 0; i < performance_query->nperfmons; i++) {
+ perfmon = v3d_perfmon_find(v3d_priv,
+
performance_query->queries[query].kperfmon_ids[i]);
+ if (!perfmon) {
+ DRM_DEBUG("Failed to find perfmon.");
+ continue;
+ }
+
+ v3d_perfmon_stop(v3d, perfmon, true);
+
+ memcpy(_values[i * DRM_V3D_MAX_PERF_COUNTERS],
perfmon->values,
+ perfmon->ncounters * sizeof(u64));
+
+ v3d_perfmon_put(perfmon);
+ }
+
+ for (int i = 0; i < performance_query->ncounters; i++)
+ write_to_buffer(data, i, copy->do_64bit, counter_values[i]);
+}
+
+
+static void
+v3d_copy_performance_query(struct v3d_cpu_job *job)
+{
+ struct v3d_performance_query_info *performance_query =
>performance_query;
+ struct v3d_copy_query_results_info *copy = >copy;
+ struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
+ struct dma_fence *fence;
+ bool available, write_result;
+ u8 *data;
+
+ v3d_get_bo_vaddr(bo);
+
+ data = ((u8 *) bo->vaddr) + copy->offset;
+
+ for (int i = 0; i < performance_query->count; i++) {
+ fence =
drm_syncobj_fence_get(performance_query->queries[i].syncobj);
+ available = fence ? dma_fence_is_signaled(fence) : false;
+
+ write_result = available || copy->do_partial;
+ if (write_result)
+ v3d_write_performance_query_result(job, data, i);
+
+ if (copy->availability_bit)
+ write_to_buffer(data, performance_query->ncounters,
+ copy->do_64bit, available ? 1u : 0u);
+
+ data += copy->stride;
+
+ dma_fence_put(fence);
+ }
+
+ v3d_put_bo_vaddr(bo);
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
@@ -464,6 +529,7 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
[V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY] =
v3d_reset_timestamp_queries,
[V3D_CPU_JOB_TYPE_COPY_TIMESTAMP_QUERY] =
v3d_copy_query_results,
[V3D_CPU_JOB_TYPE_RESET_PERFORMANCE_QUERY] =
v3d_reset_performance_queries,
+ [V3D_CPU_JOB_TYPE_COPY_PERFORMANCE_QUERY] =
v3d_copy_performance_query,
};
v3d->cpu_job = job;
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index b7d0e1ccea6b..3d60b85eb123 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -677,6 +677,84 @@ v3d_get_cpu_reset_performance_params(struct drm_file
*file_priv,
return 0;
}
+static int
+v3d_get_cpu_copy_performance_query_params(struct drm_file *file_priv,
+
[PATCH v2 15/17] drm/v3d: Create a CPU job extension to copy timestamp query to a buffer
A CPU job is a type of job that performs operations that requires CPU
intervention. A copy timestamp query job is a job that copy the complete
or partial result of a query to a buffer. As V3D doesn't provide any
mechanism to obtain a timestamp from the GPU, it is a job that needs
CPU intervention.
So, create a user extension for the CPU job that enables the creation
of a copy timestamp query job. This user extension will allow the creation
of a CPU job that copy the results of a timestamp query to a BO with the
possibility to indicate the timestamp availability with a availability bit.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h| 20 ++
drivers/gpu/drm/v3d/v3d_sched.c | 54 +
drivers/gpu/drm/v3d/v3d_submit.c | 68
include/uapi/drm/v3d_drm.h | 41 +++
4 files changed, 183 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index a1c8ff06f16b..4b7de76b504a 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -320,6 +320,7 @@ enum v3d_cpu_job_type {
V3D_CPU_JOB_TYPE_INDIRECT_CSD = 1,
V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY,
V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY,
+ V3D_CPU_JOB_TYPE_COPY_TIMESTAMP_QUERY,
};
struct v3d_timestamp_query {
@@ -361,6 +362,23 @@ struct v3d_timestamp_query_info {
u32 count;
};
+struct v3d_copy_query_results_info {
+ /* Define if should write to buffer using 64 or 32 bits */
+ bool do_64bit;
+
+ /* Define if it can write to buffer even if the query is not available
*/
+ bool do_partial;
+
+ /* Define if it should write availability bit to buffer */
+ bool availability_bit;
+
+ /* Offset of the copy buffer in the BO */
+ u32 offset;
+
+ /* Stride of the copy buffer in the BO */
+ u32 stride;
+};
+
struct v3d_cpu_job {
struct v3d_job base;
@@ -369,6 +387,8 @@ struct v3d_cpu_job {
struct v3d_indirect_csd_info indirect_csd;
struct v3d_timestamp_query_info timestamp_query;
+
+ struct v3d_copy_query_results_info copy;
};
struct v3d_submit_outsync {
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 57c9fc887c46..5068b499b7ab 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -362,6 +362,59 @@ v3d_reset_timestamp_queries(struct v3d_cpu_job *job)
v3d_put_bo_vaddr(bo);
}
+static void
+write_to_buffer(void *dst, u32 idx, bool do_64bit, u64 value)
+{
+ if (do_64bit) {
+ u64 *dst64 = (u64 *) dst;
+ dst64[idx] = value;
+ } else {
+ u32 *dst32 = (u32 *) dst;
+ dst32[idx] = (u32) value;
+ }
+}
+
+static void
+v3d_copy_query_results(struct v3d_cpu_job *job)
+{
+ struct v3d_timestamp_query_info *timestamp_query =
>timestamp_query;
+ struct v3d_timestamp_query *queries = timestamp_query->queries;
+ struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
+ struct v3d_bo *timestamp = to_v3d_bo(job->base.bo[1]);
+ struct v3d_copy_query_results_info *copy = >copy;
+ struct dma_fence *fence;
+ u8 *query_addr;
+ bool available, write_result;
+ u8 *data;
+ int i;
+
+ v3d_get_bo_vaddr(bo);
+ v3d_get_bo_vaddr(timestamp);
+
+ data = ((u8 *) bo->vaddr) + copy->offset;
+
+ for (i = 0; i < timestamp_query->count; i++) {
+ fence = drm_syncobj_fence_get(queries[i].syncobj);
+ available = fence ? dma_fence_is_signaled(fence) : false;
+
+ write_result = available || copy->do_partial;
+ if (write_result) {
+ query_addr = ((u8 *) timestamp->vaddr) +
queries[i].offset;
+ write_to_buffer(data, 0, copy->do_64bit, *((u64 *)
query_addr));
+ }
+
+ if (copy->availability_bit)
+ write_to_buffer(data, 1, copy->do_64bit, available ? 1u
: 0u);
+
+ data += copy->stride;
+
+ dma_fence_put(fence);
+ }
+
+ v3d_put_bo_vaddr(timestamp);
+ v3d_put_bo_vaddr(bo);
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
@@ -374,6 +427,7 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
[V3D_CPU_JOB_TYPE_INDIRECT_CSD] =
v3d_rewrite_csd_job_wg_counts_from_indirect,
[V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY] = v3d_timestamp_query,
[V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY] =
v3d_reset_timestamp_queries,
+ [V3D_CPU_JOB_TYPE_COPY_TIMESTAMP_QUERY] =
v3d_copy_query_results,
};
v3d->cpu_job = job;
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index b04eb6448260..7a84777f3bf4 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -544,6 +544,71 @@
[PATCH v2 16/17] drm/v3d: Create a CPU job extension for the reset performance query job
A CPU job is a type of job that performs operations that requires CPU
intervention. A reset performance query job is a job that resets the
performance queries by resetting the values of the perfmons. Moreover,
we also reset the syncobjs related to the availability of the query.
So, create a user extension for the CPU job that enables the creation
of a reset performance job. This user extension will allow the creation of
a CPU job that resets the perfmons values and resets the availability syncobj.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h| 28 +
drivers/gpu/drm/v3d/v3d_sched.c | 36
drivers/gpu/drm/v3d/v3d_submit.c | 72
include/uapi/drm/v3d_drm.h | 27
4 files changed, 163 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 4b7de76b504a..77854581d348 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -321,6 +321,7 @@ enum v3d_cpu_job_type {
V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY,
V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY,
V3D_CPU_JOB_TYPE_COPY_TIMESTAMP_QUERY,
+ V3D_CPU_JOB_TYPE_RESET_PERFORMANCE_QUERY,
};
struct v3d_timestamp_query {
@@ -331,6 +332,18 @@ struct v3d_timestamp_query {
struct drm_syncobj *syncobj;
};
+/* Number of perfmons required to handle all supported performance counters */
+#define V3D_MAX_PERFMONS DIV_ROUND_UP(V3D_PERFCNT_NUM, \
+ DRM_V3D_MAX_PERF_COUNTERS)
+
+struct v3d_performance_query {
+ /* Performance monitor IDs for this query */
+ u32 kperfmon_ids[V3D_MAX_PERFMONS];
+
+ /* Syncobj that indicates the query availability */
+ struct drm_syncobj *syncobj;
+};
+
struct v3d_indirect_csd_info {
/* Indirect CSD */
struct v3d_csd_job *job;
@@ -362,6 +375,19 @@ struct v3d_timestamp_query_info {
u32 count;
};
+struct v3d_performance_query_info {
+ struct v3d_performance_query *queries;
+
+ /* Number of performance queries */
+ u32 count;
+
+ /* Number of performance monitors related to that query pool */
+ u32 nperfmons;
+
+ /* Number of performance counters related to that query pool */
+ u32 ncounters;
+};
+
struct v3d_copy_query_results_info {
/* Define if should write to buffer using 64 or 32 bits */
bool do_64bit;
@@ -389,6 +415,8 @@ struct v3d_cpu_job {
struct v3d_timestamp_query_info timestamp_query;
struct v3d_copy_query_results_info copy;
+
+ struct v3d_performance_query_info performance_query;
};
struct v3d_submit_outsync {
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 5068b499b7ab..8ebb1f3567f6 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -78,6 +78,7 @@ v3d_cpu_job_free(struct drm_sched_job *sched_job)
{
struct v3d_cpu_job *job = to_cpu_job(sched_job);
struct v3d_timestamp_query_info *timestamp_query =
>timestamp_query;
+ struct v3d_performance_query_info *performance_query =
>performance_query;
if (timestamp_query->queries) {
for (int i = 0; i < timestamp_query->count; i++)
@@ -85,6 +86,12 @@ v3d_cpu_job_free(struct drm_sched_job *sched_job)
kvfree(timestamp_query->queries);
}
+ if (performance_query->queries) {
+ for (int i = 0; i < performance_query->count; i++)
+ drm_syncobj_put(performance_query->queries[i].syncobj);
+ kvfree(performance_query->queries);
+ }
+
v3d_job_cleanup(>base);
}
@@ -415,6 +422,34 @@ v3d_copy_query_results(struct v3d_cpu_job *job)
v3d_put_bo_vaddr(bo);
}
+static void
+v3d_reset_performance_queries(struct v3d_cpu_job *job)
+{
+ struct v3d_performance_query_info *performance_query =
>performance_query;
+ struct v3d_file_priv *v3d_priv = job->base.file->driver_priv;
+ struct v3d_dev *v3d = job->base.v3d;
+ struct v3d_perfmon *perfmon;
+
+ for (int i = 0; i < performance_query->count; i++) {
+ for (int j = 0; j < performance_query->nperfmons; j++) {
+ perfmon = v3d_perfmon_find(v3d_priv,
+
performance_query->queries[i].kperfmon_ids[j]);
+ if (!perfmon) {
+ DRM_DEBUG("Failed to find perfmon.");
+ continue;
+ }
+
+ v3d_perfmon_stop(v3d, perfmon, false);
+
+ memset(perfmon->values, 0, perfmon->ncounters *
sizeof(u64));
+
+ v3d_perfmon_put(perfmon);
+ }
+
+
drm_syncobj_replace_fence(performance_query->queries[i].syncobj, NULL);
+ }
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
[PATCH v2 13/17] drm/v3d: Create a CPU job extension for the timestamp query job
A CPU job is a type of job that performs operations that requires CPU
intervention. A timestamp query job is a job that calculates the
query timestamp and updates the query availability by signaling a
syncobj. As V3D doesn't provide any mechanism to obtain a timestamp
from the GPU, it is a job that needs CPU intervention.
So, create a user extension for the CPU job that enables the creation
of a timestamp query job. This user extension will allow the creation of
a CPU job that performs the timestamp query calculation and updates the
timestamp BO with the proper value.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h| 17 +
drivers/gpu/drm/v3d/v3d_sched.c | 40 -
drivers/gpu/drm/v3d/v3d_submit.c | 62
include/uapi/drm/v3d_drm.h | 27 ++
4 files changed, 145 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index f665f3f5b65b..524e4e952bae 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -318,6 +318,15 @@ struct v3d_csd_job {
enum v3d_cpu_job_type {
V3D_CPU_JOB_TYPE_INDIRECT_CSD = 1,
+ V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY,
+};
+
+struct v3d_timestamp_query {
+ /* Offset of this query in the timestamp BO for its value. */
+ u32 offset;
+
+ /* Syncobj that indicates the timestamp availability */
+ struct drm_syncobj *syncobj;
};
struct v3d_indirect_csd_info {
@@ -345,12 +354,20 @@ struct v3d_indirect_csd_info {
struct ww_acquire_ctx acquire_ctx;
};
+struct v3d_timestamp_query_info {
+ struct v3d_timestamp_query *queries;
+
+ u32 count;
+};
+
struct v3d_cpu_job {
struct v3d_job base;
enum v3d_cpu_job_type job_type;
struct v3d_indirect_csd_info indirect_csd;
+
+ struct v3d_timestamp_query_info timestamp_query;
};
struct v3d_submit_outsync {
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index a8ac46f70cee..828c4fc14dcd 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -21,6 +21,8 @@
#include
#include
+#include
+
#include "v3d_drv.h"
#include "v3d_regs.h"
#include "v3d_trace.h"
@@ -71,6 +73,21 @@ v3d_sched_job_free(struct drm_sched_job *sched_job)
v3d_job_cleanup(job);
}
+static void
+v3d_cpu_job_free(struct drm_sched_job *sched_job)
+{
+ struct v3d_cpu_job *job = to_cpu_job(sched_job);
+ struct v3d_timestamp_query_info *timestamp_query =
>timestamp_query;
+
+ if (timestamp_query->queries) {
+ for (int i = 0; i < timestamp_query->count; i++)
+ drm_syncobj_put(timestamp_query->queries[i].syncobj);
+ kvfree(timestamp_query->queries);
+ }
+
+ v3d_job_cleanup(>base);
+}
+
static void
v3d_switch_perfmon(struct v3d_dev *v3d, struct v3d_job *job)
{
@@ -305,6 +322,26 @@ v3d_rewrite_csd_job_wg_counts_from_indirect(struct
v3d_cpu_job *job)
v3d_put_bo_vaddr(bo);
}
+static void
+v3d_timestamp_query(struct v3d_cpu_job *job)
+{
+ struct v3d_timestamp_query_info *timestamp_query =
>timestamp_query;
+ struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
+ u8 *value_addr;
+
+ v3d_get_bo_vaddr(bo);
+
+ for (int i = 0; i < timestamp_query->count; i++) {
+ value_addr = ((u8 *) bo->vaddr) +
timestamp_query->queries[i].offset;
+ *((u64 *) value_addr) = i == 0 ? ktime_get_ns() : 0ull;
+
+ drm_syncobj_replace_fence(timestamp_query->queries[i].syncobj,
+ job->base.done_fence);
+ }
+
+ v3d_put_bo_vaddr(bo);
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
@@ -315,6 +352,7 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = {
[V3D_CPU_JOB_TYPE_INDIRECT_CSD] =
v3d_rewrite_csd_job_wg_counts_from_indirect,
+ [V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY] = v3d_timestamp_query,
};
v3d->cpu_job = job;
@@ -504,7 +542,7 @@ static const struct drm_sched_backend_ops
v3d_cache_clean_sched_ops = {
static const struct drm_sched_backend_ops v3d_cpu_sched_ops = {
.run_job = v3d_cpu_job_run,
.timedout_job = v3d_generic_job_timedout,
- .free_job = v3d_sched_job_free
+ .free_job = v3d_cpu_job_free
};
int
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index b6707ef42706..2f03c8bca593 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -438,6 +438,64 @@ v3d_get_cpu_indirect_csd_params(struct drm_file *file_priv,
NULL, >acquire_ctx);
}
+/* Get data for the query timestamp job submission. */
+static int
+v3d_get_cpu_timestamp_query_params(struct drm_file *file_priv,
+
[PATCH v2 14/17] drm/v3d: Create a CPU job extension for the reset timestamp job
A CPU job is a type of job that performs operations that requires CPU
intervention. A reset timestamp job is a job that resets the timestamp
queries based on the value offset of the first query. As V3D doesn't
provide any mechanism to obtain a timestamp from the GPU, it is a job
that needs CPU intervention.
So, create a user extension for the CPU job that enables the creation
of a reset timestamp job. This user extension will allow the creation of
a CPU job that resets the timestamp value in the timestamp BO and resets
the availability syncobj.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h| 1 +
drivers/gpu/drm/v3d/v3d_sched.c | 21 +
drivers/gpu/drm/v3d/v3d_submit.c | 51
include/uapi/drm/v3d_drm.h | 24 +++
4 files changed, 97 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 524e4e952bae..a1c8ff06f16b 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -319,6 +319,7 @@ struct v3d_csd_job {
enum v3d_cpu_job_type {
V3D_CPU_JOB_TYPE_INDIRECT_CSD = 1,
V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY,
+ V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY,
};
struct v3d_timestamp_query {
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 828c4fc14dcd..57c9fc887c46 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -342,6 +342,26 @@ v3d_timestamp_query(struct v3d_cpu_job *job)
v3d_put_bo_vaddr(bo);
}
+static void
+v3d_reset_timestamp_queries(struct v3d_cpu_job *job)
+{
+ struct v3d_timestamp_query_info *timestamp_query =
>timestamp_query;
+ struct v3d_timestamp_query *queries = timestamp_query->queries;
+ struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
+ u8 *value_addr;
+
+ v3d_get_bo_vaddr(bo);
+
+ for (int i = 0; i < timestamp_query->count; i++) {
+ value_addr = ((u8 *) bo->vaddr) + queries[i].offset;
+ *((u64 *) value_addr) = 0;
+
+ drm_syncobj_replace_fence(queries[i].syncobj, NULL);
+ }
+
+ v3d_put_bo_vaddr(bo);
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
@@ -353,6 +373,7 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = {
[V3D_CPU_JOB_TYPE_INDIRECT_CSD] =
v3d_rewrite_csd_job_wg_counts_from_indirect,
[V3D_CPU_JOB_TYPE_TIMESTAMP_QUERY] = v3d_timestamp_query,
+ [V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY] =
v3d_reset_timestamp_queries,
};
v3d->cpu_job = job;
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index 2f03c8bca593..b04eb6448260 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -496,6 +496,54 @@ v3d_get_cpu_timestamp_query_params(struct drm_file
*file_priv,
return 0;
}
+static int
+v3d_get_cpu_reset_timestamp_params(struct drm_file *file_priv,
+ struct drm_v3d_extension __user *ext,
+ struct v3d_cpu_job *job)
+{
+ u32 __user *syncs;
+ struct drm_v3d_reset_timestamp_query reset;
+
+ if (!job) {
+ DRM_DEBUG("CPU job extension was attached to a GPU job.\n");
+ return -EINVAL;
+ }
+
+ if (job->job_type) {
+ DRM_DEBUG("Two CPU job extensions were added to the same CPU
job.\n");
+ return -EINVAL;
+ }
+
+ if (copy_from_user(, ext, sizeof(reset)))
+ return -EFAULT;
+
+ job->job_type = V3D_CPU_JOB_TYPE_RESET_TIMESTAMP_QUERY;
+
+ job->timestamp_query.queries = kvmalloc_array(reset.count,
+ sizeof(struct
v3d_timestamp_query),
+ GFP_KERNEL);
+ if (!job->timestamp_query.queries)
+ return -ENOMEM;
+
+ syncs = u64_to_user_ptr(reset.syncs);
+
+ for (int i = 0; i < reset.count; i++) {
+ u32 sync;
+
+ job->timestamp_query.queries[i].offset = reset.offset + 8 * i;
+
+ if (copy_from_user(, syncs++, sizeof(sync))) {
+ kvfree(job->timestamp_query.queries);
+ return -EFAULT;
+ }
+
+ job->timestamp_query.queries[i].syncobj =
drm_syncobj_find(file_priv, sync);
+ }
+ job->timestamp_query.count = reset.count;
+
+ return 0;
+}
+
/* Whenever userspace sets ioctl extensions, v3d_get_extensions parses data
* according to the extension id (name).
*/
@@ -527,6 +575,9 @@ v3d_get_extensions(struct drm_file *file_priv,
case DRM_V3D_EXT_ID_CPU_TIMESTAMP_QUERY:
ret = v3d_get_cpu_timestamp_query_params(file_priv,
user_ext, job);
break;
+
[PATCH v2 12/17] drm/v3d: Create a CPU job extension for a indirect CSD job
A CPU job is a type of job that performs operations that requires CPU
intervention. An indirect CSD job is a job that, when executed in the
queue, will map the indirect buffer, read the dispatch parameters, and
submit a regular dispatch. Therefore, it is a job that needs CPU
intervention.
So, create a user extension for the CPU job that enables the creation
of an indirect CSD. This user extension will allow the creation of a CSD
job linked to a CPU job. The CPU job will wait for the indirect CSD job
dependencies and, once they are signaled, it will update the CSD job
parameters.
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.h| 31 +-
drivers/gpu/drm/v3d/v3d_sched.c | 41 -
drivers/gpu/drm/v3d/v3d_submit.c | 100 ++-
include/uapi/drm/v3d_drm.h | 37 +++-
4 files changed, 205 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 04e97989c442..f665f3f5b65b 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -316,12 +316,41 @@ struct v3d_csd_job {
struct drm_v3d_submit_csd args;
};
-enum v3d_cpu_job_type {};
+enum v3d_cpu_job_type {
+ V3D_CPU_JOB_TYPE_INDIRECT_CSD = 1,
+};
+
+struct v3d_indirect_csd_info {
+ /* Indirect CSD */
+ struct v3d_csd_job *job;
+
+ /* Clean cache job associated to the Indirect CSD job */
+ struct v3d_job *clean_job;
+
+ /* Offset within the BO where the workgroup counts are stored */
+ u32 offset;
+
+ /* Workgroups size */
+ u32 wg_size;
+
+ /* Indices of the uniforms with the workgroup dispatch counts
+* in the uniform stream.
+*/
+ u32 wg_uniform_offsets[3];
+
+ /* Indirect BO */
+ struct drm_gem_object *indirect;
+
+ /* Context of the Indirect CSD job */
+ struct ww_acquire_ctx acquire_ctx;
+};
struct v3d_cpu_job {
struct v3d_job base;
enum v3d_cpu_job_type job_type;
+
+ struct v3d_indirect_csd_info indirect_csd;
};
struct v3d_submit_outsync {
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 30a88e557217..a8ac46f70cee 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -25,6 +25,8 @@
#include "v3d_regs.h"
#include "v3d_trace.h"
+#define V3D_CSD_CFG012_WG_COUNT_SHIFT 16
+
static struct v3d_job *
to_v3d_job(struct drm_sched_job *sched_job)
{
@@ -268,6 +270,41 @@ v3d_csd_job_run(struct drm_sched_job *sched_job)
return fence;
}
+static void
+v3d_rewrite_csd_job_wg_counts_from_indirect(struct v3d_cpu_job *job)
+{
+ struct v3d_indirect_csd_info *indirect_csd = >indirect_csd;
+ struct v3d_bo *bo = to_v3d_bo(job->base.bo[0]);
+ struct v3d_bo *indirect = to_v3d_bo(indirect_csd->indirect);
+ struct drm_v3d_submit_csd *args = _csd->job->args;
+ u32 *wg_counts;
+
+ v3d_get_bo_vaddr(bo);
+ v3d_get_bo_vaddr(indirect);
+
+ wg_counts = (uint32_t *) (bo->vaddr + indirect_csd->offset);
+
+ if (wg_counts[0] == 0 || wg_counts[1] == 0 || wg_counts[2] == 0)
+ return;
+
+ args->cfg[0] = wg_counts[0] << V3D_CSD_CFG012_WG_COUNT_SHIFT;
+ args->cfg[1] = wg_counts[1] << V3D_CSD_CFG012_WG_COUNT_SHIFT;
+ args->cfg[2] = wg_counts[2] << V3D_CSD_CFG012_WG_COUNT_SHIFT;
+ args->cfg[4] = DIV_ROUND_UP(indirect_csd->wg_size, 16) *
+ (wg_counts[0] * wg_counts[1] * wg_counts[2]) - 1;
+
+ for (int i = 0; i < 3; i++) {
+ /* 0x indicates that the uniform rewrite is not needed
*/
+ if (indirect_csd->wg_uniform_offsets[i] != 0x) {
+ u32 uniform_idx = indirect_csd->wg_uniform_offsets[i];
+ ((uint32_t *) indirect->vaddr)[uniform_idx] =
wg_counts[i];
+ }
+ }
+
+ v3d_put_bo_vaddr(indirect);
+ v3d_put_bo_vaddr(bo);
+}
+
static struct dma_fence *
v3d_cpu_job_run(struct drm_sched_job *sched_job)
{
@@ -276,7 +313,9 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
struct v3d_file_priv *file = job->base.file->driver_priv;
u64 runtime;
- void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = { };
+ void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = {
+ [V3D_CPU_JOB_TYPE_INDIRECT_CSD] =
v3d_rewrite_csd_job_wg_counts_from_indirect,
+ };
v3d->cpu_job = job;
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index 7900bc573b96..b6707ef42706 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -396,6 +396,48 @@ v3d_get_multisync_submit_deps(struct drm_file *file_priv,
return 0;
}
+/* Get data for the indirect CSD job submission. */
+static int
+v3d_get_cpu_indirect_csd_params(struct drm_file *file_priv,
[PATCH v2 11/17] drm/v3d: Enable BO mapping
For the indirect CSD CPU job, we will need to access the internal
contents of the BO with the dispatch parameters. Therefore, create
methods to allow the mapping and unmapping of the BO.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_bo.c | 18 ++
drivers/gpu/drm/v3d/v3d_drv.h | 4
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index 357a0da7e16a..1bdfac8beafd 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -33,6 +33,9 @@ void v3d_free_object(struct drm_gem_object *obj)
struct v3d_dev *v3d = to_v3d_dev(obj->dev);
struct v3d_bo *bo = to_v3d_bo(obj);
+ if (bo->vaddr)
+ v3d_put_bo_vaddr(bo);
+
v3d_mmu_remove_ptes(bo);
mutex_lock(>bo_lock);
@@ -134,6 +137,7 @@ struct v3d_bo *v3d_bo_create(struct drm_device *dev, struct
drm_file *file_priv,
if (IS_ERR(shmem_obj))
return ERR_CAST(shmem_obj);
bo = to_v3d_bo(_obj->base);
+ bo->vaddr = NULL;
ret = v3d_bo_create_finish(_obj->base);
if (ret)
@@ -167,6 +171,20 @@ v3d_prime_import_sg_table(struct drm_device *dev,
return obj;
}
+void v3d_get_bo_vaddr(struct v3d_bo *bo)
+{
+ struct drm_gem_shmem_object *obj = >base;
+
+ bo->vaddr = vmap(obj->pages, obj->base.size >> PAGE_SHIFT, VM_MAP,
+pgprot_writecombine(PAGE_KERNEL));
+}
+
+void v3d_put_bo_vaddr(struct v3d_bo *bo)
+{
+ vunmap(bo->vaddr);
+ bo->vaddr = NULL;
+}
+
int v3d_create_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 010b146140ad..04e97989c442 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -202,6 +202,8 @@ struct v3d_bo {
* v3d_render_job->unref_list
*/
struct list_head unref_head;
+
+ void *vaddr;
};
static inline struct v3d_bo *
@@ -389,6 +391,8 @@ struct drm_gem_object *v3d_create_object(struct drm_device
*dev, size_t size);
void v3d_free_object(struct drm_gem_object *gem_obj);
struct v3d_bo *v3d_bo_create(struct drm_device *dev, struct drm_file
*file_priv,
size_t size);
+void v3d_get_bo_vaddr(struct v3d_bo *bo);
+void v3d_put_bo_vaddr(struct v3d_bo *bo);
int v3d_create_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_mmap_bo_ioctl(struct drm_device *dev, void *data,
--
2.41.0
[PATCH v2 10/17] drm/v3d: Detach the CSD job BO setup
From: Melissa Wen
Detach CSD job setup from CSD submission ioctl to reuse it in CPU
submission ioctl for indirect CSD job.
Signed-off-by: Melissa Wen
Co-developed-by: Maíra Canal
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 52 +---
1 file changed, 34 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index 337a15b4b594..7900bc573b96 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -269,6 +269,37 @@ v3d_attach_fences_and_unlock_reservation(struct drm_file
*file_priv,
}
}
+static int
+v3d_setup_csd_jobs_and_bos(struct drm_file *file_priv,
+ struct v3d_dev *v3d,
+ struct drm_v3d_submit_csd *args,
+ struct v3d_csd_job **job,
+ struct v3d_job **clean_job,
+ struct v3d_submit_ext *se,
+ struct ww_acquire_ctx *acquire_ctx)
+{
+ int ret;
+
+ ret = v3d_job_init(v3d, file_priv, (void *)job, sizeof(**job),
+ v3d_job_free, args->in_sync, se, V3D_CSD);
+ if (ret)
+ return ret;
+
+ ret = v3d_job_init(v3d, file_priv, (void *)clean_job,
sizeof(**clean_job),
+ v3d_job_free, 0, NULL, V3D_CACHE_CLEAN);
+ if (ret)
+ return ret;
+
+ (*job)->args = *args;
+
+ ret = v3d_lookup_bos(>drm, file_priv, *clean_job,
+args->bo_handles, args->bo_handle_count);
+ if (ret)
+ return ret;
+
+ return v3d_lock_bo_reservations(*clean_job, acquire_ctx);
+}
+
static void
v3d_put_multisync_post_deps(struct v3d_submit_ext *se)
{
@@ -697,24 +728,9 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
}
}
- ret = v3d_job_init(v3d, file_priv, (void *), sizeof(*job),
- v3d_job_free, args->in_sync, , V3D_CSD);
- if (ret)
- goto fail;
-
- ret = v3d_job_init(v3d, file_priv, (void *)_job,
sizeof(*clean_job),
- v3d_job_free, 0, NULL, V3D_CACHE_CLEAN);
- if (ret)
- goto fail;
-
- job->args = *args;
-
- ret = v3d_lookup_bos(dev, file_priv, clean_job,
-args->bo_handles, args->bo_handle_count);
- if (ret)
- goto fail;
-
- ret = v3d_lock_bo_reservations(clean_job, _ctx);
+ ret = v3d_setup_csd_jobs_and_bos(file_priv, v3d, args,
+, _job, ,
+_ctx);
if (ret)
goto fail;
--
2.41.0
[PATCH v2 09/17] drm/v3d: Create tracepoints to track the CPU job
Create tracepoints to track the three major events of a CPU job
lifetime:
1. Submission of a `v3d_submit_cpu` IOCTL
2. Beginning of the execution of a CPU job
3. Ending of the execution of a CPU job
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_sched.c | 4 +++
drivers/gpu/drm/v3d/v3d_submit.c | 2 ++
drivers/gpu/drm/v3d/v3d_trace.h | 57
3 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index a32c91b94898..30a88e557217 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -288,8 +288,12 @@ v3d_cpu_job_run(struct drm_sched_job *sched_job)
file->start_ns[V3D_CPU] = local_clock();
v3d->queue[V3D_CPU].start_ns = file->start_ns[V3D_CPU];
+ trace_v3d_cpu_job_begin(>drm, job->job_type);
+
v3d_cpu_job_fn[job->job_type](job);
+ trace_v3d_cpu_job_end(>drm, job->job_type);
+
runtime = local_clock() - file->start_ns[V3D_CPU];
file->enabled_ns[V3D_CPU] += runtime;
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index 955cf3106fdf..337a15b4b594 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -806,6 +806,8 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
goto fail;
}
+ trace_v3d_submit_cpu_ioctl(>drm, cpu_job->job_type);
+
ret = v3d_job_init(v3d, file_priv, (void *)_job, sizeof(*cpu_job),
v3d_job_free, 0, , V3D_CPU);
if (ret)
diff --git a/drivers/gpu/drm/v3d/v3d_trace.h b/drivers/gpu/drm/v3d/v3d_trace.h
index 7aa8dc356e54..06086ece6e9e 100644
--- a/drivers/gpu/drm/v3d/v3d_trace.h
+++ b/drivers/gpu/drm/v3d/v3d_trace.h
@@ -225,6 +225,63 @@ TRACE_EVENT(v3d_submit_csd,
__entry->seqno)
);
+TRACE_EVENT(v3d_submit_cpu_ioctl,
+ TP_PROTO(struct drm_device *dev, enum v3d_cpu_job_type job_type),
+ TP_ARGS(dev, job_type),
+
+ TP_STRUCT__entry(
+ __field(u32, dev)
+ __field(enum v3d_cpu_job_type, job_type)
+ ),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ __entry->job_type = job_type;
+ ),
+
+ TP_printk("dev=%u, job_type=%d",
+__entry->dev,
+__entry->job_type)
+);
+
+TRACE_EVENT(v3d_cpu_job_begin,
+ TP_PROTO(struct drm_device *dev, enum v3d_cpu_job_type job_type),
+ TP_ARGS(dev, job_type),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(enum v3d_cpu_job_type, job_type)
+),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ __entry->job_type = job_type;
+ ),
+
+ TP_printk("dev=%u, job_type=%d",
+ __entry->dev,
+ __entry->job_type)
+);
+
+TRACE_EVENT(v3d_cpu_job_end,
+ TP_PROTO(struct drm_device *dev, enum v3d_cpu_job_type job_type),
+ TP_ARGS(dev, job_type),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(enum v3d_cpu_job_type, job_type)
+),
+
+ TP_fast_assign(
+ __entry->dev = dev->primary->index;
+ __entry->job_type = job_type;
+ ),
+
+ TP_printk("dev=%u, job_type=%d",
+ __entry->dev,
+ __entry->job_type)
+);
+
TRACE_EVENT(v3d_cache_clean_begin,
TP_PROTO(struct drm_device *dev),
TP_ARGS(dev),
--
2.41.0
[PATCH v2 08/17] drm/v3d: Use v3d_get_extensions() to parse CPU job data
Currently, v3d_get_extensions() only parses multisync data and assigns
it to the `struct v3d_submit_ext`. But, to implement the CPU job with
user extensions, we want v3d_get_extensions() to be able to parse CPU
job data and assign it to the `struct v3d_cpu_job`.
Therefore, allow the function v3d_get_extensions() to use `struct v3d_cpu_job *`
as a parameter. If the `struct v3d_cpu_job *` is assigned to NULL, it means
that the job is a GPU job and CPU job extensions should be rejected.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index d4b85ab16345..955cf3106fdf 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -336,10 +336,9 @@ v3d_get_multisync_post_deps(struct drm_file *file_priv,
static int
v3d_get_multisync_submit_deps(struct drm_file *file_priv,
struct drm_v3d_extension __user *ext,
- void *data)
+ struct v3d_submit_ext *se)
{
struct drm_v3d_multi_sync multisync;
- struct v3d_submit_ext *se = data;
int ret;
if (se->in_sync_count || se->out_sync_count) {
@@ -353,7 +352,7 @@ v3d_get_multisync_submit_deps(struct drm_file *file_priv,
if (multisync.pad)
return -EINVAL;
- ret = v3d_get_multisync_post_deps(file_priv, data,
multisync.out_sync_count,
+ ret = v3d_get_multisync_post_deps(file_priv, se,
multisync.out_sync_count,
multisync.out_syncs);
if (ret)
return ret;
@@ -372,7 +371,8 @@ v3d_get_multisync_submit_deps(struct drm_file *file_priv,
static int
v3d_get_extensions(struct drm_file *file_priv,
u64 ext_handles,
- void *data)
+ struct v3d_submit_ext *se,
+ struct v3d_cpu_job *job)
{
struct drm_v3d_extension __user *user_ext;
int ret;
@@ -388,15 +388,16 @@ v3d_get_extensions(struct drm_file *file_priv,
switch (ext.id) {
case DRM_V3D_EXT_ID_MULTI_SYNC:
- ret = v3d_get_multisync_submit_deps(file_priv,
user_ext, data);
- if (ret)
- return ret;
+ ret = v3d_get_multisync_submit_deps(file_priv,
user_ext, se);
break;
default:
DRM_DEBUG_DRIVER("Unknown extension id: %d\n", ext.id);
return -EINVAL;
}
+ if (ret)
+ return ret;
+
user_ext = u64_to_user_ptr(ext.next);
}
@@ -443,7 +444,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
}
if (args->flags & DRM_V3D_SUBMIT_EXTENSION) {
- ret = v3d_get_extensions(file_priv, args->extensions, );
+ ret = v3d_get_extensions(file_priv, args->extensions, ,
NULL);
if (ret) {
DRM_DEBUG("Failed to get extensions.\n");
return ret;
@@ -586,7 +587,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
}
if (args->flags & DRM_V3D_SUBMIT_EXTENSION) {
- ret = v3d_get_extensions(file_priv, args->extensions, );
+ ret = v3d_get_extensions(file_priv, args->extensions, ,
NULL);
if (ret) {
DRM_DEBUG("Failed to get extensions.\n");
return ret;
@@ -689,7 +690,7 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
}
if (args->flags & DRM_V3D_SUBMIT_EXTENSION) {
- ret = v3d_get_extensions(file_priv, args->extensions, );
+ ret = v3d_get_extensions(file_priv, args->extensions, ,
NULL);
if (ret) {
DRM_DEBUG("Failed to get extensions.\n");
return ret;
@@ -792,7 +793,7 @@ v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
return ret;
if (args->flags & DRM_V3D_SUBMIT_EXTENSION) {
- ret = v3d_get_extensions(file_priv, args->extensions, );
+ ret = v3d_get_extensions(file_priv, args->extensions, ,
cpu_job);
if (ret) {
DRM_DEBUG("Failed to get extensions.\n");
goto fail;
--
2.41.0
[PATCH v2 07/17] drm/v3d: Add a CPU job submission
From: Melissa Wen
Create a new type of job, a CPU job. A CPU job is a type of job that
performs operations that requires CPU intervention. The overall idea is
to use user extensions to enable different types of CPU job, allowing the
CPU job to perform different operations according to the type of user
externsion. The user extension ID identify the type of CPU job that must
be dealt.
Having a CPU job is interesting for synchronization purposes as a CPU
job has a queue like any other V3D job and can be synchoronized by the
multisync extension.
Signed-off-by: Melissa Wen
Co-developed-by: Maíra Canal
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c| 4 ++
drivers/gpu/drm/v3d/v3d_drv.h| 14 +-
drivers/gpu/drm/v3d/v3d_sched.c | 57 +++
drivers/gpu/drm/v3d/v3d_submit.c | 79
include/uapi/drm/v3d_drm.h | 17 +++
5 files changed, 170 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 44a1ca57d6a4..3debf37e7d9b 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -91,6 +91,9 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void
*data,
case DRM_V3D_PARAM_SUPPORTS_MULTISYNC_EXT:
args->value = 1;
return 0;
+ case DRM_V3D_PARAM_SUPPORTS_CPU_QUEUE:
+ args->value = 1;
+ return 0;
default:
DRM_DEBUG("Unknown parameter %d\n", args->param);
return -EINVAL;
@@ -189,6 +192,7 @@ static const struct drm_ioctl_desc v3d_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(V3D_PERFMON_CREATE, v3d_perfmon_create_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_PERFMON_DESTROY, v3d_perfmon_destroy_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_PERFMON_GET_VALUES, v3d_perfmon_get_values_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CPU, v3d_submit_cpu_ioctl,
DRM_RENDER_ALLOW | DRM_AUTH),
};
static const struct drm_driver v3d_drm_driver = {
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 4db9ace66024..010b146140ad 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -19,7 +19,7 @@ struct reset_control;
#define GMP_GRANULARITY (128 * 1024)
-#define V3D_MAX_QUEUES (V3D_CACHE_CLEAN + 1)
+#define V3D_MAX_QUEUES (V3D_CPU + 1)
static inline char *v3d_queue_to_string(enum v3d_queue queue)
{
@@ -29,6 +29,7 @@ static inline char *v3d_queue_to_string(enum v3d_queue queue)
case V3D_TFU: return "tfu";
case V3D_CSD: return "csd";
case V3D_CACHE_CLEAN: return "cache_clean";
+ case V3D_CPU: return "cpu";
}
return "UNKNOWN";
}
@@ -122,6 +123,7 @@ struct v3d_dev {
struct v3d_render_job *render_job;
struct v3d_tfu_job *tfu_job;
struct v3d_csd_job *csd_job;
+ struct v3d_cpu_job *cpu_job;
struct v3d_queue_state queue[V3D_MAX_QUEUES];
@@ -312,6 +314,14 @@ struct v3d_csd_job {
struct drm_v3d_submit_csd args;
};
+enum v3d_cpu_job_type {};
+
+struct v3d_cpu_job {
+ struct v3d_job base;
+
+ enum v3d_cpu_job_type job_type;
+};
+
struct v3d_submit_outsync {
struct drm_syncobj *syncobj;
};
@@ -414,6 +424,8 @@ int v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+int v3d_submit_cpu_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
/* v3d_irq.c */
int v3d_irq_init(struct v3d_dev *v3d);
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index fccbea2a5f2e..a32c91b94898 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -55,6 +55,12 @@ to_csd_job(struct drm_sched_job *sched_job)
return container_of(sched_job, struct v3d_csd_job, base.base);
}
+static struct v3d_cpu_job *
+to_cpu_job(struct drm_sched_job *sched_job)
+{
+ return container_of(sched_job, struct v3d_cpu_job, base.base);
+}
+
static void
v3d_sched_job_free(struct drm_sched_job *sched_job)
{
@@ -262,6 +268,42 @@ v3d_csd_job_run(struct drm_sched_job *sched_job)
return fence;
}
+static struct dma_fence *
+v3d_cpu_job_run(struct drm_sched_job *sched_job)
+{
+ struct v3d_cpu_job *job = to_cpu_job(sched_job);
+ struct v3d_dev *v3d = job->base.v3d;
+ struct v3d_file_priv *file = job->base.file->driver_priv;
+ u64 runtime;
+
+ void (*v3d_cpu_job_fn[])(struct v3d_cpu_job *job) = { };
+
+ v3d->cpu_job = job;
+
+ if (job->job_type >= ARRAY_SIZE(v3d_cpu_job_fn)) {
+ DRM_DEBUG_DRIVER("Unknown CPU job: %d\n", job->job_type);
+ return NULL;
+ }
+
+ file->start_ns[V3D_CPU] = local_clock();
+
[PATCH v2 05/17] drm/v3d: Don't allow two multisync extensions in the same job
Currently, two multisync extensions can be added to the same job and
only the last multisync extension will be used. To avoid this
vulnerability, don't allow two multisync extensions in the same job.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index e18e7c963884..fe46dd316ca0 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -329,6 +329,11 @@ v3d_get_multisync_submit_deps(struct drm_file *file_priv,
struct v3d_submit_ext *se = data;
int ret;
+ if (se->in_sync_count || se->out_sync_count) {
+ DRM_DEBUG("Two multisync extensions were added to the same
job.");
+ return -EINVAL;
+ }
+
if (copy_from_user(, ext, sizeof(multisync)))
return -EFAULT;
--
2.41.0
[PATCH v2 06/17] drm/v3d: Decouple job allocation from job initiation
We want to allow the IOCTLs to allocate the job without initiating it.
This will be useful for the CPU job submission IOCTL, as the CPU job has
the need to use information from the user extensions. Currently, the
user extensions are parsed before the job allocation, making it
impossible to fill the CPU job when parsing the user extensions.
Therefore, decouple the job allocation from the job initiation.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index fe46dd316ca0..ed1a310bbd2f 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -135,6 +135,21 @@ void v3d_job_put(struct v3d_job *job)
kref_put(>refcount, job->free);
}
+static int
+v3d_job_allocate(void **container, size_t size)
+{
+ if (*container)
+ return 0;
+
+ *container = kcalloc(1, size, GFP_KERNEL);
+ if (!*container) {
+ DRM_ERROR("Cannot allocate memory for V3D job.\n");
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
static int
v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
void **container, size_t size, void (*free)(struct kref *ref),
@@ -145,11 +160,9 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
bool has_multisync = se && (se->flags & DRM_V3D_EXT_ID_MULTI_SYNC);
int ret, i;
- *container = kcalloc(1, size, GFP_KERNEL);
- if (!*container) {
- DRM_ERROR("Cannot allocate memory for v3d job.");
- return -ENOMEM;
- }
+ ret = v3d_job_allocate(container, size);
+ if (ret)
+ return ret;
job = *container;
job->v3d = v3d;
--
2.41.0
[PATCH v2 04/17] drm/v3d: Simplify job refcount handling
From: Melissa Wen
Instead of checking if the job is NULL every time we call the function,
check it inside the function.
Signed-off-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index f36214002f37..e18e7c963884 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -129,6 +129,9 @@ void v3d_job_cleanup(struct v3d_job *job)
void v3d_job_put(struct v3d_job *job)
{
+ if (!job)
+ return;
+
kref_put(>refcount, job->free);
}
@@ -517,11 +520,9 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
,
last_job->done_fence);
- if (bin)
- v3d_job_put(>base);
- v3d_job_put(>base);
- if (clean_job)
- v3d_job_put(clean_job);
+ v3d_job_put((void *)bin);
+ v3d_job_put((void *)render);
+ v3d_job_put((void *)clean_job);
return 0;
@@ -621,7 +622,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
,
job->base.done_fence);
- v3d_job_put(>base);
+ v3d_job_put((void *)job);
return 0;
@@ -725,7 +726,7 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
,
clean_job->done_fence);
- v3d_job_put(>base);
+ v3d_job_put((void *)job);
v3d_job_put(clean_job);
return 0;
--
2.41.0
[PATCH v2 02/17] drm/v3d: Move wait BO ioctl to the v3d_bo file
From: Melissa Wen
IOCTLs related to BO operations reside on the file v3d_bo.c. The wait BO
ioctl is the only IOCTL regarding BOs that is placed in a different file.
So, move it to the v3d_bo.c file.
Signed-off-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_bo.c | 33 +
drivers/gpu/drm/v3d/v3d_drv.h | 4 ++--
drivers/gpu/drm/v3d/v3d_gem.c | 33 -
3 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index 8b3229a37c6d..357a0da7e16a 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -233,3 +233,36 @@ int v3d_get_bo_offset_ioctl(struct drm_device *dev, void
*data,
drm_gem_object_put(gem_obj);
return 0;
}
+
+int
+v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ int ret;
+ struct drm_v3d_wait_bo *args = data;
+ ktime_t start = ktime_get();
+ u64 delta_ns;
+ unsigned long timeout_jiffies =
+ nsecs_to_jiffies_timeout(args->timeout_ns);
+
+ if (args->pad != 0)
+ return -EINVAL;
+
+ ret = drm_gem_dma_resv_wait(file_priv, args->handle,
+ true, timeout_jiffies);
+
+ /* Decrement the user's timeout, in case we got interrupted
+* such that the ioctl will be restarted.
+*/
+ delta_ns = ktime_to_ns(ktime_sub(ktime_get(), start));
+ if (delta_ns < args->timeout_ns)
+ args->timeout_ns -= delta_ns;
+ else
+ args->timeout_ns = 0;
+
+ /* Asked to wait beyond the jiffie/scheduler precision? */
+ if (ret == -ETIME && args->timeout_ns)
+ ret = -EAGAIN;
+
+ return ret;
+}
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index d8b392494eba..fc04372d5cbd 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -385,6 +385,8 @@ int v3d_mmap_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_get_bo_offset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+int v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
struct drm_gem_object *v3d_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment
*attach,
struct sg_table *sgt);
@@ -405,8 +407,6 @@ int v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-int v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
void v3d_job_cleanup(struct v3d_job *job);
void v3d_job_put(struct v3d_job *job);
void v3d_reset(struct v3d_dev *v3d);
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 9d2ac23c29e3..26f62a48d226 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -363,39 +363,6 @@ void v3d_job_put(struct v3d_job *job)
kref_put(>refcount, job->free);
}
-int
-v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
-{
- int ret;
- struct drm_v3d_wait_bo *args = data;
- ktime_t start = ktime_get();
- u64 delta_ns;
- unsigned long timeout_jiffies =
- nsecs_to_jiffies_timeout(args->timeout_ns);
-
- if (args->pad != 0)
- return -EINVAL;
-
- ret = drm_gem_dma_resv_wait(file_priv, args->handle,
- true, timeout_jiffies);
-
- /* Decrement the user's timeout, in case we got interrupted
-* such that the ioctl will be restarted.
-*/
- delta_ns = ktime_to_ns(ktime_sub(ktime_get(), start));
- if (delta_ns < args->timeout_ns)
- args->timeout_ns -= delta_ns;
- else
- args->timeout_ns = 0;
-
- /* Asked to wait beyond the jiffie/scheduler precision? */
- if (ret == -ETIME && args->timeout_ns)
- ret = -EAGAIN;
-
- return ret;
-}
-
static int
v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
void **container, size_t size, void (*free)(struct kref *ref),
--
2.41.0
[PATCH v2 03/17] drm/v3d: Detach job submissions IOCTLs to a new specific file
From: Melissa Wen
We will include a new job submission type, the CPU job submission. For
readability and maintability, separate the job submission IOCTLs and
related operations from v3d_gem.c.
Minor fix in the CSD submission kernel doc:
CSD (texture formatting) -> CSD (compute shader).
Signed-off-by: Melissa Wen
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/Makefile | 3 +-
drivers/gpu/drm/v3d/v3d_drv.h| 12 +-
drivers/gpu/drm/v3d/v3d_gem.c| 735 --
drivers/gpu/drm/v3d/v3d_submit.c | 744 +++
4 files changed, 753 insertions(+), 741 deletions(-)
create mode 100644 drivers/gpu/drm/v3d/v3d_submit.c
diff --git a/drivers/gpu/drm/v3d/Makefile b/drivers/gpu/drm/v3d/Makefile
index 4b21b20e4998..b7d673f1153b 100644
--- a/drivers/gpu/drm/v3d/Makefile
+++ b/drivers/gpu/drm/v3d/Makefile
@@ -12,7 +12,8 @@ v3d-y := \
v3d_perfmon.o \
v3d_trace_points.o \
v3d_sched.o \
- v3d_sysfs.o
+ v3d_sysfs.o \
+ v3d_submit.o
v3d-$(CONFIG_DEBUG_FS) += v3d_debugfs.o
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index fc04372d5cbd..4db9ace66024 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -401,17 +401,19 @@ struct dma_fence *v3d_fence_create(struct v3d_dev *v3d,
enum v3d_queue queue);
/* v3d_gem.c */
int v3d_gem_init(struct drm_device *dev);
void v3d_gem_destroy(struct drm_device *dev);
+void v3d_reset(struct v3d_dev *v3d);
+void v3d_invalidate_caches(struct v3d_dev *v3d);
+void v3d_clean_caches(struct v3d_dev *v3d);
+
+/* v3d_submit.c */
+void v3d_job_cleanup(struct v3d_job *job);
+void v3d_job_put(struct v3d_job *job);
int v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-void v3d_job_cleanup(struct v3d_job *job);
-void v3d_job_put(struct v3d_job *job);
-void v3d_reset(struct v3d_dev *v3d);
-void v3d_invalidate_caches(struct v3d_dev *v3d);
-void v3d_clean_caches(struct v3d_dev *v3d);
/* v3d_irq.c */
int v3d_irq_init(struct v3d_dev *v3d);
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 26f62a48d226..afc565078c78 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -11,8 +11,6 @@
#include
#include
-#include
-#include
#include "v3d_drv.h"
#include "v3d_regs.h"
@@ -241,739 +239,6 @@ v3d_invalidate_caches(struct v3d_dev *v3d)
v3d_invalidate_slices(v3d, 0);
}
-/* Takes the reservation lock on all the BOs being referenced, so that
- * at queue submit time we can update the reservations.
- *
- * We don't lock the RCL the tile alloc/state BOs, or overflow memory
- * (all of which are on exec->unref_list). They're entirely private
- * to v3d, so we don't attach dma-buf fences to them.
- */
-static int
-v3d_lock_bo_reservations(struct v3d_job *job,
-struct ww_acquire_ctx *acquire_ctx)
-{
- int i, ret;
-
- ret = drm_gem_lock_reservations(job->bo, job->bo_count, acquire_ctx);
- if (ret)
- return ret;
-
- for (i = 0; i < job->bo_count; i++) {
- ret = dma_resv_reserve_fences(job->bo[i]->resv, 1);
- if (ret)
- goto fail;
-
- ret = drm_sched_job_add_implicit_dependencies(>base,
- job->bo[i], true);
- if (ret)
- goto fail;
- }
-
- return 0;
-
-fail:
- drm_gem_unlock_reservations(job->bo, job->bo_count, acquire_ctx);
- return ret;
-}
-
-/**
- * v3d_lookup_bos() - Sets up job->bo[] with the GEM objects
- * referenced by the job.
- * @dev: DRM device
- * @file_priv: DRM file for this fd
- * @job: V3D job being set up
- * @bo_handles: GEM handles
- * @bo_count: Number of GEM handles passed in
- *
- * The command validator needs to reference BOs by their index within
- * the submitted job's BO list. This does the validation of the job's
- * BO list and reference counting for the lifetime of the job.
- *
- * Note that this function doesn't need to unreference the BOs on
- * failure, because that will happen at v3d_exec_cleanup() time.
- */
-static int
-v3d_lookup_bos(struct drm_device *dev,
- struct drm_file *file_priv,
- struct v3d_job *job,
- u64 bo_handles,
- u32 bo_count)
-{
- job->bo_count = bo_count;
-
- if (!job->bo_count) {
- /* See comment on bo_index for why we have to check
-* this.
-*/
- DRM_DEBUG("Rendering requires BOs\n");
- return -EINVAL;
- }
-
- return
[PATCH v2 00/17] drm/v3d: Introduce CPU jobs
This patchset implements the basic infrastructure for a new type of V3D job, a CPU job. A CPU job is a job that requires CPU intervention. It would be nice to perform this operations on the kernel space as we can attach multiple in/out syncobjs to it. Why we want a CPU job on the kernel? There are some Vulkan commands that cannot be performed by the GPU, so we implement those as CPU jobs on Mesa. But to synchronize a CPU job in the user space, we need to hold part of the command submission flow in order to correctly synchronize their execution. By moving the CPU job to the kernel, we can make use of the DRM schedule queues and all the advantages it brings with it. This way, instead of stalling the submission thread, we can use syncobjs to synchronize the job, providing a more effective management. About the implementation After we decided that we would like to have a CPU job implementation in the kernel, we could think about two possible implementations for this job: creating an IOCTL for each type of CPU job or using an user extension to provide a polymorphic behavior to a single CPU job IOCTL. We decided for the latter one. We have different types of CPU jobs (indirect CSD jobs, timestamp query jobs, copy query results jobs...) and each of them have a common infrastructure, but perform different operations. Therefore, by using a single IOCTL that is extended by an user extension, we can reuse the common infrastructure - avoiding code repetition - and yet use the user extension ID to identify the type of job and depending on the type of job, perform a certain operation. About the patchset == This patchset introduces the basic infrastructure of a CPU job with a new V3D queue (V3D_CPU) e new tracers. Moreover, it introduces six types of CPU jobs: an indirect CSD job, a timestamp query job, a reset timestamp queries job, a copy timestamp query results job, a reset performance queries job, and a copy performance query results job. An indirect CSD job is a job that, when executed in the queue, will map the indirect buffer, read the dispatch parameters, and submit a regular dispatch. So, the CSD job depends on the CPU job execution. We attach the wait dependencies to the CPU job and once they are satisfied, we read the dispatch parameters, rewrite the uniforms (if needed) and enable the CSD job execution, which depends on the completion of the CPU job. A timestamp query job is a job that calculates the value of the timestamp query and updates the availability of the query. In order to implement this job, we had to change the Mesa implementation of the timestamp. Now, the timestamp query value is tracked in a BO, instead of using a memory address. Moreover, the timestamp query availability is tracked with a syncobj, which is signaled when the query is available. A reset timestamp queries job is a job that resets the timestamp queries by zeroing the timestamp BO in the right positions. The right position on the timestamp BO is found through the offset of the first query. A reset performance queries job is a job that zeros the values of the performance monitors associated to that query. Moreover, it resets the availability syncobj related to that query. A copy query results job is a job that copy the results of a query to a BO in a given offset with a given stride. The patchset is divided as such: * #1 - #4: refactoring operations to prepare for the introduction of the CPU job * #5: addressing a vulnerability in the multisync extension * #6: decouple job allocation from job initiation * #7 - #9: introduction of the CPU job * #10 - #11: refactoring operations to prepare for the introduction of the indirect CSD job * #12: introduction of the indirect CSD job * #13: introduction of the timestamp query job * #14: introduction of the reset timestamp queries job * #15: introduction of the copy timestamp query results job * #16: introduction of the reset performance queries job * #17: introduction of the copy performance query results job This patchset has its Mesa counterpart, which is available on [1]. Both the kernel and Mesa implementation were tested with * `dEQP-VK.compute.pipeline.indirect_dispatch.*`, * `dEQP-VK.pipeline.monolithic.timestamp.*`, * `dEQP-VK.synchronization.*`, * `dEQP-VK.query_pool.*` * and `dEQP-VK.multiview.*`. [1] https://gitlab.freedesktop.org/mairacanal/mesa/-/tree/v3dv/v5/cpu-job Changelog = v1 -> v2: https://lore.kernel.org/dri-devel/20230904175019.1172713-1-mca...@igalia.com/ * Rebase on top of drm-misc-next. * Add GPU stats to the CPU queue. Best Regards, - Maíra Maíra Canal (11): drm/v3d: Don't allow two multisync extensions in the same job drm/v3d: Decouple job allocation from job initiation drm/v3d: Use v3d_get_extensions() to parse CPU job data drm/v3d: Create tracepoints to track the CPU job drm/v3d: Enable BO mapping
[PATCH v2 01/17] drm/v3d: Remove unused function header
From: Melissa Wen v3d_mmu_get_offset header was added but the function was never defined. Just remove it. Signed-off-by: Melissa Wen Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_drv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h index 4c59fefaa0b4..d8b392494eba 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.h +++ b/drivers/gpu/drm/v3d/v3d_drv.h @@ -420,8 +420,6 @@ void v3d_irq_disable(struct v3d_dev *v3d); void v3d_irq_reset(struct v3d_dev *v3d); /* v3d_mmu.c */ -int v3d_mmu_get_offset(struct drm_file *file_priv, struct v3d_bo *bo, - u32 *offset); int v3d_mmu_set_page_table(struct v3d_dev *v3d); void v3d_mmu_insert_ptes(struct v3d_bo *bo); void v3d_mmu_remove_ptes(struct v3d_bo *bo); -- 2.41.0
Re: [GIT PULL] exynos-drm-fixes
On Tue, 21 Nov 2023 at 09:00, Inki Dae wrote: > > Hi Dave and Daniel, > >Two fixups - fixing a potential error pointer dereference and wrong >error checking. Hi Inki, This fails to build on arm32, and it seems one of the fixes is wrong [airlied@dreadlord drm-fixes]$ make ARCH=arm CROSS_COMPILE=arm-linux-gnu- O=../../arm-build-fixes/ -j16 make[1]: Entering directory '/home/airlied/devel/kernel/arm-build-fixes' GEN Makefile CALL/home/airlied/devel/kernel/dim/drm-fixes/scripts/checksyscalls.sh CC [M] drivers/gpu/drm/exynos/exynos_drm_dma.o /home/airlied/devel/kernel/dim/drm-fixes/drivers/gpu/drm/exynos/exynos_drm_dma.c: In function ‘exynos_drm_register_dma’: /home/airlied/devel/kernel/dim/drm-fixes/drivers/gpu/drm/exynos/exynos_drm_dma.c:119:40: error: passing argument 1 of ‘PTR_ERR’ makes pointer from integer without a cast [-Werror=int-conversion] 119 | return PTR_ERR(-ENODEV); In file included from /home/airlied/devel/kernel/dim/drm-fixes/include/linux/string.h:9, from /home/airlied/devel/kernel/dim/drm-fixes/include/linux/dma-mapping.h:7, from /home/airlied/devel/kernel/dim/drm-fixes/include/linux/dma-map-ops.h:9, from /home/airlied/devel/kernel/dim/drm-fixes/drivers/gpu/drm/exynos/exynos_drm_dma.c:7: /home/airlied/devel/kernel/dim/drm-fixes/include/linux/err.h:49:61: note: expected ‘const void *’ but argument is of type ‘int’ 49 | static inline long __must_check PTR_ERR(__force const void *ptr) | ^~~ cc1: all warnings being treated as errors I think it should just be return -ENODEV, since the function returns an int. Please fix it up and resend. Thanks, Dave. > >Ps. regarding the first patch, I had sent a GIT-PULL[1] but it seems >you missed. >[1] > https://lore.kernel.org/dri-devel/20231006040950.4397-1-inki@samsung.com/T/#u > >Please kindly let me know if there is any problem. > > Thanks, > Inki Dae > > The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: > > Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos > tags/exynos-drm-fixes-for-v6.7-rc3 > > for you to fetch changes up to a30ba4bd7cdb5726d86a557c5df8df71c7bc7fad: > > drm/exynos: fix a wrong error checking (2023-11-21 07:41:11 +0900) > > > Two fixups > - Fix a potential error pointer dereference by checking the return value > of exynos_drm_crtc_get_by_type() function before accessing to crtc > object. > - Fix a wrong error checking in exynos_drm_dma.c modules, which was reported > by Dan[1] > > [1] > https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/ > > > Inki Dae (1): > drm/exynos: fix a wrong error checking > > Xiang Yang (1): > drm/exynos: fix a potential error pointer dereference > > drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +++- > drivers/gpu/drm/exynos/exynos_hdmi.c| 2 ++ > 2 files changed, 5 insertions(+), 5 deletions(-)
Re: linux-next: manual merge of the drm-intel tree with the amdgpu tree
Hi all,
On Mon, 20 Nov 2023 12:28:18 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
>
> between commits:
>
> a58555359a9f ("drm/amd/display: Fix DSC not Enabled on Direct MST Sink")
> c29085d29562 ("drm/amd/display: Enable DSC Flag in MST Mode Validation")
>
> from the amdgpu tree and commit:
>
> 7707dd602259 ("drm/dp_mst: Fix fractional DSC bpp handling")
>
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 8d7d4024f285,2afd1bc74978..
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@@ -1650,7 -1636,8 +1650,7 @@@ enum dc_status dm_dp_mst_is_port_suppor
> } else {
> /* check if mode could be supported within full_pbn */
> bpp =
> convert_dc_color_depth_into_bpc(stream->timing.display_color_depth) * 3;
> - pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
> bpp, false);
> + pbn = drm_dp_calc_pbn_mode(stream->timing.pix_clk_100hz / 10,
> bpp << 4);
> -
> if (pbn > aconnector->mst_output_port->full_pbn)
> return DC_FAIL_BANDWIDTH_VALIDATE;
> }
This is now a conflict between the amdgpu tree and the drm tree.
--
Cheers,
Stephen Rothwell
pgpTdfCQ5jV6D.pgp
Description: OpenPGP digital signature
[PATCH v4 5/5] drm/todo: Add entry about implementing buffer age for damage tracking
Currently, only damage tracking for frame damage is supported. If a driver needs to do buffer damage (e.g: the framebuffer attached to plane's state has changed since the last page-flip), the damage helpers just fallback to a full plane update. Add en entry in the TODO about implementing buffer age or any other damage accumulation algorithm for buffer damage handling. Suggested-by: Simon Ser Signed-off-by: Javier Martinez Canillas Reviewed-by: Simon Ser Reviewed-by: Thomas Zimmermann Reviewed-by: Zack Rusin Acked-by: Sima Vetter --- Changes in v4: - Reference the _plane_state.ignore_damage_clips and the damage helpers in the buffer damage TODO entry (Sima Vetter). Documentation/gpu/todo.rst | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index b62c7fa0c2bc..503d57c75215 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -782,6 +782,29 @@ Contact: Hans de Goede Level: Advanced +Buffer age or other damage accumulation algorithm for buffer damage +=== + +Drivers that do per-buffer uploads, need a buffer damage handling (rather than +frame damage like drivers that do per-plane or per-CRTC uploads), but there is +no support to get the buffer age or any other damage accumulation algorithm. + +For this reason, the damage helpers just fallback to a full plane update if the +framebuffer attached to a plane has changed since the last page-flip. Drivers +set _plane_state.ignore_damage_clips to true as indication to +drm_atomic_helper_damage_iter_init() and drm_atomic_helper_damage_iter_next() +helpers that the damage clips should be ignored. + +This should be improved to get damage tracking properly working on drivers that +do per-buffer uploads. + +More information about damage tracking and references to learning materials can +be found in :ref:`damage_tracking_properties`. + +Contact: Javier Martinez Canillas + +Level: Advanced + Outside DRM === -- 2.41.0
[PATCH v4 1/5] drm: Allow drivers to indicate the damage helpers to ignore damage clips
It allows drivers to set a struct drm_plane_state .ignore_damage_clips in
their plane's .atomic_check callback, as an indication to damage helpers
such as drm_atomic_helper_damage_iter_init() that the damage clips should
be ignored.
To be used by drivers that do per-buffer (e.g: virtio-gpu) uploads (rather
than per-plane uploads), since these type of drivers need to handle buffer
damages instead of frame damages.
That way, these drivers could force a full plane update if the framebuffer
attached to a plane's state has changed since the last update (page-flip).
Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the
primary plane")
Cc: # v6.4+
Reported-by: nerdopolis
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218115
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
Acked-by: Sima Vetter
---
Changes in v4:
- Refer in ignore_damage_clips kernel-doc to "Damage Tracking Properties"
KMS documentation section (Sima Vetter).
Changes in v2:
- Add a struct drm_plane_state .ignore_damage_clips to set in the plane's
.atomic_check, instead of having different helpers (Thomas Zimmermann).
Documentation/gpu/drm-kms.rst | 2 ++
drivers/gpu/drm/drm_damage_helper.c | 3 ++-
include/drm/drm_plane.h | 10 ++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 270d320407c7..a98a7e04e86f 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -548,6 +548,8 @@ Plane Composition Properties
.. kernel-doc:: drivers/gpu/drm/drm_blend.c
:doc: overview
+.. _damage_tracking_properties:
+
Damage Tracking Properties
--
diff --git a/drivers/gpu/drm/drm_damage_helper.c
b/drivers/gpu/drm/drm_damage_helper.c
index d8b2955e88fd..afb02aae707b 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -241,7 +241,8 @@ drm_atomic_helper_damage_iter_init(struct
drm_atomic_helper_damage_iter *iter,
iter->plane_src.x2 = (src.x2 >> 16) + !!(src.x2 & 0x);
iter->plane_src.y2 = (src.y2 >> 16) + !!(src.y2 & 0x);
- if (!iter->clips || !drm_rect_equals(>src, _state->src)) {
+ if (!iter->clips || state->ignore_damage_clips ||
+ !drm_rect_equals(>src, _state->src)) {
iter->clips = NULL;
iter->num_clips = 0;
iter->full_update = true;
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 79d62856defb..fef775200a81 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -190,6 +190,16 @@ struct drm_plane_state {
*/
struct drm_property_blob *fb_damage_clips;
+ /**
+* @ignore_damage_clips:
+*
+* Set by drivers to indicate the drm_atomic_helper_damage_iter_init()
+* helper that the @fb_damage_clips blob property should be ignored.
+*
+* See :ref:`damage_tracking_properties` for more information.
+*/
+ bool ignore_damage_clips;
+
/**
* @src:
*
--
2.41.0
[PATCH v4 4/5] drm/plane: Extend damage tracking kernel-doc
The "Damage Tracking Properties" section in the documentation doesn't have info about the two type of damage handling: frame damage vs buffer damage. Add it to the section and mention that helpers only support frame damage, and how drivers handling buffer damage can indicate that the damage clips should be ignored. Also add references to further documentation about the two damage types. Suggested-by: Simon Ser Signed-off-by: Javier Martinez Canillas Reviewed-by: Simon Ser Reviewed-by: Thomas Zimmermann Reviewed-by: Zack Rusin Acked-by: Sima Vetter --- Changes in v4: - Add another paragraph to "Damage Tracking Properties" section to mention the fields that drivers with per-buffer upload target should check to set drm_plane_state.ignore_damage_clips (Sima Vetter). Changes in v3: - Fix typo in the kernel-doc (Simon Ser). - Add a paragraph explaining what the problem in the kernel is and make it clear that the refeference documents are related to how user-space handles this case (Thomas Zimmermann). drivers/gpu/drm/drm_plane.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 24e7998d1731..662e0ba2707a 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -1442,6 +1442,36 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, * Drivers implementing damage can use drm_atomic_helper_damage_iter_init() and * drm_atomic_helper_damage_iter_next() helper iterator function to get damage * rectangles clipped to _plane_state.src. + * + * Note that there are two types of damage handling: frame damage and buffer + * damage, the type of damage handling implemented depends on a driver's upload + * target. Drivers implementing a per-plane or per-CRTC upload target need to + * handle frame damage, while drivers implementing a per-buffer upload target + * need to handle buffer damage. + * + * The existing damage helpers only support the frame damage type, there is no + * buffer age support or similar damage accumulation algorithm implemented yet. + * + * Only drivers handling frame damage can use the mentioned damage helpers to + * iterate over the damaged regions. Drivers that handle buffer damage, must set + * _plane_state.ignore_damage_clips for drm_atomic_helper_damage_iter_init() + * to know that damage clips should be ignored and return _plane_state.src + * as the damage rectangle, to force a full plane update. + * + * Drivers with a per-buffer upload target could compare the _plane_state.fb + * of the old and new plane states to determine if the framebuffer attached to a + * plane has changed or not since the last plane update. If _plane_state.fb + * has changed, then _plane_state.ignore_damage_clips must be set to true. + * + * That is because drivers with a per-plane upload target, expect the backing + * storage buffer to not change for a given plane. If the upload buffer changes + * between page flips, the new upload buffer has to be updated as a whole. This + * can be improved in the future if support for frame damage is added to the DRM + * damage helpers, similarly to how user-space already handle this case as it is + * explained in the following documents: + * + * https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_swap_buffers_with_damage.txt + * https://emersion.fr/blog/2019/intro-to-damage-tracking/ */ /** -- 2.41.0
[PATCH v4 3/5] drm/vmwgfx: Disable damage clipping if FB changed since last page-flip
The driver does per-buffer uploads and needs to force a full plane update
if the plane's attached framebuffer has change since the last page-flip.
Suggested-by: Sima Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
Acked-by: Sima Vetter
---
(no changes since v2)
Changes in v2:
- Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's
.atomic_check instead of using a different helpers (Thomas Zimmermann).
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 818b7f109f53..f9364bf222e3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -837,10 +837,21 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane
*plane,
{
struct drm_plane_state *new_state =
drm_atomic_get_new_plane_state(state,
plane);
+ struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(state,
+
plane);
struct drm_crtc_state *crtc_state = NULL;
struct drm_framebuffer *new_fb = new_state->fb;
+ struct drm_framebuffer *old_fb = old_state->fb;
int ret;
+ /*
+* Ignore damage clips if the framebuffer attached to the plane's state
+* has changed since the last plane update (page-flip). In this case, a
+* full plane update should happen because uploads are done per-buffer.
+*/
+ if (old_fb != new_fb)
+ new_state->ignore_damage_clips = true;
+
if (new_state->crtc)
crtc_state = drm_atomic_get_new_crtc_state(state,
new_state->crtc);
--
2.41.0
[PATCH v4 2/5] drm/virtio: Disable damage clipping if FB changed since last page-flip
The driver does per-buffer uploads and needs to force a full plane update
if the plane's attached framebuffer has change since the last page-flip.
Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the
primary plane")
Cc: # v6.4+
Reported-by: nerdopolis
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218115
Suggested-by: Sima Vetter
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Thomas Zimmermann
Reviewed-by: Zack Rusin
Acked-by: Sima Vetter
---
(no changes since v2)
Changes in v2:
- Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's
.atomic_check instead of using a different helpers (Thomas Zimmermann).
drivers/gpu/drm/virtio/virtgpu_plane.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index a2e045f3a000..a1ef657eba07 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -79,6 +79,8 @@ static int virtio_gpu_plane_atomic_check(struct drm_plane
*plane,
{
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
plane);
+ struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(state,
+
plane);
bool is_cursor = plane->type == DRM_PLANE_TYPE_CURSOR;
struct drm_crtc_state *crtc_state;
int ret;
@@ -86,6 +88,14 @@ static int virtio_gpu_plane_atomic_check(struct drm_plane
*plane,
if (!new_plane_state->fb || WARN_ON(!new_plane_state->crtc))
return 0;
+ /*
+* Ignore damage clips if the framebuffer attached to the plane's state
+* has changed since the last plane update (page-flip). In this case, a
+* full plane update should happen because uploads are done per-buffer.
+*/
+ if (old_plane_state->fb != new_plane_state->fb)
+ new_plane_state->ignore_damage_clips = true;
+
crtc_state = drm_atomic_get_crtc_state(state,
new_plane_state->crtc);
if (IS_ERR(crtc_state))
--
2.41.0
[PATCH v4 0/5] drm: Allow the damage helpers to handle buffer damage
Hello,
This series is to fix an issue that surfaced after damage clipping was
enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
fb damage clips property for the primary plane").
After that change, flickering artifacts was reported to be present with
both weston and wlroots wayland compositors when running in a virtual
machine. The cause was identified by Sima Vetter, who pointed out that
virtio-gpu does per-buffer uploads and for this reason it needs to do
a buffer damage handling, instead of frame damage handling.
Their suggestion was to extend the damage helpers to cover that case
and given that there's isn't a buffer damage accumulation algorithm
(e.g: buffer age), just do a full plane update if the framebuffer that
is attached to a plane changed since the last plane update (page-flip).
It is a v4 that addresses issues pointed out by Sima Vetter in v3:
https://lists.freedesktop.org/archives/dri-devel/2023-November/431409.html
Patch #1 adds a ignore_damage_clips field to struct drm_plane_state to be
set by drivers that want the damage helpers to ignore the damage clips.
Patch #2 fixes the virtio-gpu damage handling logic by asking the damage
helper to ignore the damage clips if the framebuffer attached to a plane
has changed since the last page-flip.
Patch #3 does the same but for the vmwgfx driver that also needs to handle
buffer damage and should have the same issue (although I haven't tested it
due not having a VMWare setup).
Patch #4 adds to the KMS damage tracking kernel-doc some paragraphs about
damage tracking types and references to links that explain frame damage vs
buffer damage.
Finally patch #5 adds an item to the DRM todo, about the need to implement
some buffer damage accumulation algorithm instead of just doing full plane
updates in this case.
Because commit 01f05940a9a7 landed in v6.4, the first 2 patches are marked
as Fixes and Cc stable.
I've tested this on a VM with weston, was able to reproduce the issue
reported and the patches did fix the problem.
Best regards,
Javier
Changes in v4:
- Refer in ignore_damage_clips kernel-doc to "Damage Tracking Properties"
KMS documentation section (Sima Vetter).
- Add another paragraph to "Damage Tracking Properties" section to mention
the fields that drivers with per-buffer upload target should check to set
drm_plane_state.ignore_damage_clips (Sima Vetter).
- Reference the _plane_state.ignore_damage_clips and the damage helpers
in the buffer damage TODO entry (Sima Vetter).
Changes in v3:
- Fix typo in the kernel-doc (Simon Ser).
- Add a paragraph explaining what the problem in the kernel is and
make it clear that the refeference documents are related to how
user-space handles this case (Thomas Zimmermann).
Changes in v2:
- Add a struct drm_plane_state .ignore_damage_clips to set in the plane's
.atomic_check, instead of having different helpers (Thomas Zimmermann).
- Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's
.atomic_check instead of using a different helpers (Thomas Zimmermann).
- Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's
.atomic_check instead of using a different helpers (Thomas Zimmermann).
Javier Martinez Canillas (5):
drm: Allow drivers to indicate the damage helpers to ignore damage
clips
drm/virtio: Disable damage clipping if FB changed since last page-flip
drm/vmwgfx: Disable damage clipping if FB changed since last page-flip
drm/plane: Extend damage tracking kernel-doc
drm/todo: Add entry about implementing buffer age for damage tracking
Documentation/gpu/drm-kms.rst | 2 ++
Documentation/gpu/todo.rst | 23
drivers/gpu/drm/drm_damage_helper.c| 3 ++-
drivers/gpu/drm/drm_plane.c| 30 ++
drivers/gpu/drm/virtio/virtgpu_plane.c | 10 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 11 ++
include/drm/drm_plane.h| 10 +
7 files changed, 88 insertions(+), 1 deletion(-)
--
2.41.0
Re: [PATCH v6 0/9] Fix cursor planes with virtualized drivers
On Wednesday, November 22nd, 2023 at 13:49, Javier Martinez Canillas wrote: > Any objections to merge the series ? No objections from me :)
Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support
On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote: > After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in > olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. > Class-based device auto-detection is a legacy mechanism and shouldn't > be used in new code. So we can remove this class completely now. > > Preferably this series should be applied via the i2c tree. > > v2: > - change tag in commit subject of patch 03 > - add ack tags > v3: > - fix a compile error in patch 5 > v4: > - more ack and review tags > v5: > - more acks > > Signed-off-by: Heiner Kallweit I created an immutable branch for this which the buildbots will hopefully check over night. I will reply with comments tomorrow when I got the buildbot results. signature.asc Description: PGP signature
Re: [PATCH v2 0/4] eventfd: simplify signal helpers
On 11/22/23 5:48 AM, Christian Brauner wrote: > Hey everyone, > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers > significantly. They can be made void and not take any unnecessary > arguments. > > I've added a few more simplifications based on Sean's suggestion. > > Signed-off-by: Christian Brauner > > Changes in v2: > - further simplify helpers > - Link to v1: > https://lore.kernel.org/r/20230713-vfs-eventfd-signal-v1-0-7fda6c5d2...@kernel.org Only oddity I spotted was the kerneldoc, which someone else already brought up. Reviewed-by: Jens Axboe -- Jens Axboe
Re: [PULL] drm-misc-next
On Thu, Nov 23, 2023 at 01:58:50PM +0100, Maxime Ripard wrote: > Hi, > > Here's this week drm-misc-next PR. > > It's been fairly calm, but there's one big change: the IMG GPU driver is > now merged! > > Maxime > > drm-misc-next-2023-11-23: > drm-misc-next for 6.8: > > UAPI Changes: > > Cross-subsystem Changes: > > Core Changes: > - Drop deprecated drm_kms_helper.edid_firmware module parameter > > Driver Changes: > - Convert platform drivers remove callback to return void > - imagination: Introduction of the Imagination GPU Support > - rockchip: > - rk3066_hdmi: Convert to atomic > - vop2: Support NV20 and NV30 > - panel: > - elida-kd35t133: PM reworks > - New panels: Powkiddy RK2023 > The following changes since commit 3b434a3445fff3149128db0169da864d67057325: > > accel/ivpu: Use threaded IRQ to handle JOB done messages (2023-11-16 > 13:41:49 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-11-23 Merged to drm-next, thanks. -Sima > > for you to fetch changes up to 815d8b0425ad1164e45953ac3d56a9f6f63792cc: > > drm/imagination: Add driver documentation (2023-11-23 09:01:47 +0100) > > > drm-misc-next for 6.8: > > UAPI Changes: > > Cross-subsystem Changes: > > Core Changes: > - Drop deprecated drm_kms_helper.edid_firmware module parameter > > Driver Changes: > - Convert platform drivers remove callback to return void > - imagination: Introduction of the Imagination GPU Support > - rockchip: > - rk3066_hdmi: Convert to atomic > - vop2: Support NV20 and NV30 > - panel: > - elida-kd35t133: PM reworks > - New panels: Powkiddy RK2023 > > > Abhinav Singh (1): > drm/nouveau/fence:: fix warning directly dereferencing a rcu pointer > > Arnd Bergmann (1): > drm/rockchip: rk3066_hdmi: include drm/drm_atomic.h > > Chris Morgan (8): > dt-bindings: display: nv3051d: Update NewVision NV3051D compatibles > drm/panel: nv3051d: Hold panel in reset for unprepare > drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support > drm/panel-elida-kd35t133: trival: update panel size from 5.5 to 3.5 > drm/panel-elida-kd35t133: hold panel in reset for unprepare > drm/panel-elida-kd35t133: drop drm_connector_set_orientation_from_panel > drm/panel-elida-kd35t133: Drop shutdown logic > drm/panel-elida-kd35t133: Drop prepare/unprepare logic > > Donald Robson (2): > drm/gpuvm: Helper to get range of unmap from a remap op. > drm/imagination: Add GEM and VM related code > > Jani Nikula (1): > drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compat > > Jeffrey Hugo (1): > accel/qaic: Update MAX_ORDER use to be inclusive > > Johan Jonker (2): > drm/rockchip: rk3066_hdmi: Remove useless mode_fixup > drm/rockchip: rk3066_hdmi: Switch encoder hooks to atomic > > Jonas Karlman (1): > drm/rockchip: vop2: Add NV20 and NV30 support > > Kees Cook (1): > dma-buf: Replace strlcpy() with strscpy() > > Luben Tuikov (1): > drm/print: Handle NULL drm device in __drm_printk() > > Matt Coster (1): > sizes.h: Add entries between SZ_32G and SZ_64T > > Richard Acayan (1): > fbdev/simplefb: Suppress error on missing power domains > > Sarah Walker (17): > dt-bindings: gpu: Add Imagination Technologies PowerVR/IMG GPU > drm/imagination/uapi: Add PowerVR driver UAPI > drm/imagination: Add skeleton PowerVR driver > drm/imagination: Get GPU resources > drm/imagination: Add GPU register headers > drm/imagination: Add firmware and MMU related headers > drm/imagination: Add FWIF headers > drm/imagination: Add GPU ID parsing and firmware loading > drm/imagination: Implement power management > drm/imagination: Implement firmware infrastructure and META FW support > drm/imagination: Implement MIPS firmware processor and MMU support > drm/imagination: Implement free list and HWRT create and destroy ioctls > drm/imagination: Implement context creation/destruction ioctls > drm/imagination: Implement job submission and scheduling > drm/imagination: Add firmware trace header > drm/imagination: Add firmware trace to debugfs > drm/imagination: Add driver documentation > > Tomi Valkeinen (1): > drm/tilcdc: Fix irq free on unload > > Uwe Kleine-König (14): > drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function > drm/arcpgu: Convert to platform remove callback returning void > drm/armada: Convert to platform remove callback returning void > drm/bridge: cdns-mhdp8546: Improve error reporting in remove callback > drm/bridge: cdns-mhdp8546: Convert to platform remove callback > returning void > drm/bridge:
Re: [PULL] drm-intel-next
On Thu, Nov 23, 2023 at 09:03:59PM +0200, Jani Nikula wrote: > > Hi Dave & Sima - > > The first i915 feature pull towards v6.8. > > The one thing to single out are the major DP MST, UHBR, and DSC > bandwidth management improvements from Imre. > > Alas, they also need to be singled out because there are a number of > updates in drm core and other drivers merged via drm-intel-next that > will conflict with drm-next. Nothing that wasn't acked or discussed > before, but maybe this time we erred a bit on the side of too much. > > BR, > Jani. > > > drm-intel-next-2023-11-23: > drm/i915 feature pull for v6.8: > > Features and functionality: > - Major DP MST improvements on bandwidth management, DSC (Imre, Stan, Ville) > - DP panel replay enabling (Animesh, Jouni) > - MTL C20 phy state verification (Mika) > - MTL DP DSC fractional bpp support (Ankit, Vandita, Swati, Imre) > - Audio fastset support (Ville) > > Refactoring and cleanups: > - Use dma fence interfaces instead of i915_sw_fence (Jouni) > - Separate gem and display code (Jouni, Juha-Pekka) > - AUX register macro refactoring (Jani) > - Separate display module/device parameters from the rest (Jouni) > - Move display capabilities debugfs under display (Vinod) > - Makefile cleanup (Jani) > - Register cleanups (Ville) > - Enginer iterator cleanups (Tvrtko) > - Move display lock inits under display/ (Jani) > - VLV/CHV DPIO PHY register and interface refactoring (Jani) > - DSI VBT sequence refactoring (Jani, Andy Shevchenko) > - C10/C20 PHY PLL hardware readout and calculation abstractions (Lucas) > - DPLL code cleanups (Ville) > - Cleanup PXP plane protection checks (Jani) > > Fixes: > - Replace VLV/CHV DSI GPIO direct access with proper GPIO API usage (Andy > Shevchenko) > - Fix VLV/CHV DSI GPIO wrong initial value (Hans de Goede) > - Fix UHBR data, link M/N/TU and PBN values (Imre) > - Fix HDCP state on an enable/disable cycle (Suraj) > - Fix DP MST modeset sequence to be according to spec (Ville) > - Improved atomicity for multi-pipe commits (Ville) > - Update URLs in i915 MAINTAINERS entry and code (Jani) > - Check for VGA converter presence in eDP probe (Ville) > - Fix surface size checks (Ville) > - Fix LNL port/phy assignment (Lucas) > - Reset C10/C20 message bus harder to avoid sporadic failures (Mika) > - Fix bogus VBT HDMI level shift on BDW (Ville) > - Add workaround for LNL underruns when enabling FBC (Vinod) > - DSB refactoring (Animesh) > - DPT refactoring (Juha-Pekka) > - Disable DSC on DP MST on ICL (Imre) > - Fix PSR VSC packet setup timing (Mika) > - Fix LUT rounding and conversions (Ville) > > DRM core display changes: > - DP MST fixes, helpers, refactoring to support bandwidth management (Imre) > - DP MST PBN divider value refactoring and fixes (Imre) > - DPCD register definitions (Ankit, Imre) > - Add helper to get DSC bpp precision (Ankit) > - Fix color LUT rounding (Ville) > > BR, > Jani. > > The following changes since commit 213c43676beb5f5a63cb27a0c8e8e71035b08445: > > drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake > (2023-10-18 06:23:41 +0200) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-11-23 Merged to drm-next, thanks. -Sima > > for you to fetch changes up to deac453244d309ad7a94d0501eb5e0f9d8d1f1df: > > drm/i915: Fix glk+ degamma LUT conversions (2023-11-23 15:11:47 +0200) > > > drm/i915 feature pull for v6.8: > > Features and functionality: > - Major DP MST improvements on bandwidth management, DSC (Imre, Stan, Ville) > - DP panel replay enabling (Animesh, Jouni) > - MTL C20 phy state verification (Mika) > - MTL DP DSC fractional bpp support (Ankit, Vandita, Swati, Imre) > - Audio fastset support (Ville) > > Refactoring and cleanups: > - Use dma fence interfaces instead of i915_sw_fence (Jouni) > - Separate gem and display code (Jouni, Juha-Pekka) > - AUX register macro refactoring (Jani) > - Separate display module/device parameters from the rest (Jouni) > - Move display capabilities debugfs under display (Vinod) > - Makefile cleanup (Jani) > - Register cleanups (Ville) > - Enginer iterator cleanups (Tvrtko) > - Move display lock inits under display/ (Jani) > - VLV/CHV DPIO PHY register and interface refactoring (Jani) > - DSI VBT sequence refactoring (Jani, Andy Shevchenko) > - C10/C20 PHY PLL hardware readout and calculation abstractions (Lucas) > - DPLL code cleanups (Ville) > - Cleanup PXP plane protection checks (Jani) > > Fixes: > - Replace VLV/CHV DSI GPIO direct access with proper GPIO API usage (Andy > Shevchenko) > - Fix VLV/CHV DSI GPIO wrong initial value (Hans de Goede) > - Fix UHBR data, link M/N/TU and PBN values (Imre) > - Fix HDCP state on an enable/disable cycle (Suraj) > - Fix DP MST modeset sequence to be according to spec (Ville) > - Improved atomicity for multi-pipe commits (Ville) > - Update URLs in i915 MAINTAINERS
Re: [PATCH 1/3] Revert "drm/prime: Unexport helpers for fd/handle conversion"
[+Alex]
On 2023-11-17 16:44, Felix Kuehling wrote:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated with
GEM objects while ensuring that move notifier callbacks are working as
intended.
CC: Christian König
CC: Thomas Zimmermann
Signed-off-by: Felix Kuehling
Re: our discussion about v2 of this patch: If this version is
acceptable, can I get an R-b or A-b?
I would like to get this patch into drm-next as a prerequisite for
patches 2 and 3. I cannot submit it to the current amd-staging-drm-next
because the patch I'm reverting doesn't exist there yet.
Patch 2 and 3 could go into drm-next as well, or go through Alex's
amd-staging-drm-next branch once patch 1 is in drm-next. Alex, how do
you prefer to coordinate this?
Regards,
Felix
---
drivers/gpu/drm/drm_prime.c | 33 ++---
include/drm/drm_prime.h | 7 +++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 63b709a67471..834a5e28abbe 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -278,7 +278,7 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
}
EXPORT_SYMBOL(drm_gem_dmabuf_release);
-/*
+/**
* drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
* @dev: drm_device to import into
* @file_priv: drm file-private structure
@@ -292,9 +292,9 @@ EXPORT_SYMBOL(drm_gem_dmabuf_release);
*
* Returns 0 on success or a negative error code on failure.
*/
-static int drm_gem_prime_fd_to_handle(struct drm_device *dev,
- struct drm_file *file_priv, int prime_fd,
- uint32_t *handle)
+int drm_gem_prime_fd_to_handle(struct drm_device *dev,
+ struct drm_file *file_priv, int prime_fd,
+ uint32_t *handle)
{
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
@@ -360,6 +360,7 @@ static int drm_gem_prime_fd_to_handle(struct drm_device
*dev,
dma_buf_put(dma_buf);
return ret;
}
+EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -408,7 +409,7 @@ static struct dma_buf *export_and_register_object(struct
drm_device *dev,
return dmabuf;
}
-/*
+/**
* drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
* @dev: dev to export the buffer from
* @file_priv: drm file-private structure
@@ -421,10 +422,10 @@ static struct dma_buf *export_and_register_object(struct
drm_device *dev,
* The actual exporting from GEM object to a dma-buf is done through the
* _gem_object_funcs.export callback.
*/
-static int drm_gem_prime_handle_to_fd(struct drm_device *dev,
- struct drm_file *file_priv, uint32_t
handle,
- uint32_t flags,
- int *prime_fd)
+int drm_gem_prime_handle_to_fd(struct drm_device *dev,
+ struct drm_file *file_priv, uint32_t handle,
+ uint32_t flags,
+ int *prime_fd)
{
struct drm_gem_object *obj;
int ret = 0;
@@ -506,6 +507,7 @@ static int drm_gem_prime_handle_to_fd(struct drm_device
*dev,
return ret;
}
+EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -864,9 +866,9 @@ EXPORT_SYMBOL(drm_prime_get_contiguous_size);
* @obj: GEM object to export
* @flags: flags like DRM_CLOEXEC and DRM_RDWR
*
- * This is the implementation of the _gem_object_funcs.export functions
- * for GEM drivers using the PRIME helpers. It is used as the default for
- * drivers that do not set their own.
+ * This is the implementation of the _gem_object_funcs.export functions
for GEM drivers
+ * using the PRIME helpers. It is used as the default in
+ * drm_gem_prime_handle_to_fd().
*/
struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
int flags)
@@ -962,9 +964,10 @@ EXPORT_SYMBOL(drm_gem_prime_import_dev);
* @dev: drm_device to import into
* @dma_buf: dma-buf object to import
*
- * This is the implementation of the gem_prime_import functions for GEM
- * drivers using the PRIME helpers. It is the default for drivers that do
- * not set their own _driver.gem_prime_import.
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers. Drivers can use this as their
+ * _driver.gem_prime_import implementation. It is used as the default
+ * implementation
[PULL] drm-intel-next
Hi Dave & Sima - The first i915 feature pull towards v6.8. The one thing to single out are the major DP MST, UHBR, and DSC bandwidth management improvements from Imre. Alas, they also need to be singled out because there are a number of updates in drm core and other drivers merged via drm-intel-next that will conflict with drm-next. Nothing that wasn't acked or discussed before, but maybe this time we erred a bit on the side of too much. BR, Jani. drm-intel-next-2023-11-23: drm/i915 feature pull for v6.8: Features and functionality: - Major DP MST improvements on bandwidth management, DSC (Imre, Stan, Ville) - DP panel replay enabling (Animesh, Jouni) - MTL C20 phy state verification (Mika) - MTL DP DSC fractional bpp support (Ankit, Vandita, Swati, Imre) - Audio fastset support (Ville) Refactoring and cleanups: - Use dma fence interfaces instead of i915_sw_fence (Jouni) - Separate gem and display code (Jouni, Juha-Pekka) - AUX register macro refactoring (Jani) - Separate display module/device parameters from the rest (Jouni) - Move display capabilities debugfs under display (Vinod) - Makefile cleanup (Jani) - Register cleanups (Ville) - Enginer iterator cleanups (Tvrtko) - Move display lock inits under display/ (Jani) - VLV/CHV DPIO PHY register and interface refactoring (Jani) - DSI VBT sequence refactoring (Jani, Andy Shevchenko) - C10/C20 PHY PLL hardware readout and calculation abstractions (Lucas) - DPLL code cleanups (Ville) - Cleanup PXP plane protection checks (Jani) Fixes: - Replace VLV/CHV DSI GPIO direct access with proper GPIO API usage (Andy Shevchenko) - Fix VLV/CHV DSI GPIO wrong initial value (Hans de Goede) - Fix UHBR data, link M/N/TU and PBN values (Imre) - Fix HDCP state on an enable/disable cycle (Suraj) - Fix DP MST modeset sequence to be according to spec (Ville) - Improved atomicity for multi-pipe commits (Ville) - Update URLs in i915 MAINTAINERS entry and code (Jani) - Check for VGA converter presence in eDP probe (Ville) - Fix surface size checks (Ville) - Fix LNL port/phy assignment (Lucas) - Reset C10/C20 message bus harder to avoid sporadic failures (Mika) - Fix bogus VBT HDMI level shift on BDW (Ville) - Add workaround for LNL underruns when enabling FBC (Vinod) - DSB refactoring (Animesh) - DPT refactoring (Juha-Pekka) - Disable DSC on DP MST on ICL (Imre) - Fix PSR VSC packet setup timing (Mika) - Fix LUT rounding and conversions (Ville) DRM core display changes: - DP MST fixes, helpers, refactoring to support bandwidth management (Imre) - DP MST PBN divider value refactoring and fixes (Imre) - DPCD register definitions (Ankit, Imre) - Add helper to get DSC bpp precision (Ankit) - Fix color LUT rounding (Ville) BR, Jani. The following changes since commit 213c43676beb5f5a63cb27a0c8e8e71035b08445: drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake (2023-10-18 06:23:41 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-11-23 for you to fetch changes up to deac453244d309ad7a94d0501eb5e0f9d8d1f1df: drm/i915: Fix glk+ degamma LUT conversions (2023-11-23 15:11:47 +0200) drm/i915 feature pull for v6.8: Features and functionality: - Major DP MST improvements on bandwidth management, DSC (Imre, Stan, Ville) - DP panel replay enabling (Animesh, Jouni) - MTL C20 phy state verification (Mika) - MTL DP DSC fractional bpp support (Ankit, Vandita, Swati, Imre) - Audio fastset support (Ville) Refactoring and cleanups: - Use dma fence interfaces instead of i915_sw_fence (Jouni) - Separate gem and display code (Jouni, Juha-Pekka) - AUX register macro refactoring (Jani) - Separate display module/device parameters from the rest (Jouni) - Move display capabilities debugfs under display (Vinod) - Makefile cleanup (Jani) - Register cleanups (Ville) - Enginer iterator cleanups (Tvrtko) - Move display lock inits under display/ (Jani) - VLV/CHV DPIO PHY register and interface refactoring (Jani) - DSI VBT sequence refactoring (Jani, Andy Shevchenko) - C10/C20 PHY PLL hardware readout and calculation abstractions (Lucas) - DPLL code cleanups (Ville) - Cleanup PXP plane protection checks (Jani) Fixes: - Replace VLV/CHV DSI GPIO direct access with proper GPIO API usage (Andy Shevchenko) - Fix VLV/CHV DSI GPIO wrong initial value (Hans de Goede) - Fix UHBR data, link M/N/TU and PBN values (Imre) - Fix HDCP state on an enable/disable cycle (Suraj) - Fix DP MST modeset sequence to be according to spec (Ville) - Improved atomicity for multi-pipe commits (Ville) - Update URLs in i915 MAINTAINERS entry and code (Jani) - Check for VGA converter presence in eDP probe (Ville) - Fix surface size checks (Ville) - Fix LNL port/phy assignment (Lucas) - Reset C10/C20 message bus harder to avoid sporadic failures (Mika) - Fix bogus VBT HDMI level shift on BDW (Ville) - Add workaround for LNL underruns when enabling FBC (Vinod) - DSB
Re: [PATCH 2/3] dt-bindings: ili9881c: Add Ampire AM8001280G LCD panel
On Thu, Nov 23, 2023 at 06:08:05PM +0100, Philipp Zabel wrote: > Document the compatible value for Ampire AM8001280G LCD panels. > > Signed-off-by: Philipp Zabel Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > index e7ab6224b52e..b1e624be3e33 100644 > --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml > @@ -16,6 +16,7 @@ properties: >compatible: > items: >- enum: > + - ampire,am8001280g >- bananapi,lhr050h41 >- feixin,k101-im2byl02 >- tdo,tl050hdv35 > > -- > 2.39.2 > signature.asc Description: PGP signature
[PATCH 3/3] drm/bridge: ti-sn65dsi86: Loosen coupling of PWM to ti-sn65dsi86 core
Introduce a dedicated private data structure for the pwm aux driver
provided by the sn65dsi86 driver. This way data needed for PWM operation
is (to a certain degree) nicely separated and doesn't occupy memory in
the ti_sn65dsi86 core's private data if the PWM isn't used.
The eventual goal is to decouple the PWM driver completely from the
ti-sn65dsi86 core and maybe even move it to a dedicated driver below
drivers/pwm. There are a few obstacles to that quest though:
- The busy pin check (implemented in ti_sn_pwm_pin_request() and
ti_sn_pwm_pin_release()) would need to be available unconditionally.
- The refclk should probably abstracted by a struct clk such that the
pwm_refclk_freq member that currently still lives in ti-sn65dsi86
core driver data can be dropped.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 130 +++---
1 file changed, 76 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index d6e3b1280e38..2f030998cb09 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -163,9 +163,6 @@
*bitmap so we can do atomic ops on it without an extra
*lock so concurrent users of our 4 GPIOs don't stomp on
*each other's read-modify-write.
- *
- * @pchip:pwm_chip if the PWM is exposed.
- * @pwm_enabled: Used to track if the PWM signal is currently enabled.
* @pwm_pin_busy: Track if GPIO4 is currently requested for GPIO or PWM.
* @pwm_refclk_freq: Cache for the reference clock input to the PWM.
*/
@@ -197,13 +194,25 @@ struct ti_sn65dsi86 {
DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
#endif
#if defined(CONFIG_PWM)
- struct pwm_chip pchip;
- boolpwm_enabled;
atomic_tpwm_pin_busy;
#endif
unsigned intpwm_refclk_freq;
};
+/*
+ * struct ti_sn65dsi86_pwm_ddata - Platform data for ti-sn65dsi86 pwm driver.
+ * @chip: pwm_chip if the PWM is exposed.
+ * @pwm_enabled: Used to track if the PWM signal is currently enabled.
+ * @regmap: Regmap for accessing i2c.
+ * @pdata: platform data of the parent device
+ */
+struct ti_sn65dsi86_pwm_ddata {
+ struct pwm_chip chip;
+ boolpwm_enabled;
+ struct regmap *regmap;
+ unsigned int*pwm_refclk_freq;
+};
+
static const struct regmap_range ti_sn65dsi86_volatile_ranges[] = {
{ .range_min = 0, .range_max = 0xFF },
};
@@ -1360,33 +1369,37 @@ static struct auxiliary_driver ti_sn_bridge_driver = {
* PWM Controller
*/
#if defined(CONFIG_PWM)
-static int ti_sn_pwm_pin_request(struct ti_sn65dsi86 *pdata)
+static int ti_sn_pwm_pin_request(struct device *dev)
{
+ struct ti_sn65dsi86 *pdata = dev_get_drvdata(dev);
+
return atomic_xchg(>pwm_pin_busy, 1) ? -EBUSY : 0;
}
-static void ti_sn_pwm_pin_release(struct ti_sn65dsi86 *pdata)
+static void ti_sn_pwm_pin_release(struct device *dev)
{
+ struct ti_sn65dsi86 *pdata = dev_get_drvdata(dev);
+
atomic_set(>pwm_pin_busy, 0);
}
-static struct ti_sn65dsi86 *pwm_chip_to_ti_sn_bridge(struct pwm_chip *chip)
+static struct ti_sn65dsi86_pwm_ddata *pwm_chip_to_ddata(struct pwm_chip *chip)
{
- return container_of(chip, struct ti_sn65dsi86, pchip);
+ return container_of(chip, struct ti_sn65dsi86_pwm_ddata, chip);
}
static int ti_sn_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
+ struct ti_sn65dsi86_pwm_ddata *ddata = pwm_chip_to_ddata(chip);
- return ti_sn_pwm_pin_request(pdata);
+ return ti_sn_pwm_pin_request(ddata->chip.dev);
}
static void ti_sn_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
{
- struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
+ struct ti_sn65dsi86_pwm_ddata *ddata = pwm_chip_to_ddata(chip);
- ti_sn_pwm_pin_release(pdata);
+ ti_sn_pwm_pin_release(ddata->chip.dev);
}
/*
@@ -1403,7 +1416,7 @@ static void ti_sn_pwm_free(struct pwm_chip *chip, struct
pwm_device *pwm)
static int ti_sn_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
- struct ti_sn65dsi86 *pdata = pwm_chip_to_ti_sn_bridge(chip);
+ struct ti_sn65dsi86_pwm_ddata *ddata = pwm_chip_to_ddata(chip);
unsigned int pwm_en_inv;
unsigned int backlight;
unsigned int pre_div;
@@ -1412,24 +1425,24 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip,
struct pwm_device *pwm,
u64 period;
int ret;
- if (!pdata->pwm_enabled) {
- ret = pm_runtime_resume_and_get(pdata->dev);
+ if (!ddata->pwm_enabled) {
+ ret =
[PATCH 2/3] drm/bridge: ti-sn65dsi86: Change parameters of ti_sn65dsi86_{read, write}_u16
This aligns the function's parameters to regmap_{read,write} and
simplifies the next change that takes pwm driver data out of struct
ti_sn65dsi86.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 5b8e1dfc458d..d6e3b1280e38 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -221,13 +221,13 @@ static const struct regmap_config
ti_sn65dsi86_regmap_config = {
.max_register = 0xFF,
};
-static int __maybe_unused ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
+static int __maybe_unused ti_sn65dsi86_read_u16(struct regmap *regmap,
unsigned int reg, u16 *val)
{
u8 buf[2];
int ret;
- ret = regmap_bulk_read(pdata->regmap, reg, buf, ARRAY_SIZE(buf));
+ ret = regmap_bulk_read(regmap, reg, buf, ARRAY_SIZE(buf));
if (ret)
return ret;
@@ -236,12 +236,12 @@ static int __maybe_unused ti_sn65dsi86_read_u16(struct
ti_sn65dsi86 *pdata,
return 0;
}
-static void ti_sn65dsi86_write_u16(struct ti_sn65dsi86 *pdata,
+static void ti_sn65dsi86_write_u16(struct regmap *regmap,
unsigned int reg, u16 val)
{
u8 buf[2] = { val & 0xff, val >> 8 };
- regmap_bulk_write(pdata->regmap, reg, buf, ARRAY_SIZE(buf));
+ regmap_bulk_write(regmap, reg, buf, ARRAY_SIZE(buf));
}
static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn65dsi86 *pdata)
@@ -968,9 +968,9 @@ static void ti_sn_bridge_set_video_timings(struct
ti_sn65dsi86 *pdata)
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
vsync_polarity = CHA_VSYNC_POLARITY;
- ti_sn65dsi86_write_u16(pdata, SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG,
+ ti_sn65dsi86_write_u16(pdata->regmap, SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG,
mode->hdisplay);
- ti_sn65dsi86_write_u16(pdata, SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG,
+ ti_sn65dsi86_write_u16(pdata->regmap,
SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG,
mode->vdisplay);
regmap_write(pdata->regmap, SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG,
(mode->hsync_end - mode->hsync_start) & 0xFF);
@@ -1509,8 +1509,8 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
goto out;
}
- ti_sn65dsi86_write_u16(pdata, SN_BACKLIGHT_SCALE_REG, scale);
- ti_sn65dsi86_write_u16(pdata, SN_BACKLIGHT_REG, backlight);
+ ti_sn65dsi86_write_u16(pdata->regmap, SN_BACKLIGHT_SCALE_REG,
scale);
+ ti_sn65dsi86_write_u16(pdata->regmap, SN_BACKLIGHT_REG,
backlight);
}
pwm_en_inv = FIELD_PREP(SN_PWM_EN_MASK, state->enabled) |
@@ -1544,11 +1544,11 @@ static int ti_sn_pwm_get_state(struct pwm_chip *chip,
struct pwm_device *pwm,
if (ret)
return ret;
- ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_SCALE_REG, );
+ ret = ti_sn65dsi86_read_u16(pdata->regmap, SN_BACKLIGHT_SCALE_REG,
);
if (ret)
return ret;
- ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_REG, );
+ ret = ti_sn65dsi86_read_u16(pdata->regmap, SN_BACKLIGHT_REG,
);
if (ret)
return ret;
--
2.42.0
[PATCH 0/3] drm/bridge: ti-sn65dsi86: Some updates
Hello,
this is a series I created while starring at the ti-sn65dsi86 driver in
the context of my pwm-lifetime series.
The first patch should be fine. The last one has a few rough edges, but
maybe you like the direction this is going to? The 2nd patch probably
only makes sense if you also take the third.
Best regards
Uwe
Uwe Kleine-König (3):
drm/bridge: ti-sn65dsi86: Simplify using pm_runtime_resume_and_get()
drm/bridge: ti-sn65dsi86: Change parameters of
ti_sn65dsi86_{read,write}_u16
drm/bridge: ti-sn65dsi86: Loosen coupling of PWM to ti-sn65dsi86 core
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 146 +++---
1 file changed, 83 insertions(+), 63 deletions(-)
base-commit: 4e87148f80d198ba5febcbcc969c6b9471099a09
--
2.42.0
[PATCH 1/3] drm/bridge: ti-sn65dsi86: Simplify using pm_runtime_resume_and_get()
pm_runtime_resume_and_get() already drops the runtime PM usage counter
in the error case. So a call to pm_runtime_put_sync() can be dropped.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index c45c07840f64..5b8e1dfc458d 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1413,11 +1413,9 @@ static int ti_sn_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
int ret;
if (!pdata->pwm_enabled) {
- ret = pm_runtime_get_sync(pdata->dev);
- if (ret < 0) {
- pm_runtime_put_sync(pdata->dev);
+ ret = pm_runtime_resume_and_get(pdata->dev);
+ if (ret < 0)
return ret;
- }
}
if (state->enabled) {
--
2.42.0
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: I'm agree with the idea that drm bridges drivers involved toward to a direction that support more complex design, but I think we should also leave a way for the most frequent use case. Make it straight-forward as a canonical design. Not having anything connector-related in the drm_bridge driver is a canonical design. What you said is just for the more complex uses case. I can't agree, sorry. By choosing the word "canonical design", I means that the most frequently used cases in practice are the canonical design, 95+% motherboards I have seen has only one *onboard* display bridges chip. For my driver, I abstract the internal (inside of the chip) encoder as drm_encoder and abstract the external TX chip as drm_bridge, this design still works very well. Originally, I means that this is a concept of the hardware design. You are wrong even through in the software design context, the transparent simple drm bridge drivers(simple-bridge.c) also *allow* to create drm connector manually. I don't think I need to emulate more example, please read the code by youself. Canonical or not canonical is not a question to argue, if other programmers are allowed to do such kind of abstraction, I should also allowed too. Thanks.
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
On Thu, 23 Nov 2023 at 19:04, Sui Jingfeng wrote: > > Hi, > > > On 2023/11/23 16:08, Dmitry Baryshkov wrote: > >>> The host can not specify the > >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, it will cause a warning here. And > >>> it can not omit the flag (as otherwise the first bridge will create a > >>> connector, without consulting the second bridge). > >> The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flagare implement-defined, > > No, they are not. Semantics are pretty simple: do not create the > > drm_connector instance. Pass the flag to the next bridge in the chain. > > > >> for our case, I could just ignore it if their > >> don't have a signal(DT or ACPI) tell me that there are multiple bridges > >> in the chain. This depend on community's attitude. > > Ignoring a flag is a bad idea. > > > Can you also read the code in the bridge/lontium-lt8912.c please? > when flags == 0 is true, the lt8912 driver will just create > a drm_connector instance in the drm bridge drivers. The behavior > is similar with this patch in the perspective of spirit. > > And the most important thing is that no matter what the flag the upstream > port is passed, lt8912 just always pass the DRM_BRIDGE_ATTACH_NO_CONNECTOR > flags to the next bridge. Does this count as a kind of ignore? or > > This is to say that both the lt8912 and the tfp410 drm bridge drivers are > allowing create a drm_connector manually in drm bridge drivers. They didn't > being asked to move the drm_connector related code to display controller > driver. I don't know why I can't follow this way? This is called 'legacy'. > > Do you really read the code before do comments or I failed to understand > something? -- With best wishes Dmitry
Re: [PATCH v4 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
Hi Lucas, On Thu, Sep 28, 2023 at 9:56 AM Lucas Stach wrote: > > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a > full timing generator and can switch between different video sources. On > the i.MX8MP however the only supported source is the LCDIF. The block > just needs to be powered up and told about the polarity of the video > sync signals to act in bypass mode. > > Signed-off-by: Lucas Stach > Reviewed-by: Luca Ceresoli (v2) > Tested-by: Marek Vasut (v1) > Tested-by: Luca Ceresoli (v2) > Tested-by: Richard Leitner (v2) > Tested-by: Frieder Schrempf (v2) > Reviewed-by: Laurent Pinchart (v3) Tested-by: Fabio Estevam Could someone apply this series, please?
Re: [PATCH 0/4] drm/i915: Fix LUT rounding
On Tue, Nov 21, 2023 at 11:51:10AM +0100, Maxime Ripard wrote: > On Mon, Nov 20, 2023 at 04:30:53PM +0200, Ville Syrjälä wrote: > > On Fri, Oct 13, 2023 at 04:13:58PM +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > The current LUT rounding is generating weird results. Adjust > > > it to follow the OpenGL int<->float conversion rules. > > > > > > Ville Syrjälä (4): > > > drm: Fix color LUT rounding > > ^ > > I'd like to merge this via drm-intel-next as needs to match > > the rounding done in the readout path in i915. > > > > Maarten,Maxime,Thomas can I get an ack for that? > > Acked-by: Maxime Ripard Thanks. Series pushed to drm-intel-next. -- Ville Syrjälä Intel
Re: [PATCH 1/2] dt-bindings: display: simple: add Evervision VGG644804 panel
On Thu, Nov 23, 2023 at 11:24:03AM +0100, Michael Walle wrote: > Add Evervision VGG644804 5.7" 640x480 LVDS panel compatible string. > > Signed-off-by: Michael Walle Acked-by: Conor Dooley Cheers, Conor. > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 3ec9ee95045f..2471c99a0c96 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -144,6 +144,8 @@ properties: >- edt,etmv570g2dhu > # E Ink VB3300-KCA >- eink,vb3300-kca > +# Evervision Electronics Co. Ltd. VGG644804 5.7" VGA TFT LCD Panel > + - evervision,vgg644804 > # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel >- evervision,vgg804821 > # Foxlink Group 5" WVGA TFT LCD panel > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [PATCH 2/4] dt-bindings: phy: add compatible for Mediatek MT8195
On Thu, Nov 23, 2023 at 02:37:47PM +0100, Michael Walle wrote: > Add the compatible string for MediaTek MT8195 SoC, using the same MIPI > D-PHY block as the MT8183. > > Signed-off-by: Michael Walle Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
Re: [PATCH 1/4] dt-bindings: display: mediatek: dsi: add compatible for MediaTek MT8195
On Thu, Nov 23, 2023 at 02:37:46PM +0100, Michael Walle wrote: > Add the compatible string for MediaTek MT8195 SoC, using the same DSI > block as the MT8183. > > Signed-off-by: Michael Walle Acked-by: Conor Dooley signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: display: mediatek: dsi: remove Xinlei's mail
On Thu, Nov 23, 2023 at 02:49:27PM +0100, Michael Walle wrote: > Xinlei Lee's mail is bouncing: > > : host mailgw02.mediatek.com[216.200.240.185] said: > 550 Relaying mail to xinlei@mediatek.com is not allowed (in reply to > RCPT TO command) Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature
[PATCH 2/3] dt-bindings: ili9881c: Add Ampire AM8001280G LCD panel
Document the compatible value for Ampire AM8001280G LCD panels. Signed-off-by: Philipp Zabel --- Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index e7ab6224b52e..b1e624be3e33 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -16,6 +16,7 @@ properties: compatible: items: - enum: + - ampire,am8001280g - bananapi,lhr050h41 - feixin,k101-im2byl02 - tdo,tl050hdv35 -- 2.39.2
[PATCH 3/3] drm/panel: ilitek-ili9881c: Add Ampire AM8001280G LCD panel
Add support for Ampire AM8001280G LCD panels.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 223 ++
1 file changed, 223 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 0c911ed9141b..2ffe5f68a890 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -830,6 +830,203 @@ static const struct ili9881c_instr w552946ab_init[] = {
ILI9881C_SWITCH_PAGE_INSTR(0),
};
+static const struct ili9881c_instr am8001280g_init[] = {
+ ILI9881C_SWITCH_PAGE_INSTR(3),
+ ILI9881C_COMMAND_INSTR(0x01, 0x00),
+ ILI9881C_COMMAND_INSTR(0x02, 0x00),
+ ILI9881C_COMMAND_INSTR(0x03, 0x73),
+ ILI9881C_COMMAND_INSTR(0x04, 0xD3),
+ ILI9881C_COMMAND_INSTR(0x05, 0x00),
+ ILI9881C_COMMAND_INSTR(0x06, 0x0A),
+ ILI9881C_COMMAND_INSTR(0x07, 0x0E),
+ ILI9881C_COMMAND_INSTR(0x08, 0x00),
+ ILI9881C_COMMAND_INSTR(0x09, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0a, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0b, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0c, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0d, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0e, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0f, 0x01),
+ ILI9881C_COMMAND_INSTR(0x10, 0x01),
+ ILI9881C_COMMAND_INSTR(0x11, 0x00),
+ ILI9881C_COMMAND_INSTR(0x12, 0x00),
+ ILI9881C_COMMAND_INSTR(0x13, 0x00),
+ ILI9881C_COMMAND_INSTR(0x14, 0x00),
+ ILI9881C_COMMAND_INSTR(0x15, 0x00),
+ ILI9881C_COMMAND_INSTR(0x16, 0x00),
+ ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ ILI9881C_COMMAND_INSTR(0x18, 0x00),
+ ILI9881C_COMMAND_INSTR(0x19, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1e, 0x40),
+ ILI9881C_COMMAND_INSTR(0x1f, 0x80),
+ ILI9881C_COMMAND_INSTR(0x20, 0x06),
+ ILI9881C_COMMAND_INSTR(0x21, 0x01),
+ ILI9881C_COMMAND_INSTR(0x22, 0x00),
+ ILI9881C_COMMAND_INSTR(0x23, 0x00),
+ ILI9881C_COMMAND_INSTR(0x24, 0x00),
+ ILI9881C_COMMAND_INSTR(0x25, 0x00),
+ ILI9881C_COMMAND_INSTR(0x26, 0x00),
+ ILI9881C_COMMAND_INSTR(0x27, 0x00),
+ ILI9881C_COMMAND_INSTR(0x28, 0x33),
+ ILI9881C_COMMAND_INSTR(0x29, 0x03),
+ ILI9881C_COMMAND_INSTR(0x2a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2f, 0x00),
+ ILI9881C_COMMAND_INSTR(0x30, 0x00),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x32, 0x00),
+ ILI9881C_COMMAND_INSTR(0x33, 0x00),
+ ILI9881C_COMMAND_INSTR(0x34, 0x03),
+ ILI9881C_COMMAND_INSTR(0x35, 0x00),
+ ILI9881C_COMMAND_INSTR(0x36, 0x03),
+ ILI9881C_COMMAND_INSTR(0x37, 0x00),
+ ILI9881C_COMMAND_INSTR(0x38, 0x00),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3a, 0x40),
+ ILI9881C_COMMAND_INSTR(0x3b, 0x40),
+ ILI9881C_COMMAND_INSTR(0x3c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3f, 0x00),
+ ILI9881C_COMMAND_INSTR(0x40, 0x00),
+ ILI9881C_COMMAND_INSTR(0x41, 0x00),
+ ILI9881C_COMMAND_INSTR(0x42, 0x00),
+ ILI9881C_COMMAND_INSTR(0x43, 0x00),
+ ILI9881C_COMMAND_INSTR(0x44, 0x00),
+
+ ILI9881C_COMMAND_INSTR(0x50, 0x01),
+ ILI9881C_COMMAND_INSTR(0x51, 0x23),
+ ILI9881C_COMMAND_INSTR(0x52, 0x45),
+ ILI9881C_COMMAND_INSTR(0x53, 0x67),
+ ILI9881C_COMMAND_INSTR(0x54, 0x89),
+ ILI9881C_COMMAND_INSTR(0x55, 0xab),
+ ILI9881C_COMMAND_INSTR(0x56, 0x01),
+ ILI9881C_COMMAND_INSTR(0x57, 0x23),
+ ILI9881C_COMMAND_INSTR(0x58, 0x45),
+ ILI9881C_COMMAND_INSTR(0x59, 0x67),
+ ILI9881C_COMMAND_INSTR(0x5a, 0x89),
+ ILI9881C_COMMAND_INSTR(0x5b, 0xab),
+ ILI9881C_COMMAND_INSTR(0x5c, 0xcd),
+ ILI9881C_COMMAND_INSTR(0x5d, 0xef),
+
+ ILI9881C_COMMAND_INSTR(0x5e, 0x11),
+ ILI9881C_COMMAND_INSTR(0x5f, 0x02),
+ ILI9881C_COMMAND_INSTR(0x60, 0x00),
+ ILI9881C_COMMAND_INSTR(0x61, 0x01),
+ ILI9881C_COMMAND_INSTR(0x62, 0x0D),
+ ILI9881C_COMMAND_INSTR(0x63, 0x0C),
+ ILI9881C_COMMAND_INSTR(0x64, 0x0F),
+ ILI9881C_COMMAND_INSTR(0x65, 0x0E),
+ ILI9881C_COMMAND_INSTR(0x66, 0x06),
+ ILI9881C_COMMAND_INSTR(0x67, 0x07),
+ ILI9881C_COMMAND_INSTR(0x68, 0x02),
+ ILI9881C_COMMAND_INSTR(0x69, 0x02),
+ ILI9881C_COMMAND_INSTR(0x6a, 0x08),
+ ILI9881C_COMMAND_INSTR(0x6b, 0x02),
+ ILI9881C_COMMAND_INSTR(0x6c, 0x02),
+ ILI9881C_COMMAND_INSTR(0x6d, 0x02),
+
[PATCH 1/3] drm/panel: ilitek-ili9881c: make use of prepare_prev_first
From: Marco Felsch The panel.prepare() call requires an initialized MIPI-DSI host, so set the prepare_prev_first flag to indicate that the host must be initialized first. Signed-off-by: Marco Felsch Signed-off-by: Philipp Zabel --- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c index 7838947a1bf3..0c911ed9141b 100644 --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c @@ -1094,6 +1094,8 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi) return ret; } + ctx->panel.prepare_prev_first = true; + ret = drm_panel_of_backlight(>panel); if (ret) return ret; -- 2.39.2
[PATCH 0/3] drm/panel: ilitek-ili9881c: Support Ampire AM8001280G LCD panel
Add support for Ampire AM8001280G LCD panels to the Ilitek ILI9881C
driver.
Also set prepare_prev_first, to make sure that the DSI host controller
is initialized to LP-11 before the panel is powered up. Tested to work
with samsung-dsim on i.MX8MM after commit 0c14d3130654 ("drm: bridge:
samsung-dsim: Fix i.MX8M enable flow to meet spec").
To: Neil Armstrong
To: Jessica Zhang
To: Sam Ravnborg
To: Maarten Lankhorst
To: Maxime Ripard
To: Thomas Zimmermann
To: David Airlie
To: Daniel Vetter
To: Rob Herring
To: Krzysztof Kozlowski
To: Conor Dooley
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: Marco Felsch
Cc: ker...@pengutronix.de
Signed-off-by: Philipp Zabel
---
Marco Felsch (1):
drm/panel: ilitek-ili9881c: make use of prepare_prev_first
Philipp Zabel (2):
dt-bindings: ili9881c: Add Ampire AM8001280G LCD panel
drm/panel: ilitek-ili9881c: Add Ampire AM8001280G LCD panel
.../bindings/display/panel/ilitek,ili9881c.yaml| 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 225 +
2 files changed, 226 insertions(+)
---
base-commit: e4d983ac270ccee417445a69b9ed198658b1
change-id: 20231123-drm-panel-ili9881c-am8001280g-d2e2f4b30a2e
Best regards,
--
Philipp Zabel
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: The host can not specify the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, it will cause a warning here. And it can not omit the flag (as otherwise the first bridge will create a connector, without consulting the second bridge). The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flagare implement-defined, No, they are not. Semantics are pretty simple: do not create the drm_connector instance. Pass the flag to the next bridge in the chain. for our case, I could just ignore it if their don't have a signal(DT or ACPI) tell me that there are multiple bridges in the chain. This depend on community's attitude. Ignoring a flag is a bad idea. Can you also read the code in the bridge/lontium-lt8912.c please? when flags == 0 is true, the lt8912 driver will just create a drm_connector instance in the drm bridge drivers. The behavior is similar with this patch in the perspective of spirit. And the most important thing is that no matter what the flag the upstream port is passed, lt8912 just always pass the DRM_BRIDGE_ATTACH_NO_CONNECTOR flags to the next bridge. Does this count as a kind of ignore? or This is to say that both the lt8912 and the tfp410 drm bridge drivers are allowing create a drm_connector manually in drm bridge drivers. They didn't being asked to move the drm_connector related code to display controller driver. I don't know why I can't follow this way? Do you really read the code before do comments or I failed to understand something?
[PULL] drm-intel-fixes
Hi Dave & Sima - drm-intel-fixes-2023-11-23: drm/i915 fixes for v6.7-rc3: - Fix race between DP MST connectore registration and setup - Fix GT memory leak on probe error path BR, Jani. The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: Linux 6.7-rc2 (2023-11-19 15:02:14 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-11-23 for you to fetch changes up to 0561794b6b642b84b879bf97061c4b4fa692839e: drm/i915: do not clean GT table on error path (2023-11-20 11:06:53 +0200) drm/i915 fixes for v6.7-rc3: - Fix race between DP MST connectore registration and setup - Fix GT memory leak on probe error path Andrzej Hajda (1): drm/i915: do not clean GT table on error path Imre Deak (1): drm/i915/dp_mst: Fix race between connector registration and setup drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 drivers/gpu/drm/i915/gt/intel_gt.c | 11 --- drivers/gpu/drm/i915/i915_driver.c | 4 +--- 3 files changed, 9 insertions(+), 22 deletions(-) -- Jani Nikula, Intel
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi, On 2023/11/24 00:06, Dmitry Baryshkov wrote: On Thu, 23 Nov 2023 at 17:41, Sui Jingfeng wrote: Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined, No, they are not. Semantics are pretty simple: do not create the drm_connector instance. Pass the flag to the next bridge in the chain. Then, my problem is that do we allow create a drm_connector instance in drm bridge driver nowadays? Yes, if there is no DRM_BRIDGE_ATTACH_NO_CONNECTOR. But that's deprecated IMO. Then can you read the code in bridge/ti-tfp410.c please? The tfp410_attach() function will create drm_connector instance manually if the conditional (flags == 0) is true.
Re: [PATCH v9 0/4] drm: Add support for atomic async page-flip
Em 23/11/2023 13:24, Simon Ser escreveu: Thanks! This iteration of the first 3 patches LGTM, I've pushed them to drm-misc-next. I've made two adjustments to make checkpatch.pl happy: Thank you! - s/uint64_t/u64/ - Fix indentation for a drm_dbg_atomic() ops :)
Re: [PATCH v9 0/4] drm: Add support for atomic async page-flip
Thanks! This iteration of the first 3 patches LGTM, I've pushed them to drm-misc-next. I've made two adjustments to make checkpatch.pl happy: - s/uint64_t/u64/ - Fix indentation for a drm_dbg_atomic()
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi,
On 2023/11/23 21:39, Neil Armstrong wrote:
On 23/11/2023 09:08, Dmitry Baryshkov wrote:
On Thu, 23 Nov 2023 at 07:05, Sui Jingfeng
wrote:
Hi,
On 2023/11/16 19:19, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 12:13, Sui Jingfeng
wrote:
Hi,
On 2023/11/16 17:30, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 11:14, Sui Jingfeng
wrote:
Hi,
Thanks a lot for reviewing!
On 2023/11/15 00:30, Dmitry Baryshkov wrote:
On Tue, 14 Nov 2023 at 17:09, Sui Jingfeng
wrote:
From: Sui Jingfeng
The it66121_create_bridge() and it66121_destroy_bridge() are
added to
export the core functionalities. Create a connector manually
by using
bridge connector helpers when link as a lib.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 134
+++
include/drm/bridge/ite-it66121.h | 17
2 files changed, 113 insertions(+), 38 deletions(-)
create mode 100644 include/drm/bridge/ite-it66121.h
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
index 8971414a2a60..f5968b679c5d 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -703,14 +704,32 @@ static int it66121_bridge_attach(struct
drm_bridge *bridge,
enum
drm_bridge_attach_flags flags)
{
struct it66121_ctx *ctx = bridge_to_it66121(bridge);
+ struct drm_bridge *next_bridge = ctx->next_bridge;
+ struct drm_encoder *encoder = bridge->encoder;
int ret;
- if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
- return -EINVAL;
+ if (next_bridge) {
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+ WARN_ON(1);
Why? At least use WARN() instead
Originally I want to
+ flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ }
+ ret = drm_bridge_attach(encoder, next_bridge,
bridge, flags);
+ if (ret)
+ return ret;
+ } else {
+ struct drm_connector *connector;
- ret = drm_bridge_attach(bridge->encoder,
ctx->next_bridge, bridge, flags);
- if (ret)
- return ret;
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ WARN_ON(1);
No. It is perfectly fine to create attach a bridge with no
next_bridge
and with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
The document say when DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is set
the bridge shall not create a drm_connector. So I think if a
display
bridge driver don't have a next bridge attached (Currently, this is
told by the DT), it says that this is a non-DT environment. On such
a case, this display bridge driver(it66121.ko) should behavior like
a *agent*. Because the upstream port of it66121 is the DVO port of
the display controller, the downstream port of it66121 is the HDMI
connector. it66121 is on the middle. So I think the it66121.ko
should
handle all of troubles on behalf of the display controller drivers.
No. Don't make decisions for the other drivers. They might have
different needs.
[...]
Therefore (when in non-DT use case), the display controller drivers
side should not set DRM_BRIDGE_ATTACH_NO_CONNECTOR flag anymore.
Which is to hint that the it66121 should totally in charge of those
tasks (either by using bridge connector helper or create a
connector
manually). I don't understand on such a case, why bother display
controller drivers anymore.
This is the reason why we had introduced this flag. It allows the
driver to customise the connector. It even allows the driver to
implement a connector on its own, completely ignoring the
drm_bridge_connector.
I know what you said is right in the sense of the universe cases,
but I think the most frequent(majority) use case is that there is
only one display bridge on the middle. Therefore, I don't want to
movethe connector things into device driver if there is only one
display
bridge(say it66121) in the middle. After all, there is no *direct
physical connection* from the perspective of the hardware. I means
that
there is no hardware wires connectthe HDMI connector and the DVO
port. So display controller drivers
should not interact with anything related with the connector on a
perfect abstract on the software side. Especially for such a
simple use
case. It probably make senses to make a decision for themost
frequently use case, please also note
that this patch didn't introduce any-restriction for the more advance
uses cases(multiple bridges in the middle).
So, for the sake of not having the connector in the display driver,
you want to add boilerplate code basically to each and every bridge
driver. In the end, they should all behave in the same way.
Moreover, there is no way this implementation can work without a
warning if there
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
On Thu, 23 Nov 2023 at 17:41, Sui Jingfeng wrote: > > Hi, > > > On 2023/11/23 16:08, Dmitry Baryshkov wrote: > >> The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined, > > No, they are not. Semantics are pretty simple: do not create the > > drm_connector instance. Pass the flag to the next bridge in the chain. > > > Then, my problem is that do we allow create a drm_connector instance in drm > bridge > driver nowadays? Yes, if there is no DRM_BRIDGE_ATTACH_NO_CONNECTOR. But that's deprecated IMO. -- With best wishes Dmitry
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined, No, they are not. Semantics are pretty simple: do not create the drm_connector instance. Pass the flag to the next bridge in the chain. Then, my problem is that do we allow create a drm_connector instance in drm bridge driver nowadays?
Re: [PATCH] drm/panfrost: Ignore core_mask for poweroff and sync interrupts
On Thu, 23 Nov 2023 16:14:12 +0100
AngeloGioacchino Del Regno
wrote:
> Il 23/11/23 14:51, Boris Brezillon ha scritto:
> > On Thu, 23 Nov 2023 14:24:57 +0100
> > AngeloGioacchino Del Regno
> > wrote:
> >
>
> So, while I agree that it'd be slightly more readable as a diff if those
> were two different commits I do have reasons against splitting.
> >>>
> >>> If we just need a quick fix to avoid PWRTRANS interrupts from kicking
> >>> in when we power-off the cores, I think we'd be better off dropping
> >>> GPU_IRQ_POWER_CHANGED[_ALL] from the value we write to GPU_INT_MASK
> >>> at [re]initialization time, and then have a separate series that fixes
> >>> the problem more generically.
> >>>
> >>
> >> But that didn't work:
> >> https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44...@linaro.org/
> >>
> >
> > I meant, your 'ignore-core_mask' fix + the
> > 'drop GPU_IRQ_POWER_CHANGED[_ALL] in GPU_INT_MASK' one.
> >
> > So,
> >
> > https://lore.kernel.org/all/4c73f67e-174c-497e-85a5-cb053ce65...@collabora.com/
> > +
> > https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44...@linaro.org/
> >
> >>
> >>
> >> ...while this "full" solution worked:
> >> https://lore.kernel.org/all/39e9514b-087c-42eb-8d0e-f75dc620e...@linaro.org/
> >>
> >> https://lore.kernel.org/all/5b24cc73-23aa-4837-abb9-b6d138b46...@linaro.org/
> >>
> >>
> >> ...so this *is* a "quick fix" already... :-)
> >
> > It's a half-baked solution for the missing irq-synchronization-on-suspend
> > issue IMHO. I understand why you want it all in one patch that can serve
> > as a fix for 123b431f8a5c ("drm/panfrost: Really power off GPU cores in
> > panfrost_gpu_power_off()"), which is why I'm suggesting to go for an
> > even simpler diff (see below), and then fully address the
> > irq-synhronization-on-suspend issue in a follow-up patchset.
> >
> > --->8---
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > index 09f5e1563ebd..6e2d7650cc2b 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > @@ -78,7 +78,10 @@ int panfrost_gpu_soft_reset(struct panfrost_device
> > *pfdev)
> > }
> >
> > gpu_write(pfdev, GPU_INT_CLEAR, GPU_IRQ_MASK_ALL);
> > - gpu_write(pfdev, GPU_INT_MASK, GPU_IRQ_MASK_ALL);
We probably want a comment here:
/* Only enable the interrupts we care about. */
> > + gpu_write(pfdev, GPU_INT_MASK,
> > + GPU_IRQ_MASK_ERROR |
> > + GPU_IRQ_PERFCNT_SAMPLE_COMPLETED |
> > + GPU_IRQ_CLEAN_CACHES_COMPLETED);
> >
>
> ...but if we do that, the next patch(es) will contain a partial revert of this
> commit, putting back this to gpu_write(pfdev, GPU_INT_MASK,
> GPU_IRQ_MASK_ALL)...
Why should we revert it? We're not processing the PWRTRANS interrupts
in the interrupt handler, those should never have been enabled in the
first place. The only reason we'd want to revert that change is if we
decide to do have interrupt-based waits in the poweron/off
implementation, which, as far as I'm aware, is not something we intend
to do any time soon.
>
> I'm not sure that it's worth changing this like that, then changing it back
> right
> after :-\
>
> Anyway, if anyone else agrees with doing it and then partially revert, I have
> no
> issues going with this one instead; what I care about ultimately is resolving
> the
> regression ASAP :-)
>
> Cheers,
> Angelo
>
> > /*
> > * All in-flight jobs should have released their cycle
> > @@ -425,11 +428,10 @@ void panfrost_gpu_power_on(struct panfrost_device
> > *pfdev)
> >
> > void panfrost_gpu_power_off(struct panfrost_device *pfdev)
> > {
> > - u64 core_mask = panfrost_get_core_mask(pfdev);
> > int ret;
> > u32 val;
> >
> > - gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present &
> > core_mask);
> > + gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present);
> > ret = readl_relaxed_poll_timeout(pfdev->iomem + SHADER_PWRTRANS_LO,
> > val, !val, 1, 1000);
> > if (ret)
> > @@ -441,7 +443,7 @@ void panfrost_gpu_power_off(struct panfrost_device
> > *pfdev)
> > if (ret)
> > dev_err(pfdev->dev, "tiler power transition timeout");
> >
> > - gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present &
> > core_mask);
> > + gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present);
> > ret = readl_poll_timeout(pfdev->iomem + L2_PWRTRANS_LO,
> > val, !val, 0, 1000);
> > if (ret)
> >
> >
>
Re: [PATCH v4 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation
Hi,
> mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
> always have the CRTC with id 0, the ext id 1 and the third id 2. This
> is only true if the paths are all available. But paths are optional
> (see
> also comment in mtk_drm_kms_init()), e.g. the main path might not be
> enabled or available at all. Then the CRTC IDs will shift one up, e.g.
> ext will be 0 and the third path will be 1.
>
> To fix that, dynamically calculate the IDs by the presence of the
> paths.
>
> While at it, make the return code a signed one and return -ENOENT if no
> path is found and handle the error in the callers.
>
> Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting
> possible_crtc way")
> Suggested-by: Nícolas F. R. A. Prado
> Signed-off-by: Michael Walle
> Reviewed-by: Nícolas F. R. A. Prado
> Tested-by: Nícolas F. R. A. Prado
Is there anything wrong with these two patches? They are now lingering
around for more than two months.
Unfortunately, patch 2/2 won't apply anymore because of commit
01389b324c97 ("drm/mediatek: Add connector dynamic selection
capability). And I'm a bit puzzled for what the crtc_id is used
there because I guess it will have the same problem this patch
fixes.
Please base on the latest kernel version to fix.
Of course, but the question is how to fix it. Maybe Jason-JH.Lin
can help here.
In any case, please pick patch 1/2, it's independent of the second
patch and should still apply.
-michael
Re: (subset) [PATCH v3 1/1] backlight: pwm_bl: Use dev_err_probe
On Fri, 17 Nov 2023 13:06:25 +0100, Alexander Stein wrote: > Use dev_err_probe to simplify error paths. Also let dev_err_probe handle > the -EPROBE_DEFER case and add an entry to > /sys/kernel/debug/devices_deferred when deferred. > > Applied, thanks! [1/1] backlight: pwm_bl: Use dev_err_probe commit: 58793f263abc8e5233fabf7466219202db09d048 -- Lee Jones [李琼斯]
Re: [PATCH v4 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation
Hi, Michael:
Michael Walle 於 2023年11月21日 週二 下午10:44寫道：
>
> Hi,
>
> > mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
> > always have the CRTC with id 0, the ext id 1 and the third id 2. This
> > is only true if the paths are all available. But paths are optional
> > (see
> > also comment in mtk_drm_kms_init()), e.g. the main path might not be
> > enabled or available at all. Then the CRTC IDs will shift one up, e.g.
> > ext will be 0 and the third path will be 1.
> >
> > To fix that, dynamically calculate the IDs by the presence of the
> > paths.
> >
> > While at it, make the return code a signed one and return -ENOENT if no
> > path is found and handle the error in the callers.
> >
> > Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting
> > possible_crtc way")
> > Suggested-by: Nícolas F. R. A. Prado
> > Signed-off-by: Michael Walle
> > Reviewed-by: Nícolas F. R. A. Prado
> > Tested-by: Nícolas F. R. A. Prado
>
> Is there anything wrong with these two patches? They are now lingering
> around for more than two months.
>
> Unfortunately, patch 2/2 won't apply anymore because of commit
> 01389b324c97 ("drm/mediatek: Add connector dynamic selection
> capability). And I'm a bit puzzled for what the crtc_id is used
> there because I guess it will have the same problem this patch
> fixes.
Please base on the latest kernel version to fix.
Regards,
Chun-Kuang.
>
> -michael
>
> > ---
> > v4:
> > - return -ENOENT if mtk_drm_find_possible_crtc_by_comp() doesn't find
> >any path
> > v3:
> > - use data instead of priv_n->data
> > - fixed typos
> > - collected Rb and Tb tags
> > v2:
> > - iterate over all_drm_private[] to get any vdosys
> > - new check if a path is available
> > ---
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 5 +-
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 75 -
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 +-
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +-
> > 4 files changed, 68 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 2f931e4e2b60..f9250f7ee706 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -796,7 +796,10 @@ static int mtk_dpi_bind(struct device *dev, struct
> > device *master, void *data)
> > return ret;
> > }
> >
> > - dpi->encoder.possible_crtcs =
> > mtk_drm_find_possible_crtc_by_comp(drm_dev, dpi->dev);
> > + ret = mtk_drm_find_possible_crtc_by_comp(drm_dev, dpi->dev);
> > + if (ret < 0)
> > + goto err_cleanup;
> > + dpi->encoder.possible_crtcs = ret;
> >
> > ret = drm_bridge_attach(>encoder, >bridge, NULL,
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 771f4e173353..83ae75ecd858 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -507,6 +507,27 @@ static bool mtk_drm_find_comp_in_ddp(struct device
> > *dev,
> > return false;
> > }
> >
> > +static bool mtk_ddp_path_available(const unsigned int *path,
> > +unsigned int path_len,
> > +struct device_node **comp_node)
> > +{
> > + unsigned int i;
> > +
> > + if (!path)
> > + return false;
> > +
> > + for (i = 0U; i < path_len; i++) {
> > + /* OVL_ADAPTOR doesn't have a device node */
> > + if (path[i] == DDP_COMPONENT_DRM_OVL_ADAPTOR)
> > + continue;
> > +
> > + if (!comp_node[path[i]])
> > + return false;
> > + }
> > +
> > + return true;
> > +}
> > +
> > int mtk_ddp_comp_get_id(struct device_node *node,
> > enum mtk_ddp_comp_type comp_type)
> > {
> > @@ -522,25 +543,47 @@ int mtk_ddp_comp_get_id(struct device_node *node,
> > return -EINVAL;
> > }
> >
> > -unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device
> > *drm,
> > - struct device *dev)
> > +int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm, struct
> > device *dev)
> > {
> > struct mtk_drm_private *private = drm->dev_private;
> > - unsigned int ret = 0;
> > -
> > - if (mtk_drm_find_comp_in_ddp(dev, private->data->main_path,
> > private->data->main_len,
> > - private->ddp_comp))
> > - ret = BIT(0);
> > - else if (mtk_drm_find_comp_in_ddp(dev, private->data->ext_path,
> > - private->data->ext_len,
> > private->ddp_comp))
> > - ret = BIT(1);
> > - else if (mtk_drm_find_comp_in_ddp(dev, private->data->third_path,
> > - private->data->third_len,
> >
Re: [PATCH v5 1/4] pwm: rename pwm_apply_state() to pwm_apply_cansleep()
On Sat, 18 Nov 2023, Sean Young wrote: > In order to introduce a pwm api which can be used from atomic context, > we will need two functions for applying pwm changes: > > int pwm_apply_cansleep(struct pwm *, struct pwm_state *); > int pwm_apply_atomic(struct pwm *, struct pwm_state *); > > This commit just deals with renaming pwm_apply_state(), a following > commit will introduce the pwm_apply_atomic() function. > > Acked-by: Hans de Goede > Acked-by: Jani Nikula > Signed-off-by: Sean Young > --- > Documentation/driver-api/pwm.rst | 8 +++--- > .../gpu/drm/i915/display/intel_backlight.c| 6 ++-- > drivers/gpu/drm/solomon/ssd130x.c | 2 +- > drivers/hwmon/pwm-fan.c | 8 +++--- > drivers/input/misc/da7280.c | 4 +-- > drivers/input/misc/pwm-beeper.c | 4 +-- > drivers/input/misc/pwm-vibra.c| 8 +++--- > drivers/leds/leds-pwm.c | 2 +- > drivers/leds/rgb/leds-pwm-multicolor.c| 4 +-- Acked-by: Lee Jones > drivers/media/rc/pwm-ir-tx.c | 4 +-- > drivers/platform/x86/lenovo-yogabook.c| 2 +- > drivers/pwm/core.c| 18 ++-- > drivers/pwm/pwm-twl-led.c | 2 +- > drivers/pwm/pwm-vt8500.c | 2 +- > drivers/pwm/sysfs.c | 10 +++ > drivers/regulator/pwm-regulator.c | 4 +-- > drivers/video/backlight/lm3630a_bl.c | 2 +- > drivers/video/backlight/lp855x_bl.c | 2 +- > drivers/video/backlight/pwm_bl.c | 12 Acked-by: Lee Jones > drivers/video/fbdev/ssd1307fb.c | 2 +- > include/linux/pwm.h | 28 +-- > 21 files changed, 67 insertions(+), 67 deletions(-) [...] -- Lee Jones [李琼斯]
Re: [PATCH] drm/panfrost: Ignore core_mask for poweroff and sync interrupts
Il 23/11/23 14:51, Boris Brezillon ha scritto:
On Thu, 23 Nov 2023 14:24:57 +0100
AngeloGioacchino Del Regno
wrote:
So, while I agree that it'd be slightly more readable as a diff if those
were two different commits I do have reasons against splitting.
If we just need a quick fix to avoid PWRTRANS interrupts from kicking
in when we power-off the cores, I think we'd be better off dropping
GPU_IRQ_POWER_CHANGED[_ALL] from the value we write to GPU_INT_MASK
at [re]initialization time, and then have a separate series that fixes
the problem more generically.
But that didn't work:
https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44...@linaro.org/
I meant, your 'ignore-core_mask' fix + the
'drop GPU_IRQ_POWER_CHANGED[_ALL] in GPU_INT_MASK' one.
So,
https://lore.kernel.org/all/4c73f67e-174c-497e-85a5-cb053ce65...@collabora.com/
+
https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44...@linaro.org/
...while this "full" solution worked:
https://lore.kernel.org/all/39e9514b-087c-42eb-8d0e-f75dc620e...@linaro.org/
https://lore.kernel.org/all/5b24cc73-23aa-4837-abb9-b6d138b46...@linaro.org/
...so this *is* a "quick fix" already... :-)
It's a half-baked solution for the missing irq-synchronization-on-suspend
issue IMHO. I understand why you want it all in one patch that can serve
as a fix for 123b431f8a5c ("drm/panfrost: Really power off GPU cores in
panfrost_gpu_power_off()"), which is why I'm suggesting to go for an
even simpler diff (see below), and then fully address the
irq-synhronization-on-suspend issue in a follow-up patchset.
--->8---
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 09f5e1563ebd..6e2d7650cc2b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -78,7 +78,10 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev)
}
gpu_write(pfdev, GPU_INT_CLEAR, GPU_IRQ_MASK_ALL);
- gpu_write(pfdev, GPU_INT_MASK, GPU_IRQ_MASK_ALL);
+ gpu_write(pfdev, GPU_INT_MASK,
+ GPU_IRQ_MASK_ERROR |
+ GPU_IRQ_PERFCNT_SAMPLE_COMPLETED |
+ GPU_IRQ_CLEAN_CACHES_COMPLETED);
...but if we do that, the next patch(es) will contain a partial revert of this
commit, putting back this to gpu_write(pfdev, GPU_INT_MASK, GPU_IRQ_MASK_ALL)...
I'm not sure that it's worth changing this like that, then changing it back
right
after :-\
Anyway, if anyone else agrees with doing it and then partially revert, I have no
issues going with this one instead; what I care about ultimately is resolving
the
regression ASAP :-)
Cheers,
Angelo
/*
* All in-flight jobs should have released their cycle
@@ -425,11 +428,10 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
void panfrost_gpu_power_off(struct panfrost_device *pfdev)
{
- u64 core_mask = panfrost_get_core_mask(pfdev);
int ret;
u32 val;
- gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present & core_mask);
+ gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present);
ret = readl_relaxed_poll_timeout(pfdev->iomem + SHADER_PWRTRANS_LO,
val, !val, 1, 1000);
if (ret)
@@ -441,7 +443,7 @@ void panfrost_gpu_power_off(struct panfrost_device *pfdev)
if (ret)
dev_err(pfdev->dev, "tiler power transition timeout");
- gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present & core_mask);
+ gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present);
ret = readl_poll_timeout(pfdev->iomem + L2_PWRTRANS_LO,
val, !val, 0, 1000);
if (ret)
Re: [PATCH v7 0/2] backlight: mp3309c: Add support for MPS MP3309C
On Thu, 16 Nov 2023 11:53:17 +0100, Flavio Suligoi wrote: > This patchset (rebased on v6.7.0-rc1 kernel version): > > - includes and updates the mps,mp3309c.yaml dt bindings file: > - Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml > Note: the patch related to this file was previously a separate patch > and sent in two versions (v1 and v2). > It has now been included in this patchset, starting with the > version v6. > - adds the related device driver to support the MPS MP3309C backlight chip > - adds missed history of previous versions > - adds missed "Acked-by" and "Reviewed-by" added in previous versions > > [...] Applied, thanks! [1/2] dt-bindings: backlight: mp3309c: remove two required properties commit: 87f33a1b8f7e3d223fc331fe54fd8ec337dc9cb9 [2/2] backlight: mp3309c: Add support for MPS MP3309C commit: 2e914516a58cf86bd0e42c7d3e25c81d44ec2ab8 -- Lee Jones [李琼斯]
Re: [PATCH v18 15/26] drm/panfrost: Explicitly get and put drm-shmem pages
On Mon, 30 Oct 2023 02:01:54 +0300
Dmitry Osipenko wrote:
> To simplify the drm-shmem refcnt handling, we're moving away from
> the implicit get_pages() that is used by get_pages_sgt(). From now on
> drivers will have to pin pages while they use sgt. Panfrost's shrinker
> doesn't support swapping out BOs, hence pages are pinned and sgt is valid
> as long as pages' use-count > 0.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/panfrost/panfrost_gem.c | 17 +
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 ++
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 6b77d8cebcb2..bb9d43cf7c3c 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -47,8 +47,13 @@ static void panfrost_gem_free_object(struct drm_gem_object
> *obj)
> }
> }
> kvfree(bo->sgts);
> +
> + drm_gem_shmem_put_pages(>base);
> }
>
> + if (!bo->is_heap && !obj->import_attach)
> + drm_gem_shmem_put_pages(>base);
> +
> drm_gem_shmem_free(>base);
> }
>
> @@ -269,6 +274,7 @@ panfrost_gem_create(struct drm_device *dev, size_t size,
> u32 flags)
> {
> struct drm_gem_shmem_object *shmem;
> struct panfrost_gem_object *bo;
> + int err;
>
> /* Round up heap allocations to 2MB to keep fault handling simple */
> if (flags & PANFROST_BO_HEAP)
> @@ -282,7 +288,18 @@ panfrost_gem_create(struct drm_device *dev, size_t size,
> u32 flags)
> bo->noexec = !!(flags & PANFROST_BO_NOEXEC);
> bo->is_heap = !!(flags & PANFROST_BO_HEAP);
>
> + if (!bo->is_heap) {
> + err = drm_gem_shmem_get_pages(shmem);
I really hate the fact we request pages here while we call
panfrost_mmu_map() in panfrost_gem_open(), because ultimately, pages
are requested for the MMU mapping. Also hate the quirk we have in shmem
to call free_pages() instead of put_pages_locked() when the BO refcount
dropped to zero, and I was hoping we could get rid of it at some point
by teaching drivers to request pages when they actually need it instead
of tying pages lifetime to the GEM object lifetime.
Maybe what we should do instead is move the get/put_pages() in
panfrost_mmu_map/unmap() (as I suggested), but have a special mapping
panfrost_mmu_evict/restore() helpers that kill/restore the MMU mappings
without releasing/acquiring the pages ref.
Re: [PATCH v18 15/26] drm/panfrost: Explicitly get and put drm-shmem pages
On Thu, 23 Nov 2023 15:24:32 +0300
Dmitry Osipenko wrote:
> On 11/23/23 12:05, Boris Brezillon wrote:
> > On Thu, 23 Nov 2023 01:04:56 +0300
> > Dmitry Osipenko wrote:
> >
> >> On 11/10/23 13:53, Boris Brezillon wrote:
> >>> Hm, there was no drm_gem_shmem_get_pages_sgt() call here, why
> >>> should we add a drm_gem_shmem_get_pages()? What we should do
> >>> instead is add a drm_gem_shmem_get_pages() for each
> >>> drm_gem_shmem_get_pages_sgt() we have in the driver (in
> >>> panfrost_mmu_map()), and add drm_gem_shmem_put_pages() calls
> >>> where they are missing (panfrost_mmu_unmap()).
> >>>
> +if (err)
> +goto err_free;
> +}
> +
> return bo;
> +
> +err_free:
> +drm_gem_shmem_free(>base);
> +
> +return ERR_PTR(err);
> }
>
> struct drm_gem_object *
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c index
> 770dab1942c2..ac145a98377b 100644 ---
> a/drivers/gpu/drm/panfrost/panfrost_mmu.c +++
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c @@ -504,7 +504,7 @@
> static int panfrost_mmu_map_fault_addr(struct panfrost_device
> *pfdev, int as, if (IS_ERR(pages[i])) { ret = PTR_ERR(pages[i]);
> pages[i] = NULL;
> -goto err_pages;
> +goto err_unlock;
> }
> }
>
> @@ -512,7 +512,7 @@ static int
> panfrost_mmu_map_fault_addr(struct panfrost_device *pfdev, int
> as, ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
> NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL); if (ret)
> -goto err_pages;
> +goto err_unlock;
> >>> Feels like the panfrost_gem_mapping object should hold a ref on
> >>> the BO pages, not the BO itself, because, ultimately, the user of
> >>> the BO is the GPU. This matches what I was saying about moving
> >>> get/put_pages() to panfrost_mmu_map/unmap(): everytime a
> >>> panfrost_gem_mapping becomes active, to want to take a pages ref,
> >>> every time it becomes inactive, you should release the pages ref.
> >>>
> >>
> >> The panfrost_mmu_unmap() is also used by shrinker when BO is
> >> purged. I'm unhappy with how icky it all becomes if unmap is made
> >> to put pages.
> >
> > Why, that's exactly what's supposed to happen. If you mmu_unmap(),
> > that means you no longer need the pages ref you got.
>
> The drm_gem_shmem_purge() frees the pages. If mmu_unmap() frees pages
> too, then it becomes odd for drm_gem_shmem_purge() that it needs to
> free pages that were already freed.
Hm, I didn't consider the mmu_unmap() call in the eviction path.
>
> >> Previously map() was implicitly allocating pages with get_sgt()
> >> and then pages were implicitly released by drm_gem_shmem_free(). A
> >> non-heap BO is mapped when it's created by Panfrost, hence the
> >> actual lifetime of pages is kept unchanged by this patch.
> >
> > But the whole point of making it explicit is to control when pages
> > are needed or not, isn't it. The fact we mmu_map() the BO at open
> > time, and keep it mapped until it's not longer referenced is an
> > implementation choice, and I don't think having pages_put() in
> > mmu_unmap() changes that.
>
> Previously, when the last mmu_unmap() was done, the pages were not
> released.
>
> If you'll make unmap to put pages, then you can't map BO again
> because pages are released by the last put() of unmap.
Well, you could, if panfrost_gem_mapping_get() was not only
returning an existing mapping, but was also creating one when none
exist. But you're right, it messes up with the shmem shrinker and also
changes the way we are doing things now.
> In order to
> keep the old pages allocation logic unchanged, the pages must be
> referenced while BO is alive, not while mapping is alive.
Correct.
>
> Technically, the code can be changed to put pages on unmap. This
> requires adding special quirk to drm_gem_shmem_purge() and then for
> Panfrost pages should have the same lifetime as BO, hence why bother?
No, we certainly don't want to do that.
Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote: > RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other > architectures. Enabling hardware FP requires overriding the ISA string > for the relevant compilation units. Ah yes, bringing the joy of frame-larger-than warnings to RISC-V: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:58:13: warning: stack frame size (2416) exceeds limit (2048) in 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation' [-Wframe-larger-than] Nathan, have you given up on these being sorted out? Also, what on earth is that function name, it exceeds 80 characters before even considering anything else? Actually, I don't think I want to know. signature.asc Description: PGP signature
Re: Powered off Philips TV sends corrupt EDID causing flickering
Dear Jani, Thank you for your reply. Am 22.11.23 um 11:38 schrieb Jani Nikula: On Tue, 21 Nov 2023, Paul Menzel wrote: Connecting a USB Type-C port replicator [1] to the only USB Type-C port of the Dell XPS 13 9360 with Debian sid/unstable and Debian’s Linux kernel 6.10.5, and then connecting a Philips 40PFL5206H/12 TV device, that is powered off or in standby, to the HDMI port, Linux logs: […] Depending on how the port replicator works, this may not come from the TV at all. And all of this probably depends on GPU and driver, which are not mentioned. Sorry for just mentioning the laptop model. It uses the device below: 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA controller]) If it's i915, please see [1] on how to file a bug. Thank you for taking the time to tell me the proper forum. I created the two issues below: 1. EDID has corrupt header [2] 2. No image on Philips TV when turning on while connected over HDMI/USB-C port replicator (`[drm] *ERROR* Link Training Unsuccessful`) [3] Kind regards, Paul [1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html [2]: https://gitlab.freedesktop.org/drm/intel/-/issues/9705 [3]: https://gitlab.freedesktop.org/drm/intel/-/issues/9707
Re: [PATCH v3] drm/panfrost: Ignore core_mask for poweroff and sync interrupts
On Thu, 23 Nov 2023 14:30:08 +0100
AngeloGioacchino Del Regno
wrote:
> Il 23/11/23 14:13, Boris Brezillon ha scritto:
> > On Thu, 23 Nov 2023 13:05:21 +0100
> > AngeloGioacchino Del Regno
> > wrote:
> >
> >> Some SoCs may be equipped with a GPU containing two core groups
> >> and this is exactly the case of Samsung's Exynos 5422 featuring
> >> an ARM Mali-T628 MP6 GPU: the support for this GPU in Panfrost
> >> is partial, as this driver currently supports using only one
> >> core group and that's reflected on all parts of it, including
> >> the power on (and power off, previously to this patch) function.
> >>
> >> The issue with this is that even though executing the soft reset
> >> operation should power off all cores unconditionally, on at least
> >> one platform we're seeing a crash that seems to be happening due
> >> to an interrupt firing which may be because we are calling power
> >> transition only on the first core group, leaving the second one
> >> unchanged, or because ISR execution was pending before entering
> >> the panfrost_gpu_power_off() function and executed after powering
> >> off the GPU cores, or all of the above.
> >>
> >> Finally, solve this by introducing a new panfrost_gpu_suspend_irq()
> >> helper function and changing the panfrost_device_suspend() flow to
> >> 1. Mask and clear all interrupts: we don't need nor want any, as
> >> for power_off() we are polling PWRTRANS, but we anyway don't
> >> want GPU IRQs to fire while it is suspended/powered off;
> >> 2. Call synchronize_irq() after that to make sure that any pending
> >> ISR is executed before powering off the GPU Shaders/Tilers/L2
> >> hence avoiding unpowered registers R/W; and
> >> 3. Ignore the core_mask and ask the GPU to poweroff both core groups
> >>
> >> Of course it was also necessary to add a `irq` variable to `struct
> >> panfrost_device` as we need to get that in panfrost_gpu_power_off()
> >> for calling synchronize_irq() on it.
> >>
> >> Fixes: 22aa1a209018 ("drm/panfrost: Really power off GPU cores in
> >> panfrost_gpu_power_off()")
> >> [Regression detected on Odroid HC1, Exynos5422, Mali-T628 MP6]
> >> Reported-by: Krzysztof Kozlowski
> >> Signed-off-by: AngeloGioacchino Del Regno
> >>
> >> ---
> >>
> >> Changes in v3:
> >> - Fix compile issue
> >>
> >> Changes in v2:
> >> - Fixed the commit hash of "Really power off [...]"
> >> - Actually based on a clean next-20231121
> >> - Renamed "irq" to "gpu_irq" as per Boris' suggestion
> >> - Moved the IRQ mask/clear/sync to a helper function and added
> >> a call to that in panfrost_device.c instead of doing that in
> >> panfrost_gpu_power_off().
> >>
> >> NOTE: I didn't split 1+2 from 3 as suggested by Boris, and I'm sending
> >> this one without waiting for feedback on my reasons for that which I
> >> explained as a reply to v1 because the former couldn't be applied to
> >> linux-next, and I want to unblock Krzysztof ASAP to get this tested.
> >>
> >> drivers/gpu/drm/panfrost/panfrost_device.c | 1 +
> >> drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
> >> drivers/gpu/drm/panfrost/panfrost_gpu.c| 28 +++---
> >> drivers/gpu/drm/panfrost/panfrost_gpu.h| 1 +
> >> 4 files changed, 23 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
> >> b/drivers/gpu/drm/panfrost/panfrost_device.c
> >> index c90ad5ee34e7..b0a4f3e513f4 100644
> >> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> >> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> >> @@ -421,6 +421,7 @@ static int panfrost_device_runtime_suspend(struct
> >> device *dev)
> >>return -EBUSY;
> >>
> >>panfrost_devfreq_suspend(pfdev);
> >> + panfrost_gpu_suspend_irq(pfdev);
> >>panfrost_gpu_power_off(pfdev);
> >>
> >>return 0;
> >> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> >> b/drivers/gpu/drm/panfrost/panfrost_device.h
> >> index 0fc558db6bfd..f2b1d4afb9e9 100644
> >> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> >> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> >> @@ -94,6 +94,7 @@ struct panfrost_device {
> >>struct device *dev;
> >>struct drm_device *ddev;
> >>struct platform_device *pdev;
> >> + int gpu_irq;
> >>
> >>void __iomem *iomem;
> >>struct clk *clock;
> >> diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> >> b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> >> index 09f5e1563ebd..2c09aede0945 100644
> >> --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> >> +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> >> @@ -425,11 +425,10 @@ void panfrost_gpu_power_on(struct panfrost_device
> >> *pfdev)
> >>
> >> void panfrost_gpu_power_off(struct panfrost_device *pfdev)
> >> {
> >> - u64 core_mask = panfrost_get_core_mask(pfdev);
> >>int ret;
> >>u32 val;
> >>
> >> - gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present &
> >> core_mask);
> >> + gpu_write(pfdev,
Re: [PATCH] drm/panfrost: Ignore core_mask for poweroff and sync interrupts
On Thu, 23 Nov 2023 14:24:57 +0100
AngeloGioacchino Del Regno
wrote:
> >>
> >> So, while I agree that it'd be slightly more readable as a diff if those
> >> were two different commits I do have reasons against splitting.
> >
> > If we just need a quick fix to avoid PWRTRANS interrupts from kicking
> > in when we power-off the cores, I think we'd be better off dropping
> > GPU_IRQ_POWER_CHANGED[_ALL] from the value we write to GPU_INT_MASK
> > at [re]initialization time, and then have a separate series that fixes
> > the problem more generically.
> >
>
> But that didn't work:
> https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44...@linaro.org/
I meant, your 'ignore-core_mask' fix + the
'drop GPU_IRQ_POWER_CHANGED[_ALL] in GPU_INT_MASK' one.
So,
https://lore.kernel.org/all/4c73f67e-174c-497e-85a5-cb053ce65...@collabora.com/
+
https://lore.kernel.org/all/d95259b8-10cf-4ded-866c-47cbd2a44...@linaro.org/
>
>
> ...while this "full" solution worked:
> https://lore.kernel.org/all/39e9514b-087c-42eb-8d0e-f75dc620e...@linaro.org/
>
> https://lore.kernel.org/all/5b24cc73-23aa-4837-abb9-b6d138b46...@linaro.org/
>
>
> ...so this *is* a "quick fix" already... :-)
It's a half-baked solution for the missing irq-synchronization-on-suspend
issue IMHO. I understand why you want it all in one patch that can serve
as a fix for 123b431f8a5c ("drm/panfrost: Really power off GPU cores in
panfrost_gpu_power_off()"), which is why I'm suggesting to go for an
even simpler diff (see below), and then fully address the
irq-synhronization-on-suspend issue in a follow-up patchset.
--->8---
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 09f5e1563ebd..6e2d7650cc2b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -78,7 +78,10 @@ int panfrost_gpu_soft_reset(struct panfrost_device *pfdev)
}
gpu_write(pfdev, GPU_INT_CLEAR, GPU_IRQ_MASK_ALL);
- gpu_write(pfdev, GPU_INT_MASK, GPU_IRQ_MASK_ALL);
+ gpu_write(pfdev, GPU_INT_MASK,
+ GPU_IRQ_MASK_ERROR |
+ GPU_IRQ_PERFCNT_SAMPLE_COMPLETED |
+ GPU_IRQ_CLEAN_CACHES_COMPLETED);
/*
* All in-flight jobs should have released their cycle
@@ -425,11 +428,10 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
void panfrost_gpu_power_off(struct panfrost_device *pfdev)
{
- u64 core_mask = panfrost_get_core_mask(pfdev);
int ret;
u32 val;
- gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present &
core_mask);
+ gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present);
ret = readl_relaxed_poll_timeout(pfdev->iomem + SHADER_PWRTRANS_LO,
val, !val, 1, 1000);
if (ret)
@@ -441,7 +443,7 @@ void panfrost_gpu_power_off(struct panfrost_device *pfdev)
if (ret)
dev_err(pfdev->dev, "tiler power transition timeout");
- gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present & core_mask);
+ gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present);
ret = readl_poll_timeout(pfdev->iomem + L2_PWRTRANS_LO,
val, !val, 0, 1000);
if (ret)
[PATCH] dt-bindings: display: mediatek: dsi: remove Xinlei's mail
Xinlei Lee's mail is bouncing: : host mailgw02.mediatek.com[216.200.240.185] said: 550 Relaying mail to xinlei@mediatek.com is not allowed (in reply to RCPT TO command) Remove it. Signed-off-by: Michael Walle --- .../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml index 4a7a9ff21996..8611319bed2e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml @@ -10,7 +10,6 @@ maintainers: - Chun-Kuang Hu - Philipp Zabel - Jitao Shi - - Xinlei Lee description: | The MediaTek DSI function block is a sink of the display subsystem and can -- 2.39.2
[PATCH v3] drm/mediatek: Stop using iommu_present()
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already. And if the IOMMU *is* entirely
absent, then attempting to go ahead with CMA and either suceeding or
failing decisively seems more useful than deferring forever.
Signed-off-by: Robin Murphy
---
I realised that last time I sent this I probably should have CCed a
wider audience of reviewers, so here's one with an updated commit
message as well to make the resend more worthwhile.
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2dfaa613276a..48581da51857 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -5,7 +5,6 @@
*/
#include
-#include
#include
#include
#include
@@ -608,9 +607,6 @@ static int mtk_drm_bind(struct device *dev)
struct drm_device *drm;
int ret, i;
- if (!iommu_present(_bus_type))
- return -EPROBE_DEFER;
-
pdev = of_find_device_by_node(private->mutex_node);
if (!pdev) {
dev_err(dev, "Waiting for disp-mutex device %pOF\n",
--
2.39.2.101.g768bb238c484.dirty
Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
On 23/11/2023 09:08, Dmitry Baryshkov wrote:
On Thu, 23 Nov 2023 at 07:05, Sui Jingfeng wrote:
Hi,
On 2023/11/16 19:19, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 12:13, Sui Jingfeng wrote:
Hi,
On 2023/11/16 17:30, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 11:14, Sui Jingfeng wrote:
Hi,
Thanks a lot for reviewing!
On 2023/11/15 00:30, Dmitry Baryshkov wrote:
On Tue, 14 Nov 2023 at 17:09, Sui Jingfeng wrote:
From: Sui Jingfeng
The it66121_create_bridge() and it66121_destroy_bridge() are added to
export the core functionalities. Create a connector manually by using
bridge connector helpers when link as a lib.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/ite-it66121.c | 134 +++
include/drm/bridge/ite-it66121.h | 17
2 files changed, 113 insertions(+), 38 deletions(-)
create mode 100644 include/drm/bridge/ite-it66121.h
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
index 8971414a2a60..f5968b679c5d 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -703,14 +704,32 @@ static int it66121_bridge_attach(struct drm_bridge
*bridge,
enum drm_bridge_attach_flags flags)
{
struct it66121_ctx *ctx = bridge_to_it66121(bridge);
+ struct drm_bridge *next_bridge = ctx->next_bridge;
+ struct drm_encoder *encoder = bridge->encoder;
int ret;
- if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
- return -EINVAL;
+ if (next_bridge) {
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+ WARN_ON(1);
Why? At least use WARN() instead
Originally I want to
+ flags |= DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ }
+ ret = drm_bridge_attach(encoder, next_bridge, bridge, flags);
+ if (ret)
+ return ret;
+ } else {
+ struct drm_connector *connector;
- ret = drm_bridge_attach(bridge->encoder, ctx->next_bridge, bridge,
flags);
- if (ret)
- return ret;
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ WARN_ON(1);
No. It is perfectly fine to create attach a bridge with no next_bridge
and with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
The document say when DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is set
the bridge shall not create a drm_connector. So I think if a display
bridge driver don't have a next bridge attached (Currently, this is
told by the DT), it says that this is a non-DT environment. On such
a case, this display bridge driver(it66121.ko) should behavior like
a *agent*. Because the upstream port of it66121 is the DVO port of
the display controller, the downstream port of it66121 is the HDMI
connector. it66121 is on the middle. So I think the it66121.ko should
handle all of troubles on behalf of the display controller drivers.
No. Don't make decisions for the other drivers. They might have different needs.
[...]
Therefore (when in non-DT use case), the display controller drivers
side should not set DRM_BRIDGE_ATTACH_NO_CONNECTOR flag anymore.
Which is to hint that the it66121 should totally in charge of those
tasks (either by using bridge connector helper or create a connector
manually). I don't understand on such a case, why bother display
controller drivers anymore.
This is the reason why we had introduced this flag. It allows the
driver to customise the connector. It even allows the driver to
implement a connector on its own, completely ignoring the
drm_bridge_connector.
I know what you said is right in the sense of the universe cases,
but I think the most frequent(majority) use case is that there is
only one display bridge on the middle. Therefore, I don't want to
movethe connector things into device driver if there is only one display
bridge(say it66121) in the middle. After all, there is no *direct
physical connection* from the perspective of the hardware. I means that
there is no hardware wires connectthe HDMI connector and the DVO port. So
display controller drivers
should not interact with anything related with the connector on a
perfect abstract on the software side. Especially for such a simple use
case. It probably make senses to make a decision for themost frequently use
case, please also note
that this patch didn't introduce any-restriction for the more advance
uses cases(multiple bridges in the middle).
So, for the sake of not having the connector in the display driver,
you want to add boilerplate code basically to each and every bridge
driver. In the end, they should all behave in the same way.
Moreover, there is no way this implementation can work without a
warning if there are two bridges in a chain and the it66121 is the
[PATCH 4/4] drm/mediatek: support the DSI0 output on the MT8195 VDOSYS0
With the latest dynamic selection of the output component, we can now
support different outputs. Move current output component into the
dynamic routes array and add the new DSI0 output.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2b0c35cacbc6..6fa88976376e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -222,7 +222,11 @@ static const unsigned int mt8195_mtk_ddp_main[] = {
DDP_COMPONENT_DITHER0,
DDP_COMPONENT_DSC0,
DDP_COMPONENT_MERGE0,
- DDP_COMPONENT_DP_INTF0,
+};
+
+static const struct mtk_drm_route mt8195_mtk_ddp_main_routes[] = {
+ { 0, DDP_COMPONENT_DP_INTF0 },
+ { 0, DDP_COMPONENT_DSI0 },
};
static const unsigned int mt8195_mtk_ddp_ext[] = {
@@ -308,6 +312,8 @@ static const struct mtk_mmsys_driver_data
mt8192_mmsys_driver_data = {
static const struct mtk_mmsys_driver_data mt8195_vdosys0_driver_data = {
.main_path = mt8195_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt8195_mtk_ddp_main),
+ .conn_routes = mt8195_mtk_ddp_main_routes,
+ .num_conn_routes = ARRAY_SIZE(mt8195_mtk_ddp_main_routes),
.mmsys_dev_num = 2,
};
--
2.39.2
[PATCH 3/4] arm64: dts: mediatek: mt8195: add DSI and MIPI DPHY nodes
Add the two DSI controller node and the associated DPHY nodes.
Individual boards have to enable them in the board device tree.
Signed-off-by: Michael Walle
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 48
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index 54c674c45b49..0621bb461967 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -1714,6 +1714,26 @@ u2port3: usb-phy@0 {
};
};
+ mipi_tx0: dsi-phy@11c8 {
+ compatible = "mediatek,mt8195-mipi-tx",
"mediatek,mt8183-mipi-tx";
+ reg = <0 0x11c8 0 0x1000>;
+ clocks = <>;
+ clock-output-names = "mipi_tx0_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ mipi_tx1: dsi-phy@11c9 {
+ compatible = "mediatek,mt8195-mipi-tx",
"mediatek,mt8183-mipi-tx";
+ reg = <0 0x11c9 0 0x1000>;
+ clocks = <>;
+ clock-output-names = "mipi_tx1_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
i2c5: i2c@11d0 {
compatible = "mediatek,mt8195-i2c",
"mediatek,mt8192-i2c";
@@ -2737,6 +2757,20 @@ dither0: dither@1c007000 {
mediatek,gce-client-reg = < SUBSYS_1c00 0x7000
0x1000>;
};
+ dsi0: dsi@1c008000 {
+ compatible = "mediatek,mt8195-dsi",
"mediatek,mt8183-dsi";
+ reg = <0 0x1c008000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DSI0>,
+< CLK_VDO0_DSI0_DSI>,
+<_tx0>;
+ clock-names = "engine", "digital", "hs";
+ phys = <_tx0>;
+ phy-names = "dphy";
+ status = "disabled";
+ };
+
dsc0: dsc@1c009000 {
compatible = "mediatek,mt8195-disp-dsc";
reg = <0 0x1c009000 0 0x1000>;
@@ -2746,6 +2780,20 @@ dsc0: dsc@1c009000 {
mediatek,gce-client-reg = < SUBSYS_1c00 0x9000
0x1000>;
};
+ dsi1: dsi@1c012000 {
+ compatible = "mediatek,mt8195-dsi",
"mediatek,mt8183-dsi";
+ reg = <0 0x1c012000 0 0x1000>;
+ interrupts = ;
+ power-domains = < MT8195_POWER_DOMAIN_VDOSYS0>;
+ clocks = < CLK_VDO0_DSI1>,
+< CLK_VDO0_DSI1_DSI>,
+<_tx1>;
+ clock-names = "engine", "digital", "hs";
+ phys = <_tx1>;
+ phy-names = "dphy";
+ status = "disabled";
+ };
+
merge0: merge@1c014000 {
compatible = "mediatek,mt8195-disp-merge";
reg = <0 0x1c014000 0 0x1000>;
--
2.39.2
