[PATCH] drm/etnaviv: Added error handling for dma_map_sgtable.
Added error handling for dma_map_sgtable.
If an error occurs, the sgt table is freed.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 182354a526a0 ("drm: etnaviv: fix common struct sg_table related issues")
Signed-off-by: Danila Chernetsov
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index b5f73502e3dd..59d1684dafc4 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -17,7 +17,7 @@
static struct lock_class_key etnaviv_shm_lock_class;
static struct lock_class_key etnaviv_userptr_lock_class;
-static void etnaviv_gem_scatter_map(struct etnaviv_gem_object *etnaviv_obj)
+static int etnaviv_gem_scatter_map(struct etnaviv_gem_object *etnaviv_obj)
{
struct drm_device *dev = etnaviv_obj->base.dev;
struct sg_table *sgt = etnaviv_obj->sgt;
@@ -27,7 +27,9 @@ static void etnaviv_gem_scatter_map(struct etnaviv_gem_object
*etnaviv_obj)
* because display controller, GPU, etc. are not coherent.
*/
if (etnaviv_obj->flags & ETNA_BO_CACHE_MASK)
- dma_map_sgtable(dev->dev, sgt, DMA_BIDIRECTIONAL, 0);
+ return dma_map_sgtable(dev->dev, sgt, DMA_BIDIRECTIONAL, 0);
+
+ return 0;
}
static void etnaviv_gem_scatterlist_unmap(struct etnaviv_gem_object
*etnaviv_obj)
@@ -113,7 +115,13 @@ struct page **etnaviv_gem_get_pages(struct
etnaviv_gem_object *etnaviv_obj)
etnaviv_obj->sgt = sgt;
- etnaviv_gem_scatter_map(etnaviv_obj);
+ ret = etnaviv_gem_scatter_map(etnaviv_obj);
+ if (ret < 0) {
+ sg_free_table(etnaviv_obj->sgt);
+ kfree(etnaviv_obj->sgt);
+ etnaviv_obj->sgt = NULL;
+ return ERR_PTR(ret);
+ }
}
return etnaviv_obj->pages;
--
2.25.1
[PATCH v1 3/3] drm/rockchip: inno_hdmi: Remove unused drm device pointer
The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.
Signed-off-by: Maxime Ripard
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 535cca30c256..ff7fa11dbc61 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -48,7 +48,6 @@ struct inno_hdmi_i2c {
struct inno_hdmi {
struct device *dev;
- struct drm_device *drm_dev;
int irq;
struct clk *pclk;
@@ -821,7 +820,6 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
return -ENOMEM;
hdmi->dev = dev;
- hdmi->drm_dev = drm;
hdmi->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hdmi->regs))
--
2.39.2
[PATCH v1 2/3] drm/rockchip: inno_hdmi: Switch encoder hooks to atomic
The inno_hdmi encoder still uses the non atomic variants
of enable and disable. Convert to their atomic equivalents.
In atomic mode there is no need to save the adjusted mode,
so remove the mode_set function.
Signed-off-by: Maxime Ripard
Signed-off-by: Johan Jonker
---
Changed V1:
Combined patches
Include drm_atomic.h
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 46 ++--
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index cc48cbf85f31..535cca30c256 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -5,6 +5,13 @@
*Yakir Yang
*/
+#include
+#include
+#include
+#include
+#include
+#include
+
#include
#include
#include
@@ -16,12 +23,6 @@
#include
#include
-#include
-#include
-#include
-#include
-#include
-
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
@@ -62,7 +63,6 @@ struct inno_hdmi {
unsigned int tmds_rate;
struct hdmi_data_info hdmi_data;
- struct drm_display_mode previous_mode;
};
static struct inno_hdmi *encoder_to_inno_hdmi(struct drm_encoder *encoder)
@@ -491,26 +491,27 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
return 0;
}
-static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adj_mode)
+static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
{
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+ struct drm_connector_state *conn_state;
+ struct drm_crtc_state *crtc_state;
- inno_hdmi_setup(hdmi, adj_mode);
+ conn_state = drm_atomic_get_new_connector_state(state,
>connector);
+ if (WARN_ON(!conn_state))
+ return;
- /* Store the display mode for plugin/DPMS poweron events */
- drm_mode_copy(>previous_mode, adj_mode);
-}
-
-static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
-{
- struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+ if (WARN_ON(!crtc_state))
+ return;
+ inno_hdmi_setup(hdmi, _state->adjusted_mode);
inno_hdmi_set_pwr_mode(hdmi, NORMAL);
}
-static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
+static void inno_hdmi_encoder_disable(struct drm_encoder *encoder,
+ struct drm_atomic_state *state)
{
struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
@@ -531,10 +532,9 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
}
static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
- .enable = inno_hdmi_encoder_enable,
- .disable= inno_hdmi_encoder_disable,
- .mode_set = inno_hdmi_encoder_mode_set,
- .atomic_check = inno_hdmi_encoder_atomic_check,
+ .atomic_check = inno_hdmi_encoder_atomic_check,
+ .atomic_enable = inno_hdmi_encoder_enable,
+ .atomic_disable = inno_hdmi_encoder_disable,
};
static enum drm_connector_status
--
2.39.2
[PATCH v1 1/3] drm/rockchip: inno_hdmi: Remove useless mode_fixup
The mode_fixup implementation doesn't do anything, so we can simply
remove it.
Signed-off-by: Maxime Ripard
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 6e5b922a121e..cc48cbf85f31 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -517,13 +517,6 @@ static void inno_hdmi_encoder_disable(struct drm_encoder
*encoder)
inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
}
-static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adj_mode)
-{
- return true;
-}
-
static int
inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
@@ -540,7 +533,6 @@ inno_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
.enable = inno_hdmi_encoder_enable,
.disable= inno_hdmi_encoder_disable,
- .mode_fixup = inno_hdmi_encoder_mode_fixup,
.mode_set = inno_hdmi_encoder_mode_set,
.atomic_check = inno_hdmi_encoder_atomic_check,
};
--
2.39.2
[PATCH v1 0/3] Rockchip inno_hdmi update
Combined update for the Rockchip inno_hdmi driver in a somewhat similar way to what is proposed for the "Create HDMI Connector infrastructure patch serie". Keeping the inno_hdmi and rk3066_hdmi driver functions comparable makes maintanance easier. Maxime Ripard (3): drm/rockchip: inno_hdmi: Remove useless mode_fixup drm/rockchip: inno_hdmi: Switch encoder hooks to atomic drm/rockchip: inno_hdmi: Remove unused drm device pointer drivers/gpu/drm/rockchip/inno_hdmi.c | 56 1 file changed, 23 insertions(+), 33 deletions(-) -- 2.39.2
Re: [PATCH RFC v3 22/37] drm/rockchip: inno_hdmi: Remove useless output format
Hi Maxime,
In stead of further cripplingRockchip HDMI drivers one could also make it
functional based on EDID info.
To start with the output could you turn RGB888 input and switch between
RGB444, YCBCR444 and YCBCR422 output.
Johan
On 10/31/23 17:48, Maxime Ripard wrote:
> Similarly to the input format, the driver has a lot of code to deal with
> various output format, but the driver hardcodes it to RGB always.
>
> Let's get rid of the dead code.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/rockchip/inno_hdmi.c | 57
>
> 1 file changed, 6 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
> b/drivers/gpu/drm/rockchip/inno_hdmi.c
> index e0696ab16da3..0c6c550e0ce7 100644
> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> @@ -28,7 +28,6 @@
> #include "inno_hdmi.h"
>
> struct hdmi_data_info {
> - unsigned int enc_out_format;
> unsigned int colorimetry;
> };
>
> @@ -296,26 +295,14 @@ static int inno_hdmi_config_video_avi(struct inno_hdmi
> *hdmi,
> rc = drm_hdmi_avi_infoframe_from_display_mode(,
> >connector,
> mode);
> -
> - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
> - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
> - else
> - frame.avi.colorspace = HDMI_COLORSPACE_RGB;
> + frame.avi.colorspace = HDMI_COLORSPACE_RGB;
>
> return inno_hdmi_upload_frame(hdmi, rc, , INFOFRAME_AVI, 0, 0, 0);
> }
>
> static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
> {
> - struct hdmi_data_info *data = >hdmi_data;
> - int c0_c2_change = 0;
> - int csc_enable = 0;
> - int csc_mode = 0;
> - int auto_csc = 0;
> int value;
> - int i;
>
> /* Input video mode is SDR RGB24bit, data enable signal from external */
> hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL1, v_DE_EXTERNAL |
> @@ -327,43 +314,13 @@ static int inno_hdmi_config_video_csc(struct inno_hdmi
> *hdmi)
> v_VIDEO_INPUT_CSP(0);
> hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
>
> - if (HDMI_COLORSPACE_RGB == data->enc_out_format) {
> - value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> - hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> -
> - hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> - m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> - v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> - v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> - return 0;
> - }
> -
> - if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
> - if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
> - csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
> - auto_csc = AUTO_CSC_DISABLE;
> - c0_c2_change = C0_C2_CHANGE_DISABLE;
> - csc_enable = v_CSC_ENABLE;
> - }
> - } else {
> - if (data->enc_out_format == HDMI_COLORSPACE_YUV444) {
> - csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
> - auto_csc = AUTO_CSC_DISABLE;
> - c0_c2_change = C0_C2_CHANGE_DISABLE;
> - csc_enable = v_CSC_ENABLE;
> - }
> - }
> -
> - for (i = 0; i < 24; i++)
> - hdmi_writeb(hdmi, HDMI_VIDEO_CSC_COEF + i,
> - coeff_csc[csc_mode][i]);
> -
> - value = v_SOF_DISABLE | csc_enable | v_COLOR_DEPTH_NOT_INDICATED(1);
> + value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
> hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
> - hdmi_modb(hdmi, HDMI_VIDEO_CONTRL, m_VIDEO_AUTO_CSC |
> - m_VIDEO_C0_C2_SWAP, v_VIDEO_AUTO_CSC(auto_csc) |
> - v_VIDEO_C0_C2_SWAP(c0_c2_change));
>
> + hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
> + m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
> + v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
> + v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
> return 0;
> }
>
> @@ -425,8 +382,6 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
> struct drm_display_info *display = >connector.display_info;
> u8 vic = drm_match_cea_mode(mode);
>
> - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
> -
> if ((vic == 6) || (vic == 7) ||
> (vic == 21) || (vic == 22) ||
> (vic == 2) || (vic == 3) ||
>
[PATCH 3/6] drm/bridge: tc358775: Add jeida-24 support
The jeida-24 register values are the default hardware settings, but they
not listed in the driver. Let's add them.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -458,8 +458,18 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
* Default hardware register settings of tc358775 configured
* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
*/
- if (connector->display_info.bus_formats[0] ==
- MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
+ switch (connector->display_info.bus_formats[0]) {
+ case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
+ /* JEIDA-24 */
+ d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R2, LVI_R3, LVI_R4,
LVI_R5));
+ d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R6, LVI_R1, LVI_R7,
LVI_G2));
+ d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G3, LVI_G4, LVI_G0,
LVI_G1));
+ d2l_write(tc->i2c, LV_MX1215, LV_MX(LVI_G5, LVI_G6, LVI_G7,
LVI_B2));
+ d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B0, LVI_B1, LVI_B3,
LVI_B4));
+ d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B5, LVI_B6, LVI_B7,
LVI_L0));
+ d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R0));
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
/* VESA-24 */
d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
LVI_R3));
d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_R7, LVI_R5,
LVI_G0));
@@ -468,7 +478,9 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1,
LVI_B2));
d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_R6));
- } else { /* MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - JEIDA-18 */
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+ /* JEIDA-18 */
d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2,
LVI_R3));
d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_L0, LVI_R5,
LVI_G0));
d2l_write(tc->i2c, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_L0,
LVI_L0));
@@ -476,6 +488,9 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
d2l_write(tc->i2c, LV_MX1619, LV_MX(LVI_L0, LVI_L0, LVI_B1,
LVI_B2));
d2l_write(tc->i2c, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5,
LVI_L0));
d2l_write(tc->i2c, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE,
LVI_L0));
+ break;
+ default:
+ break;
}
d2l_write(tc->i2c, VFUEN, VFUEN_EN);
--
2.42.1
[PATCH 5/6] drm/bridge: tc358775: Add support for tc358765
Looks like tc358775 is pin compatible with earlier tc358765 according to
the tc358774xbg_datasheet_en_20190118.pdf documentation. On tc358775,
there is an extra GPIO for STBY pin added, and few other improvments.
The tc358765 has a register bit for video event mode that we must set for
the LCD output to work. On tc358775, this bit no longer exists.
Looks like the registers seem to match otherwise based on a quick glance
comparing the defines to the earlier Android kernel tc358765 driver.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 55 +++
1 file changed, 42 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,6 +108,7 @@
#define RDPKTLN 0x0404 /* Command Read Packet Length */
#define VPCTRL 0x0450 /* Video Path Control */
+#define EVTMODEBIT(5) /* Video event mode enable, tc35876x
only */
#define HTIM1 0x0454 /* Horizontal Timing Control 1 */
#define HTIM2 0x0458 /* Horizontal Timing Control 2 */
#define VTIM1 0x045C /* Vertical Timing Control 1 */
@@ -254,6 +256,11 @@ enum tc358775_ports {
TC358775_LVDS_OUT1,
};
+enum tc3587x5_type {
+ TC358765,
+ TC358775,
+};
+
struct tc_data {
struct i2c_client *i2c;
struct device *dev;
@@ -271,6 +278,8 @@ struct tc_data {
struct gpio_desc*stby_gpio;
u8 lvds_link; /* single-link or dual-link */
u8 bpc;
+
+ enum tc3587x5_type type;
};
static inline struct tc_data *bridge_to_tc(struct drm_bridge *b)
@@ -294,8 +303,10 @@ static void tc_bridge_pre_enable(struct drm_bridge *bridge)
dev_err(dev, "regulator vdd enable failed, %d\n", ret);
usleep_range(1, 11000);
- gpiod_set_value(tc->stby_gpio, 0);
- usleep_range(1, 11000);
+ if (!IS_ERR(tc->stby_gpio)) {
+ gpiod_set_value(tc->stby_gpio, 0);
+ usleep_range(1, 11000);
+ }
gpiod_set_value(tc->reset_gpio, 0);
usleep_range(10, 20);
@@ -310,8 +321,10 @@ static void tc_bridge_post_disable(struct drm_bridge
*bridge)
gpiod_set_value(tc->reset_gpio, 1);
usleep_range(10, 20);
- gpiod_set_value(tc->stby_gpio, 1);
- usleep_range(1, 11000);
+ if (!IS_ERR(tc->stby_gpio)) {
+ gpiod_set_value(tc->stby_gpio, 1);
+ usleep_range(1, 11000);
+ }
ret = regulator_disable(tc->vdd);
if (ret < 0)
@@ -424,10 +437,16 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
d2l_write(tc->i2c, PPI_STARTPPI, PPI_START_FUNCTION);
d2l_write(tc->i2c, DSI_STARTDSI, DSI_RX_START);
+ /* Video event mode, this bit does not exist for tc358775 */
+ if (tc->type == TC358765)
+ val = EVTMODE;
+ else
+ val = 0;
+
if (tc->bpc == 8)
- val = TC358775_VPCTRL_OPXLFMT(1);
+ val |= TC358775_VPCTRL_OPXLFMT(1);
else /* bpc = 6; */
- val = TC358775_VPCTRL_MSF(1);
+ val |= TC358775_VPCTRL_MSF(1);
dsiclk = mode->crtc_clock * 3 * tc->bpc / tc->num_dsi_lanes / 1000;
clkdiv = dsiclk / (tc->lvds_link == DUAL_LINK ? DIVIDE_BY_6 :
DIVIDE_BY_3);
@@ -656,6 +675,7 @@ static int tc_probe(struct i2c_client *client)
tc->dev = dev;
tc->i2c = client;
+ tc->type = (enum tc3587x5_type)of_device_get_match_data(dev);
tc->panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node,
TC358775_LVDS_OUT0, 0);
@@ -680,11 +700,15 @@ static int tc_probe(struct i2c_client *client)
return ret;
}
- tc->stby_gpio = devm_gpiod_get(dev, "stby", GPIOD_OUT_HIGH);
- if (IS_ERR(tc->stby_gpio)) {
- ret = PTR_ERR(tc->stby_gpio);
- dev_err(dev, "cannot get stby-gpio %d\n", ret);
- return ret;
+ if (tc->type == TC358775) {
+ tc->stby_gpio = devm_gpiod_get(dev, "stby", GPIOD_OUT_HIGH);
+ if (IS_ERR(tc->stby_gpio)) {
+ ret = PTR_ERR(tc->stby_gpio);
+ dev_err(dev, "cannot get stby-gpio %d\n", ret);
+ return ret;
+ }
+ } else {
+ tc->stby_gpio = ERR_PTR(-ENODEV);
}
tc->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
@@ -696,6 +720,7 @@ static int tc_probe(struct i2c_client *client)
tc->bridge.funcs = _bridge_funcs;
tc->bridge.of_node = dev->of_node;
+ tc->bridge.pre_enable_prev_first = true;
Re: [PATCH v2 1/2] drm/bridge: Fix improper bridge init order with pre_enable_prev_first
On Mon, Nov 13, 2023 at 6:45 PM Jagan Teki wrote: > > On Tue, Aug 1, 2023 at 11:50 AM Dave Stevenson > wrote: > > > > Hi Jagan > > > > My apologies for dropping the ball on this one, and thanks to Frieder > > for the nudge. > > > > On Wed, 12 Apr 2023 at 07:25, Jagan Teki wrote: > > > > > > Hi Dave, > > > > > > Added Maxime, Laurent [which I thought I added before] > > > > > > On Tue, Mar 28, 2023 at 10:38 PM Jagan Teki > > > wrote: > > > > > > > > For a given bridge pipeline if any bridge sets pre_enable_prev_first > > > > flag then the pre_enable for the previous bridge will be called before > > > > pre_enable of this bridge and opposite is done for post_disable. > > > > > > > > These are the potential bridge flags to alter bridge init order in order > > > > to satisfy the MIPI DSI host and downstream panel or bridge to function. > > > > However the existing pre_enable_prev_first logic with associated bridge > > > > ordering has broken for both pre_enable and post_disable calls. > > > > > > > > [pre_enable] > > > > > > > > The altered bridge ordering has failed if two consecutive bridges on a > > > > given pipeline enables the pre_enable_prev_first flag. > > > > > > > > Example: > > > > - Panel > > > > - Bridge 1 > > > > - Bridge 2 pre_enable_prev_first > > > > - Bridge 3 > > > > - Bridge 4 pre_enable_prev_first > > > > - Bridge 5 pre_enable_prev_first > > > > - Bridge 6 > > > > - Encoder > > > > > > > > In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first. > > > > > > > > The logic looks for a bridge which enabled pre_enable_prev_first flag > > > > on each iteration and assigned the previou bridge to limit pointer > > > > if the bridge doesn't enable pre_enable_prev_first flags. > > > > > > > > If control found Bridge 2 is pre_enable_prev_first then the iteration > > > > looks for Bridge 3 and found it is not pre_enable_prev_first and assigns > > > > it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3 > > > > and Bridge 2 and assign iter pointer with limit which is Bridge 4. > > > > > > > > Here is the actual problem, for the next iteration control look for > > > > Bridge 5 instead of Bridge 4 has iter pointer in previous iteration > > > > moved to Bridge 4 so this iteration skips the Bridge 4. The iteration > > > > found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned > > > > to Encoder. From next iteration Encoder skips as it is the last bridge > > > > for reverse order pipeline. > > > > > > > > So, the resulting pre_enable bridge order would be, > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5. > > > > > > > > This patch fixes this by assigning limit to next pointer instead of > > > > previous bridge since the iteration always looks for bridge that does > > > > NOT request prev so assigning next makes sure the last bridge on a > > > > given iteration what exactly the limit bridge is. > > > > > > > > So, the resulting pre_enable bridge order with fix would be, > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, > > > > Encoder. > > > > > > > > [post_disable] > > > > > > > > The altered bridge ordering has failed if two consecutive bridges on a > > > > given pipeline enables the pre_enable_prev_first flag. > > > > > > > > Example: > > > > - Panel > > > > - Bridge 1 > > > > - Bridge 2 pre_enable_prev_first > > > > - Bridge 3 > > > > - Bridge 4 pre_enable_prev_first > > > > - Bridge 5 pre_enable_prev_first > > > > - Bridge 6 > > > > - Encoder > > > > > > > > In this example Bridge 5 and Bridge 4 have pre_enable_prev_first. > > > > > > > > The logic looks for a bridge which enabled pre_enable_prev_first flags > > > > on each iteration and assigned the previou bridge to next and next to > > > > limit pointer if the bridge does enable pre_enable_prev_first flag. > > > > > > > > If control starts from Bridge 6 then it found next Bridge 5 is > > > > pre_enable_prev_first and immediately the next assigned to previous > > > > Bridge 6 and limit assignments to next Bridge 6 and call post_enable > > > > of Bridge 6 even though the next consecutive Bridge 5 is enabled with > > > > pre_enable_prev_first. This clearly misses the logic to find the state > > > > of next conducive bridge as everytime the next and limit assigns > > > > previous bridge if given bridge enabled pre_enable_prev_first. > > > > > > > > So, the resulting post_disable bridge order would be, > > > > - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1, > > > > Panel. > > > > > > > > This patch fixes this by assigning next with previou bridge only if the > > > > bridge doesn't enable pre_enable_prev_first flag and the next further > > > > assign it to limit. This way we can find the bridge that NOT requested > > > > prev to disable last. > > > > > > > > So, the resulting pre_enable bridge order with fix would be, > > > > - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1, > > > > Panel. > > > > > > > >
Re: [GIT PULL] fbdev fixes and updates for v6.7-rc3
On Sat, 25 Nov 2023 at 22:58, Helge Deller wrote: > > please pull some small fbdev fixes for 6.7-rc3. These all seem to be pure cleanups, not bug fixes. Please resend during the merge window. Linus
[PATCH 2/6] drm/bridge: tc358775: Fix getting dsi host data lanes
The current code assume hardcoded dsi host endpoint 1, which may not
be the case. Let's fix that and simplify the code by getting the dsi
endpoint with of_graph_get_remote_endpoint() that does not assume any
endpoint numbering.
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -528,25 +528,17 @@ tc_mode_valid(struct drm_bridge *bridge,
static int tc358775_parse_dt(struct device_node *np, struct tc_data *tc)
{
struct device_node *endpoint;
- struct device_node *parent;
struct device_node *remote;
int dsi_lanes = -1;
- /*
-* To get the data-lanes of dsi, we need to access the dsi0_out of port1
-* of dsi0 endpoint from bridge port0 of d2l_in
-*/
endpoint = of_graph_get_endpoint_by_regs(tc->dev->of_node,
TC358775_DSI_IN, -1);
if (endpoint) {
- /* dsi0_out node */
- parent = of_graph_get_remote_port_parent(endpoint);
+ /* Get the configured data lanes on the dsi host side */
+ remote = of_graph_get_remote_endpoint(endpoint);
of_node_put(endpoint);
- if (parent) {
- /* dsi0 port 1 */
- dsi_lanes = drm_of_get_data_lanes_count_ep(parent, 1,
-1, 1, 4);
- of_node_put(parent);
- }
+ dsi_lanes = drm_of_get_data_lanes_count(remote, 1, 4);
+ of_node_put(remote);
}
if (dsi_lanes < 0)
--
2.42.1
Re: [PATCH] drm/sched: Fix compilation issues with DRM priority rename
On 2023-11-25 14:22, Luben Tuikov wrote:
> Fix compilation issues with DRM scheduler priority rename MIN to LOW.
>
> Signed-off-by: Luben Tuikov
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202311252109.wgbjsskg-...@intel.com/
> Cc: Danilo Krummrich
> Cc: Frank Binns
> Cc: Donald Robson
> Cc: Matt Coster
> Cc: Direct Rendering Infrastructure - Development
>
> Fixes: fe375c74806dbd ("drm/sched: Rename priority MIN to LOW")
Fixes: 38f922a563aac3 ("drm/sched: Reverse run-queue priority enumeration")
> Fixes: 5f03a507b29e44 ("drm/nouveau: implement 1:1 scheduler - entity
> relationship")
> ---
Added an additional Fixes tag as shown above, to complete the set.
--
Regards,
Luben
OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
[PATCH v2 02/11] drm/bridge: Fix a use case in the bridge disable logic
The patch fixes the code for finding the next bridge with the
"pre_enable_prev_first" flag set to false. In case this condition is
not verified, i. e. there is no subsequent bridge with the flag set to
false, the whole bridge list is traversed, invalidating the "next"
variable.
The use of a new iteration variable (i. e. "iter") ensures that the value
of the "next" variable is not invalidated.
Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order")
Co-developed-by: Michael Trimarchi
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/gpu/drm/drm_bridge.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index f66bf4925dd8..2e5781bf192e 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -662,7 +662,7 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge
*bridge,
struct drm_atomic_state *old_state)
{
struct drm_encoder *encoder;
- struct drm_bridge *next, *limit;
+ struct drm_bridge *iter, *next, *limit;
if (!bridge)
return;
@@ -680,14 +680,15 @@ void drm_atomic_bridge_chain_post_disable(struct
drm_bridge *bridge,
* was enabled first, so disabled last
*/
limit = next;
+ iter = next;
/* Find the next bridge that has NOT requested
* prev to be enabled first / disabled last
*/
- list_for_each_entry_from(next,
>bridge_chain,
+ list_for_each_entry_from(iter,
>bridge_chain,
chain_node) {
- if (!next->pre_enable_prev_first) {
- next = list_prev_entry(next,
chain_node);
+ if (!iter->pre_enable_prev_first) {
+ next = list_prev_entry(iter,
chain_node);
limit = next;
break;
}
--
2.42.0
[PATCH v2 06/11] drm/panel: Add Synaptics R63353 panel driver
From: Michael Trimarchi
The LS068B3SX02 panel is based on the Synaptics R63353 Controller.
Add a driver for it.
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
Changes in v2:
- Adjust the timings of the panel reset
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-synaptics-r63353.c| 375 ++
4 files changed, 391 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-synaptics-r63353.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 509281e9e169..ab6985806793 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6875,6 +6875,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.yaml
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR SYNAPTICS R63353 PANELS
+M: Michael Trimarchi
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
+F: drivers/gpu/drm/panel/panel-synaptics-r63353.c
+
DRM DRIVER FOR TI DLPC3433 MIPI DSI TO DMD BRIDGE
M: Jagan Teki
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..d018702be3dc 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -735,6 +735,15 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_SYNAPTICS_R63353
+ tristate "Synaptics R63353-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
+ Synaptics R63353 controller.
+
config DRM_PANEL_SONY_ACX565AKM
tristate "Sony ACX565AKM panel"
depends on GPIOLIB && OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..f267d932c2b5 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS060T1SX01) +=
panel-sharp-ls060t1sx01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_SYNAPTICS_R63353) += panel-synaptics-r63353.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) +=
panel-sony-tulip-truly-nt35521.o
diff --git a/drivers/gpu/drm/panel/panel-synaptics-r63353.c
b/drivers/gpu/drm/panel/panel-synaptics-r63353.c
new file mode 100644
index ..d45373de7c9f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-synaptics-r63353.c
@@ -0,0 +1,375 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Synaptics R63353 Controller driver
+ *
+ * Copyright (C) 2020 BSH Hausgerate GmbH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+#define R63353_INSTR(...) { \
+ .len = sizeof((u8[]) {__VA_ARGS__}), \
+ .data = (u8[]){__VA_ARGS__} \
+ }
+
+struct r63353_instr {
+ size_t len;
+ const u8 *data;
+};
+
+static const struct r63353_instr sharp_ls068b3sx02_init[] = {
+ R63353_INSTR(0x51, 0xff),
+ R63353_INSTR(0x53, 0x0c),
+ R63353_INSTR(0x55, 0x00),
+ R63353_INSTR(0x84, 0x00),
+ R63353_INSTR(0x29),
+};
+
+struct r63353_desc {
+ const char *name;
+ const struct r63353_instr *init;
+ const size_t init_length;
+ const struct drm_display_mode *mode;
+ u32 width_mm;
+ u32 height_mm;
+};
+
+struct r63353_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ struct gpio_desc *reset_gpio;
+ struct regulator *dvdd;
+ struct regulator *avdd;
+
+ bool prepared;
+ struct r63353_desc *pdata;
+};
+
+static inline struct r63353_panel *to_r63353_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct r63353_panel, base);
+}
+
+static int r63353_panel_power_on(struct r63353_panel *rpanel)
+{
+ struct mipi_dsi_device *dsi = rpanel->dsi;
+ struct device *dev = >dev;
+ int ret;
+
+ ret = regulator_enable(rpanel->avdd);
+ if (ret) {
+ dev_err(dev, "Failed to enable avdd regulator (%d)\n", ret);
+ return ret;
+ }
+
+ usleep_range(15000, 25000);
+
+ ret = regulator_enable(rpanel->dvdd);
+ if (ret) {
+ dev_err(dev, "Failed to enable dvdd regulator (%d)\n", ret);
+ regulator_disable(rpanel->avdd);
+ return ret;
+ }
+
[PATCH v2 04/11] drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting
The patch completes the setting of CLKLANE_STOP for the imx8mn and imx8mp
platforms (i. e. not exynos).
Co-developed-by: Michael Trimarchi
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/gpu/drm/bridge/samsung-dsim.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 15bf05b2bbe4..13f181c99d7e 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -96,6 +96,7 @@
#define DSIM_MFLUSH_VS BIT(29)
/* This flag is valid only for exynos3250/3472/5260/5430 */
#define DSIM_CLKLANE_STOP BIT(30)
+#define DSIM_NON_CONTINUOUS_CLKLANEBIT(31)
/* DSIM_ESCMODE */
#define DSIM_TX_TRIGGER_RSTBIT(4)
@@ -945,8 +946,12 @@ static int samsung_dsim_init_link(struct samsung_dsim *dsi)
* power consumption.
*/
if (driver_data->has_clklane_stop &&
- dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
+ dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
+ if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
+ reg |= DSIM_NON_CONTINUOUS_CLKLANE;
+
reg |= DSIM_CLKLANE_STOP;
+ }
samsung_dsim_write(dsi, DSIM_CONFIG_REG, reg);
lanes_mask = BIT(dsi->lanes) - 1;
--
2.42.0
[PATCH v2 08/11] drm/panel: Add Ilitek ILI9805 panel driver
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 v1)
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig| 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 365 +++
4 files changed, 381 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ab6985806793..db2a2e6ee14f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6647,6 +6647,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 ..749959e10d92
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
@@ -0,0 +1,365 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BSH Hausgerate GmbH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+#define ILI9805_EXTCMD_CMD_SET_ENABLE_REG (0xff)
+#define ILI9805_SETEXTC_PARAMETER1 (0xff)
+#define ILI9805_SETEXTC_PARAMETER2 (0x98)
+#define ILI9805_SETEXTC_PARAMETER3 (0x05)
+
+#define ILI9805_INSTR(_delay, ...) { \
+ .delay = (_delay), \
+ .len = sizeof((u8[]) {__VA_ARGS__}), \
+ .data = (u8[]){__VA_ARGS__} \
+ }
+
+struct ili9805_instr {
+ size_t len;
+ const u8 *data;
+ u32 delay;
+};
+
+struct ili9805_desc {
+ const char *name;
+ const struct ili9805_instr *init;
+ const size_t init_length;
+ const struct drm_display_mode *mode;
+ u32 width_mm;
+ u32 height_mm;
+};
+
+struct ili9805 {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+ const struct ili9805_desc *desc;
+
+ struct regulator*dvdd;
+ struct regulator*avdd;
+ struct gpio_desc*reset_gpio;
+
+ boolprepared;
+};
+
+static const struct ili9805_instr gpm1780a0_init[] = {
+ ILI9805_INSTR(100, ILI9805_EXTCMD_CMD_SET_ENABLE_REG,
ILI9805_SETEXTC_PARAMETER1,
+ ILI9805_SETEXTC_PARAMETER2, ILI9805_SETEXTC_PARAMETER3),
+ ILI9805_INSTR(100, 0xFD, 0x0F, 0x10, 0x44, 0x00),
+ ILI9805_INSTR(0, 0xf8, 0x18, 0x02, 0x02, 0x18, 0x02, 0x02, 0x30, 0x00,
+ 0x00, 0x30, 0x00, 0x00, 0x30, 0x00, 0x00),
+ ILI9805_INSTR(0, 0xB8, 0x62),
+ ILI9805_INSTR(0, 0xF1, 0x00),
+ ILI9805_INSTR(0, 0xF2, 0x00, 0x58, 0x40),
+ ILI9805_INSTR(0, 0xF3, 0x60, 0x83, 0x04),
+ ILI9805_INSTR(0, 0xFC, 0x04, 0x0F, 0x01),
+ ILI9805_INSTR(0, 0xEB, 0x08, 0x0F),
+ ILI9805_INSTR(0, 0xe0, 0x00, 0x08, 0x0d, 0x0e, 0x0e, 0x0d, 0x0a, 0x08,
0x04,
+ 0x08, 0x0d,
[PATCH v2 07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
From: Michael Trimarchi
Add documentation for "ilitek,ili9805" panel.
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
.../display/panel/ilitek,ili9805.yaml | 63 +++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
new file mode 100644
index ..e08af5f0b2e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ilitek,ili9805.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9805 based MIPI-DSI panels
+
+maintainers:
+ - Michael Trimarchi
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - giantplus,gpm1790a0
+ - const: ilitek,ili9805
+
+ avdd-supply: true
+ dvdd-supply: true
+ power-supply: true
+ reg: true
+
+required:
+ - compatible
+ - avdd-supply
+ - dvdd-supply
+ - reg
+ - reset-gpios
+ - port
+ - backlight
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "giantplus,gpm1790a0", "ilitek,ili9805";
+reg = <0>;
+power-supply = <_display>;
+avdd-supply = <_display>;
+dvdd-supply = <_display>;
+reset-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+backlight = <>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <_dsi_out>;
+};
+};
+};
+};
+
+...
--
2.42.0
[PATCH v2 01/11] drm/bridge: Fix bridge disable logic
As explained by the comment of the fixed code, we need to find the next
bridge that hasn't set the "pre_enable_prev_first" flag to true. The code,
on the contrary, was doing the opposite.
So, the order of disabling the bridges couldn't be altered as required
by setting the "pre_enable_prev_first" flag to true.
Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order")
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/gpu/drm/drm_bridge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 30d66bee0ec6..f66bf4925dd8 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -686,7 +686,7 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge
*bridge,
*/
list_for_each_entry_from(next,
>bridge_chain,
chain_node) {
- if (next->pre_enable_prev_first) {
+ if (!next->pre_enable_prev_first) {
next = list_prev_entry(next,
chain_node);
limit = next;
break;
--
2.42.0
[PATCH v2 05/11] dt-bindings: display: panel: Add synaptics r63353 panel controller
From: Michael Trimarchi
Add documentation for "synaptics,r63353" panel.
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
.../display/panel/synaptics,r63353.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
b/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
new file mode 100644
index ..590db3719eb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/synaptics,r63353.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics R63353 based MIPI-DSI panels
+
+maintainers:
+ - Michael Trimarchi
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - sharp,ls068b3sx02
+ - const: synaptics,r63353
+
+ avdd-supply: true
+ dvdd-supply: true
+ reg: true
+
+required:
+ - compatible
+ - avdd-supply
+ - dvdd-supply
+ - reg
+ - reset-gpios
+ - port
+ - backlight
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "sharp,ls068b3sx02", "synaptics,r63353";
+reg = <0>;
+avdd-supply = <_display>;
+dvdd-supply = <_display>;
+reset-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+backlight = <>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <_dsi_out>;
+};
+};
+};
+};
+
+...
--
2.42.0
[PATCH v2 00/11] Add displays support for bsh-smm-s2/pro boards
The series adds drivers for the displays used by bsh-smm-s2/pro boards. This required applying some patches to the samsung-dsim driver and the drm_bridge.c module. Changes in v2: - Add $ref to panel-common.yaml - Drop port, reset-gpios, and backlight - Set port and backlight ad required - Replace additionalProperties with unevaluatedProperties - Adjust the timings of the panel reset - Adjust the mipi_dsi node based on the latest patches merged into the mainline in the dtsi files it includes. - Added to the series the following patches: - 0001 drm/bridge: Fix bridge disable logic - 0002 drm/bridge: Fix a use case in the bridge disable logic - 0003 samsung-dsim: enter display mode in the enable() callback - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting Dario Binacchi (4): drm/bridge: Fix bridge disable logic drm/bridge: Fix a use case in the bridge disable logic drm: bridge: samsung-dsim: enter display mode in the enable() callback drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting Michael Trimarchi (7): dt-bindings: display: panel: Add synaptics r63353 panel controller drm/panel: Add Synaptics R63353 panel driver dt-bindings: display: panel: Add Ilitek ili9805 panel controller drm/panel: Add Ilitek ILI9805 panel driver dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01 drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup .../display/panel/ilitek,ili9805.yaml | 64 +++ .../display/panel/synaptics,r63353.yaml | 61 +++ MAINTAINERS | 12 + .../freescale/imx8mn-bsh-smm-s2-common.dtsi | 1 + .../freescale/imx8mn-bsh-smm-s2-display.dtsi | 121 + drivers/gpu/drm/bridge/samsung-dsim.c | 14 +- drivers/gpu/drm/drm_bridge.c | 9 +- drivers/gpu/drm/panel/Kconfig | 18 + drivers/gpu/drm/panel/Makefile| 2 + drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 418 ++ .../gpu/drm/panel/panel-synaptics-r63353.c| 375 11 files changed, 1088 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml create mode 100644 Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c create mode 100644 drivers/gpu/drm/panel/panel-synaptics-r63353.c -- 2.42.0
Re: [PATCH 01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
On 25/11/2023 14:17, Konrad Dybcio wrote:
The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in commit 0c0f65c6dd44
("dt-bindings: msm: dsi-controller-main: Add compatible strings for every
current SoC"), but the example hasn't been updated to reflect that.
Fix that.
Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible strings
for every current SoC")
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
index 5ad155612b6c..3d82c00a9f85 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -56,7 +56,9 @@ patternProperties:
properties:
compatible:
-const: qcom,dsi-ctrl-6g-qcm2290
+items:
+ - const: qcom,qcm2290-dsi-ctrl
+ - const: qcom,mdss-dsi-ctrl
"^phy@[0-9a-f]+$":
type: object
Reviewed-by: Bryan O'Donoghue
Re: [PATCH] drm/atomic-helpers: Invoke end_fb_access while owning plane state
Thomas Zimmermann writes:
> Invoke drm_plane_helper_funcs.end_fb_access before
> drm_atomic_helper_commit_hw_done(). The latter function hands over
> ownership of the plane state to the following commit, which might
> free it. Releasing resources in end_fb_access then operates on undefined
> state. This bug has been observed with non-blocking commits when they
> are being queued up quickly.
>
> Here is an example stack trace from the bug report. The plane state has
> been free'd already, so the pages for drm_gem_fb_vunmap() are gone.
>
> Unable to handle kernel paging request at virtual address 00010049
> [...]
> drm_gem_fb_vunmap+0x18/0x74
> drm_gem_end_shadow_fb_access+0x1c/0x2c
> drm_atomic_helper_cleanup_planes+0x58/0xd8
> drm_atomic_helper_commit_tail+0x90/0xa0
> commit_tail+0x15c/0x188
> commit_work+0x14/0x20
>
> For aborted commits, it is still ok to run end_fb_access as part of the
> plane's cleanup. Add a test to drm_atomic_helper_cleanup_planes().
>
> Reported-by: Alyssa Ross
> Closes: https://lore.kernel.org/dri-devel/87leazm0ya@alyssa.is/
> Suggested-by: Daniel Vetter
> Fixes: 94d879eaf7fb ("drm/atomic-helper: Add {begin,end}_fb_access to plane
> helpers")
> Signed-off-by: Thomas Zimmermann
> Cc: # v6.2+
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 17 +
> 1 file changed, 17 insertions(+)
I've been trying this patch for the last couple of days. Alas the
problem doesn't seem to have been resolved entirely, because I've had
the following Oopses:
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added [PLANE:31:plane-0] 01cc7517 state to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_crtc_state] Added
[CRTC:33:crtc-0] e546877a state to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_set_fb_for_plane] Set
[FB:37] for [PLANE:31:plane-0] state 01cc7517
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_connector_state]
Added [CONNECTOR:35:Unknown-1] 8cee195b state to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_check_only] checking
af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
Updating routing for [CONNECTOR:35:Unknown-1]
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
[CONNECTOR:35:Unknown-1] keeps [ENCODER:34:None-34], now on [CRTC:33:crtc-0]
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_nonblocking_commit]
committing af08a086 nonblocking
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_default_clear]
Clearing atomic state af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:__drm_atomic_state_free] Freeing
atomic state af08a086
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added [PLANE:31:plane-0] d3b51954 state to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_crtc_state] Added
[CRTC:33:crtc-0] e7c9e6b8 state to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_set_fb_for_plane] Set
[FB:38] for [PLANE:31:plane-0] state d3b51954
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_connector_state]
Added [CONNECTOR:35:Unknown-1] 016b7c7e state to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_check_only] checking
f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
Updating routing for [CONNECTOR:35:Unknown-1]
simple-framebuffer dd53a4000.framebuffer: [drm:update_connector_routing]
[CONNECTOR:35:Unknown-1] keeps [ENCODER:34:None-34], now on [CRTC:33:crtc-0]
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_add_encoder_bridges]
Adding all bridges for [encoder:34:None-34] to f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_default_clear]
Clearing atomic state f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:__drm_atomic_state_free] Freeing
atomic state f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_state_init] Allocated
atomic state f87a08e9
simple-framebuffer dd53a4000.framebuffer: [drm:drm_atomic_get_plane_state]
Added
[PATCH v2] drm/i915/irq: Improve error logging for unexpected DE Misc interrupts
Dump the iir value in hex when the interrupt is unexpected. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9652#note_2178501 Cc: Jani Nikula Signed-off-by: Rahul Rameshbabu Reviewed-by: Chaitanya Kumar Borah --- Notes: Changes: v1->v2: - Change format specifier to pad minimum width - https://lore.kernel.org/intel-gfx/20231123175638.27650-1-sergeantsag...@protonmail.com/ drivers/gpu/drm/i915/display/intel_display_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c b/drivers/gpu/drm/i915/display/intel_display_irq.c index bff4a76310c0..7c6f20cd951e 100644 --- a/drivers/gpu/drm/i915/display/intel_display_irq.c +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c @@ -896,7 +896,7 @@ gen8_de_misc_irq_handler(struct drm_i915_private *dev_priv, u32 iir) } if (!found) - drm_err(_priv->drm, "Unexpected DE Misc interrupt\n"); + drm_err(_priv->drm, "Unexpected DE Misc interrupt: 0x%08x\n", iir); } static void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv, -- 2.40.1
[PATCH] driver: gpu: Fix warning directly dereferencing a rcu pointer
Fix a sparse warning with this message
"warning:dereference of noderef expression". In this context it means we
are dereferencing a __rcu tagged pointer directly.
We should not be directly dereferencing a rcu pointer. To get a normal
(non __rcu tagged pointer) from a __rcu tagged pointer we are using the
function unrcu_pointer(...). The non __rcu tagged pointer then can be
dereferenced just like a normal pointer.
I tested with qemu with this command
qemu-system-x86_64 \
-m 2G \
-smp 2 \
-kernel bzImage \
-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
-drive file=bullseye.img,format=raw \
-net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
-net nic,model=e1000 \
-enable-kvm \
-nographic \
-pidfile vm.pid \
2>&1 | tee vm.log
with lockdep enabled.
Signed-off-by: Abhinav Singh
---
drivers/gpu/drm/nouveau/nv10_fence.c | 2 +-
drivers/gpu/drm/nouveau/nv84_fence.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv10_fence.c
b/drivers/gpu/drm/nouveau/nv10_fence.c
index c6a0db5b9e21..845b64c079ed 100644
--- a/drivers/gpu/drm/nouveau/nv10_fence.c
+++ b/drivers/gpu/drm/nouveau/nv10_fence.c
@@ -32,7 +32,7 @@
int
nv10_fence_emit(struct nouveau_fence *fence)
{
- struct nvif_push *push = fence->channel->chan.push;
+ struct nvif_push *push = unrcu_pointer(fence->channel)->chan.push;
int ret = PUSH_WAIT(push, 2);
if (ret == 0) {
PUSH_MTHD(push, NV06E, SET_REFERENCE, fence->base.seqno);
diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c
b/drivers/gpu/drm/nouveau/nv84_fence.c
index 812b8c62eeba..d42e72e23dec 100644
--- a/drivers/gpu/drm/nouveau/nv84_fence.c
+++ b/drivers/gpu/drm/nouveau/nv84_fence.c
@@ -85,7 +85,7 @@ nv84_fence_chid(struct nouveau_channel *chan)
static int
nv84_fence_emit(struct nouveau_fence *fence)
{
- struct nouveau_channel *chan = fence->channel;
+ struct nouveau_channel *chan = unrcu_pointer(fence->channel);
struct nv84_fence_chan *fctx = chan->fence;
u64 addr = fctx->vma->addr + nv84_fence_chid(chan) * 16;
--
2.39.2
Re: [PATCH v2 1/2] drm/bridge: Fix improper bridge init order with pre_enable_prev_first
Hi Jagan On Sun, Nov 26, 2023 at 5:11 PM Jagan Teki wrote: > > On Mon, Nov 13, 2023 at 6:45 PM Jagan Teki wrote: > > > > On Tue, Aug 1, 2023 at 11:50 AM Dave Stevenson > > wrote: > > > > > > Hi Jagan > > > > > > My apologies for dropping the ball on this one, and thanks to Frieder > > > for the nudge. > > > > > > On Wed, 12 Apr 2023 at 07:25, Jagan Teki > > > wrote: > > > > > > > > Hi Dave, > > > > > > > > Added Maxime, Laurent [which I thought I added before] > > > > > > > > On Tue, Mar 28, 2023 at 10:38 PM Jagan Teki > > > > wrote: > > > > > > > > > > For a given bridge pipeline if any bridge sets pre_enable_prev_first > > > > > flag then the pre_enable for the previous bridge will be called before > > > > > pre_enable of this bridge and opposite is done for post_disable. > > > > > > > > > > These are the potential bridge flags to alter bridge init order in > > > > > order > > > > > to satisfy the MIPI DSI host and downstream panel or bridge to > > > > > function. > > > > > However the existing pre_enable_prev_first logic with associated > > > > > bridge > > > > > ordering has broken for both pre_enable and post_disable calls. > > > > > > > > > > [pre_enable] > > > > > > > > > > The altered bridge ordering has failed if two consecutive bridges on a > > > > > given pipeline enables the pre_enable_prev_first flag. > > > > > > > > > > Example: > > > > > - Panel > > > > > - Bridge 1 > > > > > - Bridge 2 pre_enable_prev_first > > > > > - Bridge 3 > > > > > - Bridge 4 pre_enable_prev_first > > > > > - Bridge 5 pre_enable_prev_first > > > > > - Bridge 6 > > > > > - Encoder > > > > > > > > > > In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first. > > > > > > > > > > The logic looks for a bridge which enabled pre_enable_prev_first flag > > > > > on each iteration and assigned the previou bridge to limit pointer > > > > > if the bridge doesn't enable pre_enable_prev_first flags. > > > > > > > > > > If control found Bridge 2 is pre_enable_prev_first then the iteration > > > > > looks for Bridge 3 and found it is not pre_enable_prev_first and > > > > > assigns > > > > > it's previous Bridge 4 to limit pointer and calls pre_enable of > > > > > Bridge 3 > > > > > and Bridge 2 and assign iter pointer with limit which is Bridge 4. > > > > > > > > > > Here is the actual problem, for the next iteration control look for > > > > > Bridge 5 instead of Bridge 4 has iter pointer in previous iteration > > > > > moved to Bridge 4 so this iteration skips the Bridge 4. The iteration > > > > > found Bridge 6 doesn't pre_enable_prev_first flags so the limit > > > > > assigned > > > > > to Encoder. From next iteration Encoder skips as it is the last bridge > > > > > for reverse order pipeline. > > > > > > > > > > So, the resulting pre_enable bridge order would be, > > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5. > > > > > > > > > > This patch fixes this by assigning limit to next pointer instead of > > > > > previous bridge since the iteration always looks for bridge that does > > > > > NOT request prev so assigning next makes sure the last bridge on a > > > > > given iteration what exactly the limit bridge is. > > > > > > > > > > So, the resulting pre_enable bridge order with fix would be, > > > > > - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, > > > > > Encoder. > > > > > > > > > > [post_disable] > > > > > > > > > > The altered bridge ordering has failed if two consecutive bridges on a > > > > > given pipeline enables the pre_enable_prev_first flag. > > > > > > > > > > Example: > > > > > - Panel > > > > > - Bridge 1 > > > > > - Bridge 2 pre_enable_prev_first > > > > > - Bridge 3 > > > > > - Bridge 4 pre_enable_prev_first > > > > > - Bridge 5 pre_enable_prev_first > > > > > - Bridge 6 > > > > > - Encoder > > > > > > > > > > In this example Bridge 5 and Bridge 4 have pre_enable_prev_first. > > > > > > > > > > The logic looks for a bridge which enabled pre_enable_prev_first flags > > > > > on each iteration and assigned the previou bridge to next and next to > > > > > limit pointer if the bridge does enable pre_enable_prev_first flag. > > > > > > > > > > If control starts from Bridge 6 then it found next Bridge 5 is > > > > > pre_enable_prev_first and immediately the next assigned to previous > > > > > Bridge 6 and limit assignments to next Bridge 6 and call post_enable > > > > > of Bridge 6 even though the next consecutive Bridge 5 is enabled with > > > > > pre_enable_prev_first. This clearly misses the logic to find the state > > > > > of next conducive bridge as everytime the next and limit assigns > > > > > previous bridge if given bridge enabled pre_enable_prev_first. > > > > > > > > > > So, the resulting post_disable bridge order would be, > > > > > - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1, > > > > > Panel. > > > > > > > > > > This patch fixes this by assigning next with previou bridge only if > > > > > the > > > > > bridge
Re: [GIT PULL] fbdev fixes and updates for v6.7-rc3
On 11/26/23 17:29, Linus Torvalds wrote: On Sat, 25 Nov 2023 at 22:58, Helge Deller wrote: please pull some small fbdev fixes for 6.7-rc3. These all seem to be pure cleanups, not bug fixes. Well, at least: - fbdev: imxfb: fix left margin setting is a bug fix, and: - fbdev: fsl-diu-fb: Fix sparse warning due to virt_to_phys() prototype change pops up in in multiple sparse reports. Please resend during the merge window. I'll do. Thanks! Helge
[PATCH 6/6] drm/bridge: tc358775: Configure hs_rate and lp_rate
The hs_rate and lp_rate may be used by the dsi host for timing
calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
tc358765 has maximurate of 800 Mbps per lane.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -653,6 +653,11 @@ static int tc_attach_host(struct tc_data *tc)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_MODE_LPM;
+ if (tc->type == TC358765)
+ dsi->hs_rate = 8;
+ else
+ dsi->hs_rate = 10;
+ dsi->lp_rate = 1000;
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
--
2.42.1
Re: [PATCH v9 04/12] dt-bindings: phy: amlogic,g12a-mipi-dphy-analog: drop unneeded reg property and example
On Fri, 24 Nov 2023 09:41:15 +0100, Neil Armstrong wrote:
> The amlogic,g12a-mipi-dphy-analog is a feature of the simple-mfd
> amlogic,meson-axg-hhi-sysctrl system control register zone which is an
> intermixed registers zone, thus it's very hard to define clear ranges for
> each SoC controlled features even if possible.
>
> The amlogic,g12a-mipi-dphy-analog was wrongly documented as an independent
> register range, which is not the reality, thus fix the bindings by dropping
> the reg property now it's referred from amlogic,meson-gx-hhi-sysctrl.yaml
> and documented as a subnode of amlogic,meson-axg-hhi-sysctrl.
>
> Also drop the unnecessary example, the top level bindings example should
> be enough.
>
> Fixes: 76ab79f9726c ("dt-bindings: phy: add Amlogic G12A Analog MIPI D-PHY
> bindings")
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml | 12
>
> 1 file changed, 12 deletions(-)
>
Reviewed-by: Rob Herring
[PATCH v2 10/11] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
From: Michael Trimarchi
Tianma TM041XDHG01 utilizes the Ilitek ILI9805 controller.
Add this panel's initialzation sequence and timing to ILI9805 driver.
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 53
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
index 749959e10d92..cd187b0b1998 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
@@ -89,6 +89,36 @@ static const struct ili9805_instr gpm1780a0_init[] = {
ILI9805_INSTR(0, 0xB9, 0x02, 0x00),
};
+static const struct ili9805_instr tm041xdhg01_init[] = {
+ ILI9805_INSTR(100, ILI9805_EXTCMD_CMD_SET_ENABLE_REG,
ILI9805_SETEXTC_PARAMETER1,
+ ILI9805_SETEXTC_PARAMETER2, ILI9805_SETEXTC_PARAMETER3),
+ ILI9805_INSTR(100, 0xFD, 0x0F, 0x13, 0x44, 0x00),
+ ILI9805_INSTR(0, 0xf8, 0x18, 0x02, 0x02, 0x18, 0x02, 0x02, 0x30, 0x01,
+ 0x01, 0x30, 0x01, 0x01, 0x30, 0x01, 0x01),
+ ILI9805_INSTR(0, 0xB8, 0x74),
+ ILI9805_INSTR(0, 0xF1, 0x00),
+ ILI9805_INSTR(0, 0xF2, 0x00, 0x58, 0x40),
+ ILI9805_INSTR(0, 0xFC, 0x04, 0x0F, 0x01),
+ ILI9805_INSTR(0, 0xEB, 0x08, 0x0F),
+ ILI9805_INSTR(0, 0xe0, 0x01, 0x0d, 0x15, 0x0e, 0x0f, 0x0f, 0x0b, 0x08,
0x04,
+ 0x07, 0x0a, 0x0d, 0x0c, 0x15, 0x0f, 0x08),
+ ILI9805_INSTR(0, 0xe1, 0x01, 0x0d, 0x15, 0x0e, 0x0f, 0x0f, 0x0b, 0x08,
0x04,
+ 0x07, 0x0a, 0x0d, 0x0c, 0x15, 0x0f, 0x08),
+ ILI9805_INSTR(10, 0xc1, 0x15, 0x03, 0x03, 0x31),
+ ILI9805_INSTR(10, 0xB1, 0x00, 0x12, 0x14),
+ ILI9805_INSTR(10, 0xB4, 0x02),
+ ILI9805_INSTR(0, 0xBB, 0x14, 0x55),
+ ILI9805_INSTR(0, MIPI_DCS_SET_ADDRESS_MODE, 0x0a),
+ ILI9805_INSTR(0, MIPI_DCS_SET_PIXEL_FORMAT, 0x77),
+ ILI9805_INSTR(0, 0x20),
+ ILI9805_INSTR(0, 0xB0, 0x00),
+ ILI9805_INSTR(0, 0xB6, 0x01),
+ ILI9805_INSTR(0, 0xc2, 0x11),
+ ILI9805_INSTR(0, 0x51, 0xFF),
+ ILI9805_INSTR(0, 0x53, 0x24),
+ ILI9805_INSTR(0, 0x55, 0x00),
+};
+
static inline struct ili9805 *panel_to_ili9805(struct drm_panel *panel)
{
return container_of(panel, struct ili9805, panel);
@@ -239,6 +269,20 @@ static const struct drm_display_mode gpm1780a0_timing = {
.vtotal = 480 + 2 + 4 + 10,
};
+static const struct drm_display_mode tm041xdhg01_timing = {
+ .clock = 26227,
+
+ .hdisplay = 480,
+ .hsync_start = 480 + 10,
+ .hsync_end = 480 + 10 + 2,
+ .htotal = 480 + 10 + 2 + 36,
+
+ .vdisplay = 768,
+ .vsync_start = 768 + 2,
+ .vsync_end = 768 + 10 + 4,
+ .vtotal = 768 + 2 + 4 + 10,
+};
+
static int ili9805_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -343,8 +387,17 @@ static const struct ili9805_desc gpm1780a0_desc = {
.height_mm = 65,
};
+static const struct ili9805_desc tm041xdhg01_desc = {
+ .init = tm041xdhg01_init,
+ .init_length = ARRAY_SIZE(tm041xdhg01_init),
+ .mode = _timing,
+ .width_mm = 42,
+ .height_mm = 96,
+};
+
static const struct of_device_id ili9805_of_match[] = {
{ .compatible = "giantplus,gpm1790a0", .data = _desc },
+ { .compatible = "tianma,tm041xdhg01", .data = _desc },
{ }
};
MODULE_DEVICE_TABLE(of, ili9805_of_match);
--
2.42.0
[PATCH v2 03/11] drm: bridge: samsung-dsim: enter display mode in the enable() callback
The synaptics-r63353 (panel-bridge) can only be configured in command mode.
So, samsung-dsim (bridge) must not be in display mode during the
prepare()/unprepare() of the panel-bridge. Setting the
"pre_enable_prev_first" flag to true allows the prepare() of the
panel-bridge to be called between the pre_enabled() and enabled() of the
bridge. So, the bridge can enter display mode only in the enabled().
The unprepare() of the panel-bridge is instead called between the disable()
and post_disable() of the bridge. So, the disable() must exit the display
mode (i .e. enter command mode) to allow the panel-bridge to receive DSI
commands.
samsung_dsim_atomic_pre_enable -> command mode
r63353_panel_prepare -> send DSI commands
samsung_dsim_atomic_enable -> enter display mode
samsung_dsim_atomic_disable -> exit display mode (command mode)
r63353_panel_unprepare -> send DSI commands
samsung_dsim_atomic_post_disable
Co-developed-by: Michael Trimarchi
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/gpu/drm/bridge/samsung-dsim.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index be5914caa17d..15bf05b2bbe4 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1494,7 +1494,6 @@ static void samsung_dsim_atomic_pre_enable(struct
drm_bridge *bridge,
return;
samsung_dsim_set_display_mode(dsi);
- samsung_dsim_set_display_enable(dsi, true);
}
}
@@ -1507,6 +1506,7 @@ static void samsung_dsim_atomic_enable(struct drm_bridge
*bridge,
samsung_dsim_set_display_mode(dsi);
samsung_dsim_set_display_enable(dsi, true);
} else {
+ samsung_dsim_set_display_enable(dsi, true);
samsung_dsim_set_stop_state(dsi, false);
}
@@ -1524,6 +1524,8 @@ static void samsung_dsim_atomic_disable(struct drm_bridge
*bridge,
if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
samsung_dsim_set_stop_state(dsi, true);
+ samsung_dsim_set_display_enable(dsi, false);
+
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
}
@@ -1532,7 +1534,8 @@ static void samsung_dsim_atomic_post_disable(struct
drm_bridge *bridge,
{
struct samsung_dsim *dsi = bridge_to_dsi(bridge);
- samsung_dsim_set_display_enable(dsi, false);
+ if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
+ samsung_dsim_set_stop_state(dsi, true);
dsi->state &= ~DSIM_STATE_ENABLED;
pm_runtime_put_sync(dsi->dev);
--
2.42.0
[PATCH v2 09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
From: Michael Trimarchi Add Tianma TM041XDHG01 that utilizes an Ilitek ILI9805 controller chip, so its compatible string should be added to ilitek,ili9805 file. Add the compatible string for it. Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi --- (no changes since v1) .../devicetree/bindings/display/panel/ilitek,ili9805.yaml| 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml index e08af5f0b2e9..1b5bf42df7d6 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - giantplus,gpm1790a0 + - tianma,tm041xdhg01 - const: ilitek,ili9805 avdd-supply: true -- 2.42.0
[PATCH 1/6] dt-bindings: tc358775: Add support for tc358765
The tc358765 is similar to tc358775 except for the stdby-gpios. Signed-off-by: Tony Lindgren --- .../display/bridge/toshiba,tc358775.yaml| 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml @@ -10,7 +10,7 @@ maintainers: - Vinay Simha BN description: | - This binding supports DSI to LVDS bridge TC358775 + This binding supports DSI to LVDS bridges TC358765 and TC358775 MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane. Video frame size: @@ -21,7 +21,9 @@ description: | properties: compatible: -const: toshiba,tc358775 +enum: + - toshiba,tc358765 + - toshiba,tc358775 reg: maxItems: 1 @@ -70,12 +72,21 @@ required: - reg - vdd-supply - vddio-supply - - stby-gpios - reset-gpios - ports additionalProperties: false +allOf: + - if: + properties: +compatible: + contains: +const: toshiba,tc358775 +then: + required: +- stby-gpios + examples: - | #include -- 2.42.1
[PATCH 4/6] drm/bridge: tc358775: Add burst and low-power modes
Burst and low-power modes are supported both for tc358765 and tc358775.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -632,7 +632,8 @@ static int tc_attach_host(struct tc_data *tc)
dsi->lanes = tc->num_dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM;
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
--
2.42.1
linux-next: build failure after merge of the drm-misc-fixes tree
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: modpost: "device_is_dependent" [drivers/gpu/drm/drm_kms_helper.ko]
undefined!
Caused by commit
39d5b6a64ace ("drm/bridge: panel: Check device dependency before managing
device link")
I have used the drm-misc-fixes tree from next-20231124 for today.
--
Cheers,
Stephen Rothwell
pgpec8qQ6QowG.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 09/11] dt-bindings: ili9805: add compatible string for Tianma TM041XDHG01
On 26/11/2023 16:45, Dario Binacchi wrote: > From: Michael Trimarchi > > Add Tianma TM041XDHG01 that utilizes an Ilitek ILI9805 controller chip, > so its compatible string should be added to ilitek,ili9805 file. > > Add the compatible string for it. > > Signed-off-by: Michael Trimarchi > Signed-off-by: Dario Binacchi > --- > > (no changes since v1) > > .../devicetree/bindings/display/panel/ilitek,ili9805.yaml| 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > index e08af5f0b2e9..1b5bf42df7d6 100644 > --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > @@ -17,6 +17,7 @@ properties: > items: >- enum: >- giantplus,gpm1790a0 > + - tianma,tm041xdhg01 This should be squashed with previous patch. Best regards, Krzysztof
Re: [PATCH v2 07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller
On 26/11/2023 16:44, Dario Binacchi wrote: > From: Michael Trimarchi > > Add documentation for "ilitek,ili9805" panel. > > Signed-off-by: Michael Trimarchi > Signed-off-by: Dario Binacchi > > --- > > Changes in v2: > - Add $ref to panel-common.yaml > - Drop port, reset-gpios, and backlight > - Set port and backlight ad required > - Replace additionalProperties with unevaluatedProperties > > .../display/panel/ilitek,ili9805.yaml | 63 +++ > 1 file changed, 63 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > > diff --git > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > new file mode 100644 > index ..e08af5f0b2e9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml > @@ -0,0 +1,63 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/panel/ilitek,ili9805.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Ilitek ILI9805 based MIPI-DSI panels > + > +maintainers: > + - Michael Trimarchi > + > +allOf: > + - $ref: panel-common.yaml# > + > +properties: > + compatible: > +items: > + - enum: > + - giantplus,gpm1790a0 > + - const: ilitek,ili9805 > + > + avdd-supply: true > + dvdd-supply: true > + power-supply: true I think power-supply is used as a generic name for cases when specific supplies are not defined. If you define some specific supplies, then don't use generic. Best regards, Krzysztof
Re: [PATCH v2 05/11] dt-bindings: display: panel: Add synaptics r63353 panel controller
On 26/11/2023 16:44, Dario Binacchi wrote: > From: Michael Trimarchi > > Add documentation for "synaptics,r63353" panel. > > Signed-off-by: Michael Trimarchi > Signed-off-by: Dario Binacchi Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 1/6] dt-bindings: tc358775: Add support for tc358765
On 26/11/2023 17:32, Tony Lindgren wrote: > The tc358765 is similar to tc358775 except for the stdby-gpios. > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 04/17] drm/v3d: Simplify job refcount handling
El jue, 23-11-2023 a las 21:47 -0300, Maíra Canal escribió:
> From: Melissa Wen
>
> Instead of checking if the job is NULL every time we call the
> function,
> check it inside the function.
>
> Signed-off-by: Melissa Wen
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/v3d/v3d_submit.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
> b/drivers/gpu/drm/v3d/v3d_submit.c
> index f36214002f37..e18e7c963884 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@ -129,6 +129,9 @@ void v3d_job_cleanup(struct v3d_job *job)
>
> void v3d_job_put(struct v3d_job *job)
> {
> + if (!job)
> + return;
> +
> kref_put(>refcount, job->free);
> }
>
> @@ -517,11 +520,9 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void
> *data,
> ,
> last_job-
> >done_fence);
>
> - if (bin)
> - v3d_job_put(>base);
> - v3d_job_put(>base);
> - if (clean_job)
> - v3d_job_put(clean_job);
> + v3d_job_put((void *)bin);
> + v3d_job_put((void *)render);
> + v3d_job_put((void *)clean_job);
Personally, I am not a big fan of casting to void* instead of using
>base for all the v3d_job_put calls in this patch.
Iago
>
> return 0;
>
> @@ -621,7 +622,7 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void
> *data,
> ,
> job-
> >base.done_fence);
>
> - v3d_job_put(>base);
> + v3d_job_put((void *)job);
>
> return 0;
>
> @@ -725,7 +726,7 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void
> *data,
> ,
> clean_job-
> >done_fence);
>
> - v3d_job_put(>base);
> + v3d_job_put((void *)job);
> v3d_job_put(clean_job);
>
> return 0;
RE: linux-next: build failure after merge of the drm-misc-fixes tree
On Monday, November 27, 2023 5:32 AM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: modpost: "device_is_dependent"
> [drivers/gpu/drm/drm_kms_helper.ko] undefined!
I've sent a new patch series to address the build failure.
It includes a new patch to export device_is_dependent and then
adds the offending commit.
https://lore.kernel.org/all/20231127051414.3783108-1-victor@nxp.com/T/#t
Regards,
Liu Ying
>
> Caused by commit
>
> 39d5b6a64ace ("drm/bridge: panel: Check device dependency before
> managing device link")
>
> I have used the drm-misc-fixes tree from next-20231124 for today.
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH 01/12] dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
On 25/11/2023 15:17, Konrad Dybcio wrote:
> The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in commit 0c0f65c6dd44
> ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every
> current SoC"), but the example hasn't been updated to reflect that.
>
> Fix that.
>
> Fixes: 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add compatible
> strings for every current SoC")
> Signed-off-by: Konrad Dybcio
> ---
> Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> index 5ad155612b6c..3d82c00a9f85 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> @@ -56,7 +56,9 @@ patternProperties:
>
> properties:
>compatible:
> -const: qcom,dsi-ctrl-6g-qcm2290
> +items:
> + - const: qcom,qcm2290-dsi-ctrl
> + - const: qcom,mdss-dsi-ctrl
You must also update the example here.
Best regards,
Krzysztof
Re: [PATCH 02/12] dt-bindings: display: msm: Add reg bus and rotator interconnects
On 25/11/2023 15:17, Konrad Dybcio wrote: > Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are > other connection paths: > - a path that connects rotator block to the DDR. > - a path that needs to be handled to ensure MDSS register access > functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG > interconnect. > > Describe these paths bindings to allow using them in device trees and in > the driver > > Signed-off-by: Dmitry Baryshkov > [Konrad: rework for one vs two MDP paths] > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH 2/2] drm/panel: simple: Add BOE BP101WX1-100 panel
This panel is found on Motorola mapphone tablets from mz615 to mz617.
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1324,6 +1324,35 @@ static const struct panel_desc bananapi_s070wv20_ct16 = {
},
};
+static const struct drm_display_mode boe_bp101wx1_100_mode = {
+ .clock = 78945,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 0,
+ .hsync_end = 1280 + 0 + 2,
+ .htotal = 1280 + 62 + 0 + 2,
+ .vdisplay = 800,
+ .vsync_start = 800 + 8,
+ .vsync_end = 800 + 8 + 2,
+ .vtotal = 800 + 6 + 8 + 2,
+};
+
+static const struct panel_desc boe_bp101wx1_100 = {
+ .modes = _bp101wx1_100_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .enable = 50,
+ .disable = 50,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing boe_ev121wxm_n10_1850_timing = {
.pixelclock = { 69922000, 7100, 72293000 },
.hactive = { 1280, 1280, 1280 },
@@ -4252,6 +4281,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "bananapi,s070wv20-ct16",
.data = _s070wv20_ct16,
+ }, {
+ .compatible = "boe,bp101wx1-100",
+ .data = _bp101wx1_100,
}, {
.compatible = "boe,ev121wxm-n10-1850",
.data = _ev121wxm_n10_1850,
--
2.42.1
[PATCH 1/2] dt-bindings: display: simple: Add boe,bp101wx1-100 panel
This panel is found on Motorola mapphone tablets mz615 to mz617. Signed-off-by: Tony Lindgren --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -73,6 +73,8 @@ properties: - auo,t215hvn01 # Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel - avic,tm070ddh03 +# BOE BP101WX1-100 10.1" WXGA (1280x800) LVDS panel + - boe,bp101wx1-100 # BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel - boe,ev121wxm-n10-1850 # BOE HV070WSA-100 7.01" WSVGA TFT LCD panel -- 2.42.1
Re: [PATCH 03/12] dt-bindings: display: msm: qcm2290-mdss: Allow 2 interconnects
On 25/11/2023 15:17, Konrad Dybcio wrote: > In addition to MDP0, the cpu-cfg interconnect is also necessary. > Allow it. > > Signed-off-by: Konrad Dybcio > --- > Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > index 3d82c00a9f85..51f3e9c34dfb 100644 > --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml > @@ -36,10 +36,10 @@ properties: > maxItems: 2 > >interconnects: > -maxItems: 1 > +maxItems: 2 > >interconnect-names: > -maxItems: 1 > +maxItems: 2 You should describe the items in interconnects and interconnect-names in such case. The same for all other variants having two items here. Then this and other such patches should be squashed with previous. Best regards, Krzysztof
[PATCH v2 2/2] drm/bridge: panel: Check device dependency before managing device link
Some panel devices already depend on DRM device, like the panel in
arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts, because DRM device is
the ancestor of those panel devices. device_link_add() would fail by
returning a NULL pointer for those panel devices because of the existing
dependency. So, check the dependency by calling device_is_dependent()
before adding or deleting device link between panel device and DRM device
so that the link is managed only for independent panel devices.
Fixes: 887878014534 ("drm/bridge: panel: Fix device link for
DRM_BRIDGE_ATTACH_NO_CONNECTOR")
Fixes: 199cf07ebd2b ("drm/bridge: panel: Add a device link between drm device
and panel device")
Reported-by: Linus Walleij
Closes:
https://lore.kernel.org/lkml/cacrpkdagzxd6hbix7mvunjajtmepg00pp6+nj1p0jrfj-ar...@mail.gmail.com/T/
Tested-by: Linus Walleij
Signed-off-by: Liu Ying
---
v2:
* No change.
drivers/gpu/drm/bridge/panel.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index e48823a4f1ed..5e8980023407 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -23,6 +23,7 @@ struct panel_bridge {
struct drm_panel *panel;
struct device_link *link;
u32 connector_type;
+ bool is_independent;
};
static inline struct panel_bridge *
@@ -67,12 +68,17 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
struct drm_device *drm_dev = bridge->dev;
int ret;
- panel_bridge->link = device_link_add(drm_dev->dev, panel->dev,
-DL_FLAG_STATELESS);
- if (!panel_bridge->link) {
- DRM_ERROR("Failed to add device link between %s and %s\n",
- dev_name(drm_dev->dev), dev_name(panel->dev));
- return -EINVAL;
+ panel_bridge->is_independent = !device_is_dependent(drm_dev->dev,
+ panel->dev);
+
+ if (panel_bridge->is_independent) {
+ panel_bridge->link = device_link_add(drm_dev->dev, panel->dev,
+DL_FLAG_STATELESS);
+ if (!panel_bridge->link) {
+ DRM_ERROR("Failed to add device link between %s and
%s\n",
+ dev_name(drm_dev->dev), dev_name(panel->dev));
+ return -EINVAL;
+ }
}
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
@@ -80,7 +86,8 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
if (!bridge->encoder) {
DRM_ERROR("Missing encoder\n");
- device_link_del(panel_bridge->link);
+ if (panel_bridge->is_independent)
+ device_link_del(panel_bridge->link);
return -ENODEV;
}
@@ -92,7 +99,8 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
panel_bridge->connector_type);
if (ret) {
DRM_ERROR("Failed to initialize connector\n");
- device_link_del(panel_bridge->link);
+ if (panel_bridge->is_independent)
+ device_link_del(panel_bridge->link);
return ret;
}
@@ -115,7 +123,8 @@ static void panel_bridge_detach(struct drm_bridge *bridge)
struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
struct drm_connector *connector = _bridge->connector;
- device_link_del(panel_bridge->link);
+ if (panel_bridge->is_independent)
+ device_link_del(panel_bridge->link);
/*
* Cleanup the connector if we know it was initialized.
--
2.37.1
[PATCH v2 0/2] drm/bridge: panel: Check device dependency before managing device link
Hi, This series aims to check panel device dependency upon DRM device before managing device link between them. It fixes eariler patches in v6.7-rc1 which tried to manage the link. Without this series, the link fails to be added for dependent panel devices and hence relevant panel bridges fail to be attached. A real broken panel is "novatek,nt35510" defined in arch/arm/boot/dts/st/ste-ux500-samsung-skomer.dts as reported by Linus Walleij. Patch 1 exports device_is_dependent() to modules as needed by patch 2. Patch 2 checks device dependency before managing the device link. Note that patch 2 is already in drm-misc/drm-misc-fixes and drm-misc/for-linux-next-fixes. Patch 1 needs to be reviewed and picked up. v2: * Introduce patch 1 to export device_is_dependent() to modules as needed by patch 2. Liu Ying (2): driver core: Export device_is_dependent() to modules drm/bridge: panel: Check device dependency before managing device link drivers/base/core.c| 1 + drivers/gpu/drm/bridge/panel.c | 27 ++- 2 files changed, 19 insertions(+), 9 deletions(-) -- 2.37.1
[PATCH v2 1/2] driver core: Export device_is_dependent() to modules
Export device_is_dependent() since the drm_kms_helper module is starting to use it. Signed-off-by: Liu Ying --- v2: * Newly introduced as needed by patch 2. drivers/base/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 67ba592afc77..bfd2bf0364b7 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -328,6 +328,7 @@ int device_is_dependent(struct device *dev, void *target) } return ret; } +EXPORT_SYMBOL_GPL(device_is_dependent); static void device_link_init_status(struct device_link *link, struct device *consumer, -- 2.37.1
Re: [PATCH 05/12] dt-bindings: interconnect: qcom, msm8998-bwmon: Add QCM2290 bwmon instance
On 25/11/2023 15:17, Konrad Dybcio wrote: > QCM2290 has a single BWMONv4 intance for CPU. Document it. > > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 06/12] dt-bindings: firmware: qcom, scm: Allow interconnect for everyone
On 25/11/2023 15:17, Konrad Dybcio wrote: > Every Qualcomm SoC physically has a "CRYPTO0<->DDR" interconnect lane. > Allow this property to be present, no matter the SoC. > > Signed-off-by: Konrad Dybcio > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_sched.c:21:41: error: 'DRM_SCHED_PRIORITY_MIN'
undeclared here (not in a function); did you mean 'DRM_SCHED_PRIORITY_LOW'?
21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN,
| ^~
| DRM_SCHED_PRIORITY_LOW
Caused by commit
fe375c74806d ("drm/sched: Rename priority MIN to LOW")
I have used the drm-misc tree from next-20231124 for today.
--
Cheers,
Stephen Rothwell
pgpydoKVvljrk.pgp
Description: OpenPGP digital signature
[PATCH -next] drm/imagination: Remove unneeded semicolon
./drivers/gpu/drm/imagination/pvr_free_list.c:258:2-3: Unneeded semicolon Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7635 Signed-off-by: Yang Li --- drivers/gpu/drm/imagination/pvr_free_list.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imagination/pvr_free_list.c b/drivers/gpu/drm/imagination/pvr_free_list.c index c61fd417edcb..5e51bc980751 100644 --- a/drivers/gpu/drm/imagination/pvr_free_list.c +++ b/drivers/gpu/drm/imagination/pvr_free_list.c @@ -255,7 +255,7 @@ pvr_free_list_insert_pages_locked(struct pvr_free_list *free_list, if (!num_pages) break; - }; + } /* clang-format on */ /* Make sure our free_list update is flushed. */ -- 2.20.1.7.g153144c
Re: linux-next: build failure after merge of the drm-misc tree
On 2023-11-26 18:38, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/nouveau/nouveau_sched.c:21:41: error:
> 'DRM_SCHED_PRIORITY_MIN' undeclared here (not in a function); did you mean
> 'DRM_SCHED_PRIORITY_LOW'?
>21 | NOUVEAU_SCHED_PRIORITY_SINGLE = DRM_SCHED_PRIORITY_MIN,
> | ^~
> | DRM_SCHED_PRIORITY_LOW
>
> Caused by commit
>
> fe375c74806d ("drm/sched: Rename priority MIN to LOW")
>
> I have used the drm-misc tree from next-20231124 for today.
I posted a fix for this yesterday:
https://lore.kernel.org/r/20231125192246.87268-2-ltuiko...@gmail.com
--
Regards,
Luben
OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
