[PATCH v3 5/7] drm/bridge: tc358767: Add more volatile registers
These registers might change their value without any host write operation.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 61d8710f46293..152a6dc916079 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2049,9 +2049,16 @@ static bool tc_readable_reg(struct device *dev, unsigned
int reg)
}
static const struct regmap_range tc_volatile_ranges[] = {
+ regmap_reg_range(PPI_BUSYPPI, PPI_BUSYPPI),
+ regmap_reg_range(DSI_BUSYDSI, DSI_BUSYDSI),
+ regmap_reg_range(DSI_LANESTATUS0, DSI_INTSTATUS),
+ regmap_reg_range(DSIERRCNT, DSIERRCNT),
regmap_reg_range(VFUEN0, VFUEN0),
+ regmap_reg_range(SYSSTAT, SYSSTAT),
regmap_reg_range(GPIOI, GPIOI),
regmap_reg_range(INTSTS_G, INTSTS_G),
+ regmap_reg_range(DP0_VMNGENSTATUS, DP0_VMNGENSTATUS),
+ regmap_reg_range(DP0_AMNGENSTATUS, DP0_AMNGENSTATUS),
regmap_reg_range(DP0_AUXWDATA(0), DP0_AUXSTATUS),
regmap_reg_range(DP0_LTSTAT, DP0_SNKLTCHGREQ),
regmap_reg_range(DP_PHY_CTRL, DP_PHY_CTRL),
--
2.34.1
[PATCH v3 7/7] drm/bridge: tc358767: Add descriptions to register definitions
Use the register names from the datasheet. No functional change intended. Signed-off-by: Alexander Stein --- drivers/gpu/drm/bridge/tc358767.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 93fa057eca8dc..43e860796e683 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -145,10 +145,10 @@ #define VFUEN BIT(0) /* Video Frame Timing Upload */ /* System */ -#define TC_IDREG 0x0500 -#define SYSSTAT0x0508 -#define SYSRSTENB 0x050c +#define TC_IDREG 0x0500 /* Chip ID and Revision ID */ #define SYSBOOT0x0504 /* System BootStrap Status Register */ +#define SYSSTAT0x0508 /* System Status Register */ +#define SYSRSTENB 0x050c /* System Reset/Enable Register */ #define ENBI2C (1 << 0) #define ENBLCD0(1 << 2) #define ENBBM (1 << 3) @@ -162,12 +162,12 @@ #define DP0_VIDSRC_DSI_RX (1 << 0) #define DP0_VIDSRC_DPI_RX (2 << 0) #define DP0_VIDSRC_COLOR_BAR (3 << 0) -#define GPIOM 0x0540 -#define GPIOC 0x0544 -#define GPIOO 0x0548 -#define GPIOI 0x054c -#define INTCTL_G 0x0560 -#define INTSTS_G 0x0564 +#define GPIOM 0x0540 /* GPIO Mode Control Register */ +#define GPIOC 0x0544 /* GPIO Direction Control Register */ +#define GPIOO 0x0548 /* GPIO Output Register */ +#define GPIOI 0x054c /* GPIO Input Register */ +#define INTCTL_G 0x0560 /* General Interrupts Control Register */ +#define INTSTS_G 0x0564 /* General Interrupts Status Register */ #define INT_SYSERR BIT(16) #define INT_GPIO_H(x) (1 << (x == 0 ? 2 : 10)) @@ -176,8 +176,8 @@ #define TEST_INT_C 0x0570 /* Test Interrupts Control Register */ #define TEST_INT_S 0x0574 /* Test Interrupts Status Register */ -#define INT_GP0_LCNT 0x0584 -#define INT_GP1_LCNT 0x0588 +#define INT_GP0_LCNT 0x0584 /* Interrupt GPIO0 Low Count Value Register */ +#define INT_GP1_LCNT 0x0588 /* Interrupt GPIO1 Low Count Value Register */ /* Control */ #define DP0CTL 0x0600 @@ -187,9 +187,9 @@ #define DP_EN BIT(0) /* Enable DPTX function */ /* Clocks */ -#define DP0_VIDMNGEN0 0x0610 -#define DP0_VIDMNGEN1 0x0614 -#define DP0_VMNGENSTATUS 0x0618 +#define DP0_VIDMNGEN0 0x0610 /* DP0 Video Force M Value Register */ +#define DP0_VIDMNGEN1 0x0614 /* DP0 Video Force N Value Register */ +#define DP0_VMNGENSTATUS 0x0618 /* DP0 Video Current M Value Register */ #define DP0_AUDMNGEN0 0x0628 /* DP0 Audio Force M Value Register */ #define DP0_AUDMNGEN1 0x062c /* DP0 Audio Force N Value Register */ #define DP0_AMNGENSTATUS 0x0630 /* DP0 Audio Current M Value Register */ @@ -277,7 +277,7 @@ #define AUDIFDATA5 0x071c /* DP0 Audio Info Frame Bytes 23 to 20 */ #define AUDIFDATA6 0x0720 /* DP0 Audio Info Frame Bytes 27 to 24 */ -#define DP1_SRCCTRL0x07a0 +#define DP1_SRCCTRL0x07a0 /* DP1 Control Register */ /* PHY */ #define DP_PHY_CTRL0x0800 -- 2.34.1
[PATCH v3 6/7] drm/bridge: tc358767: Add precious register SYSSTAT
This is the single register which clears its value upon read operation.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 152a6dc916079..93fa057eca8dc 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2070,6 +2070,15 @@ static const struct regmap_access_table
tc_volatile_table = {
.n_yes_ranges = ARRAY_SIZE(tc_volatile_ranges),
};
+static const struct regmap_range tc_precious_ranges[] = {
+ regmap_reg_range(SYSSTAT, SYSSTAT),
+};
+
+static const struct regmap_access_table tc_precious_table = {
+ .yes_ranges = tc_precious_ranges,
+ .n_yes_ranges = ARRAY_SIZE(tc_precious_ranges),
+};
+
static const struct regmap_range tc_non_writeable_ranges[] = {
regmap_reg_range(PPI_BUSYPPI, PPI_BUSYPPI),
regmap_reg_range(DSI_BUSYDSI, DSI_BUSYDSI),
@@ -2093,6 +2102,7 @@ static const struct regmap_config tc_regmap_config = {
.cache_type = REGCACHE_MAPLE,
.readable_reg = tc_readable_reg,
.volatile_table = _volatile_table,
+ .precious_table = _precious_table,
.wr_table = _writeable_table,
.reg_format_endian = REGMAP_ENDIAN_BIG,
.val_format_endian = REGMAP_ENDIAN_LITTLE,
--
2.34.1
[PATCH v3 4/7] drm/bridge: tc358767: Sort volatile registers according to address
Sort the list by the starting address to ease adding new entries.
No functional change intended.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 5c0292b71e9fa..61d8710f46293 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2049,13 +2049,13 @@ static bool tc_readable_reg(struct device *dev,
unsigned int reg)
}
static const struct regmap_range tc_volatile_ranges[] = {
+ regmap_reg_range(VFUEN0, VFUEN0),
+ regmap_reg_range(GPIOI, GPIOI),
+ regmap_reg_range(INTSTS_G, INTSTS_G),
regmap_reg_range(DP0_AUXWDATA(0), DP0_AUXSTATUS),
regmap_reg_range(DP0_LTSTAT, DP0_SNKLTCHGREQ),
regmap_reg_range(DP_PHY_CTRL, DP_PHY_CTRL),
regmap_reg_range(DP0_PLLCTRL, PXL_PLLCTRL),
- regmap_reg_range(VFUEN0, VFUEN0),
- regmap_reg_range(INTSTS_G, INTSTS_G),
- regmap_reg_range(GPIOI, GPIOI),
};
static const struct regmap_access_table tc_volatile_table = {
--
2.34.1
[PATCH v3 1/7] drm/bridge: tc358767: Use regmap_access_table for writeable registers
Using ranges it is easier to add more register where writing is not allowed,
especially for sequences of registers.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 4904248e3c750..258eacb4125a4 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1992,12 +1992,15 @@ static const struct regmap_access_table
tc_volatile_table = {
.n_yes_ranges = ARRAY_SIZE(tc_volatile_ranges),
};
-static bool tc_writeable_reg(struct device *dev, unsigned int reg)
-{
- return (reg != TC_IDREG) &&
- (reg != DP0_LTSTAT) &&
- (reg != DP0_SNKLTCHGREQ);
-}
+static const struct regmap_range tc_non_writeable_ranges[] = {
+ regmap_reg_range(TC_IDREG, TC_IDREG),
+ regmap_reg_range(DP0_LTSTAT, DP0_SNKLTCHGREQ),
+};
+
+static const struct regmap_access_table tc_writeable_table = {
+ .no_ranges = tc_non_writeable_ranges,
+ .n_no_ranges = ARRAY_SIZE(tc_non_writeable_ranges),
+};
static const struct regmap_config tc_regmap_config = {
.name = "tc358767",
@@ -2008,7 +2011,7 @@ static const struct regmap_config tc_regmap_config = {
.cache_type = REGCACHE_MAPLE,
.readable_reg = tc_readable_reg,
.volatile_table = _volatile_table,
- .writeable_reg = tc_writeable_reg,
+ .wr_table = _writeable_table,
.reg_format_endian = REGMAP_ENDIAN_BIG,
.val_format_endian = REGMAP_ENDIAN_LITTLE,
};
--
2.34.1
[PATCH v3 3/7] drm/bridge: tc358767: Add more registers to non-writeable range
While at it, also add missing register definitions. HDCP registers are skipped as they are not named, range 0x0980 - 0x09ac. Signed-off-by: Alexander Stein --- drivers/gpu/drm/bridge/tc358767.c | 87 --- 1 file changed, 81 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index ab0710a35d3d1..5c0292b71e9fa 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -41,8 +41,24 @@ /* Registers */ +/* DSI D-PHY Layer registers */ +#define D0W_DPHYCONTTX 0x0004 +#define CLW_DPHYCONTTX 0x0020 +#define D0W_DPHYCONTRX 0x0024 +#define D1W_DPHYCONTRX 0x0028 +#define D2W_DPHYCONTRX 0x002c +#define D3W_DPHYCONTRX 0x0030 +#define COM_DPHYCONTRX 0x0038 +#define CLW_CNTRL 0x0040 +#define D0W_CNTRL 0x0044 +#define D1W_CNTRL 0x0048 +#define D2W_CNTRL 0x004c +#define D3W_CNTRL 0x0050 +#define TESTMODE_CNTRL 0x0054 + /* PPI layer registers */ #define PPI_STARTPPI 0x0104 /* START control bit */ +#define PPI_BUSYPPI0x0108 /* PPI busy status */ #define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */ #define LPX_PERIOD 3 #define PPI_LANEENABLE 0x0134 @@ -59,6 +75,7 @@ /* DSI layer registers */ #define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ +#define DSI_BUSYDSI0x0208 /* DSI busy status */ #define DSI_LANEENABLE 0x0210 /* Enables each lane */ #define DSI_RX_START BIT(0) @@ -69,6 +86,20 @@ #define LANEENABLE_L2ENBIT(1) #define LANEENABLE_L3ENBIT(2) +#define DSI_LANESTATUS00x0214 /* DSI lane status 0 */ +#define DSI_LANESTATUS10x0218 /* DSI lane status 1 */ +#define DSI_INTSTATUS 0x0220 /* Interrupt Status */ +#define DSI_INTMASK0x0224 /* Interrupt Mask */ +#define DSI_INTCLR 0x0228 /* Interrupt Clear */ +#define DSI_LPTXTO 0x0230 /* LPTX Time Out Counter */ + +/* DSI General Registers */ +#define DSIERRCNT 0x0300 /* DSI Error Count Register */ + +/* DSI Application Layer Registers */ +#define APLCTRL0x0400 /* Application layer Control Register */ +#define RDPKTLN0x0404 /* DSI Read packet Length Register */ + /* Display Parallel Input Interface */ #define DPIPXLFMT 0x0440 #define VS_POL_ACTIVE_LOW (1 << 10) @@ -117,6 +148,7 @@ #define TC_IDREG 0x0500 #define SYSSTAT0x0508 #define SYSRSTENB 0x050c +#define SYSBOOT0x0504 /* System BootStrap Status Register */ #define ENBI2C (1 << 0) #define ENBLCD0(1 << 2) #define ENBBM (1 << 3) @@ -141,6 +173,9 @@ #define INT_GPIO_H(x) (1 << (x == 0 ? 2 : 10)) #define INT_GPIO_LC(x) (1 << (x == 0 ? 3 : 11)) +#define TEST_INT_C 0x0570 /* Test Interrupts Control Register */ +#define TEST_INT_S 0x0574 /* Test Interrupts Status Register */ + #define INT_GP0_LCNT 0x0584 #define INT_GP1_LCNT 0x0588 @@ -155,6 +190,9 @@ #define DP0_VIDMNGEN0 0x0610 #define DP0_VIDMNGEN1 0x0614 #define DP0_VMNGENSTATUS 0x0618 +#define DP0_AUDMNGEN0 0x0628 /* DP0 Audio Force M Value Register */ +#define DP0_AUDMNGEN1 0x062c /* DP0 Audio Force N Value Register */ +#define DP0_AMNGENSTATUS 0x0630 /* DP0 Audio Current M Value Register */ /* Main Channel */ #define DP0_SECSAMPLE 0x0640 @@ -224,6 +262,20 @@ #define DP0_SNKLTCHGREQ0x06d4 #define DP0_LTLOOPCTRL 0x06d8 #define DP0_SNKLTCTRL 0x06e4 +#define DP0_TPATDAT0 0x06e8 /* DP0 Test Pattern bits 29 to 0 */ +#define DP0_TPATDAT1 0x06ec /* DP0 Test Pattern bits 59 to 30 */ +#define DP0_TPATDAT2 0x06f0 /* DP0 Test Pattern bits 89 to 60 */ +#define DP0_TPATDAT3 0x06f4 /* DP0 Test Pattern bits 119 to 90 */ + +#define AUDCFG00x0700 /* DP0 Audio Config0 Register */ +#define AUDCFG10x0704 /* DP0 Audio Config1 Register */ +#define AUDIFDATA0 0x0708 /* DP0 Audio Info Frame Bytes 3 to 0 */ +#define AUDIFDATA1 0x070c /* DP0 Audio Info Frame Bytes 7 to 4 */ +#define AUDIFDATA2 0x0710 /* DP0 Audio Info Frame Bytes 11 to 8 */ +#define AUDIFDATA3 0x0714 /* DP0 Audio Info Frame Bytes 15 to 12 */ +#define AUDIFDATA4 0x0718 /* DP0 Audio Info Frame Bytes 19 to 16 */ +#define AUDIFDATA5 0x071c /* DP0 Audio Info Frame Bytes 23 to 20 */ +#define AUDIFDATA6 0x0720 /* DP0 Audio
[PATCH v3 2/7] drm/bridge: tc358767: Fix order of register defines
0x0510 is bigger than 0x50c, order them accordingly. No functional change intended. Signed-off-by: Alexander Stein --- drivers/gpu/drm/bridge/tc358767.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 258eacb4125a4..ab0710a35d3d1 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -116,13 +116,6 @@ /* System */ #define TC_IDREG 0x0500 #define SYSSTAT0x0508 -#define SYSCTRL0x0510 -#define DP0_AUDSRC_NO_INPUT(0 << 3) -#define DP0_AUDSRC_I2S_RX (1 << 3) -#define DP0_VIDSRC_NO_INPUT(0 << 0) -#define DP0_VIDSRC_DSI_RX (1 << 0) -#define DP0_VIDSRC_DPI_RX (2 << 0) -#define DP0_VIDSRC_COLOR_BAR (3 << 0) #define SYSRSTENB 0x050c #define ENBI2C (1 << 0) #define ENBLCD0(1 << 2) @@ -130,6 +123,13 @@ #define ENBDSIRX (1 << 4) #define ENBREG (1 << 5) #define ENBHDCP(1 << 8) +#define SYSCTRL0x0510 /* System Control Register */ +#define DP0_AUDSRC_NO_INPUT(0 << 3) +#define DP0_AUDSRC_I2S_RX (1 << 3) +#define DP0_VIDSRC_NO_INPUT(0 << 0) +#define DP0_VIDSRC_DSI_RX (1 << 0) +#define DP0_VIDSRC_DPI_RX (2 << 0) +#define DP0_VIDSRC_COLOR_BAR (3 << 0) #define GPIOM 0x0540 #define GPIOC 0x0544 #define GPIOO 0x0548 -- 2.34.1
[PATCH v3 0/7] Improve tc358767 regmap usage
Hi,
this series improves the regmap usage by cleaning up current usage as well as
adding more registers to the list of volatile registers. SYSSTAT is added
to the list of precious registers as it is cleared upon read.
This series is based on [1].
Changes in v2:
* Patch 3: Use more symbolic names instead of register address numbers
* Patch 3: Add register group description for 0x300 and 0x400 area
Changes in v3:
* Rebased to next-20231212
* No changes despite the context due to commit 4dd9368671fb7 ("drm/bridge:
tc358767: Convert to use maple tree register cache")
Best regards,
Alexander
[1]
https://lore.kernel.org/dri-devel/20230817075234.1075736-1-alexander.st...@ew.tq-group.com/T/#t
Alexander Stein (7):
drm/bridge: tc358767: Use regmap_access_table for writeable registers
drm/bridge: tc358767: Fix order of register defines
drm/bridge: tc358767: Add more registers to non-writeable range
drm/bridge: tc358767: Sort volatile registers according to address
drm/bridge: tc358767: Add more volatile registers
drm/bridge: tc358767: Add precious register SYSSTAT
drm/bridge: tc358767: Add descriptions to register definitions
drivers/gpu/drm/bridge/tc358767.c | 171 +++---
1 file changed, 133 insertions(+), 38 deletions(-)
--
2.34.1
Re: [PATCH v3 14/15] drm/msm/dpu: introduce separate wb2_format arrays for rgb and yuv
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote: > > Lets rename the existing wb2_formats array wb2_formats_rgb to indicate > that it has only RGB formats and can be used on any chipset having a WB > block. > > Introduce a new wb2_formats_rgb_yuv array to the catalog to > indicate support for YUV formats to writeback in addition to RGB. > > Chipsets which have support for CDM block will use the newly added > wb2_formats_rgb_yuv array. > > changes in v3: > - change type of wb2_formats_rgb/wb2_formats_rgb_yuv to u32 > to fix checkpatch warnings > > Signed-off-by: Abhinav Kumar > --- > .../msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 4 +- > .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 4 +- > .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 4 +- > .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 4 +- > .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 4 +- > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 37 ++- > 6 files changed, 46 insertions(+), 11 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 13/15] drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote:
>
> Reserve CDM blocks for writeback if the format of the output fb
> is YUV. At the moment, the reservation is done only for writeback
> but can easily be extended by relaxing the checks once other
> interfaces are ready to output YUV.
>
> changes in v3:
> - squash CDM disable during encoder cleanup into this change
>
> changes in v2:
> - use needs_cdm from topology struct
> - drop fb related checks from atomic_mode_set()
>
> Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Minor nit below which I should probably handle while applying the patch.
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 889e9bb42715..989ee8c0e5b4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "msm_drv.h"
> #include "dpu_kms.h"
> @@ -26,6 +27,7 @@
> #include "dpu_hw_dspp.h"
> #include "dpu_hw_dsc.h"
> #include "dpu_hw_merge3d.h"
> +#include "dpu_hw_cdm.h"
> #include "dpu_formats.h"
> #include "dpu_encoder_phys.h"
> #include "dpu_crtc.h"
> @@ -582,6 +584,7 @@ static int dpu_encoder_virt_atomic_check(
> struct drm_display_mode *adj_mode;
> struct msm_display_topology topology;
> struct dpu_global_state *global_state;
> + struct drm_framebuffer *fb;
> struct drm_dsc_config *dsc;
> int i = 0;
> int ret = 0;
> @@ -622,6 +625,22 @@ static int dpu_encoder_virt_atomic_check(
>
> topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
> crtc_state, dsc);
>
> + /*
> +* Use CDM only for writeback at the moment as other interfaces
> cannot handle it.
> +* if writeback itself cannot handle cdm for some reason it will fail
> in its atomic_check()
> +* earlier.
What about s/handle/use/ ?
> +*/
> + if (dpu_enc->disp_info.intf_type == INTF_WB &&
> conn_state->writeback_job) {
> + fb = conn_state->writeback_job->fb;
> +
> + if (fb &&
> DPU_FORMAT_IS_YUV(to_dpu_format(msm_framebuffer_format(fb
> + topology.needs_cdm = true;
> + if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
> + crtc_state->mode_changed = true;
> + else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
> + crtc_state->mode_changed = true;
> + }
> +
> /*
> * Release and Allocate resources on every modeset
> * Dont allocate when active is false.
> @@ -1062,6 +1081,15 @@ static void dpu_encoder_virt_atomic_mode_set(struct
> drm_encoder *drm_enc,
>
> dpu_enc->dsc_mask = dsc_mask;
>
> + if (dpu_enc->disp_info.intf_type == INTF_WB &&
> conn_state->writeback_job) {
> + struct dpu_hw_blk *hw_cdm = NULL;
> +
> + dpu_rm_get_assigned_resources(_kms->rm, global_state,
> + drm_enc->base.id,
> DPU_HW_BLK_CDM,
> + _cdm, 1);
> + dpu_enc->cur_master->hw_cdm = hw_cdm ? to_dpu_hw_cdm(hw_cdm)
> : NULL;
> + }
> +
> cstate = to_dpu_crtc_state(crtc_state);
>
> for (i = 0; i < num_lm; i++) {
> @@ -2050,6 +2078,15 @@ void dpu_encoder_helper_phys_cleanup(struct
> dpu_encoder_phys *phys_enc)
> phys_enc->hw_pp->merge_3d->idx);
> }
>
> + if (phys_enc->hw_cdm) {
> + if (phys_enc->hw_cdm->ops.bind_pingpong_blk &&
> phys_enc->hw_pp)
> +
> phys_enc->hw_cdm->ops.bind_pingpong_blk(phys_enc->hw_cdm,
> +
> PINGPONG_NONE);
> + if (phys_enc->hw_ctl->ops.update_pending_flush_cdm)
> +
> phys_enc->hw_ctl->ops.update_pending_flush_cdm(phys_enc->hw_ctl,
> +
> phys_enc->hw_cdm->idx);
> + }
> +
> if (dpu_enc->dsc) {
> dpu_encoder_unprep_dsc(dpu_enc);
> dpu_enc->dsc = NULL;
> --
> 2.40.1
>
--
With best wishes
Dmitry
Re: [PATCH v3 11/15] drm/msm/dpu: add an API to setup the CDM block for writeback
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote: > > Add an API dpu_encoder_helper_phys_setup_cdm() which can be used by > the writeback encoder to setup the CDM block. > > Currently, this is defined and used within the writeback's physical > encoder layer however, the function can be modified to be used to setup > the CDM block even for non-writeback interfaces. > > Until those modifications are planned and made, keep it local to > writeback. > > changes in v3: > - call bind_pingpong_blk() directly as disable() is dropped > - add dpu_csc10_rgb2yuv_601l to dpu_hw_util.h and use it > - fix kbot error on the function doc > - document that dpu_encoder_helper_phys_setup_cdm() doesn't handle > DPU_CHROMA_H1V2 > > changes in v2: > - add the RGB2YUV CSC matrix to dpu util as needed by CDM > - use dpu_hw_get_csc_cfg() to get and program CSC > - drop usage of setup_csc_data() and setup_cdwn() cdm ops > as they both have been merged into enable() > - drop reduntant hw_cdm and hw_pp checks > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202312102149.qmbcdsg2-...@intel.com/ > Signed-off-by: Abhinav Kumar > --- > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 6 ++ > .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 93 ++- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 14 +++ > 3 files changed, 112 insertions(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 05/16] drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog
On Mon, 11 Dec 2023 at 23:48, Abhinav Kumar wrote:
>
>
>
> On 12/11/2023 1:42 PM, Dmitry Baryshkov wrote:
> > On Mon, 11 Dec 2023 at 23:32, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
> >>> On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar
> >>> wrote:
>
>
>
> On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
> > On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar
> > wrote:
> >>
> >> Add CDM blocks to the sc7280 dpu_hw_catalog to support
> >> YUV format output from writeback block.
> >>
> >> changes in v2:
> >>- remove explicit zero assignment for features
> >>- move sc7280_cdm to dpu_hw_catalog from the sc7280
> >> catalog file as its definition can be re-used
> >>
> >> Signed-off-by: Abhinav Kumar
> >> ---
> >> .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 ++
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13
> >> +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +
> >> 4 files changed, 29 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> index 209675de6742..19c2b7454796 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> @@ -248,6 +248,7 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
> >>.mdss_ver = _mdss_ver,
> >>.caps = _dpu_caps,
> >>.mdp = _mdp,
> >> + .cdm = _cdm,
> >>.ctl_count = ARRAY_SIZE(sc7280_ctl),
> >>.ctl = sc7280_ctl,
> >>.sspp_count = ARRAY_SIZE(sc7280_sspp),
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> index d52aae54bbd5..1be3156cde05 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> @@ -426,6 +426,16 @@ static const struct dpu_dsc_sub_blks dsc_sblk_1 =
> >> {
> >>.ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
> >> };
> >>
> >> +/*
> >> + * CDM sub block config
> >
> > Nit: it is not a subblock config.
> >
>
> Ack.
>
> >> + */
> >> +static const struct dpu_cdm_cfg sc7280_cdm = {
> >
> > I know that I have r-b'ed this patch. But then one thing occurred to
> > me. If this definition is common to all (or almost all) platforms, can
> > we just call it dpu_cdm or dpu_common_cdm?
> >
> >> + .name = "cdm_0",
> >> + .id = CDM_0,
> >> + .len = 0x228,
> >> + .base = 0x79200,
> >> +};
>
> hmmm almost common but not entirely ... msm8998's CDM has a shorter
> len of 0x224 :(
> >>>
> >>> Then sdm845_cdm?
> >>>
> >>
> >> That also has a shorter cdm length.
> >
> > Could you please clarify. According to the downstream DT files all CDM
> > blocks up to (but not including) sm8550 had length 0x224. SM8550 and
> > SM8650 got qcom,sde-cdm-size = <0x220>. But I don't see any registers
> > after 0x204.
> >>
>
> We always list 0x4 more than the last offset.
Yes, so this makes it correct for several latest DT files, which have
qcom,sde-cdm-size = <0x220>.
However all the previous DT files (from msm8998 to sm8450) had
qcom,sde-cdm-size = <0x224>;
>
> In chipsets sdm845 and msm8998, I only see the last offset of CDM as
> 0x220 but in sm8250 and sc7280, the last offset is 0x224. Hence the
> total length is more in sc7280/sm8250 as compared to sdm845/msm8998.
>
> I didnt follow that you do not see any registers after 0x204.
>
> The CDM_MUX is the last offset which has an offset 0x224 from the base
> address. So thats the last offset.
Ack
>
> The newer chipsets have CDM_MUX and the older ones did not. Hence the
> difference in length.
>
> >> BTW, sdm845 is not in this series. It will be part of RFT as we discussed.
> >>
>
> >> +
> >> /*
> >> * VBIF sub blocks config
> >> */
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> index e3c0d007481b..ba82ef4560a6 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> @@ -682,6 +682,17 @@ struct dpu_vbif_cfg {
> >>u32
Re: [PATCH v3 04/15] drm/msm/dpu: move csc matrices to dpu_hw_util
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote: > > Since the type and usage of CSC matrices is spanning across DPU > lets introduce a helper to the dpu_hw_util to return the CSC > corresponding to the request type. This will help to add more > supported CSC types such as the RGB to YUV one which is used in > the case of CDM. > > changes in v3: > - drop the extra wrapper and export the matrices directly > > Signed-off-by: Abhinav Kumar > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 30 > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 31 + > 2 files changed, 31 insertions(+), 30 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 01/15] drm/msm/dpu: add formats check for writeback encoder
On Tue, 12 Dec 2023 at 02:23, Abhinav Kumar wrote:
>
> In preparation for adding more formats to dpu writeback add
> format validation to it to fail any unsupported formats.
>
> changes in v3:
> - rebase on top of msm-next
> - replace drm_atomic_helper_check_wb_encoder_state() with
> drm_atomic_helper_check_wb_connector_state() due to the
> rebase
>
> changes in v2:
> - correct some grammar in the commit text
>
> Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
> writeback")
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
> index bb94909caa25..425415d45ec1 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
> @@ -272,6 +272,7 @@ static int dpu_encoder_phys_wb_atomic_check(
> {
> struct drm_framebuffer *fb;
> const struct drm_display_mode *mode = _state->mode;
> + int ret;
>
> DPU_DEBUG("[atomic_check:%d, \"%s\",%d,%d]\n",
> phys_enc->hw_wb->idx, mode->name, mode->hdisplay,
> mode->vdisplay);
> @@ -308,6 +309,12 @@ static int dpu_encoder_phys_wb_atomic_check(
> return -EINVAL;
> }
>
> + ret =
> drm_atomic_helper_check_wb_connector_state(conn_state->connector,
> conn_state->state);
> + if (ret < 0) {
> + DPU_ERROR("invalid pixel format %p4cc\n",
> >format->format);
> + return ret;
> + }
There is no guarantee that there will be no other checks added to this
helper. So, I think this message is incorrect. If you wish, you can
promote the level of the message in the helper itself.
On the other hand, we rarely print such messages by default. Most of
the checks use drm_dbg.
> +
> return 0;
> }
>
> --
> 2.40.1
>
--
With best wishes
Dmitry
Re: [PATCH v3] drm/msm/dpu: improve DSC allocation
On Tue, 12 Dec 2023 at 02:03, Kuogee Hsieh wrote:
>
>
> On 12/11/2023 1:30 PM, Dmitry Baryshkov wrote:
> > On Mon, 11 Dec 2023 at 20:38, Kuogee Hsieh wrote:
> >> A DCE (Display Compression Engine) contains two DSC hard slice
> >> encoders. Each DCE start with even DSC encoder index followed by
> > "starts". But it will not be correct. The DCE doesn't start with the
> > DSC encoder. DCE consists of two DSC encoders, one has an odd index
> > and another one has an even index.
> >
> >> an odd DSC encoder index. Each encoder can work independently.
> >> But Only two DSC encoders from same DCE can be paired to work
> > only
> >
> >> together to support merge mode. In addition, the DSC with even
> > There are different merge modes. Here you are talking about the DSC merge
> > mode.
> >
> >> index have to mapping to even pingpong index and DSC with odd
> > PINGPONG (end everywhere else).
> >
> > have to be mapped, should be used, etc.
> >
> >> index have to mapping to odd pingpong index at its data path.
> >> This patch improve DSC allocation mechanism with consideration
> > improves
> >
> >> of above factors.
> > of these factors.
> >
> >> Changes in V3:
> >> -- add dpu_rm_pingpong_dsc_check()
> >> -- for pair allocation use i += 2 at for loop
> >>
> >> Changes in V2:
> >> -- split _dpu_rm_reserve_dsc() into _dpu_rm_reserve_dsc_single() and
> >> _dpu_rm_reserve_dsc_pair()
> >>
> >> Fixes: f2803ee91a41 ("drm/msm/disp/dpu1: Add DSC support in RM")
> > This tag is incorrect. The patch should be split into two pieces. One
> > which fixes DSC allocation for DSC 1.1 encoders, where there were no
> > DCE blocks, another one which adds proper handling for DCE.
> > Unless the paired allocation requirement also applies to pre-DCE DSC
> > encoders. But in that case the commit message doesn't make any sense.
> >
> > I checked 4.x Qualcomm kernels. None of them contained any of these
> > restrictions for DSC blocks. Only the displaypack targeting 4.19
> > kernel got these changes. But it predates DCE pairs support.
>
> as I said earlier the rule of odd/even pp-index map to odd/even
> dsc-index is there since dsc v1.1.
>
> I think current code (including down stream code) works by luck to not
> encounter a configuration with two independence paths, one with single
> dsc and the other one use two dsc to support dsc merge mode.
>
> this patch is the fix to enforce this rule for both dsc v1.1 and v1.2
> and I will rework commit message yo have better description.
Good. Does this apply to paired allocation too? I think so, as the
techpack first got the paired allocation and only afterwards it has
got the DSC/PP idx check.
Regarding the patch itself. May I suggest an alternative approach,
which should work better, I think. At least it will not require
'deleting' the PP indices. First you preprocess the pp_to_enc_id array
and list all PP indices selected for this encoder. Then you work with
this array, matching PP and DSC blocks.
--
With best wishes
Dmitry
Re: [RFT PATCH v2 0/4] drm/msm/dpu: enable writeback on the other platforms
On Tue, 12 Dec 2023 at 02:30, Abhinav Kumar wrote: > > > > On 12/2/2023 4:31 PM, Dmitry Baryshkov wrote: > > I was not able to test it on my own, this is a call for testing for the > > owners of these platforms. The git version of modetest now fully > > supports writeback. > > > > Use libdrm >= 2.4.117, run modetest -ac to determine the writeback > > connector, cat /sys/kernel/debug/dri/0/state to determine > > spare CRTC and plane, then run something like: > > > > modetest -M msm -a -s 36@85:1024x768 -o test.d -P 79@85:1024x768 > > > > where 36 is the Writeback connector id, 85 is CRTC and 79 is the plane. > > > > Then press Enter and check the test.d file for the raw image dump. > > > > Changes since v1: > > - Fixed the DPU_CLK_CTRL_WB2 definition > > > > I think this series needs to be re-based as WB_SDM845_MASK is no longer > present in msm-next and 3/4 patches in this series use that. Quite the contrary: the WB_SDM845_MASK was added in https://patchwork.freedesktop.org/patch/570189/?series=127245=1, which is now merged to msm-next-lumag > > > Dmitry Baryshkov (4): > >drm/msm/dpu: enable writeback on SM8150 > >drm/msm/dpu: enable writeback on SC8108X > >drm/msm/dpu: enable writeback on SM6125 > >drm/msm/dpu: enable writeback on SM6350 > > > > .../drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 18 ++ > > .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 18 ++ > > .../drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 18 ++ > > .../drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 18 ++ > > 4 files changed, 72 insertions(+) > > -- With best wishes Dmitry
Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove callback returning void
Hello Uwe Kleine-König, 2023년 12월 7일 (목) 오후 5:03, Uwe Kleine-König 님이 작성: > > Hello Inki, > > On Thu, Dec 07, 2023 at 11:37:44AM +0900, 대인기/Tizen Platform Lab(SR)/삼성전자 > wrote: > > Hello Uwe Kleine-König, > > > > > -Original Message- > > > From: Uwe Kleine-König > > > Sent: Wednesday, November 29, 2023 1:55 AM > > > To: Inki Dae > > > Cc: linux-samsung-...@vger.kernel.org; Daniel Vetter ; > > > Jingoo Han ; Seung-Woo Kim ; > > > Kyungmin Park ; DRI mailing list > > de...@lists.freedesktop.org>; Krzysztof Kozlowski > > > ; ker...@pengutronix.de; Alim Akhtar > > > ; David Airlie ; linux-arm- > > > ker...@lists.infradead.org > > > Subject: Re: [PATCH v3 08/16] drm/exynos: Convert to platform remove > > > callback returning void > > > > > > Hello Inki, > > > > > > On Wed, Nov 08, 2023 at 08:54:54AM +0100, Uwe Kleine-König wrote: > > > > Hello Inki, > > > > > > > > On Wed, Nov 08, 2023 at 01:16:18PM +0900, Inki Dae wrote: > > > > > Sorry for late. There was a merge conflict so I fixed it manually and > > > > > merged. And seems your patch description is duplicated so dropped > > > > > duplicated one. > > > > > > > > Ah. I have a template that generates one patch per driver. I guess this > > > > is the result of using squash instead of fixup while putting all exynos > > > > changes into a single patch. > > > > > > This patch didn't make it into next yet even though it's included in > > > your exynos-drm-next branch at > > > https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git. > > > > > > Is this on purpose? > > > > drm-exynos tree is not included in the next tree. It was previously > > included, but it has been removed. drm-exynos tree is merged into the > > mainline through the drm-next tree, but when the drm-next is > > synchronized to the next tree, a conflict occurred between the > > exynos-drm tree and the drm-next tree. Therefore, I had requested that > > drm-exynos tree be removed from the next. Perhaps I was inexperienced > > in managing the git tree at that time. :) > > That sounds more like a reason to have your tree in next. One of the > core motivations of next is to find inter-tree conflicts early. If such > a conflict occurs and you only notice it when it's time to send your PR > to drm-next (or even later) the pressure to fix the problem is higher. > > Also for patch contributors it's nice to have a "complete" next, their > tests are more expressive then. > > So I want to encourage you to readd your tree to next. Thanks for your feedback. Requested to Stephen Rothwell. :) Thanks, Inki Dae > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ |
[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just one fixup to shutdown relevant issue and two cleanups. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit a2f8994c1001cfa48483a3afa3550016a3ab0a3e: Merge tag 'exynos-drm-next-for-v6.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next (2023-12-12 13:06:29 +0900) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.8 for you to fetch changes up to ead5a41c8f8a13ad7b1c9fd2d7edb1ea909b777f: drm/exynos: dpi: Change connector type to DPI (2023-12-12 13:06:38 +0900) One bug fix - Add a missing call to drm_atomic_helper_shutdown() in Exynos DRM driver. This function is necessary during system shutdown and when the driver is unbound. Without this function, components like panels may not shut down properly, potentially leading to power issue as mentioned in the kernel documentation, specially in the "driver instance overview" secstion of 'drm_drv.c'. Two cleanups - Convert '.remove()' callback function in the Exynos DRM platform driver to a version that returns void instead of an integer. - Change connector type of exynos_drm_dpi.c module to DPI. Douglas Anderson (1): drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time Paul Cercueil (1): drm/exynos: dpi: Change connector type to DPI Uwe Kleine-König (1): drm/exynos: Convert to platform remove callback returning void drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++ drivers/gpu/drm/exynos/exynos7_drm_decon.c| 6 ++ drivers/gpu/drm/exynos/exynos_dp.c| 6 ++ drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 16 +--- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_gsc.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_mic.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_rotator.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_scaler.c| 6 ++ drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 6 ++ drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++ 15 files changed, 40 insertions(+), 56 deletions(-)
[PATCH 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too small which can cause
some monitors to not sync properly. In these instances, adjust htotal
and hsync to round the HFP up, and recalculate the htotal.
Tested-by: Frieder Schrempf # Kontron BL i.MX8MM
with HDMI monitor
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 239d253a7d71..f5795da1d8bb 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1628,6 +1628,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
*bridge,
adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
}
+ /*
+* When using video sync pulses, the HFP, HBP, and HSA are divided
between
+* the available lanes if there is more than one lane. For certain
+* timings and lane configurations, the HFP may not be evenly divisible.
+* If the HFP is rounded down, it ends up being too small which can
cause
+* some monitors to not sync properly. In these instances, adjust htotal
+* and hsync to round the HFP up, and recalculate the htotal. Through
trial
+* and error, it appears that the HBP and HSA do not appearto need the
same
+* correction that HFP does.
+*/
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 1)
{
+ int hfp = adjusted_mode->hsync_start - adjusted_mode->hdisplay;
+ int remainder = hfp % dsi->lanes;
+
+ if (remainder) {
+ adjusted_mode->hsync_start += remainder;
+ adjusted_mode->hsync_end += remainder;
+ adjusted_mode->htotal += remainder;
+ }
+ }
+
return 0;
}
--
2.40.1
[PATCH 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index be5914caa17d..239d253a7d71 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -573,8 +573,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
samsung_dsim *dsi,
u16 _m, best_m;
u8 _s, best_s;
- p_min = DIV_ROUND_UP(fin, (12 * MHZ));
- p_max = fin / (6 * MHZ);
+ p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
+ p_max = fin / (driver_data->pll_fin_min * MHZ);
for (_p = p_min; _p <= p_max; ++_p) {
for (_s = 0; _s <= 5; ++_s) {
--
2.40.1
[PATCH v3 7/7] dma_buf: heaps: secure_heap_mtk: Add a new CMA heap
Create a new MediaTek CMA heap from the CMA reserved buffer.
In this heap, When the first allocating buffer, use cma_alloc to prepare
whole the CMA range, then send its range to TEE to protect and manage.
For the later allocating, we just adds the cma_used_size.
When SVP done, cma_release will release the buffer, then kernel may
reuse it.
For the "CMA" secure heap, "struct cma *cma" is a common property, not just
for MediaTek, so put it into "struct secure_heap" instead of our private
data.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 2 +-
drivers/dma-buf/heaps/secure_heap.h | 4 +
drivers/dma-buf/heaps/secure_heap_mtk.c | 119 +++-
3 files changed, 122 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 12962189878e..f117d91a0a9d 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -21,7 +21,7 @@ config DMABUF_HEAPS_SECURE
config DMABUF_HEAPS_SECURE_MTK
bool "MediaTek DMA-BUF Secure Heap"
- depends on DMABUF_HEAPS_SECURE && TEE=y
+ depends on DMABUF_HEAPS_SECURE && DMA_CMA && TEE=y
help
Enable secure dma-buf heaps for MediaTek platform. This heap is
backed by
TEE client interfaces. If in doubt, say N.
diff --git a/drivers/dma-buf/heaps/secure_heap.h
b/drivers/dma-buf/heaps/secure_heap.h
index 374fd276bdd7..9f80edcd3e1f 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -20,6 +20,10 @@ struct secure_heap {
const struct secure_heap_ops *ops;
+ struct cma *cma;
+ unsigned long cma_paddr;
+ unsigned long cma_size;
+
void*priv_data;
};
diff --git a/drivers/dma-buf/heaps/secure_heap_mtk.c
b/drivers/dma-buf/heaps/secure_heap_mtk.c
index 2c6aaeaf469f..58148120f4ed 100644
--- a/drivers/dma-buf/heaps/secure_heap_mtk.c
+++ b/drivers/dma-buf/heaps/secure_heap_mtk.c
@@ -4,9 +4,11 @@
*
* Copyright (C) 2023 MediaTek Inc.
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +25,13 @@ enum mtk_secure_mem_type {
* management is inside the TEE.
*/
MTK_SECURE_MEMORY_TYPE_CM_TZ= 1,
+ /*
+* MediaTek dynamic chunk memory carved out from CMA.
+* In normal case, the CMA could be used in kernel; When SVP start, we
will
+* allocate whole this CMA and pass whole the CMA PA and size into TEE
to
+* protect it, then the detail memory management also is inside the TEE.
+*/
+ MTK_SECURE_MEMORY_TYPE_CM_CMA = 2,
};
enum mtk_secure_buffer_tee_cmd {
@@ -32,6 +41,8 @@ enum mtk_secure_buffer_tee_cmd {
* [in] value[0].a: The buffer size.
* value[0].b: alignment.
* [in] value[1].a: enum mtk_secure_mem_type.
+* [in] value[2].a: pa base in cma case.
+* value[2].b: The buffer size in cma case.
* [out] value[3].a: The secure handle.
*/
MTK_TZCMD_SECMEM_ZALLOC = 0x1, /* MTK TEE Command ID Base */
@@ -52,6 +63,9 @@ struct mtk_secure_heap_data {
const enum mtk_secure_mem_type mem_type;
+ struct page *cma_page;
+ unsigned long cma_used_size;
+ struct mutexlock; /* lock for cma_used_size */
};
static int mtk_tee_ctx_match(struct tee_ioctl_version_data *ver, const void
*data)
@@ -126,6 +140,10 @@ static int mtk_tee_secure_memory(struct secure_heap
*sec_heap, struct secure_buf
params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
params[1].u.value.a = data->mem_type;
params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+ if (sec_heap->cma && data->mem_type == MTK_SECURE_MEMORY_TYPE_CM_CMA) {
+ params[2].u.value.a = sec_heap->cma_paddr;
+ params[2].u.value.b = sec_heap->cma_size;
+ }
params[3].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
ret = mtk_tee_service_call(data->tee_ctx, data->tee_session,
MTK_TZCMD_SECMEM_ZALLOC, params);
@@ -162,6 +180,48 @@ static void mtk_secure_memory_free(struct secure_heap
*sec_heap, struct secure_b
{
}
+static int mtk_secure_memory_cma_allocate(struct secure_heap *sec_heap,
+ struct secure_buffer *sec_buf)
+{
+ struct mtk_secure_heap_data *data = sec_heap->priv_data;
+ int ret = 0;
+ /*
+* Allocate CMA only when allocating buffer for the first time, and just
+* increase cma_used_size at the other time, Actually the memory
+* allocating is within the TEE.
+*/
+ mutex_lock(>lock);
+ if (!data->cma_used_size) {
+ data->cma_page = cma_alloc(sec_heap->cma, sec_heap->cma_size >>
PAGE_SHIFT,
+ get_order(PAGE_SIZE), false);
[PATCH v3 6/7] dma-buf: heaps: secure_heap_mtk: Add tee memory service call
Add TEE service call for MediaTek heap. We have a limited number of
hardware entries to protect memory, therefore we cannot protect memory
arbitrarily, then our secure memory management is actually inside OPTEE.
The kernel just tells the TEE what size I want and the TEE will return a
"secure address". The secure_address is a reference to a secure buffer
within TEE. We put it in the sg_dma_address, please see the comment in
code.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 16 +
drivers/dma-buf/heaps/secure_heap.h | 2 +
drivers/dma-buf/heaps/secure_heap_mtk.c | 92 +
3 files changed, 110 insertions(+)
diff --git a/drivers/dma-buf/heaps/secure_heap.c
b/drivers/dma-buf/heaps/secure_heap.c
index ca4b433fb3f1..e2b8b97ad4dc 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -94,8 +94,22 @@ static struct sg_table *
secure_heap_map_dma_buf(struct dma_buf_attachment *attachment, enum
dma_data_direction direction)
{
struct secure_heap_attachment *a = attachment->priv;
+ struct dma_buf *dmabuf = attachment->dmabuf;
+ struct secure_buffer *sec_buf = dmabuf->priv;
struct sg_table *table = a->table;
+ /*
+* Technically dma_address refers to the address used by HW, But for
secure buffer
+* we don't know its dma_address in kernel, Instead, we only know its
"secure handle".
+* Thus use this property to save the "secure handle", and the user
will use it to
+* obtain the real address in secure world.
+*
+* Note: CONFIG_DMA_API_DEBUG requires it to be aligned with PAGE_SIZE.
+*/
+ if (sec_buf->secure_address) {
+ sg_dma_address(table->sgl) = sec_buf->secure_address;
+ sg_dma_len(table->sgl) = sec_buf->size;
+ }
return table;
}
@@ -106,6 +120,8 @@ secure_heap_unmap_dma_buf(struct dma_buf_attachment
*attachment, struct sg_table
struct secure_heap_attachment *a = attachment->priv;
WARN_ON(a->table != table);
+ sg_dma_address(table->sgl) = 0;
+ sg_dma_len(table->sgl) = 0;
}
static int
diff --git a/drivers/dma-buf/heaps/secure_heap.h
b/drivers/dma-buf/heaps/secure_heap.h
index 1ce9c431d989..374fd276bdd7 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -11,6 +11,8 @@
struct secure_buffer {
struct dma_heap *heap;
size_t size;
+
+ u64 secure_address; /* A reference to the buffer in
the secure world */
};
struct secure_heap {
diff --git a/drivers/dma-buf/heaps/secure_heap_mtk.c
b/drivers/dma-buf/heaps/secure_heap_mtk.c
index c7e609dd7bd3..2c6aaeaf469f 100644
--- a/drivers/dma-buf/heaps/secure_heap_mtk.c
+++ b/drivers/dma-buf/heaps/secure_heap_mtk.c
@@ -25,6 +25,27 @@ enum mtk_secure_mem_type {
MTK_SECURE_MEMORY_TYPE_CM_TZ= 1,
};
+enum mtk_secure_buffer_tee_cmd {
+ /*
+* Allocate the zeroed secure memory from TEE.
+*
+* [in] value[0].a: The buffer size.
+* value[0].b: alignment.
+* [in] value[1].a: enum mtk_secure_mem_type.
+* [out] value[3].a: The secure handle.
+*/
+ MTK_TZCMD_SECMEM_ZALLOC = 0x1, /* MTK TEE Command ID Base */
+
+ /*
+* Free secure memory.
+*
+* [in] value[0].a: The secure handle of this buffer, It's value[3].a
of
+* MTK_TZCMD_SECMEM_ZALLOC.
+* [out] value[1].a: return value, 0 means successful, otherwise fail.
+*/
+ MTK_TZCMD_SECMEM_FREE = 0x10001,
+};
+
struct mtk_secure_heap_data {
struct tee_context *tee_ctx;
u32 tee_session;
@@ -74,6 +95,73 @@ static int mtk_tee_session_init(struct mtk_secure_heap_data
*data)
return ret;
}
+static int
+mtk_tee_service_call(struct tee_context *tee_ctx, u32 session,
+unsigned int command, struct tee_param *params)
+{
+ struct tee_ioctl_invoke_arg arg = {0};
+ int ret;
+
+ arg.num_params = TEE_PARAM_NUM;
+ arg.session = session;
+ arg.func = command;
+
+ ret = tee_client_invoke_func(tee_ctx, , params);
+ if (ret < 0 || arg.ret) {
+ pr_err("%s: cmd %d ret %d:%x.\n", __func__, command, ret,
arg.ret);
+ ret = -EOPNOTSUPP;
+ }
+ return ret;
+}
+
+static int mtk_tee_secure_memory(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf)
+{
+ struct mtk_secure_heap_data *data = sec_heap->priv_data;
+ struct tee_param params[TEE_PARAM_NUM] = {0};
+ int ret;
+
+ params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+ params[0].u.value.a = sec_buf->size;
+ params[0].u.value.b = PAGE_SIZE;
+ params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+ params[1].u.value.a = data->mem_type;
+
[PATCH v3 5/7] dma-buf: heaps: secure_heap: Add MediaTek secure heap and heap_init
Add a Mediatek secure heap which uses TEE service call to protect
buffer. Currently this secure heap is NULL, Prepare for the later patch.
Mainly there are two changes:
a) Add a heap_init ops since TEE probe late than secure heap, thus
initialize the heap when we require the buffer the first time.
b) Add a priv_data for each heap, like the special data used by MTK
(such as "TEE session") can be placed in priv_data.
Currently our heap depends on CMA which could only be bool, thus
depend on "TEE=y".
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 7 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/secure_heap.c | 11 +++
drivers/dma-buf/heaps/secure_heap.h | 4 +
drivers/dma-buf/heaps/secure_heap_mtk.c | 114
5 files changed, 137 insertions(+)
create mode 100644 drivers/dma-buf/heaps/secure_heap_mtk.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 3a9943e94200..12962189878e 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -18,3 +18,10 @@ config DMABUF_HEAPS_SECURE
depends on DMABUF_HEAPS
help
Choose this option to enable dma-buf secure heap. If in doubt, say N.
+
+config DMABUF_HEAPS_SECURE_MTK
+ bool "MediaTek DMA-BUF Secure Heap"
+ depends on DMABUF_HEAPS_SECURE && TEE=y
+ help
+ Enable secure dma-buf heaps for MediaTek platform. This heap is
backed by
+ TEE client interfaces. If in doubt, say N.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index b1ad9d1f2fbe..9751dea345df 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DMABUF_HEAPS_SECURE) += secure_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_SECURE_MTK) += secure_heap_mtk.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/secure_heap.c
b/drivers/dma-buf/heaps/secure_heap.c
index 7cb4db3e55c2..ca4b433fb3f1 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -150,11 +150,22 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long
size,
unsigned long fd_flags, unsigned long heap_flags)
{
struct secure_heap *sec_heap = dma_heap_get_drvdata(heap);
+ const struct secure_heap_ops *ops = sec_heap->ops;
struct secure_buffer *sec_buf;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct dma_buf *dmabuf;
int ret;
+ /*
+* In some implements, TEE is required to protect buffer. However TEE
probe
+* may be late, Thus heap_init is performed when the first buffer is
requested.
+*/
+ if (ops->heap_init) {
+ ret = ops->heap_init(sec_heap);
+ if (ret)
+ return ERR_PTR(ret);
+ }
+
sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
if (!sec_buf)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/dma-buf/heaps/secure_heap.h
b/drivers/dma-buf/heaps/secure_heap.h
index ec5349cd28d0..1ce9c431d989 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -17,9 +17,13 @@ struct secure_heap {
const char *name;
const struct secure_heap_ops *ops;
+
+ void*priv_data;
};
struct secure_heap_ops {
+ int (*heap_init)(struct secure_heap *sec_heap);
+
int (*memory_alloc)(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf);
void(*memory_free)(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf);
diff --git a/drivers/dma-buf/heaps/secure_heap_mtk.c
b/drivers/dma-buf/heaps/secure_heap_mtk.c
new file mode 100644
index ..c7e609dd7bd3
--- /dev/null
+++ b/drivers/dma-buf/heaps/secure_heap_mtk.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF MediaTek secure heap exporter
+ *
+ * Copyright (C) 2023 MediaTek Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "secure_heap.h"
+
+#define TZ_TA_MEM_UUID_MTK "4477588a-8476-11e2-ad15-e41f1390d676"
+
+#define TEE_PARAM_NUM 4
+
+enum mtk_secure_mem_type {
+ /*
+* MediaTek static chunk memory carved out for TrustZone. The memory
+* management is inside the TEE.
+*/
+ MTK_SECURE_MEMORY_TYPE_CM_TZ= 1,
+};
+
+struct mtk_secure_heap_data {
+ struct tee_context *tee_ctx;
+ u32 tee_session;
+
+ const enum mtk_secure_mem_type mem_type;
+
+};
+
+static int mtk_tee_ctx_match(struct tee_ioctl_version_data *ver, const void
*data)
+{
+ return ver->impl_id == TEE_IMPL_ID_OPTEE;
+}
+
+static int mtk_tee_session_init(struct mtk_secure_heap_data *data)
+{
+ struct
[PATCH v3 4/7] dma-buf: heaps: secure_heap: Add dma_ops
Add the dma_ops for this secure heap. For secure buffer, cache_ops/mmap
are not allowed, thus return EPERM for them.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 103
1 file changed, 103 insertions(+)
diff --git a/drivers/dma-buf/heaps/secure_heap.c
b/drivers/dma-buf/heaps/secure_heap.c
index 925cf8e1c7ce..7cb4db3e55c2 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -12,6 +12,10 @@
#include "secure_heap.h"
+struct secure_heap_attachment {
+ struct sg_table *table;
+};
+
static int secure_heap_memory_allocate(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf)
{
const struct secure_heap_ops *ops = sec_heap->ops;
@@ -43,6 +47,104 @@ static void secure_heap_memory_free(struct secure_heap
*sec_heap, struct secure_
ops->memory_free(sec_heap, sec_buf);
}
+static int secure_heap_attach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attachment)
+{
+ struct secure_buffer *sec_buf = dmabuf->priv;
+ struct secure_heap_attachment *a;
+ struct sg_table *table;
+ int ret;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ table = kzalloc(sizeof(*table), GFP_KERNEL);
+ if (!table) {
+ ret = -ENOMEM;
+ goto err_free_attach;
+ }
+
+ ret = sg_alloc_table(table, 1, GFP_KERNEL);
+ if (ret)
+ goto err_free_sgt;
+ sg_set_page(table->sgl, NULL, sec_buf->size, 0);
+
+ a->table = table;
+ attachment->priv = a;
+
+ return 0;
+
+err_free_sgt:
+ kfree(table);
+err_free_attach:
+ kfree(a);
+ return ret;
+}
+
+static void secure_heap_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attachment)
+{
+ struct secure_heap_attachment *a = attachment->priv;
+
+ sg_free_table(a->table);
+ kfree(a->table);
+ kfree(a);
+}
+
+static struct sg_table *
+secure_heap_map_dma_buf(struct dma_buf_attachment *attachment, enum
dma_data_direction direction)
+{
+ struct secure_heap_attachment *a = attachment->priv;
+ struct sg_table *table = a->table;
+
+ return table;
+}
+
+static void
+secure_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, struct
sg_table *table,
+ enum dma_data_direction direction)
+{
+ struct secure_heap_attachment *a = attachment->priv;
+
+ WARN_ON(a->table != table);
+}
+
+static int
+secure_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, enum
dma_data_direction direction)
+{
+ return -EPERM;
+}
+
+static int
+secure_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, enum
dma_data_direction direction)
+{
+ return -EPERM;
+}
+
+static int secure_heap_dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma)
+{
+ return -EPERM;
+}
+
+static void secure_heap_free(struct dma_buf *dmabuf)
+{
+ struct secure_buffer *sec_buf = dmabuf->priv;
+ struct secure_heap *sec_heap = dma_heap_get_drvdata(sec_buf->heap);
+
+ secure_heap_memory_free(sec_heap, sec_buf);
+ kfree(sec_buf);
+}
+
+static const struct dma_buf_ops sec_heap_buf_ops = {
+ .attach = secure_heap_attach,
+ .detach = secure_heap_detach,
+ .map_dma_buf= secure_heap_map_dma_buf,
+ .unmap_dma_buf = secure_heap_unmap_dma_buf,
+ .begin_cpu_access = secure_heap_dma_buf_begin_cpu_access,
+ .end_cpu_access = secure_heap_dma_buf_end_cpu_access,
+ .mmap = secure_heap_dma_buf_mmap,
+ .release= secure_heap_free,
+};
+
static struct dma_buf *
secure_heap_allocate(struct dma_heap *heap, unsigned long size,
unsigned long fd_flags, unsigned long heap_flags)
@@ -64,6 +166,7 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long
size,
if (ret)
goto err_free_buf;
exp_info.exp_name = dma_heap_get_name(heap);
+ exp_info.ops = _heap_buf_ops;
exp_info.size = sec_buf->size;
exp_info.flags = fd_flags;
exp_info.priv = sec_buf;
--
2.25.1
[PATCH v3 3/7] dma-buf: heaps: secure_heap: Add private heap ops
Add "struct secure_heap_ops". For the secure memory, totally there are
two steps:
a) memory_alloc: Allocate the buffer in kernel;
b) secure_the_memory: Secure/Proect that buffer.
The memory_alloc is mandatory while secure_the_memory is optinal since
it may be part of memory_alloc.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/secure_heap.c | 39 -
drivers/dma-buf/heaps/secure_heap.h | 11
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/secure_heap.c
b/drivers/dma-buf/heaps/secure_heap.c
index e087da5638aa..925cf8e1c7ce 100644
--- a/drivers/dma-buf/heaps/secure_heap.c
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -12,10 +12,42 @@
#include "secure_heap.h"
+static int secure_heap_memory_allocate(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf)
+{
+ const struct secure_heap_ops *ops = sec_heap->ops;
+ int ret;
+
+ ret = ops->memory_alloc(sec_heap, sec_buf);
+ if (ret)
+ return ret;
+
+ if (ops->secure_the_memory) {
+ ret = ops->secure_the_memory(sec_heap, sec_buf);
+ if (ret)
+ goto sec_memory_free;
+ }
+ return 0;
+
+sec_memory_free:
+ ops->memory_free(sec_heap, sec_buf);
+ return ret;
+}
+
+static void secure_heap_memory_free(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf)
+{
+ const struct secure_heap_ops *ops = sec_heap->ops;
+
+ if (ops->unsecure_the_memory)
+ ops->unsecure_the_memory(sec_heap, sec_buf);
+
+ ops->memory_free(sec_heap, sec_buf);
+}
+
static struct dma_buf *
secure_heap_allocate(struct dma_heap *heap, unsigned long size,
unsigned long fd_flags, unsigned long heap_flags)
{
+ struct secure_heap *sec_heap = dma_heap_get_drvdata(heap);
struct secure_buffer *sec_buf;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct dma_buf *dmabuf;
@@ -28,6 +60,9 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long
size,
sec_buf->size = ALIGN(size, PAGE_SIZE);
sec_buf->heap = heap;
+ ret = secure_heap_memory_allocate(sec_heap, sec_buf);
+ if (ret)
+ goto err_free_buf;
exp_info.exp_name = dma_heap_get_name(heap);
exp_info.size = sec_buf->size;
exp_info.flags = fd_flags;
@@ -36,11 +71,13 @@ secure_heap_allocate(struct dma_heap *heap, unsigned long
size,
dmabuf = dma_buf_export(_info);
if (IS_ERR(dmabuf)) {
ret = PTR_ERR(dmabuf);
- goto err_free_buf;
+ goto err_free_sec_mem;
}
return dmabuf;
+err_free_sec_mem:
+ secure_heap_memory_free(sec_heap, sec_buf);
err_free_buf:
kfree(sec_buf);
return ERR_PTR(ret);
diff --git a/drivers/dma-buf/heaps/secure_heap.h
b/drivers/dma-buf/heaps/secure_heap.h
index 50733dc6d4db..ec5349cd28d0 100644
--- a/drivers/dma-buf/heaps/secure_heap.h
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -15,6 +15,17 @@ struct secure_buffer {
struct secure_heap {
const char *name;
+
+ const struct secure_heap_ops *ops;
+};
+
+struct secure_heap_ops {
+ int (*memory_alloc)(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf);
+ void(*memory_free)(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf);
+
+ /* Protect/unprotect the memory */
+ int (*secure_the_memory)(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf);
+ void(*unsecure_the_memory)(struct secure_heap *sec_heap, struct
secure_buffer *sec_buf);
};
int secure_heap_add(struct secure_heap *sec_heap);
--
2.25.1
[PATCH v3 1/7] dt-bindings: reserved-memory: Add mediatek, dynamic-secure-region
Add a binding for describing the dynamic secure reserved memory range. The
memory range also will be defined in the TEE firmware. It means the TEE
will be configured with the same address/size that is being set in this
DT node. Regarding to the detail TEE command, Please search
MTK_TZCMD_SECMEM_ZALLOC and MTK_TZCMD_SECMEM_FREE.
Signed-off-by: Yong Wu
---
.../mediatek,dynamic-secure-region.yaml | 43 +++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
diff --git
a/Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
b/Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
new file mode 100644
index ..4a735aeafc62
--- /dev/null
+++
b/Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/reserved-memory/mediatek,dynamic-secure-region.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Dynamic Reserved Region
+
+description:
+ A memory region that can dynamically transition as a whole between
+ secure and non-secure states. This memory will be protected by OP-TEE
+ when allocations are active and unprotected otherwise.
+
+maintainers:
+ - Yong Wu
+
+allOf:
+ - $ref: reserved-memory.yaml
+
+properties:
+ compatible:
+const: mediatek,dynamic-secure-region
+
+required:
+ - compatible
+ - reg
+ - reusable
+
+unevaluatedProperties: false
+
+examples:
+ - |
+reserved-memory {
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+reserved-memory@8000 {
+compatible = "mediatek,dynamic-secure-region";
+reg = <0x8000 0x1800>;
+reusable;
+};
+};
--
2.25.1
[PATCH v3 2/7] dma-buf: heaps: Initialize a secure heap
Initialize a secure heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 6 +++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/secure_heap.c | 67 +
drivers/dma-buf/heaps/secure_heap.h | 22 ++
4 files changed, 96 insertions(+)
create mode 100644 drivers/dma-buf/heaps/secure_heap.c
create mode 100644 drivers/dma-buf/heaps/secure_heap.h
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..3a9943e94200 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -12,3 +12,9 @@ config DMABUF_HEAPS_CMA
Choose this option to enable dma-buf CMA heap. This heap is backed
by the Contiguous Memory Allocator (CMA). If your system has these
regions, you should say Y here.
+
+config DMABUF_HEAPS_SECURE
+ bool "DMA-BUF Secure Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable dma-buf secure heap. If in doubt, say N.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..b1ad9d1f2fbe 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_SECURE) += secure_heap.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/secure_heap.c
b/drivers/dma-buf/heaps/secure_heap.c
new file mode 100644
index ..e087da5638aa
--- /dev/null
+++ b/drivers/dma-buf/heaps/secure_heap.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF secure heap exporter
+ *
+ * Copyright (C) 2023 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "secure_heap.h"
+
+static struct dma_buf *
+secure_heap_allocate(struct dma_heap *heap, unsigned long size,
+unsigned long fd_flags, unsigned long heap_flags)
+{
+ struct secure_buffer *sec_buf;
+ DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ struct dma_buf *dmabuf;
+ int ret;
+
+ sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
+ if (!sec_buf)
+ return ERR_PTR(-ENOMEM);
+
+ sec_buf->size = ALIGN(size, PAGE_SIZE);
+ sec_buf->heap = heap;
+
+ exp_info.exp_name = dma_heap_get_name(heap);
+ exp_info.size = sec_buf->size;
+ exp_info.flags = fd_flags;
+ exp_info.priv = sec_buf;
+
+ dmabuf = dma_buf_export(_info);
+ if (IS_ERR(dmabuf)) {
+ ret = PTR_ERR(dmabuf);
+ goto err_free_buf;
+ }
+
+ return dmabuf;
+
+err_free_buf:
+ kfree(sec_buf);
+ return ERR_PTR(ret);
+}
+
+static const struct dma_heap_ops sec_heap_ops = {
+ .allocate = secure_heap_allocate,
+};
+
+int secure_heap_add(struct secure_heap *sec_heap)
+{
+ struct dma_heap_export_info exp_info;
+ struct dma_heap *heap;
+
+ exp_info.name = sec_heap->name;
+ exp_info.ops = _heap_ops;
+ exp_info.priv = (void *)sec_heap;
+
+ heap = dma_heap_add(_info);
+ if (IS_ERR(heap))
+ return PTR_ERR(heap);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(secure_heap_add);
diff --git a/drivers/dma-buf/heaps/secure_heap.h
b/drivers/dma-buf/heaps/secure_heap.h
new file mode 100644
index ..50733dc6d4db
--- /dev/null
+++ b/drivers/dma-buf/heaps/secure_heap.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Secure heap Header.
+ *
+ * Copyright (C) 2023 MediaTek, Inc.
+ */
+
+#ifndef _DMABUF_SECURE_HEAP_H_
+#define _DMABUF_SECURE_HEAP_H_
+
+struct secure_buffer {
+ struct dma_heap *heap;
+ size_t size;
+};
+
+struct secure_heap {
+ const char *name;
+};
+
+int secure_heap_add(struct secure_heap *sec_heap);
+
+#endif
--
2.25.1
[PATCH v3 0/7] dma-buf: heaps: Add secure heap
This patchset is for secure video playback and enables other potential uses in the future. The 'secure dma-heap' will be used to allocate dma_buf objects that reference memory in the secure world that is inaccessible/ unmappable by the non-secure (i.e.kernel/userspace) world. That memory will be used by the secure world to store secure information (i.e. decrypted media content). The dma_bufs allocated from the kernel will be passed to V4L2 for video decoding (as input and output). They will also be used by the drm system for rendering of the content. This patchset adds two secure heaps and they will be used v4l2[1] and drm[2]. 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path). The buffer is reserved for the secure world after bootup and it is used for vcodec's ES/working buffer; 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is dynamically reserved for the secure world and will be got when we start playing secure videos, Once the security video playing is complete, the CMA will be released. This heap is used for the vcodec's frame buffer. [1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.d...@mediatek.com/ [2] https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh@mediatek.com/ Change note: v3: Base on v6.7-rc1. 1) Separate the secure heap into a common file(secure_heap.c) and a mtk special file (secure_heap_mtk.c), and put all tee related code into our special file. 2) About dt-binding, a) Add "mediatek," prefix since this is Mediatek TEE firmware definition. b) Mute dt-binding check waring. 3) Remove the normal CMA heap which is a draft for qcom. v2: https://lore.kernel.org/linux-mediatek/2023111559.8218-1-yong...@mediatek.com/ 1) Move John's patches into the vcodec patchset since they use the new dma heap interface directly. https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.d...@mediatek.com/ 2) Reword the dt-binding description. 3) Rename the heap name from mtk_svp to secure_mtk_cm. This means the current vcodec/DRM upstream code doesn't match this. 4) Add a normal CMA heap. currently it should be a draft version. 5) Regarding the UUID, I still use hard code, but put it in a private data which allow the others could set their own UUID. What's more, UUID is necessary for the session with TEE. If we don't have it, we can't communicate with the TEE, including the get_uuid interface, which tries to make uuid more generic, not working. If there is other way to make UUID more general, please free to tell me. v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong...@mediatek.com/ Base on v6.6-rc1. Yong Wu (7): dt-bindings: reserved-memory: Add mediatek,dynamic-secure-region dma-buf: heaps: Initialize a secure heap dma-buf: heaps: secure_heap: Add private heap ops dma-buf: heaps: secure_heap: Add dma_ops dma-buf: heaps: secure_heap: Add MediaTek secure heap and heap_init dma-buf: heaps: secure_heap_mtk: Add tee memory service call dma_buf: heaps: secure_heap_mtk: Add a new CMA heap .../mediatek,dynamic-secure-region.yaml | 43 +++ drivers/dma-buf/heaps/Kconfig | 13 + drivers/dma-buf/heaps/Makefile| 2 + drivers/dma-buf/heaps/secure_heap.c | 234 + drivers/dma-buf/heaps/secure_heap.h | 43 +++ drivers/dma-buf/heaps/secure_heap_mtk.c | 321 ++ 6 files changed, 656 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml create mode 100644 drivers/dma-buf/heaps/secure_heap.c create mode 100644 drivers/dma-buf/heaps/secure_heap.h create mode 100644 drivers/dma-buf/heaps/secure_heap_mtk.c -- 2.18.0
[PATCH 2/2] drm/bridge: ti-sn65dsi86: Never increase the length when reading from AUX
For aux reads, the value `msg->size` indicates the size of the buffer
provided by `msg->buffer`. We should never in any circumstances write
more bytes to the buffer since it may overflow the buffer.
In the ti-sn65dsi86 driver there is one code path that reads the
transfer length from hardware. Even though it's never been seen to be
a problem, we should make extra sure that the hardware isn't
increasing the length since doing so would cause us to overrun the
buffer.
Fixes: 982f589bde7a ("drm/bridge: ti-sn65dsi86: Update reply on aux failures")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 5b8e1dfc458d..7ff465241267 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -527,6 +527,7 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
u32 request_val = AUX_CMD_REQ(msg->request);
u8 *buf = msg->buffer;
unsigned int len = msg->size;
+ unsigned int short_len;
unsigned int val;
int ret;
u8 addr_len[SN_AUX_LENGTH_REG + 1 - SN_AUX_ADDR_19_16_REG];
@@ -600,7 +601,8 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
}
if (val & AUX_IRQ_STATUS_AUX_SHORT) {
- ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, );
+ ret = regmap_read(pdata->regmap, SN_AUX_LENGTH_REG, _len);
+ len = min(len, short_len);
if (ret)
goto exit;
} else if (val & AUX_IRQ_STATUS_NAT_I2C_FAIL) {
--
2.43.0.472.g3155946c3a-goog
[PATCH 1/2] drm/bridge: parade-ps8640: Never increase the length when reading from AUX
While testing, I happened to notice a random crash that looked like:
Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
(allocated on the stack) to the aux->transfer() function. Presumably
if the aux->transfer() writes more than one byte to this buffer then
we're in a bad shape.
Dropping into kgdb, I noticed that "aux->transfer" pointed at
ps8640_aux_transfer().
Reading through ps8640_aux_transfer(), I can see that there are cases
where it could write more bytes to msg->buffer than were specified by
msg->size. This could happen if the hardware reported back something
bogus to us. Let's fix this so we never increase the length.
NOTE: I have no actual way to reproduce this issue but it seems likely
this is what was happening in the crash I looked at.
Fixes: 13afcdd7277e ("drm/bridge: parade-ps8640: Add support for AUX channel")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/parade-ps8640.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 8161b1a1a4b1..fb2ec4264549 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -302,7 +302,7 @@ static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux
*aux,
fallthrough;
case SWAUX_STATUS_ACKM:
- len = data & SWAUX_M_MASK;
+ len = min(len, (unsigned int)(data & SWAUX_M_MASK));
break;
case SWAUX_STATUS_DEFER:
case SWAUX_STATUS_I2C_DEFER:
@@ -310,7 +310,7 @@ static ssize_t ps8640_aux_transfer_msg(struct drm_dp_aux
*aux,
msg->reply |= DP_AUX_NATIVE_REPLY_DEFER;
else
msg->reply |= DP_AUX_I2C_REPLY_DEFER;
- len = data & SWAUX_M_MASK;
+ len = min(len, (unsigned int)(data & SWAUX_M_MASK));
break;
case SWAUX_STATUS_INVALID:
return -EOPNOTSUPP;
--
2.43.0.472.g3155946c3a-goog
Re: [RFT PATCH v2 0/4] drm/msm/dpu: enable writeback on the other platforms
On 12/2/2023 4:31 PM, Dmitry Baryshkov wrote: I was not able to test it on my own, this is a call for testing for the owners of these platforms. The git version of modetest now fully supports writeback. Use libdrm >= 2.4.117, run modetest -ac to determine the writeback connector, cat /sys/kernel/debug/dri/0/state to determine spare CRTC and plane, then run something like: modetest -M msm -a -s 36@85:1024x768 -o test.d -P 79@85:1024x768 where 36 is the Writeback connector id, 85 is CRTC and 79 is the plane. Then press Enter and check the test.d file for the raw image dump. Changes since v1: - Fixed the DPU_CLK_CTRL_WB2 definition I think this series needs to be re-based as WB_SDM845_MASK is no longer present in msm-next and 3/4 patches in this series use that. Dmitry Baryshkov (4): drm/msm/dpu: enable writeback on SM8150 drm/msm/dpu: enable writeback on SC8108X drm/msm/dpu: enable writeback on SM6125 drm/msm/dpu: enable writeback on SM6350 .../drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 18 ++ .../msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h| 18 ++ .../drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 18 ++ .../drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 18 ++ 4 files changed, 72 insertions(+)
Re: Radeon regression in 6.6 kernel
Phillip Susi writes: > And it works, but 6.7-rc5 does not, even though it includes that patch. > Here's the syslog from the attempt. I'll start bisecting again. I checked out the patch that got merged upstream and it also fails. I looked at the two commits, and I see what happened. Your original patch MOVED the call to amdgpu_ttm_set_buffer_funcs_status(). The one that got merged into Linus' tree instead DUPLICATES the call. Oops?
[PATCH v3 15/15] drm/msm/dpu: add cdm blocks to dpu snapshot
Now that CDM block support has been added to DPU lets also add its entry to the DPU snapshot to help debugging. Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index dc24fe4bb3b0..59647ad19906 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -947,6 +947,10 @@ static void dpu_kms_mdp_snapshot(struct msm_disp_state *disp_state, struct msm_k } } + if (cat->cdm) + msm_disp_snapshot_add_block(disp_state, cat->cdm->len, + dpu_kms->mmio + cat->cdm->base, cat->cdm->name); + pm_runtime_put_sync(_kms->pdev->dev); } -- 2.40.1
[PATCH v3 14/15] drm/msm/dpu: introduce separate wb2_format arrays for rgb and yuv
Lets rename the existing wb2_formats array wb2_formats_rgb to indicate
that it has only RGB formats and can be used on any chipset having a WB
block.
Introduce a new wb2_formats_rgb_yuv array to the catalog to
indicate support for YUV formats to writeback in addition to RGB.
Chipsets which have support for CDM block will use the newly added
wb2_formats_rgb_yuv array.
changes in v3:
- change type of wb2_formats_rgb/wb2_formats_rgb_yuv to u32
to fix checkpatch warnings
Signed-off-by: Abhinav Kumar
---
.../msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 4 +-
.../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 4 +-
.../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 4 +-
.../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 4 +-
.../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 4 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 37 ++-
6 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
index 04d2a73dd942..eb5dfff2ec4f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
@@ -341,8 +341,8 @@ static const struct dpu_wb_cfg sm8650_wb[] = {
.name = "wb_2", .id = WB_2,
.base = 0x65000, .len = 0x2c8,
.features = WB_SM8250_MASK,
- .format_list = wb2_formats,
- .num_formats = ARRAY_SIZE(wb2_formats),
+ .format_list = wb2_formats_rgb,
+ .num_formats = ARRAY_SIZE(wb2_formats_rgb),
.xin_id = 6,
.vbif_idx = VBIF_RT,
.maxlinewidth = 4096,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index 58b0f50518c8..a57d50b1f028 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -336,8 +336,8 @@ static const struct dpu_wb_cfg sm8250_wb[] = {
.name = "wb_2", .id = WB_2,
.base = 0x65000, .len = 0x2c8,
.features = WB_SM8250_MASK,
- .format_list = wb2_formats,
- .num_formats = ARRAY_SIZE(wb2_formats),
+ .format_list = wb2_formats_rgb_yuv,
+ .num_formats = ARRAY_SIZE(wb2_formats_rgb_yuv),
.clk_ctrl = DPU_CLK_CTRL_WB2,
.xin_id = 6,
.vbif_idx = VBIF_RT,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
index bcfedfc8251a..7382ebb6e5b2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
@@ -157,8 +157,8 @@ static const struct dpu_wb_cfg sc7180_wb[] = {
.name = "wb_2", .id = WB_2,
.base = 0x65000, .len = 0x2c8,
.features = WB_SM8250_MASK,
- .format_list = wb2_formats,
- .num_formats = ARRAY_SIZE(wb2_formats),
+ .format_list = wb2_formats_rgb,
+ .num_formats = ARRAY_SIZE(wb2_formats_rgb),
.clk_ctrl = DPU_CLK_CTRL_WB2,
.xin_id = 6,
.vbif_idx = VBIF_RT,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 19c2b7454796..2f153e0b5c6a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -169,8 +169,8 @@ static const struct dpu_wb_cfg sc7280_wb[] = {
.name = "wb_2", .id = WB_2,
.base = 0x65000, .len = 0x2c8,
.features = WB_SM8250_MASK,
- .format_list = wb2_formats,
- .num_formats = ARRAY_SIZE(wb2_formats),
+ .format_list = wb2_formats_rgb_yuv,
+ .num_formats = ARRAY_SIZE(wb2_formats_rgb_yuv),
.clk_ctrl = DPU_CLK_CTRL_WB2,
.xin_id = 6,
.vbif_idx = VBIF_RT,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
index bf56265967c0..ad48defa154f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h
@@ -315,8 +315,8 @@ static const struct dpu_wb_cfg sm8550_wb[] = {
.name = "wb_2", .id = WB_2,
.base = 0x65000, .len = 0x2c8,
.features = WB_SM8250_MASK,
- .format_list = wb2_formats,
- .num_formats = ARRAY_SIZE(wb2_formats),
+ .format_list = wb2_formats_rgb,
+ .num_formats = ARRAY_SIZE(wb2_formats_rgb),
.xin_id = 6,
.vbif_idx = VBIF_RT,
.maxlinewidth = 4096,
diff --git
[PATCH v3 11/15] drm/msm/dpu: add an API to setup the CDM block for writeback
Add an API dpu_encoder_helper_phys_setup_cdm() which can be used by
the writeback encoder to setup the CDM block.
Currently, this is defined and used within the writeback's physical
encoder layer however, the function can be modified to be used to setup
the CDM block even for non-writeback interfaces.
Until those modifications are planned and made, keep it local to
writeback.
changes in v3:
- call bind_pingpong_blk() directly as disable() is dropped
- add dpu_csc10_rgb2yuv_601l to dpu_hw_util.h and use it
- fix kbot error on the function doc
- document that dpu_encoder_helper_phys_setup_cdm() doesn't handle
DPU_CHROMA_H1V2
changes in v2:
- add the RGB2YUV CSC matrix to dpu util as needed by CDM
- use dpu_hw_get_csc_cfg() to get and program CSC
- drop usage of setup_csc_data() and setup_cdwn() cdm ops
as they both have been merged into enable()
- drop reduntant hw_cdm and hw_pp checks
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202312102149.qmbcdsg2-...@intel.com/
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 6 ++
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 93 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 14 +++
3 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index e2934a6702d1..bdb89cbbcfb8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -14,8 +14,10 @@
#include "dpu_hw_intf.h"
#include "dpu_hw_wb.h"
#include "dpu_hw_pingpong.h"
+#include "dpu_hw_cdm.h"
#include "dpu_hw_ctl.h"
#include "dpu_hw_top.h"
+#include "dpu_hw_util.h"
#include "dpu_encoder.h"
#include "dpu_crtc.h"
@@ -150,6 +152,7 @@ enum dpu_intr_idx {
* @hw_pp: Hardware interface to the ping pong registers
* @hw_intf: Hardware interface to the intf registers
* @hw_wb: Hardware interface to the wb registers
+ * @hw_cdm:Hardware interface to the CDM registers
* @dpu_kms: Pointer to the dpu_kms top level
* @cached_mode: DRM mode cached at mode_set time, acted on in enable
* @enabled: Whether the encoder has enabled and running a mode
@@ -178,6 +181,7 @@ struct dpu_encoder_phys {
struct dpu_hw_pingpong *hw_pp;
struct dpu_hw_intf *hw_intf;
struct dpu_hw_wb *hw_wb;
+ struct dpu_hw_cdm *hw_cdm;
struct dpu_kms *dpu_kms;
struct drm_display_mode cached_mode;
enum dpu_enc_split_role split_role;
@@ -207,6 +211,7 @@ static inline int dpu_encoder_phys_inc_pending(struct
dpu_encoder_phys *phys)
* @wbirq_refcount: Reference count of writeback interrupt
* @wb_done_timeout_cnt: number of wb done irq timeout errors
* @wb_cfg: writeback block config to store fb related details
+ * @cdm_cfg: cdm block config needed to store writeback block's CDM
configuration
* @wb_conn: backpointer to writeback connector
* @wb_job: backpointer to current writeback job
* @dest: dpu buffer layout for current writeback output buffer
@@ -216,6 +221,7 @@ struct dpu_encoder_phys_wb {
atomic_t wbirq_refcount;
int wb_done_timeout_cnt;
struct dpu_hw_wb_cfg wb_cfg;
+ struct dpu_hw_cdm_cfg cdm_cfg;
struct drm_writeback_connector *wb_conn;
struct drm_writeback_job *wb_job;
struct dpu_hw_fmt_layout dest;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 8f05f2a1fc24..85cb8596737d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -259,6 +259,96 @@ static void dpu_encoder_phys_wb_setup_ctl(struct
dpu_encoder_phys *phys_enc)
}
}
+/**
+ * dpu_encoder_helper_phys_setup_cdm - setup chroma down sampling block
+ * This API does not handle
DPU_CHROMA_H1V2.
+ * @phys_enc:Pointer to physical encoder
+ */
+static void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys
*phys_enc)
+{
+ struct dpu_hw_cdm *hw_cdm;
+ struct dpu_hw_cdm_cfg *cdm_cfg;
+ struct dpu_hw_pingpong *hw_pp;
+ struct dpu_encoder_phys_wb *wb_enc;
+ const struct msm_format *format;
+ const struct dpu_format *dpu_fmt;
+ struct drm_writeback_job *wb_job;
+ int ret;
+
+ if (!phys_enc)
+ return;
+
+ wb_enc = to_dpu_encoder_phys_wb(phys_enc);
+ cdm_cfg = _enc->cdm_cfg;
+ hw_pp = phys_enc->hw_pp;
+ hw_cdm = phys_enc->hw_cdm;
+ wb_job = wb_enc->wb_job;
+
+ format = msm_framebuffer_format(wb_enc->wb_job->fb);
+ dpu_fmt = dpu_get_dpu_format_ext(format->pixel_format,
wb_job->fb->modifier);
+
+ if (!hw_cdm)
+ return;
+
+
[PATCH v3 06/15] drm/msm/dpu: add cdm blocks to sm8250 dpu_hw_catalog
Add CDM blocks to the sm8250 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- re-use the cdm definition from sc7280
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index 2359c16e9206..58b0f50518c8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -384,6 +384,7 @@ const struct dpu_mdss_cfg dpu_sm8250_cfg = {
.mdss_ver = _mdss_ver,
.caps = _dpu_caps,
.mdp = _mdp,
+ .cdm = _cdm,
.ctl_count = ARRAY_SIZE(sm8250_ctl),
.ctl = sm8250_ctl,
.sspp_count = ARRAY_SIZE(sm8250_sspp),
--
2.40.1
[PATCH v3 10/15] drm/msm/dpu: add CDM related logic to dpu_hw_ctl layer
CDM block will need its own logic to program the flush and active
bits in the dpu_hw_ctl layer.
Make necessary changes in dpu_hw_ctl to support CDM programming.
changes in v3:
- drop unused cdm_active as reported by kbot
- retained the R-b as its a trivial change
changes in v2:
- remove unused empty line
- pass in cdm_num to update_pending_flush_cdm()
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202312102047.s0i69pcs-...@intel.com/
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 33 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 12
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index e7b680a151d6..e76565c3e6a4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -32,11 +32,13 @@
#define CTL_DSC_ACTIVE0x0E8
#define CTL_WB_ACTIVE 0x0EC
#define CTL_INTF_ACTIVE 0x0F4
+#define CTL_CDM_ACTIVE0x0F8
#define CTL_FETCH_PIPE_ACTIVE 0x0FC
#define CTL_MERGE_3D_FLUSH0x100
#define CTL_DSC_FLUSH0x104
#define CTL_WB_FLUSH 0x108
#define CTL_INTF_FLUSH0x110
+#define CTL_CDM_FLUSH0x114
#define CTL_INTF_MASTER 0x134
#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
@@ -46,6 +48,7 @@
#define DPU_REG_RESET_TIMEOUT_US2000
#define MERGE_3D_IDX 23
#define DSC_IDX22
+#define CDM_IDX 26
#define INTF_IDX 31
#define WB_IDX 16
#define DSPP_IDX 29 /* From DPU hw rev 7.x.x */
@@ -107,6 +110,7 @@ static inline void dpu_hw_ctl_clear_pending_flush(struct
dpu_hw_ctl *ctx)
ctx->pending_wb_flush_mask = 0;
ctx->pending_merge_3d_flush_mask = 0;
ctx->pending_dsc_flush_mask = 0;
+ ctx->pending_cdm_flush_mask = 0;
memset(ctx->pending_dspp_flush_mask, 0,
sizeof(ctx->pending_dspp_flush_mask));
@@ -151,6 +155,10 @@ static inline void dpu_hw_ctl_trigger_flush_v1(struct
dpu_hw_ctl *ctx)
DPU_REG_WRITE(>hw, CTL_DSC_FLUSH,
ctx->pending_dsc_flush_mask);
+ if (ctx->pending_flush_mask & BIT(CDM_IDX))
+ DPU_REG_WRITE(>hw, CTL_CDM_FLUSH,
+ ctx->pending_cdm_flush_mask);
+
DPU_REG_WRITE(>hw, CTL_FLUSH, ctx->pending_flush_mask);
}
@@ -282,6 +290,13 @@ static void dpu_hw_ctl_update_pending_flush_wb(struct
dpu_hw_ctl *ctx,
}
}
+static void dpu_hw_ctl_update_pending_flush_cdm(struct dpu_hw_ctl *ctx, enum
dpu_cdm cdm_num)
+{
+ /* update pending flush only if CDM_0 is flushed */
+ if (cdm_num == CDM_0)
+ ctx->pending_flush_mask |= BIT(CDM_IDX);
+}
+
static void dpu_hw_ctl_update_pending_flush_wb_v1(struct dpu_hw_ctl *ctx,
enum dpu_wb wb)
{
@@ -310,6 +325,12 @@ static void dpu_hw_ctl_update_pending_flush_dsc_v1(struct
dpu_hw_ctl *ctx,
ctx->pending_flush_mask |= BIT(DSC_IDX);
}
+static void dpu_hw_ctl_update_pending_flush_cdm_v1(struct dpu_hw_ctl *ctx,
enum dpu_cdm cdm_num)
+{
+ ctx->pending_cdm_flush_mask |= BIT(cdm_num - CDM_0);
+ ctx->pending_flush_mask |= BIT(CDM_IDX);
+}
+
static void dpu_hw_ctl_update_pending_flush_dspp(struct dpu_hw_ctl *ctx,
enum dpu_dspp dspp, u32 dspp_sub_blk)
{
@@ -543,6 +564,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->dsc)
DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
+
+ if (cfg->cdm)
+ DPU_REG_WRITE(c, CTL_CDM_ACTIVE, cfg->cdm);
}
static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
@@ -586,6 +610,7 @@ static void dpu_hw_ctl_reset_intf_cfg_v1(struct dpu_hw_ctl
*ctx,
u32 wb_active = 0;
u32 merge3d_active = 0;
u32 dsc_active;
+ u32 cdm_active;
/*
* This API resets each portion of the CTL path namely,
@@ -621,6 +646,12 @@ static void dpu_hw_ctl_reset_intf_cfg_v1(struct dpu_hw_ctl
*ctx,
dsc_active &= ~cfg->dsc;
DPU_REG_WRITE(c, CTL_DSC_ACTIVE, dsc_active);
}
+
+ if (cfg->cdm) {
+ cdm_active = DPU_REG_READ(c, CTL_CDM_ACTIVE);
+ cdm_active &= ~cfg->cdm;
+ DPU_REG_WRITE(c, CTL_CDM_ACTIVE, cdm_active);
+ }
}
static void dpu_hw_ctl_set_fetch_pipe_active(struct dpu_hw_ctl *ctx,
@@ -654,12 +685,14 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->update_pending_flush_wb =
dpu_hw_ctl_update_pending_flush_wb_v1;
ops->update_pending_flush_dsc =
dpu_hw_ctl_update_pending_flush_dsc_v1;
+ ops->update_pending_flush_cdm =
[PATCH v3 13/15] drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output
Reserve CDM blocks for writeback if the format of the output fb
is YUV. At the moment, the reservation is done only for writeback
but can easily be extended by relaxing the checks once other
interfaces are ready to output YUV.
changes in v3:
- squash CDM disable during encoder cleanup into this change
changes in v2:
- use needs_cdm from topology struct
- drop fb related checks from atomic_mode_set()
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 889e9bb42715..989ee8c0e5b4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "msm_drv.h"
#include "dpu_kms.h"
@@ -26,6 +27,7 @@
#include "dpu_hw_dspp.h"
#include "dpu_hw_dsc.h"
#include "dpu_hw_merge3d.h"
+#include "dpu_hw_cdm.h"
#include "dpu_formats.h"
#include "dpu_encoder_phys.h"
#include "dpu_crtc.h"
@@ -582,6 +584,7 @@ static int dpu_encoder_virt_atomic_check(
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
struct dpu_global_state *global_state;
+ struct drm_framebuffer *fb;
struct drm_dsc_config *dsc;
int i = 0;
int ret = 0;
@@ -622,6 +625,22 @@ static int dpu_encoder_virt_atomic_check(
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state, dsc);
+ /*
+* Use CDM only for writeback at the moment as other interfaces cannot
handle it.
+* if writeback itself cannot handle cdm for some reason it will fail
in its atomic_check()
+* earlier.
+*/
+ if (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
+ fb = conn_state->writeback_job->fb;
+
+ if (fb &&
DPU_FORMAT_IS_YUV(to_dpu_format(msm_framebuffer_format(fb
+ topology.needs_cdm = true;
+ if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
+ else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
+ }
+
/*
* Release and Allocate resources on every modeset
* Dont allocate when active is false.
@@ -1062,6 +1081,15 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
dpu_enc->dsc_mask = dsc_mask;
+ if (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
+ struct dpu_hw_blk *hw_cdm = NULL;
+
+ dpu_rm_get_assigned_resources(_kms->rm, global_state,
+ drm_enc->base.id, DPU_HW_BLK_CDM,
+ _cdm, 1);
+ dpu_enc->cur_master->hw_cdm = hw_cdm ? to_dpu_hw_cdm(hw_cdm) :
NULL;
+ }
+
cstate = to_dpu_crtc_state(crtc_state);
for (i = 0; i < num_lm; i++) {
@@ -2050,6 +2078,15 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
phys_enc->hw_pp->merge_3d->idx);
}
+ if (phys_enc->hw_cdm) {
+ if (phys_enc->hw_cdm->ops.bind_pingpong_blk && phys_enc->hw_pp)
+
phys_enc->hw_cdm->ops.bind_pingpong_blk(phys_enc->hw_cdm,
+ PINGPONG_NONE);
+ if (phys_enc->hw_ctl->ops.update_pending_flush_cdm)
+
phys_enc->hw_ctl->ops.update_pending_flush_cdm(phys_enc->hw_ctl,
+
phys_enc->hw_cdm->idx);
+ }
+
if (dpu_enc->dsc) {
dpu_encoder_unprep_dsc(dpu_enc);
dpu_enc->dsc = NULL;
--
2.40.1
[PATCH v3 12/15] drm/msm/dpu: plug-in the cdm related bits to writeback setup
To setup and enable CDM block for the writeback pipeline, lets
add the pieces together to set the active bits and the flush
bits for the CDM block.
changes in v2:
- passed the cdm idx to update_pending_flush_cdm()
(have retained the R-b as its a minor change)
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 85cb8596737d..0a28198886d5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -214,6 +214,7 @@ static void dpu_encoder_phys_wb_setup_ctl(struct
dpu_encoder_phys *phys_enc)
{
struct dpu_hw_wb *hw_wb;
struct dpu_hw_ctl *ctl;
+ struct dpu_hw_cdm *hw_cdm;
if (!phys_enc) {
DPU_ERROR("invalid encoder\n");
@@ -222,6 +223,7 @@ static void dpu_encoder_phys_wb_setup_ctl(struct
dpu_encoder_phys *phys_enc)
hw_wb = phys_enc->hw_wb;
ctl = phys_enc->hw_ctl;
+ hw_cdm = phys_enc->hw_cdm;
if (test_bit(DPU_CTL_ACTIVE_CFG, >caps->features) &&
(phys_enc->hw_ctl &&
@@ -238,6 +240,9 @@ static void dpu_encoder_phys_wb_setup_ctl(struct
dpu_encoder_phys *phys_enc)
if (mode_3d && hw_pp && hw_pp->merge_3d)
intf_cfg.merge_3d = hw_pp->merge_3d->idx;
+ if (hw_cdm)
+ intf_cfg.cdm = hw_cdm->idx;
+
if (phys_enc->hw_pp->merge_3d &&
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode)
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
mode_3d);
@@ -418,6 +423,7 @@ static void _dpu_encoder_phys_wb_update_flush(struct
dpu_encoder_phys *phys_enc)
struct dpu_hw_wb *hw_wb;
struct dpu_hw_ctl *hw_ctl;
struct dpu_hw_pingpong *hw_pp;
+ struct dpu_hw_cdm *hw_cdm;
u32 pending_flush = 0;
if (!phys_enc)
@@ -426,6 +432,7 @@ static void _dpu_encoder_phys_wb_update_flush(struct
dpu_encoder_phys *phys_enc)
hw_wb = phys_enc->hw_wb;
hw_pp = phys_enc->hw_pp;
hw_ctl = phys_enc->hw_ctl;
+ hw_cdm = phys_enc->hw_cdm;
DPU_DEBUG("[wb:%d]\n", hw_wb->idx - WB_0);
@@ -441,6 +448,9 @@ static void _dpu_encoder_phys_wb_update_flush(struct
dpu_encoder_phys *phys_enc)
hw_ctl->ops.update_pending_flush_merge_3d(hw_ctl,
hw_pp->merge_3d->idx);
+ if (hw_cdm && hw_ctl->ops.update_pending_flush_cdm)
+ hw_ctl->ops.update_pending_flush_cdm(hw_ctl, hw_cdm->idx);
+
if (hw_ctl->ops.get_pending_flush)
pending_flush = hw_ctl->ops.get_pending_flush(hw_ctl);
--
2.40.1
[PATCH v3 08/15] drm/msm/dpu: add cdm blocks to RM
Add the RM APIs necessary to initialize and allocate CDM
blocks to be used by the rest of the DPU pipeline.
changes in v2:
- treat cdm_init() failure as fatal
- fixed the commit text
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 13 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 0bb28cf4a6cb..7ed476b96304 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -8,6 +8,7 @@
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
#include "dpu_hw_ctl.h"
+#include "dpu_hw_cdm.h"
#include "dpu_hw_pingpong.h"
#include "dpu_hw_sspp.h"
#include "dpu_hw_intf.h"
@@ -176,6 +177,18 @@ int dpu_rm_init(struct drm_device *dev,
rm->hw_sspp[sspp->id - SSPP_NONE] = hw;
}
+ if (cat->cdm) {
+ struct dpu_hw_cdm *hw;
+
+ hw = dpu_hw_cdm_init(dev, cat->cdm, mmio, cat->mdss_ver);
+ if (IS_ERR(hw)) {
+ rc = PTR_ERR(hw);
+ DPU_ERROR("failed cdm object creation: err %d\n", rc);
+ goto fail;
+ }
+ rm->cdm_blk = >base;
+ }
+
return 0;
fail:
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 36752d837be4..e3f83ebc656b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -22,6 +22,7 @@ struct dpu_global_state;
* @hw_wb: array of wb hardware resources
* @dspp_blks: array of dspp hardware resources
* @hw_sspp: array of sspp hardware resources
+ * @cdm_blk: cdm hardware resource
*/
struct dpu_rm {
struct dpu_hw_blk *pingpong_blks[PINGPONG_MAX - PINGPONG_0];
@@ -33,6 +34,7 @@ struct dpu_rm {
struct dpu_hw_blk *merge_3d_blks[MERGE_3D_MAX - MERGE_3D_0];
struct dpu_hw_blk *dsc_blks[DSC_MAX - DSC_0];
struct dpu_hw_sspp *hw_sspp[SSPP_MAX - SSPP_NONE];
+ struct dpu_hw_blk *cdm_blk;
};
/**
--
2.40.1
[PATCH v3 09/15] drm/msm/dpu: add support to allocate CDM from RM
Even though there is usually only one CDM block, it can be
used by either HDMI, DisplayPort OR Writeback interfaces.
Hence its allocation needs to be tracked properly by the
resource manager to ensure appropriate availability of the
block.
changes in v2:
- move needs_cdm to topology struct
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 38 +++--
drivers/gpu/drm/msm/msm_drv.h | 2 ++
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index 9db4cf61bd29..5df545904057 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -98,6 +98,7 @@ enum dpu_hw_blk_type {
DPU_HW_BLK_DSPP,
DPU_HW_BLK_MERGE_3D,
DPU_HW_BLK_DSC,
+ DPU_HW_BLK_CDM,
DPU_HW_BLK_MAX,
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index df6271017b80..a0cd36e45a01 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -135,6 +135,7 @@ struct dpu_global_state {
uint32_t ctl_to_enc_id[CTL_MAX - CTL_0];
uint32_t dspp_to_enc_id[DSPP_MAX - DSPP_0];
uint32_t dsc_to_enc_id[DSC_MAX - DSC_0];
+ uint32_t cdm_to_enc_id;
};
struct dpu_global_state
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 7ed476b96304..b58a9c2ae326 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -435,6 +435,26 @@ static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
return 0;
}
+static int _dpu_rm_reserve_cdm(struct dpu_rm *rm,
+ struct dpu_global_state *global_state,
+ struct drm_encoder *enc)
+{
+ /* try allocating only one CDM block */
+ if (!rm->cdm_blk) {
+ DPU_ERROR("CDM block does not exist\n");
+ return -EIO;
+ }
+
+ if (global_state->cdm_to_enc_id) {
+ DPU_ERROR("CDM_0 is already allocated\n");
+ return -EIO;
+ }
+
+ global_state->cdm_to_enc_id = enc->base.id;
+
+ return 0;
+}
+
static int _dpu_rm_make_reservation(
struct dpu_rm *rm,
struct dpu_global_state *global_state,
@@ -460,6 +480,14 @@ static int _dpu_rm_make_reservation(
if (ret)
return ret;
+ if (reqs->topology.needs_cdm) {
+ ret = _dpu_rm_reserve_cdm(rm, global_state, enc);
+ if (ret) {
+ DPU_ERROR("unable to find CDM blk\n");
+ return ret;
+ }
+ }
+
return ret;
}
@@ -470,9 +498,9 @@ static int _dpu_rm_populate_requirements(
{
reqs->topology = req_topology;
- DRM_DEBUG_KMS("num_lm: %d num_dsc: %d num_intf: %d\n",
+ DRM_DEBUG_KMS("num_lm: %d num_dsc: %d num_intf: %d cdm: %d\n",
reqs->topology.num_lm, reqs->topology.num_dsc,
- reqs->topology.num_intf);
+ reqs->topology.num_intf, reqs->topology.needs_cdm);
return 0;
}
@@ -501,6 +529,7 @@ void dpu_rm_release(struct dpu_global_state *global_state,
ARRAY_SIZE(global_state->dsc_to_enc_id), enc->base.id);
_dpu_rm_clear_mapping(global_state->dspp_to_enc_id,
ARRAY_SIZE(global_state->dspp_to_enc_id), enc->base.id);
+ _dpu_rm_clear_mapping(_state->cdm_to_enc_id, 1, enc->base.id);
}
int dpu_rm_reserve(
@@ -574,6 +603,11 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
hw_to_enc_id = global_state->dsc_to_enc_id;
max_blks = ARRAY_SIZE(rm->dsc_blks);
break;
+ case DPU_HW_BLK_CDM:
+ hw_blks = >cdm_blk;
+ hw_to_enc_id = _state->cdm_to_enc_id;
+ max_blks = 1;
+ break;
default:
DPU_ERROR("blk type %d not managed by rm\n", type);
return 0;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index c0446fa66b98..16a7cbc0b7dd 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -90,12 +90,14 @@ enum msm_event_wait {
* @num_intf: number of interfaces the panel is mounted on
* @num_dspp: number of dspp blocks used
* @num_dsc: number of Display Stream Compression (DSC) blocks used
+ * @needs_cdm:indicates whether cdm block is needed for this display
topology
*/
struct msm_display_topology {
u32 num_lm;
u32 num_intf;
u32 num_dspp;
u32 num_dsc;
+ bool needs_cdm;
};
/* Commit/Event thread specific structure */
--
2.40.1
[PATCH v3 03/15] drm/msm/dpu: fix writeback programming for YUV cases
For YUV cases, setting the required format bits was missed out in the register programming. Lets fix it now in preparation of adding YUV formats support for writeback. changes in v2: - dropped the fixes tag as its not a fix but adding new functionality Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c index ed0e80616129..e75995f7fcea 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c @@ -89,6 +89,9 @@ static void dpu_hw_wb_setup_format(struct dpu_hw_wb *ctx, dst_format |= BIT(14); /* DST_ALPHA_X */ } + if (DPU_FORMAT_IS_YUV(fmt)) + dst_format |= BIT(15); + pattern = (fmt->element[3] << 24) | (fmt->element[2] << 16) | (fmt->element[1] << 8) | -- 2.40.1
[PATCH v3 07/15] drm/msm/dpu: add dpu_hw_cdm abstraction for CDM block
CDM block comes with its own set of registers and operations
which can be done. In-line with other hardware blocks, this
change adds the dpu_hw_cdm abstraction for the CDM block.
changes in v3:
- fix commit text from sub-blk to blk for CDM
- fix kbot issue for missing static for dpu_hw_cdm_enable()
- fix kbot issue for incorrect documentation style
- add more documentation for enums and struct in dpu_hw_cdm.h
- drop "enable" parameter from bind_pingpong_blk() as we can
just use PINGPONG_NONE for disable cases
- drop unnecessary bit operation for zero value of cdm_cfg
changes in v2:
- replace bit magic with relevant defines
- use drmm_kzalloc instead of kzalloc/free
- some formatting fixes
- inline _setup_cdm_ops()
- protect bind_pingpong_blk with core_rev check
- drop setup_csc_data() and setup_cdwn() ops as they
are merged into enable()
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202312101815.b3zh7pfy-...@intel.com/
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 263
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h | 130 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 1 +
4 files changed, 395 insertions(+)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 49671364fdcf..b1173128b5b9 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -63,6 +63,7 @@ msm-$(CONFIG_DRM_MSM_DPU) += \
disp/dpu1/dpu_encoder_phys_wb.o \
disp/dpu1/dpu_formats.o \
disp/dpu1/dpu_hw_catalog.o \
+ disp/dpu1/dpu_hw_cdm.o \
disp/dpu1/dpu_hw_ctl.o \
disp/dpu1/dpu_hw_dsc.o \
disp/dpu1/dpu_hw_dsc_1_2.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
new file mode 100644
index ..4976f8a05ce7
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023, The Linux Foundation. All rights reserved.
+ */
+
+#include
+
+#include "dpu_hw_mdss.h"
+#include "dpu_hw_util.h"
+#include "dpu_hw_catalog.h"
+#include "dpu_hw_cdm.h"
+#include "dpu_kms.h"
+
+#define CDM_CSC_10_OPMODE 0x000
+#define CDM_CSC_10_BASE0x004
+
+#define CDM_CDWN2_OP_MODE 0x100
+#define CDM_CDWN2_CLAMP_OUT0x104
+#define CDM_CDWN2_PARAMS_3D_0 0x108
+#define CDM_CDWN2_PARAMS_3D_1 0x10C
+#define CDM_CDWN2_COEFF_COSITE_H_0 0x110
+#define CDM_CDWN2_COEFF_COSITE_H_1 0x114
+#define CDM_CDWN2_COEFF_COSITE_H_2 0x118
+#define CDM_CDWN2_COEFF_OFFSITE_H_00x11C
+#define CDM_CDWN2_COEFF_OFFSITE_H_10x120
+#define CDM_CDWN2_COEFF_OFFSITE_H_20x124
+#define CDM_CDWN2_COEFF_COSITE_V 0x128
+#define CDM_CDWN2_COEFF_OFFSITE_V 0x12C
+#define CDM_CDWN2_OUT_SIZE 0x130
+
+#define CDM_HDMI_PACK_OP_MODE 0x200
+#define CDM_CSC_10_MATRIX_COEFF_0 0x004
+
+#define CDM_MUX0x224
+
+/* CDM CDWN2 sub-block bit definitions */
+#define CDM_CDWN2_OP_MODE_EN BIT(0)
+#define CDM_CDWN2_OP_MODE_ENABLE_HBIT(1)
+#define CDM_CDWN2_OP_MODE_ENABLE_VBIT(2)
+#define CDM_CDWN2_OP_MODE_METHOD_H_AVGBIT(3)
+#define CDM_CDWN2_OP_MODE_METHOD_H_COSITE BIT(4)
+#define CDM_CDWN2_OP_MODE_METHOD_V_AVGBIT(5)
+#define CDM_CDWN2_OP_MODE_METHOD_V_COSITE BIT(6)
+#define CDM_CDWN2_OP_MODE_BITS_OUT_8BIT BIT(7)
+#define CDM_CDWN2_OP_MODE_METHOD_H_OFFSITEGENMASK(4, 3)
+#define CDM_CDWN2_OP_MODE_METHOD_V_OFFSITEGENMASK(6, 5)
+#define CDM_CDWN2_V_PIXEL_DROP_MASK GENMASK(6, 5)
+#define CDM_CDWN2_H_PIXEL_DROP_MASK GENMASK(4, 3)
+
+/* CDM CSC10 sub-block bit definitions */
+#define CDM_CSC10_OP_MODE_EN BIT(0)
+#define CDM_CSC10_OP_MODE_SRC_FMT_YUV BIT(1)
+#define CDM_CSC10_OP_MODE_DST_FMT_YUV BIT(2)
+
+/* CDM HDMI pack sub-block bit definitions */
+#define CDM_HDMI_PACK_OP_MODE_EN BIT(0)
+
+/*
+ * Horizontal coefficients for cosite chroma downscale
+ * s13 representation of coefficients
+ */
+static u32 cosite_h_coeff[] = {0x0016, 0x01cc, 0x019e};
+
+/*
+ * Horizontal coefficients for offsite chroma downscale
+ */
+static u32 offsite_h_coeff[] = {0x000b0005, 0x01db01eb, 0x00e40046};
+
+/*
+ * Vertical coefficients for cosite chroma downscale
+ */
+static u32 cosite_v_coeff[] = {0x00080004};
+/*
+ * Vertical coefficients for offsite chroma downscale
+ */
+static u32 offsite_v_coeff[] = {0x00060002};
+
+static int
[PATCH v3 05/15] drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v3:
- change the comment from sub-blk to clk for CDM
changes in v2:
- remove explicit zero assignment for features
- move sc7280_cdm to dpu_hw_catalog from the sc7280
catalog file as its definition can be re-used
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 209675de6742..19c2b7454796 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -248,6 +248,7 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
.mdss_ver = _mdss_ver,
.caps = _dpu_caps,
.mdp = _mdp,
+ .cdm = _cdm,
.ctl_count = ARRAY_SIZE(sc7280_ctl),
.ctl = sc7280_ctl,
.sspp_count = ARRAY_SIZE(sc7280_sspp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index d52aae54bbd5..b304bebedb84 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -426,6 +426,16 @@ static const struct dpu_dsc_sub_blks dsc_sblk_1 = {
.ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
};
+/*
+ * CDM block config
+ */
+static const struct dpu_cdm_cfg sc7280_cdm = {
+ .name = "cdm_0",
+ .id = CDM_0,
+ .len = 0x228,
+ .base = 0x79200,
+};
+
/*
* VBIF sub blocks config
*/
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index e3c0d007481b..ba82ef4560a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -682,6 +682,17 @@ struct dpu_vbif_cfg {
u32 memtype[MAX_XIN_COUNT];
};
+/**
+ * struct dpu_cdm_cfg - information of chroma down blocks
+ * @name string name for debug purposes
+ * @id enum identifying this block
+ * @base register offset of this block
+ * @features bit mask identifying sub-blocks/features
+ */
+struct dpu_cdm_cfg {
+ DPU_HW_BLK_INFO;
+};
+
/**
* Define CDP use cases
* @DPU_PERF_CDP_UDAGE_RT: real-time use cases
@@ -805,6 +816,8 @@ struct dpu_mdss_cfg {
u32 wb_count;
const struct dpu_wb_cfg *wb;
+ const struct dpu_cdm_cfg *cdm;
+
u32 ad_count;
u32 dspp_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index a6702b2bfc68..f319c8232ea5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -185,6 +185,11 @@ enum dpu_dsc {
DSC_MAX
};
+enum dpu_cdm {
+ CDM_0 = 1,
+ CDM_MAX
+};
+
enum dpu_pingpong {
PINGPONG_NONE,
PINGPONG_0,
--
2.40.1
[PATCH v3 04/15] drm/msm/dpu: move csc matrices to dpu_hw_util
Since the type and usage of CSC matrices is spanning across DPU
lets introduce a helper to the dpu_hw_util to return the CSC
corresponding to the request type. This will help to add more
supported CSC types such as the RGB to YUV one which is used in
the case of CDM.
changes in v3:
- drop the extra wrapper and export the matrices directly
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 30
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 31 +
2 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index fe083b2e5696..aa50005042d1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
@@ -19,6 +19,36 @@
#define MISR_CTRL_STATUS_CLEAR BIT(10)
#define MISR_CTRL_FREE_RUN_MASK BIT(31)
+static const struct dpu_csc_cfg dpu_csc_YUV2RGB_601L = {
+ {
+ /* S15.16 format */
+ 0x00012A00, 0x, 0x00019880,
+ 0x00012A00, 0x9B80, 0x3000,
+ 0x00012A00, 0x00020480, 0x,
+ },
+ /* signed bias */
+ { 0xfff0, 0xff80, 0xff80,},
+ { 0x0, 0x0, 0x0,},
+ /* unsigned clamp */
+ { 0x10, 0xeb, 0x10, 0xf0, 0x10, 0xf0,},
+ { 0x00, 0xff, 0x00, 0xff, 0x00, 0xff,},
+};
+
+static const struct dpu_csc_cfg dpu_csc10_YUV2RGB_601L = {
+ {
+ /* S15.16 format */
+ 0x00012A00, 0x, 0x00019880,
+ 0x00012A00, 0x9B80, 0x3000,
+ 0x00012A00, 0x00020480, 0x,
+ },
+ /* signed bias */
+ { 0xffc0, 0xfe00, 0xfe00,},
+ { 0x0, 0x0, 0x0,},
+ /* unsigned clamp */
+ { 0x40, 0x3ac, 0x40, 0x3c0, 0x40, 0x3c0,},
+ { 0x00, 0x3ff, 0x00, 0x3ff, 0x00, 0x3ff,},
+};
+
/*
* This is the common struct maintained by each sub block
* for mapping the register offsets in this block to the
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 3235ab132540..ff975ad51145 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -21,6 +21,7 @@
#include "dpu_kms.h"
#include "dpu_formats.h"
#include "dpu_hw_sspp.h"
+#include "dpu_hw_util.h"
#include "dpu_trace.h"
#include "dpu_crtc.h"
#include "dpu_vbif.h"
@@ -508,36 +509,6 @@ static void _dpu_plane_setup_pixel_ext(struct
dpu_hw_scaler3_cfg *scale_cfg,
}
}
-static const struct dpu_csc_cfg dpu_csc_YUV2RGB_601L = {
- {
- /* S15.16 format */
- 0x00012A00, 0x, 0x00019880,
- 0x00012A00, 0x9B80, 0x3000,
- 0x00012A00, 0x00020480, 0x,
- },
- /* signed bias */
- { 0xfff0, 0xff80, 0xff80,},
- { 0x0, 0x0, 0x0,},
- /* unsigned clamp */
- { 0x10, 0xeb, 0x10, 0xf0, 0x10, 0xf0,},
- { 0x00, 0xff, 0x00, 0xff, 0x00, 0xff,},
-};
-
-static const struct dpu_csc_cfg dpu_csc10_YUV2RGB_601L = {
- {
- /* S15.16 format */
- 0x00012A00, 0x, 0x00019880,
- 0x00012A00, 0x9B80, 0x3000,
- 0x00012A00, 0x00020480, 0x,
- },
- /* signed bias */
- { 0xffc0, 0xfe00, 0xfe00,},
- { 0x0, 0x0, 0x0,},
- /* unsigned clamp */
- { 0x40, 0x3ac, 0x40, 0x3c0, 0x40, 0x3c0,},
- { 0x00, 0x3ff, 0x00, 0x3ff, 0x00, 0x3ff,},
-};
-
static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct dpu_sw_pipe *pipe,
const struct dpu_format
*fmt)
{
--
2.40.1
[PATCH v3 02/15] drm/msm/dpu: rename dpu_encoder_phys_wb_setup_cdp to match its functionality
dpu_encoder_phys_wb_setup_cdp() is not programming the chroma down
prefetch block. Its setting up the display ctl path for writeback.
Hence rename it to dpu_encoder_phys_wb_setup_ctl() to match what its
actually doing.
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
writeback")
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 425415d45ec1..8f05f2a1fc24 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -207,10 +207,10 @@ static void dpu_encoder_phys_wb_setup_fb(struct
dpu_encoder_phys *phys_enc,
}
/**
- * dpu_encoder_phys_wb_setup_cdp - setup chroma down prefetch block
+ * dpu_encoder_phys_wb_setup_ctl - setup wb pipeline for ctl path
* @phys_enc:Pointer to physical encoder
*/
-static void dpu_encoder_phys_wb_setup_cdp(struct dpu_encoder_phys *phys_enc)
+static void dpu_encoder_phys_wb_setup_ctl(struct dpu_encoder_phys *phys_enc)
{
struct dpu_hw_wb *hw_wb;
struct dpu_hw_ctl *ctl;
@@ -382,7 +382,7 @@ static void dpu_encoder_phys_wb_setup(
dpu_encoder_phys_wb_setup_fb(phys_enc, fb);
- dpu_encoder_phys_wb_setup_cdp(phys_enc);
+ dpu_encoder_phys_wb_setup_ctl(phys_enc);
}
--
2.40.1
[PATCH v3 01/15] drm/msm/dpu: add formats check for writeback encoder
In preparation for adding more formats to dpu writeback add
format validation to it to fail any unsupported formats.
changes in v3:
- rebase on top of msm-next
- replace drm_atomic_helper_check_wb_encoder_state() with
drm_atomic_helper_check_wb_connector_state() due to the
rebase
changes in v2:
- correct some grammar in the commit text
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
writeback")
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index bb94909caa25..425415d45ec1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -272,6 +272,7 @@ static int dpu_encoder_phys_wb_atomic_check(
{
struct drm_framebuffer *fb;
const struct drm_display_mode *mode = _state->mode;
+ int ret;
DPU_DEBUG("[atomic_check:%d, \"%s\",%d,%d]\n",
phys_enc->hw_wb->idx, mode->name, mode->hdisplay,
mode->vdisplay);
@@ -308,6 +309,12 @@ static int dpu_encoder_phys_wb_atomic_check(
return -EINVAL;
}
+ ret = drm_atomic_helper_check_wb_connector_state(conn_state->connector,
conn_state->state);
+ if (ret < 0) {
+ DPU_ERROR("invalid pixel format %p4cc\n", >format->format);
+ return ret;
+ }
+
return 0;
}
--
2.40.1
[PATCH v3 00/15] Add CDM support for MSM writeback
Chroma Down Sampling (CDM) block is a hardware block in the DPU pipeline which among other things has a CSC block that can convert RGB input from the DPU to YUV data. This block can be used with either HDMI, DP or writeback interface. In this series, lets first add the support for CDM block to be used with writeback and then follow-up with support for other interfaces such as DP. This was validated by adding support to pass custom output format to the IGT's kms_writeback test-case, specifically only for the output dump test-case [1]. The usage for this is: ./kms_writeback -d -f So for NV12, this can be verified with the below command: ./kms_writeback -d -f NV12 [1] : https://patchwork.freedesktop.org/series/122125/ changes in v3: - rebase on top of msm-next - drop the extra wrapper and export the CSC matrices directly - fixes in commit text as requested - fixes for kbot errors as reported - drop "enable" parameter from bind_pingpong_blk() as we can just use PINGPONG_NONE for disable cases - squash cdm changes in encoder cleanup to the change which allocates cdm changes in v2: - rebased on top of current msm-next-lumag - fix commit text of some of the patches - move csc matrices to dpu_hw_util as they span across DPU - move cdm blk define to dpu_hw_catalog as its common across chipsets - remove bit magic in dpu_hw_cdm with relevant defines - use drmm_kzalloc instead of kzalloc/free - protect bind_pingpong_blk with core_rev check - drop setup_csc_data() and setup_cdwn() ops as they are merged into enable() - protect bind_pingpong_blk with core_rev check - drop setup_csc_data() and setup_cdwn() ops as they are merged into enable() - move needs_cdm to topology struct - call update_pending_flush_cdm even when bind_pingpong_blk is not present - drop usage of setup_csc_data() and setup_cdwn() cdm ops as they both have been merged into enable() - drop reduntant hw_cdm and hw_pp checks - drop fb related checks from dpu_encoder::atomic_mode_set() - introduce separate wb2_format arrays for rgb and yuv Abhinav Kumar (15): drm/msm/dpu: add formats check for writeback encoder drm/msm/dpu: rename dpu_encoder_phys_wb_setup_cdp to match its functionality drm/msm/dpu: fix writeback programming for YUV cases drm/msm/dpu: move csc matrices to dpu_hw_util drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog drm/msm/dpu: add cdm blocks to sm8250 dpu_hw_catalog drm/msm/dpu: add dpu_hw_cdm abstraction for CDM block drm/msm/dpu: add cdm blocks to RM drm/msm/dpu: add support to allocate CDM from RM drm/msm/dpu: add CDM related logic to dpu_hw_ctl layer drm/msm/dpu: add an API to setup the CDM block for writeback drm/msm/dpu: plug-in the cdm related bits to writeback setup drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output drm/msm/dpu: introduce separate wb2_format arrays for rgb and yuv drm/msm/dpu: add cdm blocks to dpu snapshot drivers/gpu/drm/msm/Makefile | 1 + .../msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 4 +- .../msm/disp/dpu1/catalog/dpu_6_0_sm8250.h| 5 +- .../msm/disp/dpu1/catalog/dpu_6_2_sc7180.h| 4 +- .../msm/disp/dpu1/catalog/dpu_7_2_sc7280.h| 5 +- .../msm/disp/dpu1/catalog/dpu_9_0_sm8550.h| 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 37 +++ .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 6 + .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 114 +++- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 47 +++- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 13 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c| 263 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h| 130 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 33 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 12 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 7 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 44 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 3 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 31 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 51 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 2 + drivers/gpu/drm/msm/msm_drv.h | 2 + 24 files changed, 777 insertions(+), 46 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.h -- 2.40.1
Re: [PATCH v3] drm/msm/dpu: improve DSC allocation
On 12/11/2023 1:30 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 20:38, Kuogee Hsieh wrote:
A DCE (Display Compression Engine) contains two DSC hard slice
encoders. Each DCE start with even DSC encoder index followed by
"starts". But it will not be correct. The DCE doesn't start with the
DSC encoder. DCE consists of two DSC encoders, one has an odd index
and another one has an even index.
an odd DSC encoder index. Each encoder can work independently.
But Only two DSC encoders from same DCE can be paired to work
only
together to support merge mode. In addition, the DSC with even
There are different merge modes. Here you are talking about the DSC merge mode.
index have to mapping to even pingpong index and DSC with odd
PINGPONG (end everywhere else).
have to be mapped, should be used, etc.
index have to mapping to odd pingpong index at its data path.
This patch improve DSC allocation mechanism with consideration
improves
of above factors.
of these factors.
Changes in V3:
-- add dpu_rm_pingpong_dsc_check()
-- for pair allocation use i += 2 at for loop
Changes in V2:
-- split _dpu_rm_reserve_dsc() into _dpu_rm_reserve_dsc_single() and
_dpu_rm_reserve_dsc_pair()
Fixes: f2803ee91a41 ("drm/msm/disp/dpu1: Add DSC support in RM")
This tag is incorrect. The patch should be split into two pieces. One
which fixes DSC allocation for DSC 1.1 encoders, where there were no
DCE blocks, another one which adds proper handling for DCE.
Unless the paired allocation requirement also applies to pre-DCE DSC
encoders. But in that case the commit message doesn't make any sense.
I checked 4.x Qualcomm kernels. None of them contained any of these
restrictions for DSC blocks. Only the displaypack targeting 4.19
kernel got these changes. But it predates DCE pairs support.
as I said earlier the rule of odd/even pp-index map to odd/even
dsc-index is there since dsc v1.1.
I think current code (including down stream code) works by luck to not
encounter a configuration with two independence paths, one with single
dsc and the other one use two dsc to support dsc merge mode.
this patch is the fix to enforce this rule for both dsc v1.1 and v1.2
and I will rework commit message yo have better description.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 171 ++---
1 file changed, 155 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 17ecf23..43598ee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -470,33 +470,172 @@ static int _dpu_rm_reserve_ctls(
return 0;
}
-static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
+static int _dpu_rm_pingpong_dsc_check(int dsc_idx,
+ uint32_t enc_id,
+ uint32_t *pp_to_enc_id,
+ int pp_max,
+ bool pair)
+{
+ int pp_idx;
+
+ /*
+* find the pingpong index which had been reserved
+* previously at layer mixer allocation
during
+*/
+ for (pp_idx = 0; pp_idx < pp_max; pp_idx++) {
+ if (pp_to_enc_id[pp_idx] == enc_id)
+ break;
+ }
+
+ /*
+* dsc even index must map to pingpong even index
DSC with even index.
be mapped or correspond
+* dsc odd index must map to pingpong odd index
+*/
+ if ((dsc_idx & 0x01) != (pp_idx & 0x01))
+ return -ENAVAIL;
+
+ if (pair) {
+ /*
+* delete pp_idx so that same pp_id can not be paired with
+* next dsc_id
+*/
+ pp_to_enc_id[pp_idx] = 0x;
+ }
Ugh. "Non tangere circulos meos". Move this deletion away from this function.
+
+ return 0;
+
+}
+
+static int _dpu_rm_reserve_dsc_single(struct dpu_rm *rm,
struct dpu_global_state *global_state,
- struct drm_encoder *enc,
+ uint32_t enc_id,
const struct msm_display_topology *top)
{
- int num_dsc = top->num_dsc;
- int i;
+ int num_dsc = 0;
+ int i, ret;
+ int dsc_id[DSC_MAX - DSC_0];
+ uint32_t *pp_enc_id = global_state->pingpong_to_enc_id;
+ int pp_max = PINGPONG_MAX - PINGPONG_0;
- /* check if DSC required are allocated or not */
- for (i = 0; i < num_dsc; i++) {
- if (!rm->dsc_blks[i]) {
- DPU_ERROR("DSC %d does not exist\n", i);
- return -EIO;
- }
+ memset(dsc_id, 0, sizeof(dsc_id));
- if (global_state->dsc_to_enc_id[i]) {
- DPU_ERROR("DSC %d is already allocated\n", i);
- return -EIO;
-
Re: [PATCH 3/3] drm/panel: st7701: Add Anbernic RG-ARC Panel Support
On Fri, Dec 8, 2023 at 4:48 PM Chris Morgan wrote: > From: Chris Morgan > > The Powkiddy RG-ARC is a series of 2 handheld devices, each with a 4 > inch 480x640 display. Add support for the display. > > Signed-off-by: Chris Morgan Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 1/3] drm/panel: st7701: Fix AVCL calculation
On Fri, Dec 8, 2023 at 4:48 PM Chris Morgan wrote:
> From: Chris Morgan
>
> The AVCL register, according to the datasheet, comes in increments
> of -0.2v between -4.4v (represented by 0x0) to -5.0v (represented
> by 0x3). The current calculation is done by adding the defined
> AVCL value in mV to -4400 and then dividing by 200 to get the register
> value. Unfortunately if I subtract -4400 from -4400 I get -8800, which
> divided by 200 gives me -44. If I instead subtract -4400 from -4400
> I get 0, which divided by 200 gives me 0. Based on the datasheet this
> is the expected register value.
>
> Fixes: 83b7a8e7e88e ("drm/panel/panel-sitronix-st7701: Parametrize voltage
> and timing")
>
> Signed-off-by: Chris Morgan
Good catch!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH 2/2] drm/amdgpu: Enable clear page functionality
On 2023-12-11 04:50, Christian König wrote: Am 08.12.23 um 20:53 schrieb Alex Deucher: [SNIP] You also need a functionality which resets all cleared blocks to uncleared after suspend/resume. No idea how to do this, maybe Alex knows of hand. Since the buffers are cleared on creation, is there actually anything to do? Well exactly that's the problem, the buffers are no longer always cleared on creation with this patch. Instead we clear on free, track which areas are cleared and clear only the ones which aren't cleared yet on creation. The code I added for clearing-on-free a long time ago, does not clear to 0, but to a non-0 poison value. That was meant to make it easier to catch applications incorrectly relying on 0-initialized memory. Is that being changed? I didn't see it in this patch series. Regards, Felix So some cases need special handling. E.g. when the engine is not initialized yet or suspend/resume. In theory after a suspend/resume cycle the VRAM is cleared to zeros, but in practice that's not always true. Christian. Alex
Re: [PATCH] drm/msm/dpu: Ratelimit framedone timeout msgs
On Mon, Dec 11, 2023 at 2:09 PM Marijn Suijten
wrote:
>
> On 2023-12-11 10:19:55, Rob Clark wrote:
> > From: Rob Clark
> >
> > When we start getting these, we get a *lot*. So ratelimit it to not
> > flood dmesg.
> >
> > Signed-off-by: Rob Clark
> > ---
> >
> > dpu should probably stop rolling it's own trace macros, but that would
> > be a larger cleanup.
>
> That would be lovely, use is currently all over the place.
>
> Should this patch also ratelimit the corresponding:
>
> [drm:dpu_encoder_phys_cmd_prepare_for_kickoff] *ERROR* failed
> wait_for_idle: id:31 ret:-110 pp:0
>
> On CMD-mode panels?
Probably it should for consistency. But I think you normally wouldn't
get this error at 60Hz with a cmd mode panel, so probably ok to make
it ratelimited for cmd mode later.
BR,
-R
> Note that this is a prime example of using DRM_ERROR over DPU_ERROR*,
> resulting
> in unnecessary divergence (and un-readability) between error messages and the
> code (DPU_DEBUG_CMDENC, which has a corresponding DPU_ERROR variant, is also
> used within that function...)
>
> Reviewed-by: Marijn Suijten
>
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 -
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 82538844614b..7c22235d0eba 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -39,6 +39,9 @@
> > #define DPU_ERROR_ENC(e, fmt, ...) DPU_ERROR("enc%d " fmt,\
> > (e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
> >
> > +#define DPU_ERROR_ENC_RATELIMITED(e, fmt, ...)
> > DPU_ERROR_RATELIMITED("enc%d " fmt,\
> > + (e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
> > +
> > /*
> > * Two to anticipate panels that can do cmd/vid dynamic switching
> > * plan is to create all possible physical encoder types, and switch
> > between
> > @@ -2339,7 +2342,7 @@ static void dpu_encoder_frame_done_timeout(struct
> > timer_list *t)
> > return;
> > }
> >
> > - DPU_ERROR_ENC(dpu_enc, "frame done timeout\n");
> > + DPU_ERROR_ENC_RATELIMITED(dpu_enc, "frame done timeout\n");
> >
> > event = DPU_ENCODER_FRAME_EVENT_ERROR;
> > trace_dpu_enc_frame_done_timeout(DRMID(drm_enc), event);
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > index b6f53ca6e962..f5473d4dea92 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> > @@ -51,6 +51,7 @@
> > } while (0)
> >
> > #define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__)
> > +#define DPU_ERROR_RATELIMITED(fmt, ...) pr_err_ratelimited("[dpu error]"
> > fmt, ##__VA_ARGS__)
> >
> > /**
> > * ktime_compare_safe - compare two ktime structures
> > --
> > 2.43.0
> >
[PATCH v3 3/3] drm/tests: managed: Add a simple test for drmm_managed_release
Add a simple test that checks whether the action is indeed called right
away and that it is not called on the final drm_dev_put().
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_managed_test.c
b/drivers/gpu/drm/tests/drm_managed_test.c
index 15bd2474440b5..ef5e784afbc6d 100644
--- a/drivers/gpu/drm/tests/drm_managed_test.c
+++ b/drivers/gpu/drm/tests/drm_managed_test.c
@@ -48,6 +48,34 @@ static void drm_test_managed_run_action(struct kunit *test)
KUNIT_EXPECT_GT_MSG(test, ret, 0, "Release action was not called");
}
+/*
+ * The test verifies that the release action is called immediately when
+ * drmm_release_action is called and that it is not called for a second time
+ * when the device is released.
+ */
+static void drm_test_managed_release_action(struct kunit *test)
+{
+ struct managed_test_priv *priv = test->priv;
+ int ret;
+
+ ret = drmm_add_action_or_reset(priv->drm, drm_action, priv);
+ KUNIT_EXPECT_EQ(test, ret, 0);
+
+ ret = drm_dev_register(priv->drm, 0);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ drmm_release_action(priv->drm, drm_action, priv);
+ KUNIT_EXPECT_TRUE_MSG(test, priv->action_done, "Release action was not
called");
+ priv->action_done = false;
+
+ drm_dev_unregister(priv->drm);
+ drm_kunit_helper_free_device(test, priv->drm->dev);
+
+ ret = wait_event_interruptible_timeout(priv->action_wq,
priv->action_done,
+
msecs_to_jiffies(TEST_TIMEOUT_MS));
+ KUNIT_EXPECT_EQ_MSG(test, ret, 0, "Unexpected release action call
during cleanup");
+}
+
static int drm_managed_test_init(struct kunit *test)
{
struct managed_test_priv *priv;
@@ -76,6 +104,7 @@ static int drm_managed_test_init(struct kunit *test)
}
static struct kunit_case drm_managed_tests[] = {
+ KUNIT_CASE(drm_test_managed_release_action),
KUNIT_CASE(drm_test_managed_run_action),
{}
};
--
2.43.0
[PATCH v3 2/3] drm/tests: managed: Extract device initialization into test init
It simplifies the process of extending the test suite with additional
test cases without unnecessary duplication.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 51 +---
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_managed_test.c
b/drivers/gpu/drm/tests/drm_managed_test.c
index 1652dca11d30c..15bd2474440b5 100644
--- a/drivers/gpu/drm/tests/drm_managed_test.c
+++ b/drivers/gpu/drm/tests/drm_managed_test.c
@@ -12,6 +12,7 @@
#define TEST_TIMEOUT_MS100
struct managed_test_priv {
+ struct drm_device *drm;
bool action_done;
wait_queue_head_t action_wq;
};
@@ -24,35 +25,54 @@ static void drm_action(struct drm_device *drm, void *ptr)
wake_up_interruptible(>action_wq);
}
+/*
+ * The test verifies that the release action is called automatically when the
+ * device is released.
+ */
static void drm_test_managed_run_action(struct kunit *test)
+{
+ struct managed_test_priv *priv = test->priv;
+ int ret;
+
+ ret = drmm_add_action_or_reset(priv->drm, drm_action, priv);
+ KUNIT_EXPECT_EQ(test, ret, 0);
+
+ ret = drm_dev_register(priv->drm, 0);
+ KUNIT_ASSERT_EQ(test, ret, 0);
+
+ drm_dev_unregister(priv->drm);
+ drm_kunit_helper_free_device(test, priv->drm->dev);
+
+ ret = wait_event_interruptible_timeout(priv->action_wq,
priv->action_done,
+
msecs_to_jiffies(TEST_TIMEOUT_MS));
+ KUNIT_EXPECT_GT_MSG(test, ret, 0, "Release action was not called");
+}
+
+static int drm_managed_test_init(struct kunit *test)
{
struct managed_test_priv *priv;
- struct drm_device *drm;
struct device *dev;
- int ret;
priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
- init_waitqueue_head(>action_wq);
dev = drm_kunit_helper_alloc_device(test);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev);
- drm = __drm_kunit_helper_alloc_drm_device(test, dev, sizeof(*drm), 0,
DRIVER_MODESET);
- KUNIT_ASSERT_NOT_ERR_OR_NULL(test, drm);
+ /*
+* DRM device can't be embedded in priv, since priv->action_done needs
+* to remain allocated beyond both parent device and drm_device
+* lifetime.
+*/
+ priv->drm = __drm_kunit_helper_alloc_drm_device(test, dev,
sizeof(*priv->drm), 0,
+ DRIVER_MODESET);
+ KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv->drm);
- ret = drmm_add_action_or_reset(drm, drm_action, priv);
- KUNIT_EXPECT_EQ(test, ret, 0);
-
- ret = drm_dev_register(drm, 0);
- KUNIT_ASSERT_EQ(test, ret, 0);
+ init_waitqueue_head(>action_wq);
- drm_dev_unregister(drm);
- drm_kunit_helper_free_device(test, dev);
+ test->priv = priv;
- ret = wait_event_interruptible_timeout(priv->action_wq,
priv->action_done,
-
msecs_to_jiffies(TEST_TIMEOUT_MS));
- KUNIT_EXPECT_GT(test, ret, 0);
+ return 0;
}
static struct kunit_case drm_managed_tests[] = {
@@ -62,6 +82,7 @@ static struct kunit_case drm_managed_tests[] = {
static struct kunit_suite drm_managed_test_suite = {
.name = "drm-test-managed",
+ .init = drm_managed_test_init,
.test_cases = drm_managed_tests
};
--
2.43.0
[PATCH v3 1/3] drm/managed: Add drmm_release_action
Similar to devres equivalent, it allows to call the "release" action
directly and remove the resource from the managed resources list.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_managed.c | 39 +++
include/drm/drm_managed.h | 4
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
index bcd111404b128..7646f67bda4e4 100644
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -176,6 +176,45 @@ int __drmm_add_action_or_reset(struct drm_device *dev,
}
EXPORT_SYMBOL(__drmm_add_action_or_reset);
+/**
+ * drmm_release_action - release a managed action from a _device
+ * @dev: DRM device
+ * @action: function which would be called when @dev is released
+ * @data: opaque pointer, passed to @action
+ *
+ * This function calls the @action previously added by drmm_add_action()
+ * immediately.
+ * The @action is removed from the list of cleanup actions for @dev,
+ * which means that it won't be called in the final drm_dev_put().
+ */
+void drmm_release_action(struct drm_device *dev,
+drmres_release_t action,
+void *data)
+{
+ struct drmres *dr_match = NULL, *dr;
+ unsigned long flags;
+
+ spin_lock_irqsave(>managed.lock, flags);
+ list_for_each_entry_reverse(dr, >managed.resources, node.entry) {
+ if (dr->node.release == action) {
+ if (!data || (data && *(void **)dr->data == data)) {
+ dr_match = dr;
+ del_dr(dev, dr_match);
+ break;
+ }
+ }
+ }
+ spin_unlock_irqrestore(>managed.lock, flags);
+
+ if (WARN_ON(!dr_match))
+ return;
+
+ action(dev, data);
+
+ free_dr(dr_match);
+}
+EXPORT_SYMBOL(drmm_release_action);
+
/**
* drmm_kmalloc - _device managed kmalloc()
* @dev: DRM device
diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
index ad08f834af408..f547b09ca0239 100644
--- a/include/drm/drm_managed.h
+++ b/include/drm/drm_managed.h
@@ -45,6 +45,10 @@ int __must_check __drmm_add_action_or_reset(struct
drm_device *dev,
drmres_release_t action,
void *data, const char *name);
+void drmm_release_action(struct drm_device *dev,
+drmres_release_t action,
+void *data);
+
void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp) __malloc;
/**
--
2.43.0
Re: [PATCH] drm/msm/dpu: Ratelimit framedone timeout msgs
On 2023-12-11 10:19:55, Rob Clark wrote:
> From: Rob Clark
>
> When we start getting these, we get a *lot*. So ratelimit it to not
> flood dmesg.
>
> Signed-off-by: Rob Clark
> ---
>
> dpu should probably stop rolling it's own trace macros, but that would
> be a larger cleanup.
That would be lovely, use is currently all over the place.
Should this patch also ratelimit the corresponding:
[drm:dpu_encoder_phys_cmd_prepare_for_kickoff] *ERROR* failed
wait_for_idle: id:31 ret:-110 pp:0
On CMD-mode panels?
Note that this is a prime example of using DRM_ERROR over DPU_ERROR*, resulting
in unnecessary divergence (and un-readability) between error messages and the
code (DPU_DEBUG_CMDENC, which has a corresponding DPU_ERROR variant, is also
used within that function...)
Reviewed-by: Marijn Suijten
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 82538844614b..7c22235d0eba 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -39,6 +39,9 @@
> #define DPU_ERROR_ENC(e, fmt, ...) DPU_ERROR("enc%d " fmt,\
> (e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
>
> +#define DPU_ERROR_ENC_RATELIMITED(e, fmt, ...) DPU_ERROR_RATELIMITED("enc%d
> " fmt,\
> + (e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
> +
> /*
> * Two to anticipate panels that can do cmd/vid dynamic switching
> * plan is to create all possible physical encoder types, and switch between
> @@ -2339,7 +2342,7 @@ static void dpu_encoder_frame_done_timeout(struct
> timer_list *t)
> return;
> }
>
> - DPU_ERROR_ENC(dpu_enc, "frame done timeout\n");
> + DPU_ERROR_ENC_RATELIMITED(dpu_enc, "frame done timeout\n");
>
> event = DPU_ENCODER_FRAME_EVENT_ERROR;
> trace_dpu_enc_frame_done_timeout(DRMID(drm_enc), event);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> index b6f53ca6e962..f5473d4dea92 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> @@ -51,6 +51,7 @@
> } while (0)
>
> #define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__)
> +#define DPU_ERROR_RATELIMITED(fmt, ...) pr_err_ratelimited("[dpu error]"
> fmt, ##__VA_ARGS__)
>
> /**
> * ktime_compare_safe - compare two ktime structures
> --
> 2.43.0
>
[PATCH v3 0/3] drm/managed: Add drmm_release_action
Upcoming Intel Xe driver will need to have a more fine-grained control over DRM managed actions - namely, the ability to release a given action, triggering it manually at a different point in time than the final drm_dev_put(). This series adds a drmm_release_action function (which is similar to devres devm_release_action) and a simple test that uses it. v1 -> v2: - Split the test changes (Maxime) - Simplify priv lifetime management (Maxime) v2 -> v3: - Order tests alphabetically (Maxime) - Add comments explaining the intention behind the tests and the reason why DRM device can't be embedded inside test priv (Maxime) - Bring back priv lifetime management from v1 to avoid use-after-free Michał Winiarski (3): drm/managed: Add drmm_release_action drm/tests: managed: Extract device initialization into test init drm/tests: managed: Add a simple test for drmm_managed_release drivers/gpu/drm/drm_managed.c| 39 drivers/gpu/drm/tests/drm_managed_test.c | 80 +++- include/drm/drm_managed.h| 4 ++ 3 files changed, 108 insertions(+), 15 deletions(-) -- 2.43.0
Re: [PATCH 1/9] dt-bindings: display: msm: dp: declare compatible string for sm8150
On 10/12/2023 00:21, Dmitry Baryshkov wrote: > Add compatible string for the DisplayPort controller found on the > Qualcomm SM8150 platform. > > Signed-off-by: Dmitry Baryshkov > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 05/16] drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog
On 12/11/2023 1:42 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 23:32, Abhinav Kumar wrote:
On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar wrote:
On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar wrote:
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- remove explicit zero assignment for features
- move sc7280_cdm to dpu_hw_catalog from the sc7280
catalog file as its definition can be re-used
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 209675de6742..19c2b7454796 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -248,6 +248,7 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
.mdss_ver = _mdss_ver,
.caps = _dpu_caps,
.mdp = _mdp,
+ .cdm = _cdm,
.ctl_count = ARRAY_SIZE(sc7280_ctl),
.ctl = sc7280_ctl,
.sspp_count = ARRAY_SIZE(sc7280_sspp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index d52aae54bbd5..1be3156cde05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -426,6 +426,16 @@ static const struct dpu_dsc_sub_blks dsc_sblk_1 = {
.ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
};
+/*
+ * CDM sub block config
Nit: it is not a subblock config.
Ack.
+ */
+static const struct dpu_cdm_cfg sc7280_cdm = {
I know that I have r-b'ed this patch. But then one thing occurred to
me. If this definition is common to all (or almost all) platforms, can
we just call it dpu_cdm or dpu_common_cdm?
+ .name = "cdm_0",
+ .id = CDM_0,
+ .len = 0x228,
+ .base = 0x79200,
+};
hmmm almost common but not entirely ... msm8998's CDM has a shorter
len of 0x224 :(
Then sdm845_cdm?
That also has a shorter cdm length.
Could you please clarify. According to the downstream DT files all CDM
blocks up to (but not including) sm8550 had length 0x224. SM8550 and
SM8650 got qcom,sde-cdm-size = <0x220>. But I don't see any registers
after 0x204.
We always list 0x4 more than the last offset.
In chipsets sdm845 and msm8998, I only see the last offset of CDM as
0x220 but in sm8250 and sc7280, the last offset is 0x224. Hence the
total length is more in sc7280/sm8250 as compared to sdm845/msm8998.
I didnt follow that you do not see any registers after 0x204.
The CDM_MUX is the last offset which has an offset 0x224 from the base
address. So thats the last offset.
The newer chipsets have CDM_MUX and the older ones did not. Hence the
difference in length.
BTW, sdm845 is not in this series. It will be part of RFT as we discussed.
+
/*
* VBIF sub blocks config
*/
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index e3c0d007481b..ba82ef4560a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -682,6 +682,17 @@ struct dpu_vbif_cfg {
u32 memtype[MAX_XIN_COUNT];
};
+/**
+ * struct dpu_cdm_cfg - information of chroma down blocks
+ * @name string name for debug purposes
+ * @id enum identifying this block
+ * @base register offset of this block
+ * @features bit mask identifying sub-blocks/features
+ */
+struct dpu_cdm_cfg {
+ DPU_HW_BLK_INFO;
+};
+
/**
* Define CDP use cases
* @DPU_PERF_CDP_UDAGE_RT: real-time use cases
@@ -805,6 +816,8 @@ struct dpu_mdss_cfg {
u32 wb_count;
const struct dpu_wb_cfg *wb;
+ const struct dpu_cdm_cfg *cdm;
+
u32 ad_count;
u32 dspp_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index a6702b2bfc68..f319c8232ea5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -185,6 +185,11 @@ enum dpu_dsc {
DSC_MAX
};
+enum dpu_cdm {
+ CDM_0 = 1,
+ CDM_MAX
+};
+
enum dpu_pingpong {
Re: [PATCH v2 05/16] drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog
On Mon, 11 Dec 2023 at 23:32, Abhinav Kumar wrote:
>
>
>
> On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
> > On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
> >>> On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar
> >>> wrote:
>
> Add CDM blocks to the sc7280 dpu_hw_catalog to support
> YUV format output from writeback block.
>
> changes in v2:
> - remove explicit zero assignment for features
> - move sc7280_cdm to dpu_hw_catalog from the sc7280
> catalog file as its definition can be re-used
>
> Signed-off-by: Abhinav Kumar
> ---
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> index 209675de6742..19c2b7454796 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> @@ -248,6 +248,7 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
> .mdss_ver = _mdss_ver,
> .caps = _dpu_caps,
> .mdp = _mdp,
> + .cdm = _cdm,
> .ctl_count = ARRAY_SIZE(sc7280_ctl),
> .ctl = sc7280_ctl,
> .sspp_count = ARRAY_SIZE(sc7280_sspp),
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index d52aae54bbd5..1be3156cde05 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -426,6 +426,16 @@ static const struct dpu_dsc_sub_blks dsc_sblk_1 = {
> .ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
> };
>
> +/*
> + * CDM sub block config
> >>>
> >>> Nit: it is not a subblock config.
> >>>
> >>
> >> Ack.
> >>
> + */
> +static const struct dpu_cdm_cfg sc7280_cdm = {
> >>>
> >>> I know that I have r-b'ed this patch. But then one thing occurred to
> >>> me. If this definition is common to all (or almost all) platforms, can
> >>> we just call it dpu_cdm or dpu_common_cdm?
> >>>
> + .name = "cdm_0",
> + .id = CDM_0,
> + .len = 0x228,
> + .base = 0x79200,
> +};
> >>
> >> hmmm almost common but not entirely ... msm8998's CDM has a shorter
> >> len of 0x224 :(
> >
> > Then sdm845_cdm?
> >
>
> That also has a shorter cdm length.
Could you please clarify. According to the downstream DT files all CDM
blocks up to (but not including) sm8550 had length 0x224. SM8550 and
SM8650 got qcom,sde-cdm-size = <0x220>. But I don't see any registers
after 0x204.
>
> BTW, sdm845 is not in this series. It will be part of RFT as we discussed.
>
> >>
> +
> /*
> * VBIF sub blocks config
> */
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index e3c0d007481b..ba82ef4560a6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -682,6 +682,17 @@ struct dpu_vbif_cfg {
> u32 memtype[MAX_XIN_COUNT];
> };
>
> +/**
> + * struct dpu_cdm_cfg - information of chroma down blocks
> + * @name string name for debug purposes
> + * @id enum identifying this block
> + * @base register offset of this block
> + * @features bit mask identifying sub-blocks/features
> + */
> +struct dpu_cdm_cfg {
> + DPU_HW_BLK_INFO;
> +};
> +
> /**
> * Define CDP use cases
> * @DPU_PERF_CDP_UDAGE_RT: real-time use cases
> @@ -805,6 +816,8 @@ struct dpu_mdss_cfg {
> u32 wb_count;
> const struct dpu_wb_cfg *wb;
>
> + const struct dpu_cdm_cfg *cdm;
> +
> u32 ad_count;
>
> u32 dspp_count;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> index a6702b2bfc68..f319c8232ea5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> @@ -185,6
Re: [PATCH v2 05/16] drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog
On 12/11/2023 1:31 PM, Dmitry Baryshkov wrote:
On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar wrote:
On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar wrote:
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- remove explicit zero assignment for features
- move sc7280_cdm to dpu_hw_catalog from the sc7280
catalog file as its definition can be re-used
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 209675de6742..19c2b7454796 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -248,6 +248,7 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
.mdss_ver = _mdss_ver,
.caps = _dpu_caps,
.mdp = _mdp,
+ .cdm = _cdm,
.ctl_count = ARRAY_SIZE(sc7280_ctl),
.ctl = sc7280_ctl,
.sspp_count = ARRAY_SIZE(sc7280_sspp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index d52aae54bbd5..1be3156cde05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -426,6 +426,16 @@ static const struct dpu_dsc_sub_blks dsc_sblk_1 = {
.ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
};
+/*
+ * CDM sub block config
Nit: it is not a subblock config.
Ack.
+ */
+static const struct dpu_cdm_cfg sc7280_cdm = {
I know that I have r-b'ed this patch. But then one thing occurred to
me. If this definition is common to all (or almost all) platforms, can
we just call it dpu_cdm or dpu_common_cdm?
+ .name = "cdm_0",
+ .id = CDM_0,
+ .len = 0x228,
+ .base = 0x79200,
+};
hmmm almost common but not entirely ... msm8998's CDM has a shorter
len of 0x224 :(
Then sdm845_cdm?
That also has a shorter cdm length.
BTW, sdm845 is not in this series. It will be part of RFT as we discussed.
+
/*
* VBIF sub blocks config
*/
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index e3c0d007481b..ba82ef4560a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -682,6 +682,17 @@ struct dpu_vbif_cfg {
u32 memtype[MAX_XIN_COUNT];
};
+/**
+ * struct dpu_cdm_cfg - information of chroma down blocks
+ * @name string name for debug purposes
+ * @id enum identifying this block
+ * @base register offset of this block
+ * @features bit mask identifying sub-blocks/features
+ */
+struct dpu_cdm_cfg {
+ DPU_HW_BLK_INFO;
+};
+
/**
* Define CDP use cases
* @DPU_PERF_CDP_UDAGE_RT: real-time use cases
@@ -805,6 +816,8 @@ struct dpu_mdss_cfg {
u32 wb_count;
const struct dpu_wb_cfg *wb;
+ const struct dpu_cdm_cfg *cdm;
+
u32 ad_count;
u32 dspp_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index a6702b2bfc68..f319c8232ea5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -185,6 +185,11 @@ enum dpu_dsc {
DSC_MAX
};
+enum dpu_cdm {
+ CDM_0 = 1,
+ CDM_MAX
+};
+
enum dpu_pingpong {
PINGPONG_NONE,
PINGPONG_0,
--
2.40.1
Re: [PATCH v2 05/16] drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog
On Mon, 11 Dec 2023 at 23:16, Abhinav Kumar wrote:
>
>
>
> On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
> > On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar
> > wrote:
> >>
> >> Add CDM blocks to the sc7280 dpu_hw_catalog to support
> >> YUV format output from writeback block.
> >>
> >> changes in v2:
> >> - remove explicit zero assignment for features
> >> - move sc7280_cdm to dpu_hw_catalog from the sc7280
> >>catalog file as its definition can be re-used
> >>
> >> Signed-off-by: Abhinav Kumar
> >> ---
> >> .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 ++
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +
> >> 4 files changed, 29 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> index 209675de6742..19c2b7454796 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
> >> @@ -248,6 +248,7 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
> >> .mdss_ver = _mdss_ver,
> >> .caps = _dpu_caps,
> >> .mdp = _mdp,
> >> + .cdm = _cdm,
> >> .ctl_count = ARRAY_SIZE(sc7280_ctl),
> >> .ctl = sc7280_ctl,
> >> .sspp_count = ARRAY_SIZE(sc7280_sspp),
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> index d52aae54bbd5..1be3156cde05 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> @@ -426,6 +426,16 @@ static const struct dpu_dsc_sub_blks dsc_sblk_1 = {
> >> .ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
> >> };
> >>
> >> +/*
> >> + * CDM sub block config
> >
> > Nit: it is not a subblock config.
> >
>
> Ack.
>
> >> + */
> >> +static const struct dpu_cdm_cfg sc7280_cdm = {
> >
> > I know that I have r-b'ed this patch. But then one thing occurred to
> > me. If this definition is common to all (or almost all) platforms, can
> > we just call it dpu_cdm or dpu_common_cdm?
> >
> >> + .name = "cdm_0",
> >> + .id = CDM_0,
> >> + .len = 0x228,
> >> + .base = 0x79200,
> >> +};
>
> hmmm almost common but not entirely ... msm8998's CDM has a shorter
> len of 0x224 :(
Then sdm845_cdm?
>
> >> +
> >> /*
> >>* VBIF sub blocks config
> >>*/
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> index e3c0d007481b..ba82ef4560a6 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> @@ -682,6 +682,17 @@ struct dpu_vbif_cfg {
> >> u32 memtype[MAX_XIN_COUNT];
> >> };
> >>
> >> +/**
> >> + * struct dpu_cdm_cfg - information of chroma down blocks
> >> + * @name string name for debug purposes
> >> + * @id enum identifying this block
> >> + * @base register offset of this block
> >> + * @features bit mask identifying sub-blocks/features
> >> + */
> >> +struct dpu_cdm_cfg {
> >> + DPU_HW_BLK_INFO;
> >> +};
> >> +
> >> /**
> >>* Define CDP use cases
> >>* @DPU_PERF_CDP_UDAGE_RT: real-time use cases
> >> @@ -805,6 +816,8 @@ struct dpu_mdss_cfg {
> >> u32 wb_count;
> >> const struct dpu_wb_cfg *wb;
> >>
> >> + const struct dpu_cdm_cfg *cdm;
> >> +
> >> u32 ad_count;
> >>
> >> u32 dspp_count;
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> >> index a6702b2bfc68..f319c8232ea5 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
> >> @@ -185,6 +185,11 @@ enum dpu_dsc {
> >> DSC_MAX
> >> };
> >>
> >> +enum dpu_cdm {
> >> + CDM_0 = 1,
> >> + CDM_MAX
> >> +};
> >> +
> >> enum dpu_pingpong {
> >> PINGPONG_NONE,
> >> PINGPONG_0,
> >> --
> >> 2.40.1
> >>
> >
> >
--
With best wishes
Dmitry
Re: [PATCH v3] drm/msm/dpu: improve DSC allocation
On Mon, 11 Dec 2023 at 20:38, Kuogee Hsieh wrote:
>
> A DCE (Display Compression Engine) contains two DSC hard slice
> encoders. Each DCE start with even DSC encoder index followed by
"starts". But it will not be correct. The DCE doesn't start with the
DSC encoder. DCE consists of two DSC encoders, one has an odd index
and another one has an even index.
> an odd DSC encoder index. Each encoder can work independently.
> But Only two DSC encoders from same DCE can be paired to work
only
> together to support merge mode. In addition, the DSC with even
There are different merge modes. Here you are talking about the DSC merge mode.
> index have to mapping to even pingpong index and DSC with odd
PINGPONG (end everywhere else).
have to be mapped, should be used, etc.
> index have to mapping to odd pingpong index at its data path.
> This patch improve DSC allocation mechanism with consideration
improves
> of above factors.
of these factors.
>
> Changes in V3:
> -- add dpu_rm_pingpong_dsc_check()
> -- for pair allocation use i += 2 at for loop
>
> Changes in V2:
> -- split _dpu_rm_reserve_dsc() into _dpu_rm_reserve_dsc_single() and
>_dpu_rm_reserve_dsc_pair()
>
> Fixes: f2803ee91a41 ("drm/msm/disp/dpu1: Add DSC support in RM")
This tag is incorrect. The patch should be split into two pieces. One
which fixes DSC allocation for DSC 1.1 encoders, where there were no
DCE blocks, another one which adds proper handling for DCE.
Unless the paired allocation requirement also applies to pre-DCE DSC
encoders. But in that case the commit message doesn't make any sense.
I checked 4.x Qualcomm kernels. None of them contained any of these
restrictions for DSC blocks. Only the displaypack targeting 4.19
kernel got these changes. But it predates DCE pairs support.
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 171
> ++---
> 1 file changed, 155 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> index 17ecf23..43598ee 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
> @@ -470,33 +470,172 @@ static int _dpu_rm_reserve_ctls(
> return 0;
> }
>
> -static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
> +static int _dpu_rm_pingpong_dsc_check(int dsc_idx,
> + uint32_t enc_id,
> + uint32_t *pp_to_enc_id,
> + int pp_max,
> + bool pair)
> +{
> + int pp_idx;
> +
> + /*
> +* find the pingpong index which had been reserved
> +* previously at layer mixer allocation
during
> +*/
> + for (pp_idx = 0; pp_idx < pp_max; pp_idx++) {
> + if (pp_to_enc_id[pp_idx] == enc_id)
> + break;
> + }
> +
> + /*
> +* dsc even index must map to pingpong even index
DSC with even index.
be mapped or correspond
> +* dsc odd index must map to pingpong odd index
> +*/
> + if ((dsc_idx & 0x01) != (pp_idx & 0x01))
> + return -ENAVAIL;
> +
> + if (pair) {
> + /*
> +* delete pp_idx so that same pp_id can not be paired with
> +* next dsc_id
> +*/
> + pp_to_enc_id[pp_idx] = 0x;
> + }
Ugh. "Non tangere circulos meos". Move this deletion away from this function.
> +
> + return 0;
> +
> +}
> +
> +static int _dpu_rm_reserve_dsc_single(struct dpu_rm *rm,
>struct dpu_global_state *global_state,
> - struct drm_encoder *enc,
> + uint32_t enc_id,
>const struct msm_display_topology *top)
> {
> - int num_dsc = top->num_dsc;
> - int i;
> + int num_dsc = 0;
> + int i, ret;
> + int dsc_id[DSC_MAX - DSC_0];
> + uint32_t *pp_enc_id = global_state->pingpong_to_enc_id;
> + int pp_max = PINGPONG_MAX - PINGPONG_0;
>
> - /* check if DSC required are allocated or not */
> - for (i = 0; i < num_dsc; i++) {
> - if (!rm->dsc_blks[i]) {
> - DPU_ERROR("DSC %d does not exist\n", i);
> - return -EIO;
> - }
> + memset(dsc_id, 0, sizeof(dsc_id));
>
> - if (global_state->dsc_to_enc_id[i]) {
> - DPU_ERROR("DSC %d is already allocated\n", i);
> - return -EIO;
> - }
> + for (i = 0; i < ARRAY_SIZE(rm->dsc_blks) && num_dsc >= top->num_dsc;
> i++) {
Wait. num_dsc >= top->num_dsc? num_dsc starts with 0, so this loop
will never be executed?
> + if (!rm->dsc_blks[i])
> + continue;
> +
> + if (global_state->dsc_to_enc_id[i]) /*
Re: [PATCH] drm/msm/dpu: remove extra drm_encoder_cleanup from the error path
On 12/11/2023 6:54 AM, Dmitry Baryshkov wrote:
The drmm handler will perform drm_encoder_cleanup() for us. Moreover if
we call drm_encoder_cleanup() manually, the drmm_encoder_alloc_release()
will spawn warnings at drivers/gpu/drm/drm_encoder.c:214. Drop these
extra drm_encoder_cleanup() calls.
Fixes: cd42c56d9c0b ("drm/msm/dpu: use drmm-managed allocation for
dpu_encoder_virt")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 ---
1 file changed, 3 deletions(-)
Reviewed-by: Abhinav Kumar
Tested-by: Abhinav Kumar #sm8250 CI
Re: [PATCH] drm/msm/dp: call dp_display_get_next_bridge() during probe
On 11/6/2023 4:43 PM, Dmitry Baryshkov wrote:
The funcion dp_display_get_next_bridge() can return -EPROBE_DEFER if the
next bridge is not (yet) available. However returning -EPROBE_DEFER from
msm_dp_modeset_init() is not ideal. This leads to -EPROBE return from
component_bind, which can easily result in -EPROBE_DEFR loops.
Signed-off-by: Dmitry Baryshkov
---
Dependencies: https://patchwork.freedesktop.org/series/120375/
---
Reviewed-by: Kuogee Hsieh
drivers/gpu/drm/msm/dp/dp_display.c | 36 +
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index d542db37763a..ddb3c84f39a2 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1197,15 +1197,27 @@ static const struct msm_dp_desc
*dp_display_get_desc(struct platform_device *pde
return NULL;
}
-static int dp_auxbus_done_probe(struct drm_dp_aux *aux)
+static int dp_display_get_next_bridge(struct msm_dp *dp);
+
+static int dp_display_probe_tail(struct device *dev)
{
- int rc;
+ struct msm_dp *dp = dev_get_drvdata(dev);
+ int ret;
- rc = component_add(aux->dev, _display_comp_ops);
- if (rc)
- DRM_ERROR("eDP component add failed, rc=%d\n", rc);
+ ret = dp_display_get_next_bridge(dp);
+ if (ret)
+ return ret;
- return rc;
+ ret = component_add(dev, _display_comp_ops);
+ if (ret)
+ DRM_ERROR("component add failed, rc=%d\n", ret);
+
+ return ret;
+}
+
+static int dp_auxbus_done_probe(struct drm_dp_aux *aux)
+{
+ return dp_display_probe_tail(aux->dev);
}
static int dp_display_probe(struct platform_device *pdev)
@@ -1280,11 +1292,9 @@ static int dp_display_probe(struct platform_device *pdev)
goto err;
}
} else {
- rc = component_add(>dev, _display_comp_ops);
- if (rc) {
- DRM_ERROR("component add failed, rc=%d\n", rc);
+ rc = dp_display_probe_tail(>dev);
+ if (rc)
goto err;
- }
}
return rc;
@@ -1415,7 +1425,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
* For DisplayPort interfaces external bridges are optional, so
* silently ignore an error if one is not present (-ENODEV).
*/
- rc = devm_dp_parser_find_next_bridge(dp->drm_dev->dev, dp_priv->parser);
+ rc = devm_dp_parser_find_next_bridge(>pdev->dev, dp_priv->parser);
if (!dp->is_edp && rc == -ENODEV)
return 0;
@@ -1435,10 +1445,6 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
dp_priv = container_of(dp_display, struct dp_display_private, dp_display);
- ret = dp_display_get_next_bridge(dp_display);
- if (ret)
- return ret;
-
ret = dp_bridge_init(dp_display, dev, encoder);
if (ret) {
DRM_DEV_ERROR(dev->dev,
Re: [PATCH v2 05/16] drm/msm/dpu: add cdm blocks to sc7280 dpu_hw_catalog
On 12/8/2023 3:19 AM, Dmitry Baryshkov wrote:
On Fri, 8 Dec 2023 at 07:07, Abhinav Kumar wrote:
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- remove explicit zero assignment for features
- move sc7280_cdm to dpu_hw_catalog from the sc7280
catalog file as its definition can be re-used
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 5 +
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
index 209675de6742..19c2b7454796 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
@@ -248,6 +248,7 @@ const struct dpu_mdss_cfg dpu_sc7280_cfg = {
.mdss_ver = _mdss_ver,
.caps = _dpu_caps,
.mdp = _mdp,
+ .cdm = _cdm,
.ctl_count = ARRAY_SIZE(sc7280_ctl),
.ctl = sc7280_ctl,
.sspp_count = ARRAY_SIZE(sc7280_sspp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index d52aae54bbd5..1be3156cde05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -426,6 +426,16 @@ static const struct dpu_dsc_sub_blks dsc_sblk_1 = {
.ctl = {.name = "ctl", .base = 0xF80, .len = 0x10},
};
+/*
+ * CDM sub block config
Nit: it is not a subblock config.
Ack.
+ */
+static const struct dpu_cdm_cfg sc7280_cdm = {
I know that I have r-b'ed this patch. But then one thing occurred to
me. If this definition is common to all (or almost all) platforms, can
we just call it dpu_cdm or dpu_common_cdm?
+ .name = "cdm_0",
+ .id = CDM_0,
+ .len = 0x228,
+ .base = 0x79200,
+};
hmmm almost common but not entirely ... msm8998's CDM has a shorter
len of 0x224 :(
+
/*
* VBIF sub blocks config
*/
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index e3c0d007481b..ba82ef4560a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -682,6 +682,17 @@ struct dpu_vbif_cfg {
u32 memtype[MAX_XIN_COUNT];
};
+/**
+ * struct dpu_cdm_cfg - information of chroma down blocks
+ * @name string name for debug purposes
+ * @id enum identifying this block
+ * @base register offset of this block
+ * @features bit mask identifying sub-blocks/features
+ */
+struct dpu_cdm_cfg {
+ DPU_HW_BLK_INFO;
+};
+
/**
* Define CDP use cases
* @DPU_PERF_CDP_UDAGE_RT: real-time use cases
@@ -805,6 +816,8 @@ struct dpu_mdss_cfg {
u32 wb_count;
const struct dpu_wb_cfg *wb;
+ const struct dpu_cdm_cfg *cdm;
+
u32 ad_count;
u32 dspp_count;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
index a6702b2bfc68..f319c8232ea5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h
@@ -185,6 +185,11 @@ enum dpu_dsc {
DSC_MAX
};
+enum dpu_cdm {
+ CDM_0 = 1,
+ CDM_MAX
+};
+
enum dpu_pingpong {
PINGPONG_NONE,
PINGPONG_0,
--
2.40.1
Re: [PATCH 1/9] dt-bindings: display: msm: dp: declare compatible string for sm8150
On 10/12/2023 00:21, Dmitry Baryshkov wrote: > Add compatible string for the DisplayPort controller found on the > Qualcomm SM8150 platform. > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH 3/3] arm64: dts: imx8mq: Exclude "fsl,imx6sx-lcdif"
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
i.MX8MQ does not have an LCDIF power domain, so pass only
"fsl,imx8mq-lcdif" as compatible string to fix the following
dt-schema warning:
imx8mq-evk.dtb: lcd-controller@3032: 'power-domains' is a required property
from schema $id: http://devicetree.org/schemas/display/fsl,lcdif.yaml#
Signed-off-by: Fabio Estevam
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index c6dc3ba0d43b..5d8365e4eb26 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -739,7 +739,7 @@ sdma2: dma-controller@302c {
};
lcdif: lcd-controller@3032 {
- compatible = "fsl,imx8mq-lcdif",
"fsl,imx6sx-lcdif";
+ compatible = "fsl,imx8mq-lcdif";
reg = <0x3032 0x1>;
interrupts = ;
clocks = < IMX8MQ_CLK_LCDIF_PIXEL>,
--
2.34.1
[PATCH 2/3] dt-bindings: lcdif: Decouple imx8mq from imx6sx
From: Fabio Estevam On i.MX6SX, the LCDIF has an associated power domain. i.MX8MQ does not have an LCDIF power domain, so allow passing only "fsl,imx8mq-lcdif" as compatible string to fix the following dt-schema warning: imx8mq-evk.dtb: lcd-controller@3032: 'power-domains' is a required property from schema $id: http://devicetree.org/schemas/display/fsl,lcdif.yaml# Signed-off-by: Fabio Estevam --- Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 1c2be8d6f633..8969e56d4c98 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -20,6 +20,7 @@ properties: - fsl,imx23-lcdif - fsl,imx28-lcdif - fsl,imx6sx-lcdif + - fsl,imx8mq-lcdif - fsl,imx8mp-lcdif - fsl,imx93-lcdif - items: @@ -77,7 +78,9 @@ allOf: properties: compatible: contains: -const: fsl,imx6sx-lcdif +enum: + - fsl,imx6sx-lcdif + - fsl,imx8mq-lcdif then: properties: clocks: @@ -113,6 +116,7 @@ allOf: enum: - fsl,imx6sx-lcdif - fsl,imx8mp-lcdif +- fsl,imx8mq-lcdif - fsl,imx93-lcdif then: properties: -- 2.34.1
[PATCH 1/3] drm/mxsfb: Add an entry for "fsl,imx8mq-lcdif"
From: Fabio Estevam
On i.MX6SX, the LCDIF has an associated power domain.
However, i.MX8MQ does not have an LCDIF power domain.
imx8mq.dtsi has the following compatible string:
compatible = "fsl,imx8mq-lcdif", "fsl,imx6sx-lcdif";
which causes the following dt-schema warning:
imx8mq-evk.dtb: lcd-controller@3032: 'power-domains' is a required property
from schema $id: http://devicetree.org/schemas/display/fsl,lcdif.yaml#
To prevent this problem, add a specific fsl,imx8mq-lcdif entry in
the driver to properly handle such a power-domain requirement difference.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index b483ef48216a..ac9ce3b45b38 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -340,6 +340,7 @@ static const struct of_device_id mxsfb_dt_ids[] = {
{ .compatible = "fsl,imx23-lcdif", .data = _devdata[MXSFB_V3], },
{ .compatible = "fsl,imx28-lcdif", .data = _devdata[MXSFB_V4], },
{ .compatible = "fsl,imx6sx-lcdif", .data = _devdata[MXSFB_V6], },
+ { .compatible = "fsl,imx8mq-lcdif", .data = _devdata[MXSFB_V6], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxsfb_dt_ids);
--
2.34.1
Re: [net-next v1 08/16] memory-provider: dmabuf devmem memory provider
On 12/11/23 02:30, Mina Almasry wrote:
On Sat, Dec 9, 2023 at 7:05 PM Pavel Begunkov wrote:
On 12/8/23 23:25, Mina Almasry wrote:
On Fri, Dec 8, 2023 at 2:56 PM Pavel Begunkov wrote:
On 12/8/23 00:52, Mina Almasry wrote:
...
+ if (pool->p.queue)
+ binding = READ_ONCE(pool->p.queue->binding);
+
+ if (binding) {
+ pool->mp_ops = _devmem_ops;
+ pool->mp_priv = binding;
+ }
Hmm, I don't understand why would we replace a nice transparent
api with page pool relying on a queue having devmem specific
pointer? It seemed more flexible and cleaner in the last RFC.
Jakub requested this change and may chime in, but I suspect it's to
further abstract the devmem changes from driver. In this iteration,
the driver grabs the netdev_rx_queue and passes it to the page_pool,
and any future configurations between the net stack and page_pool can
be passed this way with the driver unbothered.
Ok, that makes sense, but even if passed via an rx queue I'd
at least hope it keeping abstract provider parameters, e.g.
ops, but not hard coded with devmem specific code.
It might even be better done with a helper like
create_page_pool_from_queue(), unless there is some deeper
interaction b/w pp and rx queues is predicted.
Off hand I don't see the need for a new create_page_pool_from_queue().
page_pool_create() already takes in a param arg that lets us pass in
the queue as well as any other params.
+
if (pool->mp_ops) {
err = pool->mp_ops->init(pool);
if (err) {
@@ -1020,3 +1033,77 @@ void page_pool_update_nid(struct page_pool *pool, int
new_nid)
}
}
EXPORT_SYMBOL(page_pool_update_nid);
+
+void __page_pool_iov_free(struct page_pool_iov *ppiov)
+{
+ if (WARN_ON(ppiov->pp->mp_ops != _devmem_ops))
+ return;
+
+ netdev_free_dmabuf(ppiov);
+}
+EXPORT_SYMBOL_GPL(__page_pool_iov_free);
I didn't look too deep but I don't think I immediately follow
the pp refcounting. It increments pages_state_hold_cnt on
allocation, but IIUC doesn't mark skbs for recycle? Then, they all
will be put down via page_pool_iov_put_many() bypassing
page_pool_return_page() and friends. That will call
netdev_free_dmabuf(), which doesn't bump pages_state_release_cnt.
At least I couldn't make it work with io_uring, and for my purposes,
I forced all puts to go through page_pool_return_page(), which calls
the ->release_page callback. The callback will put the reference and
ask its page pool to account release_cnt. It also gets rid of
__page_pool_iov_free(), as we'd need to add a hook there for
customization otherwise.
I didn't care about overhead because the hot path for me is getting
buffers from a ring, which is somewhat analogous to sock_devmem_dontneed(),
but done on pp allocations under napi, and it's done separately.
Completely untested with TCP devmem:
https://github.com/isilence/linux/commit/14bd56605183dc80b540999e8058c79ac92ae2d8
This was a mistake in the last RFC, which should be fixed in v1. In
the RFC I was not marking the skbs as skb_mark_for_recycle(), so the
unreffing path wasn't as expected.
In this iteration, that should be completely fixed. I suspect since I
just posted this you're actually referring to the issue tested on the
last RFC? Correct me if wrong.
Right, it was with RFCv3
In this iteration, the reffing story:
- memory provider allocs ppiov and returns it to the page pool with
ppiov->refcount == 1.
- The page_pool gives the page to the driver. The driver may
obtain/release references with page_pool_page_[get|put]_many(), but
the driver is likely not doing that unless it's doing its own page
recycling.
- The net stack obtains references via skb_frag_ref() ->
page_pool_page_get_many()
- The net stack drops references via skb_frag_unref() ->
napi_pp_put_page() -> page_pool_return_page() and friends.
Thus, the issue where the unref path was skipping
page_pool_return_page() and friends should be resolved in this
iteration, let me know if you think otherwise, but I think this was an
issue limited to the last RFC.
Then page_pool_iov_put_many() should and supposedly would never be
called by non devmap code because all puts must circle back into
->release_page. Why adding it to into page_pool_page_put_many()?
@@ -731,6 +731,29 @@ __page_pool_put_page(struct page_pool *pool, struct page
*page,
+ if (page_is_page_pool_iov(page)) {
...
+ page_pool_page_put_many(page, 1);
+ return NULL;
+ }
Well, I'm looking at this new branch from Patch 10, it can put
the buffer, but what if we race at it's actually the final put?
Looks like nobody is going to to bump up pages_state_release_cnt
Good catch, I think indeed the release_cnt would be incorrect in this
case. I think the race is benign in the sense that the ppiov will be
freed correctly and available for allocation when the page_pool next
needs it; the issue is with the stats AFAICT.
hold_cnt + release_cnt
Re: [PATCH] drm/amd/display: Fix memory leak in dm_set_writeback()
Thanks for catching this.
Reviewed-by: Alex Hung
On 2023-12-08 02:58, Harshit Mogalapalli wrote:
'wb_info' needs to be freed on error paths or it would leak the memory.
Smatch pointed this out.
Fixes: c81e13b929df ("drm/amd/display: Hande writeback request from userspace")
Signed-off-by: Harshit Mogalapalli
---
This is based on static analysis and only compile tested
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index afdcc43ea06c..333995f70239 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8871,12 +8871,14 @@ static void dm_set_writeback(struct
amdgpu_display_manager *dm,
acrtc = to_amdgpu_crtc(wb_conn->encoder.crtc);
if (!acrtc) {
DRM_ERROR("no amdgpu_crtc found\n");
+ kfree(wb_info);
return;
}
afb = to_amdgpu_framebuffer(new_con_state->writeback_job->fb);
if (!afb) {
DRM_ERROR("No amdgpu_framebuffer found\n");
+ kfree(wb_info);
return;
}
[PATCH v3] drm/msm/dpu: improve DSC allocation
A DCE (Display Compression Engine) contains two DSC hard slice
encoders. Each DCE start with even DSC encoder index followed by
an odd DSC encoder index. Each encoder can work independently.
But Only two DSC encoders from same DCE can be paired to work
together to support merge mode. In addition, the DSC with even
index have to mapping to even pingpong index and DSC with odd
index have to mapping to odd pingpong index at its data path.
This patch improve DSC allocation mechanism with consideration
of above factors.
Changes in V3:
-- add dpu_rm_pingpong_dsc_check()
-- for pair allocation use i += 2 at for loop
Changes in V2:
-- split _dpu_rm_reserve_dsc() into _dpu_rm_reserve_dsc_single() and
_dpu_rm_reserve_dsc_pair()
Fixes: f2803ee91a41 ("drm/msm/disp/dpu1: Add DSC support in RM")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 171 ++---
1 file changed, 155 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 17ecf23..43598ee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -470,33 +470,172 @@ static int _dpu_rm_reserve_ctls(
return 0;
}
-static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
+static int _dpu_rm_pingpong_dsc_check(int dsc_idx,
+ uint32_t enc_id,
+ uint32_t *pp_to_enc_id,
+ int pp_max,
+ bool pair)
+{
+ int pp_idx;
+
+ /*
+* find the pingpong index which had been reserved
+* previously at layer mixer allocation
+*/
+ for (pp_idx = 0; pp_idx < pp_max; pp_idx++) {
+ if (pp_to_enc_id[pp_idx] == enc_id)
+ break;
+ }
+
+ /*
+* dsc even index must map to pingpong even index
+* dsc odd index must map to pingpong odd index
+*/
+ if ((dsc_idx & 0x01) != (pp_idx & 0x01))
+ return -ENAVAIL;
+
+ if (pair) {
+ /*
+* delete pp_idx so that same pp_id can not be paired with
+* next dsc_id
+*/
+ pp_to_enc_id[pp_idx] = 0x;
+ }
+
+ return 0;
+
+}
+
+static int _dpu_rm_reserve_dsc_single(struct dpu_rm *rm,
struct dpu_global_state *global_state,
- struct drm_encoder *enc,
+ uint32_t enc_id,
const struct msm_display_topology *top)
{
- int num_dsc = top->num_dsc;
- int i;
+ int num_dsc = 0;
+ int i, ret;
+ int dsc_id[DSC_MAX - DSC_0];
+ uint32_t *pp_enc_id = global_state->pingpong_to_enc_id;
+ int pp_max = PINGPONG_MAX - PINGPONG_0;
- /* check if DSC required are allocated or not */
- for (i = 0; i < num_dsc; i++) {
- if (!rm->dsc_blks[i]) {
- DPU_ERROR("DSC %d does not exist\n", i);
- return -EIO;
- }
+ memset(dsc_id, 0, sizeof(dsc_id));
- if (global_state->dsc_to_enc_id[i]) {
- DPU_ERROR("DSC %d is already allocated\n", i);
- return -EIO;
- }
+ for (i = 0; i < ARRAY_SIZE(rm->dsc_blks) && num_dsc >= top->num_dsc;
i++) {
+ if (!rm->dsc_blks[i])
+ continue;
+
+ if (global_state->dsc_to_enc_id[i]) /* used */
+ continue;
+
+ ret = _dpu_rm_pingpong_dsc_check(i, enc_id, pp_enc_id, pp_max,
false);
+ if (!ret)
+ dsc_id[num_dsc++] = DSC_0 + i; /* found, start from
DSC_0 */
}
- for (i = 0; i < num_dsc; i++)
- global_state->dsc_to_enc_id[i] = enc->base.id;
+ if (num_dsc < top->num_dsc) {
+ DPU_ERROR("DSC allocation failed num_dsc=%d required=%d\n",
+ num_dsc, top->num_dsc);
+ return -ENAVAIL;
+ }
+
+ /* allocate dsc */
+ for (i = 0; i < top->num_dsc; i++) {
+ int id;
+
+ id = dsc_id[i];
+ if (id >= DSC_0)
+ global_state->dsc_to_enc_id[id - DSC_0] = enc_id;
+ }
return 0;
}
+static int _dpu_rm_reserve_dsc_pair(struct dpu_rm *rm,
+ struct dpu_global_state *global_state,
+ uint32_t enc_id,
+ const struct msm_display_topology *top)
+{
+ int num_dsc = 0;
+ int i, ret;
+ int dsc_id[DSC_MAX - DSC_0];
+ uint32_t pp_to_enc_id[PINGPONG_MAX - PINGPONG_0];
+ uint32_t *dsc_enc_id = global_state->dsc_to_enc_id;
+ int pp_max = PINGPONG_MAX - PINGPONG_0;
+
+ memset(dsc_id, 0,
Re: [PATCH] drm/msm/dpu: Ratelimit framedone timeout msgs
On 12/11/2023 10:19 AM, Rob Clark wrote: From: Rob Clark When we start getting these, we get a *lot*. So ratelimit it to not flood dmesg. Signed-off-by: Rob Clark --- dpu should probably stop rolling it's own trace macros, but that would be a larger cleanup. drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Abhinav Kumar
Re: [PATCH v3 00/14] drm: Add a driver for CSF-based Mali GPUs
On Mon, 2023-12-11 at 09:52 +0100, Boris Brezillon wrote: > Hi, > > On Sun, 10 Dec 2023 13:58:51 +0900 > Tatsuyuki Ishi wrote: > > > > On Dec 5, 2023, at 2:32, Boris Brezillon > > > wrote: > > > > > > Hello, > > > > > > This is the 3rd version of the kernel driver for Mali CSF-based > > > GPUs. > > > > > > With all the DRM dependencies being merged (drm-sched single > > > entity and > > > drm_gpuvm), I thought now was a good time to post a new version. > > > Note > > > that the iommu series we depend on [1] has been merged recently. > > > The > > > only remaining dependency that hasn't been merged yet is this > > > rather > > > trival drm_gpuvm [2] patch. > > > > > > As for v2, I pushed a branch based on drm-misc-next and > > > containing > > > all the dependencies that are not yet available in drm-misc-next > > > here[3], and another [4] containing extra patches to have things > > > working on rk3588. The CSF firmware binary can be found here[5], > > > and > > > should be placed under > > > /lib/firmware/arm/mali/arch10.8/mali_csffw.bin. > > > > > > The mesa MR adding v10 support on top of panthor is available > > > here [6]. > > > > > > Regarding the GPL2+MIT relicensing, Liviu did an audit and found > > > two > > > more people that I didn't spot initially: Clément Péron for the > > > devfreq > > > code, and Alexey Sheplyakov for some bits in panthor_gpu.c. Both > > > are > > > Cc-ed on the relevant patches. The rest of the code is either > > > new, or > > > covered by the Linaro, Arm and Collabora acks. > > > > > > And here is a non-exhaustive changelog, check each commit for a > > > detailed > > > changelog. > > > > > > v3; > > > - Quite a few changes at the MMU/sched level to make the fix some > > > race conditions and deadlocks > > > - Addition of the a sync-only VM_BIND operation (to support > > > vkQueueSparseBind with zero commands). > > > > Hi Boris, > > > > Just wanted to point out that vkQueueBindSparse's semantics is > > rather different > > from vkQueueSubmit when it comes to synchronization. In short, > > vkQueueBindSparse does not operate on a particular timeline (aka > > scheduling > > queue / drm_sched_entity). The property of following a timeline > > order is known > > as “submission order” [1] in Vulkan, and applies to vkQueueSubmit > > only and not > > vkQueueBindSparse. > > Hm, okay. I really though the same ordering guarantees applied to > sparse binding queues too, as the spec [1] says > > " > Batches begin execution in the order they appear in pBindInfo, but > may complete out of order. > " Right. So this is something where the Vulkan spec isn't terribly clear and I think I need to go file a spec bug. I'm fairly sure that the intent is that bind operations MAY complete out-of-order but are not required to complete out-of-order. In other words, I'm fairly sure that implementations are allowed but not required to insert extra dependencies that force some amount of ordering. We take advantage of this in Mesa today to properly implement vkQueueWaitIdle() on sparse binding queues. This is also a requirement of Windows WDDM2 as far as I can tell so I'd be very surprised if we disallowed it in the spec. That said, that's all very unclear and IDK where you'd get that from the spec. I'm going to go file a spec bug so we can get this sorted out. ~Faith > which means things are submitted in order inside a vkQueueSparseBind > context, so I was expecting the submission ordering guarantee to > apply > across vkQueueSparseBind() calls on the same queue too. Just want to > mention that all kernel implementations I have seen so far assume > VM_BIND submissions on a given queue are serialized (that's how > drm_sched works, and Xe, Nouveau and Panthor are basing their VM_BIND > implemenation on drm_sched). > > Maybe Faith, or anyone deeply involved in the Vulkan specification, > can > confirm that submission ordering guarantees are relaxed on sparse > binding queues. > > > > > Hence, an implementation that takes full advantage of Vulkan > > semantics would > > essentially have an infinite amount of VM_BIND contexts. > > Uh, that's definitely not how I understood it initially... > > > It would also not need > > sync-only VM_BIND submissions, assuming that drmSyncobjTransfer > > works. > > Sure, if each vkQueueSparseBind() has its own timeline, an internal > timeline-syncobj with a bunch of drmSyncobjTransfer() calls would do > the > trick (might require several ioctls() to merge input syncobjs, but > that's probably not the end of the world). > > > > > I’m not saying that the driver should always be implemented that > > way; in > > particular, app developers are also confused by the semantics and > > native Vulkan > > games can be terribly wrong [2]. > > Okay, thanks for the pointer. If I may, I find this semantics utterly > confusing, to say the least. At the very least, the > vkQueueBindSparse() > doc could be update so it clearly reflects the facts
[PATCH] drm/msm/dpu: Ratelimit framedone timeout msgs
From: Rob Clark
When we start getting these, we get a *lot*. So ratelimit it to not
flood dmesg.
Signed-off-by: Rob Clark
---
dpu should probably stop rolling it's own trace macros, but that would
be a larger cleanup.
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82538844614b..7c22235d0eba 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -39,6 +39,9 @@
#define DPU_ERROR_ENC(e, fmt, ...) DPU_ERROR("enc%d " fmt,\
(e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
+#define DPU_ERROR_ENC_RATELIMITED(e, fmt, ...) DPU_ERROR_RATELIMITED("enc%d "
fmt,\
+ (e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
+
/*
* Two to anticipate panels that can do cmd/vid dynamic switching
* plan is to create all possible physical encoder types, and switch between
@@ -2339,7 +2342,7 @@ static void dpu_encoder_frame_done_timeout(struct
timer_list *t)
return;
}
- DPU_ERROR_ENC(dpu_enc, "frame done timeout\n");
+ DPU_ERROR_ENC_RATELIMITED(dpu_enc, "frame done timeout\n");
event = DPU_ENCODER_FRAME_EVENT_ERROR;
trace_dpu_enc_frame_done_timeout(DRMID(drm_enc), event);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index b6f53ca6e962..f5473d4dea92 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -51,6 +51,7 @@
} while (0)
#define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__)
+#define DPU_ERROR_RATELIMITED(fmt, ...) pr_err_ratelimited("[dpu error]" fmt,
##__VA_ARGS__)
/**
* ktime_compare_safe - compare two ktime structures
--
2.43.0
Re: [net-next v1 09/16] page_pool: device memory support
On Mon, Dec 11, 2023 at 3:51 AM Yunsheng Lin wrote:
>
> On 2023/12/11 12:04, Mina Almasry wrote:
> > On Sun, Dec 10, 2023 at 6:26 PM Mina Almasry wrote:
> >>
> >> On Sun, Dec 10, 2023 at 6:04 PM Yunsheng Lin
> >> wrote:
> >>>
> >>> On 2023/12/9 0:05, Mina Almasry wrote:
> On Fri, Dec 8, 2023 at 1:30 AM Yunsheng Lin
> wrote:
> >
> >
> > As mentioned before, it seems we need to have the above checking every
> > time we need to do some per-page handling in page_pool core, is there
> > a plan in your mind how to remove those kind of checking in the future?
> >
>
> I see 2 ways to remove the checking, both infeasible:
>
> 1. Allocate a wrapper struct that pulls out all the fields the page pool
> needs:
>
> struct netmem {
> /* common fields */
> refcount_t refcount;
> bool is_pfmemalloc;
> int nid;
> ...
> union {
> struct dmabuf_genpool_chunk_owner *owner;
> struct page * page;
> };
> };
>
> The page pool can then not care if the underlying memory is iov or
> page. However this introduces significant memory bloat as this struct
> needs to be allocated for each page or ppiov, which I imagine is not
> acceptable for the upside of removing a few static_branch'd if
> statements with no performance cost.
>
> 2. Create a unified struct for page and dmabuf memory, which the mm
> folks have repeatedly nacked, and I imagine will repeatedly nack in
> the future.
>
> So I imagine the special handling of ppiov in some form is critical
> and the checking may not be removable.
> >>>
> >>> If the above is true, perhaps devmem is not really supposed to be
> >>> intergated
> >>> into page_pool.
> >>>
> >>> Adding a checking for every per-page handling in page_pool core is just
> >>> too
> >>> hacky to be really considerred a longterm solution.
> >>>
> >>
> >> The only other option is to implement another page_pool for ppiov and
> >> have the driver create page_pool or ppiov_pool depending on the state
> >> of the netdev_rx_queue (or some helper in the net stack to do that for
> >> the driver). This introduces some code duplication. The ppiov_pool &
> >> page_pool would look similar in implementation.
>
> I think there is a design pattern already to deal with this kind of problem,
> refactoring common code used by both page_pool and ppiov into a library to
> aovid code duplication if most of them have similar implementation.
>
Code can be refactored if it's identical, not if it is similar. I
suspect the page_pools will be only similar, and if you're not willing
to take devmem handling into the page pool then refactoring page_pool
code into helpers that do devmem handling may also not be an option.
> >>
> >> But this was all discussed in detail in RFC v2 and the last response I
> >> heard from Jesper was in favor if this approach, if I understand
> >> correctly:
> >>
> >> https://lore.kernel.org/netdev/7aedc5d5-0daf-63be-21bc-3b724cc1c...@redhat.com/
> >>
> >> Would love to have the maintainer weigh in here.
> >>
> >
> > I should note we may be able to remove some of the checking, but maybe not
> > all.
> >
> > - Checks that disable page fragging for ppiov can be removed once
> > ppiov has frag support (in this series or follow up).
> >
> > - If we use page->pp_frag_count (or page->pp_ref_count) for
> > refcounting ppiov, we can remove the if checking in the refcounting.
> >
I'm not sure this is actually possible in the short term. The
page_pool uses both page->_refcount and page->pp_frag_count for
refcounting, and I will not be able to remove the special handling
around page->_refcount as i'm not allowed to call page_ref_*() APIs on
a non-struct page.
> > - We may be able to store the dma_addr of the ppiov in page->dma_addr,
> > but I'm unsure if that actually works, because the dma_buf dmaddr is
> > dma_addr_t (u32 or u64), but page->dma_addr is unsigned long (4 bytes
> > I think). But if it works for pages I may be able to make it work for
> > ppiov as well.
> >
> > - Checks that obtain the page->pp can work with ppiov if we align the
> > offset of page->pp and ppiov->pp.
> >
> > - Checks around page->pp_magic can be removed if we also have offset
> > aligned ppiov->pp_magic.
> >
> > Sadly I don't see us removing the checking for these other cases:
> >
> > - page_is_pfmemalloc(): I'm not allowed to pass a non-struct page into
> > that helper.
>
> We can do similar trick like above as bit 1 of page->pp_magic is used to
> indicate that if it is a pfmemalloc page.
>
Likely yes.
> >
> > - page_to_nid(): I'm not allowed to pass a non-struct page into that helper.
>
> Yes, this one need special case.
>
> >
> > - page_pool_free_va(): ppiov have no va.
>
> Doesn't the skb_frags_readable() checking will protect the page_pool_free_va()
> from being
Re: [PATCH] drm/msm/dp: call dp_display_get_next_bridge() during probe
On Tue, Nov 07, 2023 at 02:43:33AM +0200, Dmitry Baryshkov wrote:
> The funcion dp_display_get_next_bridge() can return -EPROBE_DEFER if the
> next bridge is not (yet) available. However returning -EPROBE_DEFER from
> msm_dp_modeset_init() is not ideal. This leads to -EPROBE return from
> component_bind, which can easily result in -EPROBE_DEFR loops.
>
Nice!
> Signed-off-by: Dmitry Baryshkov
> ---
>
> Dependencies: https://patchwork.freedesktop.org/series/120375/
>
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 36 +
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index d542db37763a..ddb3c84f39a2 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1197,15 +1197,27 @@ static const struct msm_dp_desc
> *dp_display_get_desc(struct platform_device *pde
> return NULL;
> }
>
> -static int dp_auxbus_done_probe(struct drm_dp_aux *aux)
> +static int dp_display_get_next_bridge(struct msm_dp *dp);
> +
> +static int dp_display_probe_tail(struct device *dev)
> {
> - int rc;
> + struct msm_dp *dp = dev_get_drvdata(dev);
> + int ret;
>
> - rc = component_add(aux->dev, _display_comp_ops);
> - if (rc)
> - DRM_ERROR("eDP component add failed, rc=%d\n", rc);
> + ret = dp_display_get_next_bridge(dp);
> + if (ret)
> + return ret;
>
> - return rc;
> + ret = component_add(dev, _display_comp_ops);
> + if (ret)
> + DRM_ERROR("component add failed, rc=%d\n", ret);
> +
> + return ret;
> +}
> +
> +static int dp_auxbus_done_probe(struct drm_dp_aux *aux)
> +{
> + return dp_display_probe_tail(aux->dev);
> }
>
> static int dp_display_probe(struct platform_device *pdev)
> @@ -1280,11 +1292,9 @@ static int dp_display_probe(struct platform_device
> *pdev)
> goto err;
> }
> } else {
> - rc = component_add(>dev, _display_comp_ops);
> - if (rc) {
> - DRM_ERROR("component add failed, rc=%d\n", rc);
> + rc = dp_display_probe_tail(>dev);
> + if (rc)
> goto err;
> - }
> }
>
> return rc;
> @@ -1415,7 +1425,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
>* For DisplayPort interfaces external bridges are optional, so
>* silently ignore an error if one is not present (-ENODEV).
>*/
> - rc = devm_dp_parser_find_next_bridge(dp->drm_dev->dev, dp_priv->parser);
> + rc = devm_dp_parser_find_next_bridge(>pdev->dev, dp_priv->parser);
This transition worried me, but after reading the code the current model
of mixing devices for devres scares me more. So, nice cleanup! But I
think we have a few more of these...
That said, >pdev->dev is dp_priv->parser->dev, the function no
longer relate to the "parser module", and we stash the return value of
devm_drm_of_get_bridge(dev, dev->of_node, 1, 0)
in parser->next_brigde, so that we 5 lines below this call can move it
into dp->next_bridge.
As such, I'd like to propose that we change
devm_dp_parser_find_next_bridge() to just take >pdev->dev and return
the next_bridge, in an ERR_PTR().
But that's follow-up-patch material.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> if (!dp->is_edp && rc == -ENODEV)
> return 0;
>
> @@ -1435,10 +1445,6 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
> struct drm_device *dev,
>
> dp_priv = container_of(dp_display, struct dp_display_private,
> dp_display);
>
> - ret = dp_display_get_next_bridge(dp_display);
> - if (ret)
> - return ret;
> -
> ret = dp_bridge_init(dp_display, dev, encoder);
> if (ret) {
> DRM_DEV_ERROR(dev->dev,
> --
> 2.42.0
>
>
[Bug 218250] Regression nouveau driver
https://bugzilla.kernel.org/show_bug.cgi?id=218250 --- Comment #4 from Jaime Pérez (19.jaime...@gmail.com) --- Created attachment 305589 --> https://bugzilla.kernel.org/attachment.cgi?id=305589=edit dmesg wo commit -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
On Wed, Sep 20, 2023 at 12:10 PM 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) > --- > drivers/gpu/drm/bridge/imx/Kconfig | 7 + > drivers/gpu/drm/bridge/imx/Makefile | 1 + > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 206 +++ > 3 files changed, 214 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c > > diff --git a/drivers/gpu/drm/bridge/imx/Kconfig > b/drivers/gpu/drm/bridge/imx/Kconfig > index 9fae28db6aa7..3a4e663d922a 100644 > --- a/drivers/gpu/drm/bridge/imx/Kconfig > +++ b/drivers/gpu/drm/bridge/imx/Kconfig > @@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST > config DRM_IMX_LDB_HELPER > tristate > > +config DRM_IMX8MP_HDMI_PVI > + tristate "Freescale i.MX8MP HDMI PVI bridge support" > + depends on OF > + help > + Choose this to enable support for the internal HDMI TX Parallel > + Video Interface found on the Freescale i.MX8MP SoC. > + > config DRM_IMX8QM_LDB > tristate "Freescale i.MX8QM LVDS display bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/imx/Makefile > b/drivers/gpu/drm/bridge/imx/Makefile > index 8e2ebf3399a1..be9b4f9adb50 100644 > --- a/drivers/gpu/drm/bridge/imx/Makefile > +++ b/drivers/gpu/drm/bridge/imx/Makefile > @@ -1,4 +1,5 @@ > obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o > +obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o > obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o > obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o > obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c > b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c > new file mode 100644 > index ..5ccd70c98187 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c > @@ -0,0 +1,206 @@ > +// SPDX-License-Identifier: GPL-2.0+ > + > +/* > + * Copyright (C) 2022 Pengutronix, Lucas Stach > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include You probably don't need this header and the implicit includes it makes are dropped now in linux-next. Please check what you actually need and make them explicit. Rob
Re: [v3 5/6] drm/vs: Add hdmi driver
On Mon, Dec 4, 2023 at 6:33 AM Keith Zhao wrote: > > add hdmi driver as encoder and connect > > Signed-off-by: Keith Zhao > --- > drivers/gpu/drm/verisilicon/Kconfig | 8 + > drivers/gpu/drm/verisilicon/Makefile| 1 + > drivers/gpu/drm/verisilicon/starfive_hdmi.c | 849 > drivers/gpu/drm/verisilicon/starfive_hdmi.h | 304 +++ > drivers/gpu/drm/verisilicon/vs_drv.c| 3 + > drivers/gpu/drm/verisilicon/vs_drv.h| 4 + > 6 files changed, 1169 insertions(+) > create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c > create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h > > diff --git a/drivers/gpu/drm/verisilicon/Kconfig > b/drivers/gpu/drm/verisilicon/Kconfig > index e10fa97635aa..122c786e3948 100644 > --- a/drivers/gpu/drm/verisilicon/Kconfig > +++ b/drivers/gpu/drm/verisilicon/Kconfig > @@ -11,3 +11,11 @@ config DRM_VERISILICON > This driver provides VeriSilicon kernel mode > setting and buffer management. It does not > provide 2D or 3D acceleration. > + > +config DRM_VERISILICON_STARFIVE_HDMI > + bool "Starfive HDMI extensions" > + depends on DRM_VERISILICON > + help > + This selects support for StarFive soc specific extensions > + for the Innosilicon HDMI driver. If you want to enable > + HDMI on JH7110 based soc, you should select this option. > diff --git a/drivers/gpu/drm/verisilicon/Makefile > b/drivers/gpu/drm/verisilicon/Makefile > index bf6f2b7ee480..71fadafcee13 100644 > --- a/drivers/gpu/drm/verisilicon/Makefile > +++ b/drivers/gpu/drm/verisilicon/Makefile > @@ -6,4 +6,5 @@ vs_drm-objs := vs_dc_hw.o \ > vs_drv.o \ > vs_modeset.o \ > vs_plane.o > +vs_drm-$(CONFIG_DRM_VERISILICON_STARFIVE_HDMI) += starfive_hdmi.o > obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o > diff --git a/drivers/gpu/drm/verisilicon/starfive_hdmi.c > b/drivers/gpu/drm/verisilicon/starfive_hdmi.c > new file mode 100644 > index ..aa621db0dee0 > --- /dev/null > +++ b/drivers/gpu/drm/verisilicon/starfive_hdmi.c > @@ -0,0 +1,849 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (C) 2023 StarFive Technology Co., Ltd. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include You probably don't need this header and the implicit includes it makes are dropped now in linux-next. Please check what you actually need and make them explicit. Rob
Re: [PATCH v5 08/10] drm/panel: Add Ilitek ILI9805 panel driver
On Thu, Dec 7, 2023 at 8:17 AM Dario Binacchi wrote: > > From: Michael Trimarchi > > The GPM1790A0 panel is based on the Ilitek ILI9805 Controller. > Add a driver for it. > > Signed-off-by: Michael Trimarchi > Signed-off-by: Dario Binacchi > > --- > > (no changes since v4) > > Changes in v4: > - Remove duplicated code for prepare/unprepare callbacks > > MAINTAINERS | 6 + > drivers/gpu/drm/panel/Kconfig| 9 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 353 +++ > 4 files changed, 369 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index b82dc141d209..4dccc72a0ed6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6646,6 +6646,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F: Documentation/devicetree/bindings/display/ilitek,ili9486.yaml > F: drivers/gpu/drm/tiny/ili9486.c > > +DRM DRIVER FOR ILITEK ILI9805 PANELS > +M: Michael Trimarchi > +S: Maintained > +F: Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > +F: drivers/gpu/drm/panel/panel-ilitek-ili9805.c > + > DRM DRIVER FOR JADARD JD9365DA-H3 MIPI-DSI LCD PANELS > M: Jagan Teki > S: Maintained > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index d018702be3dc..dad938cf6dec 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -194,6 +194,15 @@ config DRM_PANEL_ILITEK_ILI9341 > QVGA (240x320) RGB panels. support serial & parallel rgb > interface. > > +config DRM_PANEL_ILITEK_ILI9805 > + tristate "Ilitek ILI9805-based panels" > + depends on OF > + depends on DRM_MIPI_DSI > + depends on BACKLIGHT_CLASS_DEVICE > + help > + Say Y if you want to enable support for panels based on the > + Ilitek ILI9805 controller. > + > config DRM_PANEL_ILITEK_ILI9881C > tristate "Ilitek ILI9881C-based panels" > depends on OF > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index f267d932c2b5..d94a644d0a6c 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += > panel-feiyang-fy07024di26a30d > obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o > obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o > obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o > +obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o > obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o > obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9882T) += panel-ilitek-ili9882t.o > obj-$(CONFIG_DRM_PANEL_INNOLUX_EJ030NA) += panel-innolux-ej030na.o > diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c > b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c > new file mode 100644 > index ..e36984b46e14 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c > @@ -0,0 +1,353 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 BSH Hausgerate GmbH > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include You probably don't need this header and the implicit includes it makes are dropped now in linux-next. Please check what you actually need and make them explicit. Rob
Re: [PATCH 2/2] drm/amdgpu: Enable clear page functionality
On Mon, Dec 11, 2023 at 4:50 AM Christian König wrote: > > Am 08.12.23 um 20:53 schrieb Alex Deucher: > > [SNIP] > > You also need a functionality which resets all cleared blocks to > uncleared after suspend/resume. > > No idea how to do this, maybe Alex knows of hand. > > Since the buffers are cleared on creation, is there actually anything to do? > > > Well exactly that's the problem, the buffers are no longer always cleared on > creation with this patch. > > Instead we clear on free, track which areas are cleared and clear only the > ones which aren't cleared yet on creation. > > So some cases need special handling. E.g. when the engine is not initialized > yet or suspend/resume. > > In theory after a suspend/resume cycle the VRAM is cleared to zeros, but in > practice that's not always true. The vbios asic_init table will clear vram on boards with RAS, but not on others. Alex
Re: drm/msm/dp: call dp_display_get_next_bridge() during probe
On 7.11.2023 01:43, Dmitry Baryshkov wrote: > The funcion dp_display_get_next_bridge() can return -EPROBE_DEFER if the > next bridge is not (yet) available. However returning -EPROBE_DEFER from > msm_dp_modeset_init() is not ideal. This leads to -EPROBE return from > component_bind, which can easily result in -EPROBE_DEFR loops. > > Signed-off-by: Dmitry Baryshkov > --- Tested-by: Konrad Dybcio # sc8180x-primus Konrad
Re: [PATCH v3 10/14] drm/panthor: Add the scheduler logical block
On 04/12/2023 17:33, Boris Brezillon wrote:
> This is the piece of software interacting with the FW scheduler, and
> taking care of some scheduling aspects when the FW comes short of slots
> scheduling slots. Indeed, the FW only expose a few slots, and the kernel
> has to give all submission contexts, a chance to execute their jobs.
>
> The kernel-side scheduler is timeslice-based, with a round-robin queue
> per priority level.
>
> Job submission is handled with a 1:1 drm_sched_entity:drm_gpu_scheduler,
> allowing us to delegate the dependency tracking to the core.
>
> All the gory details should be documented inline.
>
> v3:
> - Rework the FW event handling logic to avoid races
> - Make sure MMU faults kill the group immediately
> - Use the panthor_kernel_bo abstraction for group/queue buffers
> - Make in_progress an atomic_t, so we can check it without the reset lock
> held
> - Don't limit the number of groups per context to the FW scheduler
> capacity. Fix the limit to 128 for now.
> - Add a panthor_job_vm() helper
> - Account for panthor_vm changes
> - Add our job fence as DMA_RESV_USAGE_WRITE to all external objects
> (was previously DMA_RESV_USAGE_BOOKKEEP). I don't get why, given
> we're supposed to be fully-explicit, but other drivers do that, so
> there must be a good reason
> - Account for drm_sched changes
> - Provide a panthor_queue_put_syncwait_obj()
> - Unconditionally return groups to their idle list in
> panthor_sched_suspend()
> - Condition of sched_queue_{,delayed_}work fixed to be only when a reset
> isn't pending or in progress.
> - Several typos in comments fixed.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
Two minor comments below, but either way:
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 3410 +++
> drivers/gpu/drm/panthor/panthor_sched.h | 48 +
> 2 files changed, 3458 insertions(+)
> create mode 100644 drivers/gpu/drm/panthor/panthor_sched.c
> create mode 100644 drivers/gpu/drm/panthor/panthor_sched.h
>
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> new file mode 100644
> index ..08e5662f4879
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -0,0 +1,3410 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/* Copyright 2023 Collabora ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "panthor_sched.h"
> +#include "panthor_devfreq.h"
> +#include "panthor_device.h"
> +#include "panthor_gem.h"
> +#include "panthor_heap.h"
> +#include "panthor_regs.h"
> +#include "panthor_gpu.h"
> +#include "panthor_fw.h"
> +#include "panthor_mmu.h"
> +
> +/**
> + * DOC: Scheduler
> + *
> + * Mali CSF hardware adopts a firmware-assisted scheduling model, where
> + * the firmware takes care of scheduling aspects, to some extend.
> + *
> + * The scheduling happens at the scheduling group level, each group
> + * contains 1 to N queues (N is FW/hardware dependent, and exposed
> + * through the firmware interface). Each queue is assigned a command
> + * stream ring buffer, which serves as a way to get jobs submitted to
> + * the GPU, among other things.
> + *
> + * The firmware can schedule a maximum of M groups (M is FW/hardware
> + * dependent, and exposed through the firmware interface). Passed
> + * this maximum number of groups, the kernel must take care of
> + * rotating the groups passed to the firmware so every group gets
> + * a chance to have his queues scheduled for execution.
> + *
> + * The current implementation only supports with kernel-mode queues.
> + * In other terms, userspace doesn't have access to the ring-buffer.
> + * Instead, userspace passes indirect command stream buffers that are
> + * called from the queue ring-buffer by the kernel using a pre-defined
> + * sequence of command stream instructions to ensure the userspace driver
> + * always gets consistent results (cache maintenance,
> + * synchronization, ...).
> + *
> + * We rely on the drm_gpu_scheduler framework to deal with job
> + * dependencies and submission. As any other driver dealing with a
> + * FW-scheduler, we use the 1:1 entity:scheduler mode, such that each
> + * entity has its own job scheduler. When a job is ready to be executed
> + * (all its dependencies are met), it is pushed to the appropriate
> + * queue ring-buffer, and the group is scheduled for execution if it
> + * wasn't already active.
> + *
> + * Kernel-side group scheduling is timeslice-based. When we have less
> + * groups than there are slots, the periodic tick is disabled and we
> + * just let the FW schedule the active groups. When there are more
> + * groups than slots, we let each group a chance to execute stuff for
> + * a given
Re: [PATCH v3] drm/bridge: ti-sn65dsi86: Associate PWM device to auxiliary device
Hi,
On Sat, Dec 9, 2023 at 7:31 AM Uwe Kleine-König
wrote:
>
> It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so
> let the auxiliary device be the parent of the pwm device.
>
> Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get()
> isn't affected by this change as ti_sn65dsi86_add_aux_device() sets the
> auxiliary device's of_node to that of the main device.
>
> Also change PM runtime tracking and diagnostic messages to use that one.
> After enabling runtime PM operation for the auxiliary device, all works
> as expected as parent devices are handled just fine.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Changes since v2
> (https://lore.kernel.org/dri-devel/20231209152520.1987483-2-u.kleine-koe...@pengutronix.de):
>
> - Make use of devm_pm_runtime_enable as suggested by Douglas Anderson
>in reply to v1 already. (Sorry, missed that while preparing v2 :-\)
>
> Changes since (implicit) v1
> (https://lore.kernel.org/dri-devel/20231127101547.734061-2-u.kleine-koe...@pengutronix.de):
>
> - Add a call to pm_runtime_enable() for the aux device
>(tested and diagnosed by Nikita Travkin).
> - Rebased to yesterday's next, which required some (easy) conflict
>resolution for commit c9d99c73940e ("drm/bridge: ti-sn65dsi86:
>Simplify using pm_runtime_resume_and_get()").
>
> Best regards
> Uwe
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
Reviewed-by: Douglas Anderson
I'll also note that, via IRC, Steev also confirmed that "on the c630
with the devm_pm display works too"
Pushed to drm-misc-next:
eb3f7cbee294 drm/bridge: ti-sn65dsi86: Associate PWM device to auxiliary device
Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
On Sun, Dec 10, 2023 at 5:10 AM Samuel Holland
wrote:
>
> Hi Arnd,
>
> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
> > On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
> >> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
> >>> On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
> 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?
> >>>
> >>> Does your configuration have KASAN (I don't think RISC-V supports
> >>> KCSAN)? It is possible that dml/dcn32 needs something similar to commit
> >>> 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN
> >>> or KCSAN in dml2")?
> >>>
> >>> I am not really interested in playing whack-a-mole with these warnings
> >>> like I have done in the past for the reasons I outlined here:
> >>>
> >>> https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/
> >>
> >> I also see one of these with clang 17 even with KASAN disabled:
> >>
> >> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:37:6:
> >> warning: stack frame size (2208) exceeds limit (2048) in
> >> 'dml32_recalculate'
> >> [-Wframe-larger-than]
> >> void dml32_recalculate(struct display_mode_lib *mode_lib)
> >>
> >> ^
> >> 1532/2208 (69.38%) spills, 676/2208 (30.62%) variables
> >>
> >> So I'm in favor of just raising the limit for these files for clang, like
> >> you
> >> suggested in the linked thread.
> >
> > How about just adding a BUG_ON(IS_ENABLED(CONFIG_RISCV))
> > in that function? That should also avoid the build failure
> > but give a better indication of where the problem is
> > if someone actually runs into that function and triggers
> > a runtime stack overflow.
>
> Won't that break actual users of the driver, trading an unlikely but
> theoretically possible stack overflow for a guaranteed crash? The intent of
> this
> series is that I have one of these GPUs plugged in to a RISC-V board, and I
> want
> to use it.
Does this patch address the issue?
https://gitlab.freedesktop.org/agd5f/linux/-/commit/72ada8603e36291ad91e4f40f10ef742ef79bc4e
Alex
Re: [PATCH] drm/msm/dpu: remove extra drm_encoder_cleanup from the error path
On Mon, 11 Dec 2023 at 16:54, Dmitry Baryshkov
wrote:
>
> The drmm handler will perform drm_encoder_cleanup() for us. Moreover if
> we call drm_encoder_cleanup() manually, the drmm_encoder_alloc_release()
> will spawn warnings at drivers/gpu/drm/drm_encoder.c:214. Drop these
> extra drm_encoder_cleanup() calls.
>
> Fixes: cd42c56d9c0b ("drm/msm/dpu: use drmm-managed allocation for
> dpu_encoder_virt")
> Signed-off-by: Dmitry Baryshkov
Reported-by: Konrad Dybcio
--
With best wishes
Dmitry
Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V
Hi Alex,
On 2023-12-11 9:17 AM, Alex Deucher wrote:
> On Sun, Dec 10, 2023 at 5:10 AM Samuel Holland
> wrote:
>>
>> Hi Arnd,
>>
>> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
>>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
> On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
>> 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?
>
> Does your configuration have KASAN (I don't think RISC-V supports
> KCSAN)? It is possible that dml/dcn32 needs something similar to commit
> 6740ec97bcdb ("drm/amd/display: Increase frame warning limit with KASAN
> or KCSAN in dml2")?
>
> I am not really interested in playing whack-a-mole with these warnings
> like I have done in the past for the reasons I outlined here:
>
> https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/
I also see one of these with clang 17 even with KASAN disabled:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:37:6:
warning: stack frame size (2208) exceeds limit (2048) in
'dml32_recalculate'
[-Wframe-larger-than]
void dml32_recalculate(struct display_mode_lib *mode_lib)
^
1532/2208 (69.38%) spills, 676/2208 (30.62%) variables
So I'm in favor of just raising the limit for these files for clang, like
you
suggested in the linked thread.
>>>
>>> How about just adding a BUG_ON(IS_ENABLED(CONFIG_RISCV))
>>> in that function? That should also avoid the build failure
>>> but give a better indication of where the problem is
>>> if someone actually runs into that function and triggers
>>> a runtime stack overflow.
>>
>> Won't that break actual users of the driver, trading an unlikely but
>> theoretically possible stack overflow for a guaranteed crash? The intent of
>> this
>> series is that I have one of these GPUs plugged in to a RISC-V board, and I
>> want
>> to use it.
>
> Does this patch address the issue?
> https://gitlab.freedesktop.org/agd5f/linux/-/commit/72ada8603e36291ad91e4f40f10ef742ef79bc4e
No, I get the warning without any of these debugging options enabled. I can
reproduce with just defconfig + CONFIG_DRM_AMDGPU=m when built with clang 17.
Regards,
Samuel
[PATCH v2 6/8] arm64: dts: qcom: sm8150: add USB-C ports to the USB+DP QMP PHY
Expand Combo USB+DP QMP PHY device node with the OF ports required to
support USB-C / DisplayPort switching.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index ea7c92c0e405..77d32f4fe7da 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -3447,6 +3447,32 @@ usb_1_qmpphy: phy@88e8000 {
#phy-cells = <1>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_1_qmpphy_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_1_qmpphy_usb_ss_in: endpoint {
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_1_qmpphy_dp_in: endpoint {
+ };
+ };
+ };
};
usb_2_qmpphy: phy@88eb000 {
--
2.39.2
[PATCH v2 7/8] arm64: dts: qcom: sm8150: add USB-C ports to the OTG USB host
Expand first USB host controller device node with the OF ports required
to support USB-C / DisplayPort switching.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 77d32f4fe7da..168d49b01807 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -3608,6 +3608,25 @@ usb_1_dwc3: usb@a60 {
snps,dis_enblslpm_quirk;
phys = <_1_hsphy>, <_1_qmpphy
QMP_USB43DP_USB3_PHY>;
phy-names = "usb2-phy", "usb3-phy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_1_dwc3_hs: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_1_dwc3_ss: endpoint {
+ };
+ };
+ };
};
};
--
2.39.2
[PATCH v2 8/8] arm64: dts: qcom: sm8150-hdk: enable DisplayPort and USB-C altmode
Enable the USB-C related functionality for the USB-C port on this board.
This includes OTG, PowerDelivery and DP AltMode. Also enable the
DisplayPort itself.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 124 +++-
1 file changed, 123 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
index ea4d75308ac8..de670b407ef1 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
@@ -7,6 +7,7 @@
#include
#include
+#include
#include "sm8150.dtsi"
#include "pm8150.dtsi"
#include "pm8150b.dtsi"
@@ -374,6 +375,10 @@ {
status = "okay";
};
+_dma0 {
+ status = "okay";
+};
+
_dma1 {
status = "okay";
};
@@ -382,6 +387,29 @@ {
status = "okay";
};
+ {
+ clock-frequency = <10>;
+
+ status = "okay";
+
+ typec-mux@42 {
+ compatible = "fcs,fsa4480";
+ reg = <0x42>;
+
+ interrupts-extended = < 152 IRQ_TYPE_LEVEL_LOW>;
+
+ vcc-supply = <_bob>;
+ mode-switch;
+ orientation-switch;
+
+ port {
+ fsa4480_sbu_mux: endpoint {
+ remote-endpoint = <_typec_sbu_out>;
+ };
+ };
+ };
+};
+
{
status = "okay";
clock-frequency = <40>;
@@ -436,6 +464,15 @@ {
status = "okay";
};
+_dp {
+ status = "okay";
+};
+
+_dp_out {
+ data-lanes = <0 1>;
+ remote-endpoint = <_1_qmpphy_dp_in>;
+};
+
_dsi0 {
status = "okay";
vdda-supply = <_l3c_1p2>;
@@ -483,6 +520,65 @@ _dsi1_phy {
status = "okay";
};
+_vbus {
+ regulator-min-microamp = <50>;
+ regulator-max-microamp = <300>;
+ status = "okay";
+};
+
+_typec {
+ status = "okay";
+
+ vdd-pdphy-supply = <_l2a_3p1>;
+
+ connector {
+ compatible = "usb-c-connector";
+
+ power-role = "source";
+ data-role = "dual";
+ self-powered;
+
+ source-pdos = ;
+
+ altmodes {
+ displayport {
+ svid = /bits/ 16 <0xff01>;
+ vdo = <0x1c46>;
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ pm8150b_role_switch_in: endpoint {
+ remote-endpoint = <_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ pm8150b_typec_mux_in: endpoint {
+ remote-endpoint = <_1_qmpphy_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ pm8150b_typec_sbu_out: endpoint {
+ remote-endpoint = <_sbu_mux>;
+ };
+ };
+ };
+ };
+};
+
_pwrkey {
status = "okay";
};
@@ -493,6 +589,10 @@ _resin {
linux,code = ;
};
+_id_0 {
+ status = "okay";
+};
+
_id_1 {
status = "okay";
};
@@ -568,6 +668,19 @@ _1_qmpphy {
status = "okay";
vdda-phy-supply = <_l3c_1p2>;
vdda-pll-supply = <_l18a_0p8>;
+ orientation-switch;
+};
+
+_1_qmpphy_dp_in {
+ remote-endpoint = <_dp_out>;
+};
+
+_1_qmpphy_out {
+ remote-endpoint = <_typec_mux_in>;
+};
+
+_1_qmpphy_usb_ss_in {
+ remote-endpoint = <_1_dwc3_ss>;
};
_2_qmpphy {
@@ -585,7 +698,16 @@ _2 {
};
_1_dwc3 {
- dr_mode = "peripheral";
+ dr_mode = "otg";
+ usb-role-switch;
+};
+
+_1_dwc3_hs {
+ remote-endpoint = <_role_switch_in>;
+};
+
+_1_dwc3_ss {
+ remote-endpoint = <_1_qmpphy_usb_ss_in>;
};
_2_dwc3 {
--
2.39.2
[PATCH v2 4/8] arm64: dts: qcom: sm8150-hdk: fix SS USB regulators
The SM8150-HDK uses two different regulators to power up SuperSpeed USB
PHYs. The L5A regulator is used for the second USB host, while the first
(OTG) USB host uses different regulator, L18A. Fix the regulator for the
usb_1 QMPPHY and (to remove possible confusion) drop the
usb_ss_dp_core_1/_2 labels.
Fixes: 0ab1b2d10afe ("arm64: dts: qcom: add sm8150 hdk dts")
Reviewed-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
index 6a036f9ba1c9..ea4d75308ac8 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
@@ -138,8 +138,6 @@ vdda_qrefs_0p875_5:
vdda_sp_sensor:
vdda_ufs_2ln_core_1:
vdda_ufs_2ln_core_2:
- vdda_usb_ss_dp_core_1:
- vdda_usb_ss_dp_core_2:
vdda_qlink_lv:
vdda_qlink_lv_ck:
vreg_l5a_0p875: ldo5 {
@@ -221,6 +219,12 @@ vreg_l17a_3p0: ldo17 {
regulator-max-microvolt = <3008000>;
regulator-initial-mode = ;
};
+
+ vreg_l18a_0p8: ldo18 {
+ regulator-min-microvolt = <88>;
+ regulator-max-microvolt = <88>;
+ regulator-initial-mode = ;
+ };
};
regulators-1 {
@@ -563,13 +567,13 @@ _2_hsphy {
_1_qmpphy {
status = "okay";
vdda-phy-supply = <_l3c_1p2>;
- vdda-pll-supply = <_usb_ss_dp_core_1>;
+ vdda-pll-supply = <_l18a_0p8>;
};
_2_qmpphy {
status = "okay";
vdda-phy-supply = <_l3c_1p2>;
- vdda-pll-supply = <_usb_ss_dp_core_1>;
+ vdda-pll-supply = <_l5a_0p875>;
};
_1 {
--
2.39.2
[PATCH v2 2/8] arm64: dts: qcom: sm8150: make dispcc cast minimal vote on MMCX
Add required-opps property to the display clock controller. This makes
it cast minimal vote on the MMCX lane and prevents further 'clock stuck'
errors when enabling the display.
Fixes: 2ef3bb17c45c ("arm64: dts: qcom: sm8150: Add DISPCC node")
Acked-by: Konrad Dybcio
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index fb41f91cefc6..153c531c1d41 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -3925,6 +3925,7 @@ dispcc: clock-controller@af0 {
"dp_phy_pll_link_clk",
"dp_phy_pll_vco_div_clk";
power-domains = < SM8150_MMCX>;
+ required-opps = <_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.39.2
[PATCH v2 5/8] arm64: dts: qcom: sm8150: add DisplayPort controller
Add device tree node for the DisplayPort controller and link it to the
display controller interface.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 87
1 file changed, 87 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 153c531c1d41..ea7c92c0e405 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -3712,6 +3712,13 @@ dpu_intf2_out: endpoint {
remote-endpoint =
<_dsi1_in>;
};
};
+
+ port@2 {
+ reg = <2>;
+ dpu_intf0_out: endpoint {
+ remote-endpoint =
<_dp_in>;
+ };
+ };
};
mdp_opp_table: opp-table {
@@ -3739,6 +3746,86 @@ opp-46000 {
};
};
+ mdss_dp: displayport-controller@ae9 {
+ compatible = "qcom,sm8150-dp", "qcom,sm8350-dp";
+ reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0x0ae90a00 0 0x600>,
+ <0 0x0ae91000 0 0x600>;
+
+ interrupt-parent = <>;
+ interrupts = <12>;
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_DP_AUX_CLK>,
+< DISP_CC_MDSS_DP_LINK_CLK>,
+<
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+< DISP_CC_MDSS_DP_PIXEL_CLK>;
+ clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+ assigned-clocks = <
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ <
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+ assigned-clock-parents = <_1_qmpphy
QMP_USB43DP_DP_LINK_CLK>,
+<_1_qmpphy
QMP_USB43DP_DP_VCO_DIV_CLK>;
+
+ phys = <_1_qmpphy QMP_USB43DP_DP_PHY>;
+ phy-names = "dp";
+
+ #sound-dai-cells = <0>;
+
+ operating-points-v2 = <_opp_table>;
+ power-domains = < SM8250_MMCX>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mdss_dp_in: endpoint {
+ remote-endpoint =
<_intf0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_dp_out: endpoint {
+ };
+ };
+ };
+
+ dp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-16000 {
+ opp-hz = /bits/ 64 <16000>;
+ required-opps =
<_opp_low_svs>;
+ };
+
+ opp-27000 {
+ opp-hz = /bits/ 64 <27000>;
+ required-opps =
<_opp_svs>;
+ };
+
+ opp-54000 {
+ opp-hz = /bits/ 64 <54000>;
+ required-opps =
<_opp_svs_l1>;
+ };
+
+
[PATCH v2 3/8] arm64: dts: qcom: sm8150-hdk: enable HDMI output
Add DSI outputs and link them to the onboard Lontium LT9611 DSI-to-HDMI
bridge, enabling HDMI output on this board. While adding the display
resources, also drop the headless ("amd,imageon") compat string from the
GPU node, since the board now has output.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 128 +++-
1 file changed, 123 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
index bb161b536da4..6a036f9ba1c9 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
@@ -54,6 +54,17 @@ key-vol-up {
gpios = <_gpios 6 GPIO_ACTIVE_LOW>;
};
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
};
_rsc {
@@ -359,12 +370,112 @@ {
status = "okay";
};
+_dma1 {
+ status = "okay";
+};
+
{
- /*
-* NOTE: "amd,imageon" makes Adreno start in headless mode, remove it
-* after display support is added on this board.
-*/
- compatible = "qcom,adreno-640.1", "qcom,adreno", "amd,imageon";
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ clock-frequency = <40>;
+
+ lt9611_codec: hdmi-bridge@3b {
+ compatible = "lontium,lt9611";
+ reg = <0x3b>;
+ #sound-dai-cells = <1>;
+
+ interrupts-extended = < 9 IRQ_TYPE_EDGE_FALLING>;
+
+ reset-gpios = < 7 GPIO_ACTIVE_HIGH>;
+
+ vdd-supply = <_s4a_1p8>;
+ vcc-supply = <_bob>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_irq_pin>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt9611_a: endpoint {
+ remote-endpoint = <_dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lt9611_b: endpoint {
+ remote-endpoint = <_dsi1_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ lt9611_out: endpoint {
+ remote-endpoint = <_con>;
+ };
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+_dsi0 {
+ status = "okay";
+ vdda-supply = <_l3c_1p2>;
+
+ qcom,dual-dsi-mode;
+ qcom,master-dsi;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <_a>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+_dsi0_phy {
+ status = "okay";
+ vdds-supply = <_l5a_0p875>;
+};
+
+_dsi1 {
+ vdda-supply = <_l3c_1p2>;
+
+ qcom,dual-dsi-mode;
+
+ /* DSI1 is slave, so use DSI0 clocks */
+ assigned-clock-parents = <_dsi0_phy 0>, <_dsi0_phy 1>;
+
+ status = "okay";
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <_b>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+_dsi1_phy {
+ vdds-supply = <_l5a_0p875>;
status = "okay";
};
@@ -402,6 +513,13 @@ _slpi {
{
gpio-reserved-ranges = <0 4>, <126 4>;
+
+ lt9611_irq_pin: lt9611-irq-state {
+ pins = "gpio9";
+ function = "gpio";
+ bias-disable;
+ };
+
};
{
--
2.39.2
[PATCH v2 1/8] dt-bindings: display: msm: dp: declare compatible string for sm8150
Add compatible string for the DisplayPort controller found on the Qualcomm SM8150 platform. Signed-off-by: Dmitry Baryshkov --- Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index dbe398f84ffb..f850bd9b8263 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -28,6 +28,7 @@ properties: - qcom,sm8350-dp - items: - enum: + - qcom,sm8150-dp - qcom,sm8250-dp - qcom,sm8450-dp - qcom,sm8550-dp -- 2.39.2
[PATCH v2 0/8] arm64: dts: qcom: sm8150-hdk: enable display output
Enable display output on the SM8150 HDK device. This includes HDMI output through the onboard DSI-HDMI bridge and DP output on the USB-C port. Changes since v1 - Dropped irrelevant stats patch - Fixed endpoint stye (Konrad) - Changed SVID from u32 to 16-bits value (Konrad) Dmitry Baryshkov (8): dt-bindings: display: msm: dp: declare compatible string for sm8150 arm64: dts: qcom: sm8150: make dispcc cast minimal vote on MMCX arm64: dts: qcom: sm8150-hdk: enable HDMI output arm64: dts: qcom: sm8150-hdk: fix SS USB regulators arm64: dts: qcom: sm8150: add DisplayPort controller arm64: dts: qcom: sm8150: add USB-C ports to the USB+DP QMP PHY arm64: dts: qcom: sm8150: add USB-C ports to the OTG USB host arm64: dts: qcom: sm8150-hdk: enable DisplayPort and USB-C altmode .../bindings/display/msm/dp-controller.yaml | 1 + arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 264 +- arch/arm64/boot/dts/qcom/sm8150.dtsi | 133 + 3 files changed, 388 insertions(+), 10 deletions(-) -- 2.39.2
[GIT PULL] mediatek drm fixes 20231211
Hi, Dave & Daniel: This includes: 1. mtk_disp_gamma: Fix breakage due to merge issue 2. fix kernel oops if no crtc is found 3. Add spinlock for setting vblank event in atomic_begin 4. Fix access violation in mtk_drm_crtc_dma_dev_get Regards, Chun-Kuang. The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86: Linux 6.7-rc1 (2023-11-12 16:19:07 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git tags/mediatek-drm-fixes-20231211 for you to fetch changes up to b6961d187fcd138981b8707dac87b9fcdbfe75d1: drm/mediatek: Fix access violation in mtk_drm_crtc_dma_dev_get (2023-12-11 14:40:05 +) Mediatek DRM Fixes - 20231211 1. mtk_disp_gamma: Fix breakage due to merge issue 2. fix kernel oops if no crtc is found 3. Add spinlock for setting vblank event in atomic_begin 4. Fix access violation in mtk_drm_crtc_dma_dev_get AngeloGioacchino Del Regno (1): drm/mediatek: mtk_disp_gamma: Fix breakage due to merge issue Jason-JH.Lin (1): drm/mediatek: Add spinlock for setting vblank event in atomic_begin Michael Walle (1): drm/mediatek: fix kernel oops if no crtc is found Stuart Lee (1): drm/mediatek: Fix access violation in mtk_drm_crtc_dma_dev_get drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 2 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 14 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 5 - 3 files changed, 18 insertions(+), 3 deletions(-)
