Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> Channel 1 has polarity bits for vsync and hsync signals but driver never
> sets them. It turns out that with pre-HDMI2 controllers seemingly there
> is no issue if polarity is not set. However, with HDMI2 controllers
> (H6) there often comes to de-synchronization due to phase shift. This
> causes flickering screen. It's safe to assume that similar issues might
> happen also with pre-HDMI2 controllers.
>
> Solve issue with setting vsync and hsync polarity. Note that display
> stacks with tcon top have polarity bits actually in tcon0 polarity
> register.
>
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 6b9af4c08cd6..0d132dae58c0 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> SUN4I_TCON1_BASIC5_H_SYNC(hsync));
>
> + /* Setup the polarity of sync signals */
> + if (tcon->quirks->polarity_in_ch0) {
> + val = 0;
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> + } else {
> + val = SUN4I_TCON1_IO_POL_UNKNOWN;
I think a comment for the origin of this is warranted.
Otherwise,
Reviewed-by: Chen-Yu Tsai
> +
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + val |= SUN4I_TCON1_IO_POL_HSYNC_POSITIVE;
> +
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + val |= SUN4I_TCON1_IO_POL_VSYNC_POSITIVE;
> +
> + regmap_write(tcon->regs, SUN4I_TCON1_IO_POL_REG, val);
> + }
> +
> /* Map output pins to channel 1 */
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>SUN4I_TCON_GCTL_IOMAP_MASK,
> @@ -1500,6 +1523,7 @@ static const struct sun4i_tcon_quirks
> sun8i_a83t_tv_quirks = {
>
> static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
> .has_channel_1 = true,
> + .polarity_in_ch0= true,
> .set_mux= sun8i_r40_tcon_tv_set_mux,
> };
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index c5ac1b02482c..b504fb2d3de5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -154,6 +154,10 @@
> #define SUN4I_TCON1_BASIC5_V_SYNC(height) (((height) - 1) &
> 0x3ff)
>
> #define SUN4I_TCON1_IO_POL_REG 0xf0
> +#define SUN4I_TCON1_IO_POL_UNKNOWN BIT(26)
> +#define SUN4I_TCON1_IO_POL_HSYNC_POSITIVE BIT(25)
> +#define SUN4I_TCON1_IO_POL_VSYNC_POSITIVE BIT(24)
> +
> #define SUN4I_TCON1_IO_TRI_REG 0xf4
>
> #define SUN4I_TCON_ECC_FIFO_REG0xf8
> @@ -236,6 +240,7 @@ struct sun4i_tcon_quirks {
> boolneeds_de_be_mux; /* sun6i needs mux to select backend */
> boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
> boolsupports_lvds; /* Does the TCON support an LVDS output? */
> + boolpolarity_in_ch0; /* some tcon1 channels have polarity bits in
> tcon0 pol register */
> u8 dclk_min_div; /* minimum divider for TCON0 DCLK */
>
> /* callback to handle tcon muxing options */
> --
> 2.30.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> one. Fix that.
>
> Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> allowed")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/sun4i: dw-hdmi: always set clock rate
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> As expected, HDMI controller clock should always match pixel clock. In
> the past, changing HDMI controller rate would seemingly worsen
> situation. However, that was the result of other bugs which are now
> fixed.
>
> Fix that by removing set_rate quirk and always set clock rate.
>
> Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 4/5] drm/sun4i: Fix H6 HDMI PHY configuration
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> cpce value for 594 MHz is set differently in BSP driver. Fix that.
>
> Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 5/5] drm/sun4i: dw-hdmi: Fix max. frequency for H6
On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> It turns out that reasoning for lowering max. supported frequency is
> wrong. Scrambling works just fine. Several now fixed bugs prevented
> proper functioning, even with rates lower than 340 MHz. Issues were just
> more pronounced with higher frequencies.
>
> Fix that by allowing max. supported frequency in HW and fix the comment.
>
> Fixes: cd9063757a22 ("drm/sun4i: DW HDMI: Lower max. supported rate for H6")
> Tested-by: Andre Heider
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
On Sat, Feb 6, 2021 at 12:21 AM Jernej Škrabec wrote:
>
> Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> > On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
> wrote:
> > > >
> > > > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > > > sets them. It turns out that with pre-HDMI2 controllers seemingly there
> > > > is no issue if polarity is not set. However, with HDMI2 controllers
> > > > (H6) there often comes to de-synchronization due to phase shift. This
> > > > causes flickering screen. It's safe to assume that similar issues might
> > > > happen also with pre-HDMI2 controllers.
> > > >
> > > > Solve issue with setting vsync and hsync polarity. Note that display
> > > > stacks with tcon top have polarity bits actually in tcon0 polarity
> > > > register.
> > > >
> > > > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> > > > Tested-by: Andre Heider
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > > > 2 files changed, 29 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/
> sun4i_tcon.c
> > > > index 6b9af4c08cd6..0d132dae58c0 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon
> *tcon,
> > > > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > > > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> > > >
> > > > + /* Setup the polarity of sync signals */
> > > > + if (tcon->quirks->polarity_in_ch0) {
> > > > + val = 0;
> > > > +
> > > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > > > +
> > > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > > > +
> > > > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> > > > + } else {
> > > > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
> > >
> > > I think a comment for the origin of this is warranted.
> >
> > If it's anything like TCON0, it's the pixel clock polarity
>
> Hard to say, DW HDMI controller has "data enable" polarity along hsync and
> vsync. It could be either or none of those.
>
> What should I write in comment? BSP drivers and documentation use only generic
> names like io2_inv.
Just say that we don't know exactly what it is, but it is required for things
to work properly? Would be interesting to know what happens if you don't set
this bit, but do set VSYNC/HSYNC polarity properly.
ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/aperture: Pass DRM driver structure instead of driver name
On Tue, Jun 29, 2021 at 9:58 PM Thomas Zimmermann wrote: > > Print the name of the DRM driver when taking over fbdev devices. Makes > the output to dmesg more consistent. Note that the driver name is only > used for printing a string to the kernel log. No UAPI is affected by this > change. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- Acked-by: Chen-Yu Tsai
Re: [PATCH 0/7] sunxi: Remove the calls to dma_direct_set_offset
Hi, On Fri, Nov 6, 2020 at 11:15 PM Maxime Ripard wrote: > > Hi, > > Here's an attempt to removing the dma_direct_set_offset calls we have in > numerous drivers and move all those quirks into a global notifier as suggested > by Robin. > > Let me know what you think, > Maxime > > Maxime Ripard (7): > drm/sun4i: backend: Fix probe failure with multiple backends > soc: sunxi: Deal with the MBUS DMA offsets in a central place > drm/sun4i: backend: Remove the MBUS quirks > media: sun4i: Remove the MBUS quirks > media: sun6i: Remove the MBUS quirks > media: cedrus: Remove the MBUS quirks > media: sun8i-di: Remove the call to of_dma_configure Whole series looks good to me. Reviewed-by: Chen-Yu Tsai Now the question remaining is how do we merge this series so that the notifier gets merged before all the code dealing with the MBUS quirk gets removed. > drivers/gpu/drm/sun4i/sun4i_backend.c | 13 -- > .../platform/sunxi/sun4i-csi/sun4i_csi.c | 27 > .../platform/sunxi/sun6i-csi/sun6i_csi.c | 17 --- > .../media/platform/sunxi/sun8i-di/sun8i-di.c | 4 - > drivers/soc/sunxi/Kconfig | 8 ++ > drivers/soc/sunxi/Makefile| 1 + > drivers/soc/sunxi/sunxi_mbus.c| 132 ++ > drivers/staging/media/sunxi/cedrus/cedrus.c | 1 - > drivers/staging/media/sunxi/cedrus/cedrus.h | 3 - > .../staging/media/sunxi/cedrus/cedrus_hw.c| 18 --- > 10 files changed, 141 insertions(+), 83 deletions(-) > create mode 100644 drivers/soc/sunxi/sunxi_mbus.c > > -- > 2.28.0 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: ssd130x: Fix COM scan direction register mask
From: Chen-Yu Tsai
The SSD130x's command to toggle COM scan direction uses bit 3 and only
bit 3 to set the direction of the scanout. The driver has an incorrect
GENMASK(3, 2), causing the setting to be set on bit 2, rendering it
ineffective.
Fix the mask to only bit 3, so that the requested setting is applied
correctly.
Fixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index ce4dc20412e0..ccd378135589 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -61,7 +61,7 @@
#define SSD130X_SET_COM_PINS_CONFIG0xda
#define SSD130X_SET_VCOMH 0xdb
-#define SSD130X_SET_COM_SCAN_DIR_MASK GENMASK(3, 2)
+#define SSD130X_SET_COM_SCAN_DIR_MASK GENMASK(3, 3)
#define SSD130X_SET_COM_SCAN_DIR_SET(val)
FIELD_PREP(SSD130X_SET_COM_SCAN_DIR_MASK, (val))
#define SSD130X_SET_CLOCK_DIV_MASK GENMASK(3, 0)
#define SSD130X_SET_CLOCK_DIV_SET(val)
FIELD_PREP(SSD130X_SET_CLOCK_DIV_MASK, (val))
--
2.34.1
[PATCH 2/2] drm: ssd130x: Always apply segment remap setting
From: Chen-Yu Tsai
Currently the ssd130x driver only sets the segment remap setting when
the device tree requests it; it however does not clear the setting if
it is not requested. This leads to the setting incorrectly persisting
if the hardware is always on and has no reset GPIO wired. This might
happen when a developer is trying to find the correct settings for an
unknown module, and cause the developer to get confused because the
settings from the device tree are not consistently applied.
Make the driver apply the segment remap setting consistently, setting
the value correctly based on the device tree setting. This also makes
this setting's behavior consistent with the other settings, which are
always applied.
Fixes: a61732e80867 ("drm: Add driver for Solomon SSD130x OLED displays")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/solomon/ssd130x.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index ccd378135589..d08d86ef07bc 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -48,7 +48,7 @@
#define SSD130X_CONTRAST 0x81
#define SSD130X_SET_LOOKUP_TABLE 0x91
#define SSD130X_CHARGE_PUMP0x8d
-#define SSD130X_SEG_REMAP_ON 0xa1
+#define SSD130X_SET_SEG_REMAP 0xa0
#define SSD130X_DISPLAY_OFF0xae
#define SSD130X_SET_MULTIPLEX_RATIO0xa8
#define SSD130X_DISPLAY_ON 0xaf
@@ -61,6 +61,8 @@
#define SSD130X_SET_COM_PINS_CONFIG0xda
#define SSD130X_SET_VCOMH 0xdb
+#define SSD130X_SET_SEG_REMAP_MASK GENMASK(0, 0)
+#define SSD130X_SET_SEG_REMAP_SET(val)
FIELD_PREP(SSD130X_SET_SEG_REMAP_MASK, (val))
#define SSD130X_SET_COM_SCAN_DIR_MASK GENMASK(3, 3)
#define SSD130X_SET_COM_SCAN_DIR_SET(val)
FIELD_PREP(SSD130X_SET_COM_SCAN_DIR_MASK, (val))
#define SSD130X_SET_CLOCK_DIV_MASK GENMASK(3, 0)
@@ -235,7 +237,7 @@ static void ssd130x_power_off(struct ssd130x_device
*ssd130x)
static int ssd130x_init(struct ssd130x_device *ssd130x)
{
- u32 precharge, dclk, com_invdir, compins, chargepump;
+ u32 precharge, dclk, com_invdir, compins, chargepump, seg_remap;
int ret;
/* Set initial contrast */
@@ -244,11 +246,11 @@ static int ssd130x_init(struct ssd130x_device *ssd130x)
return ret;
/* Set segment re-map */
- if (ssd130x->seg_remap) {
- ret = ssd130x_write_cmd(ssd130x, 1, SSD130X_SEG_REMAP_ON);
- if (ret < 0)
- return ret;
- }
+ seg_remap = (SSD130X_SET_SEG_REMAP |
+SSD130X_SET_SEG_REMAP_SET(ssd130x->seg_remap));
+ ret = ssd130x_write_cmd(ssd130x, 1, seg_remap);
+ if (ret < 0)
+ return ret;
/* Set COM direction */
com_invdir = (SSD130X_SET_COM_SCAN_DIR |
--
2.34.1
Re: [PATCH v8 18/19] drm/mediatek: change the aux retries times when receiving AUX_DEFER
On Fri, Feb 18, 2022 at 11:15 PM Guillaume Ranquet wrote: > > From: Jitao Shi > > DP 1.4a Section 2.8.7.1.5.6.1: > A DP Source device shall retry at least seven times upon receiving > AUX_DEFER before giving up the AUX transaction. > > Aux should retry to send msg whether how many bytes. > > Signed-off-by: Jitao Shi > Signed-off-by: Guillaume Ranquet Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2] drm/bridge: anx7625: Set downstream sink into normal status
On Tue, Mar 22, 2022 at 4:52 PM Xin Ji wrote:
>
> On Tue, Mar 22, 2022 at 04:43:20PM +0800, Hsin-Yi Wang wrote:
> > On Tue, Mar 22, 2022 at 4:02 PM Xin Ji wrote:
> > >
> > > As downstream sink was set into standby mode while bridge disabled,
> > > this patch used for setting downstream sink into normal status
> > > while enable bridge.
> > >
> > > Signed-off-by: Xin Ji
> > > Reviewed-by: Pin-Yen Lin
> > >
> > > ---
> > > V1 -> V2: use dev_dbg replace of dev_info
> > > ---
> > > drivers/gpu/drm/bridge/analogix/anx7625.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > index 9a2a19ad4202..dcf3275a00fe 100644
> > > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > @@ -924,12 +924,20 @@ static void anx7625_dp_start(struct anx7625_data
> > > *ctx)
> > > {
> > > int ret;
> > > struct device *dev = &ctx->client->dev;
> > > + u8 data;
> > >
> > > if (!ctx->display_timing_valid) {
> > > DRM_DEV_ERROR(dev, "mipi not set display timing yet.\n");
> > > return;
> > > }
> > >
> > > + dev_dbg(dev, "set downstream sink into normal\n");
> > > + /* Downstream sink enter into normal mode */
> > > + data = 1;
> > > + ret = anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1,
> > > &data);
> > > + if (ret < 0)
> > > + dev_err(dev, "IO error : set sink into normal mode
> > > fail\n");
> > > +
> >
> > The driver uses DRM_DEV_* for logs. Can we use this?
> Hi Hsin-Yi, as comment in drm/drm_print.h:
> "NOTE: this is deprecated in favor of drm_dbg". DRM bridge driver not
> use DRM_DEV_* any more. I'll send a patch to replace all of DRM_DEV_*
> later.
drm_dbg is better than dev_dbg though. With the former, you still get the
option to control it with the drm.debug module parameter, unlike the latter
which normally gets compiled out.
Please use drm_dbg*.
ChenYu
> Thanks,
> Xin
> >
> > > /* Disable HDCP */
> > > anx7625_write_and(ctx, ctx->i2c.rx_p1_client, 0xee, 0x9f);
> > >
> > > --
> > > 2.25.1
> > >
[PATCH 3/4] drm: ssd130x: Support page addressing mode
From: Chen-Yu Tsai
On the SINO WEALTH SH1106, which is mostly compatible with the SSD1306,
only the basic page addressing mode is supported. This addressing mode
is not as easy to use compared to the currently supported horizontal
addressing mode, as the page address has to be set prior to writing
out each page, and each page must be written out separately as a result.
Also, there is no way to force the column address to wrap around early,
thus the column address must also be reset for each page to be accurate.
Add support for this addressing mode, with a flag to choose it. This
flag is designed to be set from the device info data structure, but
can be extended to be explicitly forced on through a device tree
property if such a need arises.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/solomon/ssd130x.c | 72 ---
drivers/gpu/drm/solomon/ssd130x.h | 2 +
2 files changed, 67 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index d08d86ef07bc..21040d8bf9d1 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -42,6 +42,8 @@
#define SSD130X_DATA 0x40
#define SSD130X_COMMAND0x80
+#define SSD130X_PAGE_COL_START_LOW 0x00
+#define SSD130X_PAGE_COL_START_HIGH0x10
#define SSD130X_SET_ADDRESS_MODE 0x20
#define SSD130X_SET_COL_RANGE 0x21
#define SSD130X_SET_PAGE_RANGE 0x22
@@ -61,6 +63,10 @@
#define SSD130X_SET_COM_PINS_CONFIG0xda
#define SSD130X_SET_VCOMH 0xdb
+#define SSD130X_PAGE_COL_START_MASKGENMASK(3, 0)
+#define SSD130X_PAGE_COL_START_SET(val)
FIELD_PREP(SSD130X_PAGE_COL_START_MASK, (val))
+#define SSD130X_START_PAGE_ADDRESS_MASKGENMASK(2, 0)
+#define SSD130X_START_PAGE_ADDRESS_SET(val)
FIELD_PREP(SSD130X_START_PAGE_ADDRESS_MASK, (val))
#define SSD130X_SET_SEG_REMAP_MASK GENMASK(0, 0)
#define SSD130X_SET_SEG_REMAP_SET(val)
FIELD_PREP(SSD130X_SET_SEG_REMAP_MASK, (val))
#define SSD130X_SET_COM_SCAN_DIR_MASK GENMASK(3, 3)
@@ -130,6 +136,7 @@ static int ssd130x_write_cmd(struct ssd130x_device
*ssd130x, int count,
return ret;
}
+/* Set address range for horizontal/vertical addressing modes */
static int ssd130x_set_col_range(struct ssd130x_device *ssd130x,
u8 col_start, u8 cols)
{
@@ -166,6 +173,26 @@ static int ssd130x_set_page_range(struct ssd130x_device
*ssd130x,
return 0;
}
+/* Set page and column start address for page addressing mode */
+static int ssd130x_set_page_pos(struct ssd130x_device *ssd130x,
+ u8 page_start, u8 col_start)
+{
+ int ret;
+ u32 page, col_low, col_high;
+
+ page = SSD130X_START_PAGE_ADDRESS |
+ SSD130X_START_PAGE_ADDRESS_SET(page_start);
+ col_low = SSD130X_PAGE_COL_START_LOW |
+ SSD130X_PAGE_COL_START_SET(col_start & 0xf);
+ col_high = SSD130X_PAGE_COL_START_HIGH |
+ SSD130X_PAGE_COL_START_SET((col_start >> 4) & 0xf);
+ ret = ssd130x_write_cmd(ssd130x, 3, page, col_low, col_high);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int ssd130x_pwm_enable(struct ssd130x_device *ssd130x)
{
struct device *dev = ssd130x->dev;
@@ -342,6 +369,11 @@ static int ssd130x_init(struct ssd130x_device *ssd130x)
}
}
+ /* Switch to page addressing mode */
+ if (ssd130x->page_address_mode)
+ return ssd130x_write_cmd(ssd130x, 2, SSD130X_SET_ADDRESS_MODE,
+SSD130X_SET_ADDRESS_MODE_PAGE);
+
/* Switch to horizontal addressing mode */
return ssd130x_write_cmd(ssd130x, 2, SSD130X_SET_ADDRESS_MODE,
SSD130X_SET_ADDRESS_MODE_HORIZONTAL);
@@ -393,13 +425,16 @@ static int ssd130x_update_rect(struct ssd130x_device
*ssd130x, u8 *buf,
* (5) A4 B4 C4 D4 E4 F4 G4 H4
*/
- ret = ssd130x_set_col_range(ssd130x, ssd130x->col_offset + x, width);
- if (ret < 0)
- goto out_free;
+ if (!ssd130x->page_address_mode) {
+ /* Set address range for horizontal addressing mode */
+ ret = ssd130x_set_col_range(ssd130x, ssd130x->col_offset + x,
width);
+ if (ret < 0)
+ goto out_free;
- ret = ssd130x_set_page_range(ssd130x, ssd130x->page_offset + y / 8,
pages);
- if (ret < 0)
- goto out_free;
+ ret = ssd130x_set_page_range(ssd130x, ssd130x->page_offset + y
/ 8, pages);
+ if (ret < 0)
+ goto out_free;
+ }
for (i = y / 8; i < y / 8 + pages
[PATCH 4/4] drm: ssd130x: Add support for SINO WEALTH SH1106
From: Chen-Yu Tsai
The SINO WEALTH SH1106 is an OLED display driver that is somewhat
compatible with the SSD1306. It supports a slightly wider display,
at 132 instead of 128 pixels. The basic commands are the same, but
the SH1106 doesn't support the horizontal or vertical address modes.
Add support for this display driver. The default values for some of
the hardware settings are taken from the datasheet.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/solomon/ssd130x-i2c.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
index 3126aeda4ced..d099b241dd3f 100644
--- a/drivers/gpu/drm/solomon/ssd130x-i2c.c
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -53,6 +53,13 @@ static void ssd130x_i2c_shutdown(struct i2c_client *client)
ssd130x_shutdown(ssd130x);
}
+static struct ssd130x_deviceinfo ssd130x_sh1106_deviceinfo = {
+ .default_vcomh = 0x40,
+ .default_dclk_div = 1,
+ .default_dclk_frq = 5,
+ .page_mode_only = 1,
+};
+
static struct ssd130x_deviceinfo ssd130x_ssd1305_deviceinfo = {
.default_vcomh = 0x34,
.default_dclk_div = 1,
@@ -80,6 +87,10 @@ static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo
= {
};
static const struct of_device_id ssd130x_of_match[] = {
+ {
+ .compatible = "sinowealth,sh1106-i2c",
+ .data = &ssd130x_sh1106_deviceinfo,
+ },
{
.compatible = "solomon,ssd1305fb-i2c",
.data = &ssd130x_ssd1305_deviceinfo,
--
2.34.1
[PATCH 2/4] dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106
From: Chen-Yu Tsai The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes. Add a compatible string for it. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 9baafd0c42dd..1ac016a2d847 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -13,6 +13,7 @@ maintainers: properties: compatible: enum: + - sinowealth,sh1106-i2c - solomon,ssd1305fb-i2c - solomon,ssd1306fb-i2c - solomon,ssd1307fb-i2c -- 2.34.1
[PATCH 1/4] dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd.
From: Chen-Yu Tsai Add a vendor prefix entry for SINO WEALTH Eletronics Ltd. (http://www.sinowealth.com). Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 01430973ecec..bb4ae59a3c89 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1128,6 +1128,8 @@ patternProperties: description: Cypress Semiconductor Corporation (Simtek Corporation) "^sinlinx,.*": description: Sinlinx Electronics Technology Co., LTD + "^sinowealth,.*": +description: SINO WEALTH Electronic Ltd. "^sinovoip,.*": description: SinoVoip Co., Ltd "^sipeed,.*": -- 2.34.1
[PATCH 0/4] drm: ssd130x: Add support for SINO WEALTH SH1106
From: Chen-Yu Tsai Hi everyone, This series adds support for SH1106 to the ssd130x OLED display driver. The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes. This driver chip is found in some cheap 1.3" OLED panel modules. It acts as a substitute for the SSD1306. Patch 1 adds an entry to the vendor prefixes for SINO WEALTH Eletronics Ltd. Patch 2 adds an entry for SH1106 to the ssd1307fb binding. Patch 3 adds support for the base "page addressing mode" to the ssd130x driver. Patch 4 adds support for the SH1106 to the ssd130x driver. Please have a look. Thanks ChenYu Chen-Yu Tsai (4): dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd. dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106 drm: ssd130x: Support page addressing mode drm: ssd130x: Add support for SINO WEALTH SH1106 .../bindings/display/solomon,ssd1307fb.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/solomon/ssd130x-i2c.c | 11 +++ drivers/gpu/drm/solomon/ssd130x.c | 72 +-- drivers/gpu/drm/solomon/ssd130x.h | 2 + 5 files changed, 81 insertions(+), 7 deletions(-) -- 2.34.1
Re: [PATCH v2] arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint
Hi,
(CC-ed DRM bridge maintainers and the dri-devel ML)
On Wed, Feb 2, 2022 at 1:47 AM Nícolas F. R. A. Prado
wrote:
>
> mt8183-kukui-jacuzzi has an anx7625 bridge connected to the output of
> its DSI host. However, after commit fd0310b6fe7d ("drm/bridge: anx7625:
> add MIPI DPI input feature"), a bus-type property started being required
> in the endpoint node by the driver to indicate whether it is DSI or DPI.
>
> Add the missing bus-type property and set it to 5
> (V4L2_FWNODE_BUS_TYPE_PARALLEL) so that the driver has its input
> configured to DSI and the display pipeline can probe correctly.
Don't people find it odd that this is setting the bus-type to "parallel"
(5) for the device to use DSI? Instead of "MIPI CSI-2 D-PHY" (4) or even
"MIPI CSI-2 C-PHY" (1) which is specified in the binding? It's completely
backwards.
Would it be possible to fix the binding and driver at this point?
Thanks
ChenYu
> While at it, also set the data-lanes property that was also introduced
> in that same commit, so that we don't rely on the default value.
>
> Fixes: fd0310b6fe7d ("drm/bridge: anx7625: add MIPI DPI input feature")
> Signed-off-by: Nícolas F. R. A. Prado
>
> ---
> v1:
> https://lore.kernel.org/all/20220120224204.773117-1-nfrapr...@collabora.com
>
> Changes in v2:
> - (thanks Rob) Use proper format when refering to commit in commit
> message as pointed out by checkpatch
>
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> index 8f7bf33f607d..e8f133dc96b9 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> @@ -171,6 +171,8 @@ port@0 {
>
> anx7625_in: endpoint {
> remote-endpoint = <&dsi_out>;
> + bus-type = <5>;
> + data-lanes = <0 1 2 3>;
> };
> };
>
> --
> 2.35.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
[PATCH] drm/mediatek: Fix DPI component detection for MT8192
When support for MT8192 was added, the DPI device was not added to the
list of components to look for. This causes the secondary display
pipeline to not be able to fully bind, and the DRM driver subsequently
defers probing.
Add the DPI device compatible to list of DPI components to fix this.
Fixes: 01365f549c88 ("drm/mediatek: Add support for Mediatek SoC MT8192")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b147797177c6..47ba18cbc5c8 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -511,6 +511,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8183-dpi",
.data = (void *)MTK_DPI },
+ { .compatible = "mediatek,mt8192-dpi",
+ .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt2701-dsi",
.data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dsi",
--
2.35.1.574.g5d30c73bfb-goog
Re: [PATCH v12 3/4] drm/bridge: anx7625: add MIPI DPI input feature
On Sun, Mar 06, 2022 at 07:13:30PM +0200, Laurent Pinchart wrote:
> Hello Xin,
>
> (Question for Rob below, and I'm afraid this is urgent as we need to
> merge a fix in v5.17).
>
> On Fri, Nov 05, 2021 at 11:19:03AM +0800, Xin Ji wrote:
> > The basic anx7625 driver only support MIPI DSI rx signal input.
> > This patch add MIPI DPI rx input configuration support, after apply
> > this patch, the driver can support DSI rx or DPI rx by adding
> > 'bus-type' in DT.
> >
> > Reviewed-by: Robert Foss
> > Signed-off-by: Xin Ji
> > ---
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 247 --
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 18 +-
> > 2 files changed, 205 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index f48e91134c20..f7c3386c8929 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
[...]
> > static int anx7625_parse_dt(struct device *dev,
> > struct anx7625_platform_data *pdata)
> > {
> > - struct device_node *np = dev->of_node;
> > + struct device_node *np = dev->of_node, *ep0;
> > struct drm_panel *panel;
> > int ret;
> > + int bus_type, mipi_lanes;
> > +
> > + anx7625_get_swing_setting(dev, pdata);
> >
> > + pdata->is_dpi = 1; /* default dpi mode */
> > pdata->mipi_host_node = of_graph_get_remote_node(np, 0, 0);
> > if (!pdata->mipi_host_node) {
> > DRM_DEV_ERROR(dev, "fail to get internal panel.\n");
> > return -ENODEV;
> > }
> >
> > - DRM_DEV_DEBUG_DRIVER(dev, "found dsi host node.\n");
> > + bus_type = V4L2_FWNODE_BUS_TYPE_PARALLEL;
> > + mipi_lanes = MAX_LANES_SUPPORT;
> > + ep0 = of_graph_get_endpoint_by_regs(np, 0, 0);
> > + if (ep0) {
> > + if (of_property_read_u32(ep0, "bus-type", &bus_type))
> > + bus_type = 0;
> > +
> > + mipi_lanes = of_property_count_u32_elems(ep0, "data-lanes");
> > + }
> > +
> > + if (bus_type == V4L2_FWNODE_BUS_TYPE_PARALLEL) /* bus type is
> > Parallel(DSI) */
>
> This is not correct *at all*. V4L2_FWNODE_BUS_TYPE_PARALLEL has nothing
> to do with DSI. DSI stands for Digital *Serial* Interface. If anything,
> the V4L2_FWNODE_BUS_TYPE_PARALLEL type would map better to DPI, even if
> it's not an exact match.
>
> This patch has landed in v5.17-rc1, along with the corresponding
> bindings. As DT bindings are an ABI, we should really fix this before
> v5.17 is released. There is no DSI bus types defined in DT, and adding
> one as a fix so late in the v5.17-rc cycle seems a bit of a stretch to
> me (unless Rob disagrees).
>
> It would seem best to revert this series and the corresponding bindings,
> and retry in v5.18.
There is a DT patch using this property that is already queued up for 5.17
in the soc tree:
https://lore.kernel.org/all/20220214200507.2500693-1-nfrapr...@collabora.com/
merged here:
http://git.kernel.org/soc/soc/c/32568ae37596b529628ac09b875f4874e614f63f
We will need to revert that one as well.
ChenYu
Re: [PATCH v1 2/2] Revert "arm64: dts: mt8183: jacuzzi: Fix bus properties in anx's DSI endpoint"
On Tue, Mar 8, 2022 at 12:20 AM Robert Foss wrote:
>
> Signed-off-by: Robert Foss
Reviewed-by: Chen-Yu Tsai
I think we need to send this directly to the soc maintainers to get it
picked up before the final 5.17 release?
>
> On Mon, 7 Mar 2022 at 16:46, Robert Foss wrote:
> >
> > This reverts commit 32568ae37596b529628ac09b875f4874e614f63f.
> > ---
> > arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> > index e8f133dc96b95..8f7bf33f607da 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> > @@ -171,8 +171,6 @@ port@0 {
> >
> > anx7625_in: endpoint {
> > remote-endpoint = <&dsi_out>;
> > - bus-type = <5>;
> > - data-lanes = <0 1 2 3>;
> > };
> > };
> >
> > --
> > 2.32.0
> >
Re: [PATCH] drm/sun4i: Fix macros in sun8i_csc.h
On Wed, Sep 1, 2021 at 2:48 AM Jernej Skrabec wrote:
>
> Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual
> recommendation of having arguments enclosed in parenthesis. While that
> didn't change anything for quiet sometime, it actually become important
^ Typo
> after CSC code rework with commit ea067aee45a8 ("drm/sun4i: de2/de3:
> Remove redundant CSC matrices").
>
> Without this fix, colours are completely off for supported YVU formats
> on SoCs with DE2 (A64, H3, R40, etc.).
>
> Fix the issue by enclosing macro arguments in parenthesis.
>
> Cc: sta...@vger.kernel.org # 5.12+
> Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library")
> Reported-by: Roman Stratiienko
> Signed-off-by: Jernej Skrabec
Otherwise,
Reviewed-by: Chen-Yu Tsai
Re: [PATCH v6 0/3] support gce on mt8192 platform
On Mon, Aug 2, 2021 at 3:47 PM Yongqiang Niu wrote: > > Change since v5: > -rebase on linux 5.14-rc1 > > Yongqiang Niu (3): > dt-binding: gce: add gce header file for mt8192 > arm64: dts: mt8192: add gce node > mailbox: cmdq: add mt8192 support Looks like all the driver parts are in -next, but the dts patch is not. Can you resend that patch after the merge window? Thanks ChenYu
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
On Fri, Sep 3, 2021 at 12:31 AM Ezequiel Garcia
wrote:
>
> On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote:
> >
> > This series adds support for multi hardware decode into mtk-vcodec, by first
> > adding component framework to manage each hardware information: interrupt,
> > clock, register bases and power. Secondly add core thread to deal with core
> > hardware message, at the same time, add msg queue for different hardware
> > share messages. Lastly, the architecture of different specs are not the
> > same,
> > using specs type to separate them.
> >
> > This series has been tested with both MT8183 and MT8173. Decoding was
> > working
> > for both chips.
> >
> > Patches 1~3 rewrite get register bases and power on/off interface.
> >
> > Patch 4 add component framework to support multi hardware.
> >
> > Patch 5 separate video encoder and decoder document
> >
> > Patches 6-15 add interfaces to support core hardware.
> >
> > This patch dependents on : "media: mtk-vcodec: support for MT8183
> > decoder"[1] and
> > "Mediatek MT8192 clock support"[2].
> >
> > 1: Multi hardware decode is based on stateless decoder, MT8183 is the first
> > time
> > to add stateless decoder. Otherwise it will cause conflict. This patch will
> > be
> > accepted in 5.15[1].
> >
> > 2: The definition of decoder clocks are in mt8192-clk.h, this patch already
> > in clk tree[2].
> >
> > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826
> > [2]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189
> >
> > Changes compared with v5:
> > -Add decoder hardware block diagram for patch 13/15
> >
>
>
> The discussion on v5 was still on-going, so sending this v6
> is not helpful. The context for v5's discussion is now harder to find.
>
> Please avoid sending a new version without properly
> discussing all the feedback, and without reaching consensus.
> This is very important, please keep it in mind.
>
> Specifically, the feedback on v5 was NAK, with the request to avoid
> using any async framework, and instead try to find a simpler solution.
>
> For instance, you can model things with a bus-like pattern,
> which ties all the devices together, under a parent node.
> This pattern is common in the kernel, the parent
> node can use of_platform_populate or similar
> (git grep of_platform_populate, you will see plenty of examples).
>
> You will still have to do some work to have the proper
> regs resources, but this is doable. Each child is a device,
> so it can have its own resources (clocks, interrupts, iommus).
AFAIK of_platform_populate doesn't guarantee the drivers actually
probed (modules loaded late, missing modules, deferred probe, etc.),
only that the devices are created, so you still need some sort of
(async) mechanism to wait for the subdevices to be in operational
state. Most of the examples using of_platform_populate are there
to ensure that the parent device is operational before creating
the sub-devices, not the other way around.
ChenYu
> You don't need any async framework.
>
> vcodec_dec: vcodec_dec@1600 {
> compatible = "mediatek,mt8192-vcodec-dec";
> reg = ;
> mediatek,scp = <&scp>;
> iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>;
> dma-ranges = <0x1 0x0 0x0 0x4000 0x0 0xfff0>;
>
> vcodec_lat@0x1 {
> compatible = "mediatek,mtk-vcodec-lat";
> reg = <0x1 0x800>; /* VDEC_MISC */
> interrupts = ;
> // etc
> };
>
> vcodec_core@0x25000 {
>compatible = "mediatek,mtk-vcodec-core";
>reg = <0x25000 0x1000>; /* VDEC_CORE_MISC */
>interrupts = ;
>// etc
> };
> };
>
> Thanks,
> Ezequiel
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/2] drm/rockchip: dsi: hold pm-runtime across bind/unbind
Hi,
On Sat, Sep 25, 2021 at 7:24 AM Brian Norris wrote:
>
> In commit 59eb7193bef2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power domain in between the hardware configuration
> (bind()) and when we enable the display. This can cause us to lose
> hardware state and fail to configure our display. For example:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-innolux-p079zca ff96.mipi.0: failed to write command 0
>
> or:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> We should match the runtime PM to the lifetime of the bind()/unbind()
> cycle.
I'm not too familiar with MIPI DSI, but it seems that the subsystem expects
the DSI link to be always available, and in LPM if power saving is required?
If so then this change matches that expectation, though we might lose some
power savings compared to the previous non-conforming behavior.
> Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
> built either as modules or built-in.
>
> Side notes: it seems one is more likely to see this problem when the
> panel driver is built into the kernel. I've also seen this problem
> bisect down to commits that simply changed Kconfig dependencies, because
> it changed the order in which driver init functions were compiled into
> the kernel, and therefore the ordering and timing of built-in device
> probe.
>
> Fixes: 59eb7193bef2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
This hash is from some stable branch. The mainline one is:
43c2de1002d2 drm/rockchip: dsi: move all lane config except LCDC mux to bind()
> Link:
> https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
> Reported-by:
> Cc:
> Signed-off-by: Brian Norris
> ---
>
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 22 +++
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index a2262bee5aa4..4340a99edb97 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -773,10 +773,6 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> if (mux < 0)
> return;
>
> - pm_runtime_get_sync(dsi->dev);
> - if (dsi->slave)
> - pm_runtime_get_sync(dsi->slave->dev);
> -
> /*
> * For the RK3399, the clk of grf must be enabled before writing grf
> * register. And for RK3288 or other soc, this grf_clk must be NULL,
> @@ -795,20 +791,10 @@ static void dw_mipi_dsi_encoder_enable(struct
> drm_encoder *encoder)
> clk_disable_unprepare(dsi->grf_clk);
> }
>
> -static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
> -{
> - struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
> -
> - if (dsi->slave)
> - pm_runtime_put(dsi->slave->dev);
> - pm_runtime_put(dsi->dev);
> -}
> -
> static const struct drm_encoder_helper_funcs
> dw_mipi_dsi_encoder_helper_funcs = {
> .atomic_check = dw_mipi_dsi_encoder_atomic_check,
> .enable = dw_mipi_dsi_encoder_enable,
> - .disable = dw_mipi_dsi_encoder_disable,
> };
>
> static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi,
> @@ -938,6 +924,10 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> put_device(second);
> }
>
> + pm_runtime_get_sync(dsi->dev);
> + if (dsi->slave)
> + pm_runtime_get_sync(dsi->slave->dev);
> +
> ret = clk_prepare_enable(dsi->pllref_clk);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to enable pllref_clk: %d\n", ret);
The bind function is missing an error cleanup path. We might end up with
unbalanced runtime PM references. (And also possibly an enabled pllref clk.)
This is a pre-existing issue though. The code changes here look correct.
Regards
ChenYu
> @@ -989,6 +979,10 @@ static void dw_mipi_dsi_rockchip_unbind(struct device
> *dev,
> dw_mipi_dsi_unbind(dsi->dmd);
>
> clk_disable_unprepare(dsi->pllref_clk);
> +
> + pm_runtime_put(dsi->dev);
> + if (dsi->slave)
> + pm_runtime_put(dsi->slave->dev);
> }
>
> static const struct component_ops dw_mipi_dsi_rockchip_ops = {
> --
> 2.33.0.685.g46640cef36-goog
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH 2/2] drm/rockchip: dsi: Fix unbalanced clock on probe error
On Sat, Sep 25, 2021 at 7:24 AM Brian Norris wrote:
>
> Our probe() function never enabled this clock, so we shouldn't disable
> it if we fail to probe the bridge.
>
> Noted by inspection.
>
> Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge
> driver")
> Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2 3/3] drm/rockchip: dsi: Disable PLL clock on bind error
On Tue, Sep 28, 2021 at 2:00 AM Brian Norris wrote:
>
> Fix some error handling here noticed in review of other changes.
>
> Reported-by: Chen-Yu Tsai
> Signed-off-by: Brian Norris
Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi
bridge driver")
Otherwise,
Reviewed-by: Chen-Yu Tsai
Additionally, I would move patch 2 and this patch before the first patch,
as these two fix a commit introduced in v5.0, while the first patch fixes
something introduced in v5.14. This would make automatic backporting cleaner.
> ---
>
> Changes in v2:
> - New
>
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index fa4080176719..0ed13d81fe60 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -943,7 +943,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> ret = clk_prepare_enable(dsi->grf_clk);
> if (ret) {
> DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n",
> ret);
> - goto out_pm_runtime;
> + goto out_pll_clk;
> }
>
> dw_mipi_dsi_rockchip_config(dsi);
> @@ -955,17 +955,19 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
> - goto out_pm_runtime;
> + goto out_pll_clk;
> }
>
> ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
> - goto out_pm_runtime;
> + goto out_pll_clk;
> }
>
> return 0;
>
> +out_pll_clk:
> + clk_disable_unprepare(dsi->pllref_clk);
> out_pm_runtime:
> pm_runtime_put(dsi->dev);
> if (dsi->slave)
> --
> 2.33.0.685.g46640cef36-goog
>
Re: [PATCH v3 1/4] drm/rockchip: dsi: Hold pm-runtime across bind/unbind
On Wed, Sep 29, 2021 at 5:36 AM Brian Norris wrote:
>
> In commit 43c2de1002d2, we moved most HW configuration to bind(), but we
> didn't move the runtime PM management. Therefore, depending on initial
> boot state, runtime-PM workqueue delays, and other timing factors, we
> may disable our power domain in between the hardware configuration
> (bind()) and when we enable the display. This can cause us to lose
> hardware state and fail to configure our display. For example:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-innolux-p079zca ff96.mipi.0: failed to write command 0
>
> or:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> We should match the runtime PM to the lifetime of the bind()/unbind()
> cycle.
>
> Tested on Acer Chrometab 10 (RK3399 Gru-Scarlet), with panel drivers
> built either as modules or built-in.
>
> Side notes: it seems one is more likely to see this problem when the
> panel driver is built into the kernel. I've also seen this problem
> bisect down to commits that simply changed Kconfig dependencies, because
> it changed the order in which driver init functions were compiled into
> the kernel, and therefore the ordering and timing of built-in device
> probe.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Link:
> https://lore.kernel.org/linux-rockchip/9aedfb528600ecf871885f7293ca4207c84d16c1.ca...@gmail.com/
> Reported-by:
> Cc:
> Signed-off-by: Brian Norris
> Tested-by: Nícolas F. R. A. Prado
Reviewed-by: Chen-Yu Tsai
Re: [PATCH v3 2/4] drm/rockchip: dsi: Reconfigure hardware on resume()
On Wed, Sep 29, 2021 at 5:36 AM Brian Norris wrote:
>
> Since commit 43c2de1002d2, we perform most HW configuration in the
> bind() function. This configuration may be lost on suspend/resume, so we
> need to call it again. That may lead to errors like this after system
> suspend/resume:
>
> dw-mipi-dsi-rockchip ff968000.mipi: failed to write command FIFO
> panel-kingdisplay-kd097d04 ff96.mipi.0: failed write init cmds: -110
>
> Tested on Acer Chromebook Tab 10 (RK3399 Gru-Scarlet).
>
> Note that early mailing list versions of this driver borrowed Rockchip's
> downstream/BSP solution, to do HW configuration in mode_set() (which
> *is* called at the appropriate pre-enable() times), but that was
> discarded along the way. I've avoided that still, because mode_set()
> documentation doesn't suggest this kind of purpose as far as I can tell.
>
> Fixes: 43c2de1002d2 ("drm/rockchip: dsi: move all lane config except LCDC mux
> to bind()")
> Cc:
> Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2 1/3] arm64: dts: rockchip: Switch RK3399-Gru DP to SPDIF output
On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote:
>
> Commit b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
> switched the platform to SPDIF, but we didn't fix up the device tree.
>
> Drop the pinctrl settings, because the 'spdif_bus' pins are either:
> * unused (on kevin, bob), so the settings is ~harmless
> * used by a different function (on scarlet), which causes probe
>failures (!!)
I suppose that means the default pinctrl should be dropped? Or maybe this
use case is the outlier. Up to Heiko?
> Fixes: b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
> Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2 2/3] drm/rockchip: cdn-dp: Support HDMI codec plug-change callback
On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote: > > Some audio servers like to monitor a jack device (perhaps combined with > EDID, for audio-presence info) to determine DP/HDMI audio presence. > > Signed-off-by: Brian Norris Reviewed-by: Chen-Yu Tsai
Re: [PATCH v2 3/3] ASoC: rk3399_gru_sound: Wire up DP jack detection
Hi,
On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote:
>
> Now that the cdn-dp driver supports plug-change callbacks, let's wire it
> up.
>
> Signed-off-by: Brian Norris
> ---
>
> (no changes since v1)
>
> sound/soc/rockchip/rk3399_gru_sound.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
> b/sound/soc/rockchip/rk3399_gru_sound.c
> index e2d52d8d0ff9..eeef3ed70037 100644
> --- a/sound/soc/rockchip/rk3399_gru_sound.c
> +++ b/sound/soc/rockchip/rk3399_gru_sound.c
> @@ -164,6 +164,25 @@ static int rockchip_sound_da7219_hw_params(struct
> snd_pcm_substream *substream,
> return 0;
> }
>
> +static struct snd_soc_jack cdn_dp_card_jack;
> +
> +static int rockchip_sound_cdndp_init(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_soc_component *component = asoc_rtd_to_codec(rtd,
> 0)->component;
Using snd_soc_card_get_codec_dai() might be a better choice throughout this
driver. While it will work for the cdn_dp case, because it is the first DAI
in |rockchip_dais[]|, all the invocations for the other codecs are likely
returning the wrong DAI.
For this particular patch it works either way, so
Reviewed-by: Chen-Yu Tsai
> + struct snd_soc_card *card = rtd->card;
> + int ret;
> +
> + /* Enable jack detection. */
> + ret = snd_soc_card_jack_new(card, "DP Jack", SND_JACK_LINEOUT,
> + &cdn_dp_card_jack, NULL, 0);
> + if (ret) {
> + dev_err(card->dev, "Can't create DP Jack %d\n", ret);
> + return ret;
> + }
> +
> + return snd_soc_component_set_jack(component, &cdn_dp_card_jack, NULL);
> +}
> +
> static int rockchip_sound_da7219_init(struct snd_soc_pcm_runtime *rtd)
> {
> struct snd_soc_component *component = asoc_rtd_to_codec(rtd,
> 0)->component;
> @@ -315,6 +334,7 @@ static const struct snd_soc_dai_link rockchip_dais[] = {
> [DAILINK_CDNDP] = {
> .name = "DP",
> .stream_name = "DP PCM",
> + .init = rockchip_sound_cdndp_init,
> .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
> SND_SOC_DAIFMT_CBS_CFS,
> SND_SOC_DAILINK_REG(cdndp),
> --
> 2.34.1.703.g22d0c6ccf7-goog
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v2 3/3] ASoC: rk3399_gru_sound: Wire up DP jack detection
On Wed, Jan 19, 2022 at 4:18 AM Brian Norris wrote:
>
> Hi Chen-Yu,
>
> On Mon, Jan 17, 2022 at 05:01:52PM +0800, Chen-Yu Tsai wrote:
> > On Sat, Jan 15, 2022 at 7:03 AM Brian Norris
> > wrote:
> > >
> > > Now that the cdn-dp driver supports plug-change callbacks, let's wire it
> > > up.
> > >
> > > Signed-off-by: Brian Norris
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > sound/soc/rockchip/rk3399_gru_sound.c | 20
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/sound/soc/rockchip/rk3399_gru_sound.c
> > > b/sound/soc/rockchip/rk3399_gru_sound.c
> > > index e2d52d8d0ff9..eeef3ed70037 100644
> > > --- a/sound/soc/rockchip/rk3399_gru_sound.c
> > > +++ b/sound/soc/rockchip/rk3399_gru_sound.c
> > > @@ -164,6 +164,25 @@ static int rockchip_sound_da7219_hw_params(struct
> > > snd_pcm_substream *substream,
> > > return 0;
> > > }
> > >
> > > +static struct snd_soc_jack cdn_dp_card_jack;
> > > +
> > > +static int rockchip_sound_cdndp_init(struct snd_soc_pcm_runtime *rtd)
> > > +{
> > > + struct snd_soc_component *component = asoc_rtd_to_codec(rtd,
> > > 0)->component;
> >
> > Using snd_soc_card_get_codec_dai() might be a better choice throughout this
> > driver. While it will work for the cdn_dp case, because it is the first DAI
> > in |rockchip_dais[]|, all the invocations for the other codecs are likely
> > returning the wrong DAI.
>
> I'll admit, I'm not very familiar with the ASoC object model, so you may
> well be correct that there's something fishy in here. But I did trace
> through the objects involved here, and we *are* getting the correct DAI
> for both this case and the DA7219 case (preexisting code).
Neither am I, so ...
> It looks like we actually have a new runtime for each of our static
> dai_links:
>
> devm_snd_soc_register_card()
> ...
> for_each_card_prelinks()
> snd_soc_add_pcm_runtime()
>
> So I think this is valid to keep as-is.
I missed this bit. As you say, things are good.
> > For this particular patch it works either way, so
> >
> > Reviewed-by: Chen-Yu Tsai
>
> Thanks for looking!
And thanks for double checking!
Re: [PATCH v1, 7/8] media: uapi: Init VP9 stateless decode params
Hi,
On Thu, Jan 27, 2022 at 10:56 AM Yunfei Dong wrote:
>
> Init some of VP9 frame decode params to default value.
>
> Signed-off-by: Yunfei Dong
Maybe add
Fixes: b88dbe38dca8 ("media: uapi: Add VP9 stateless decoder controls")
> ---
> drivers/media/v4l2-core/v4l2-ctrls-core.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c
> b/drivers/media/v4l2-core/v4l2-ctrls-core.c
> index 54abe5245dcc..b25c77b8a445 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
> @@ -112,6 +112,7 @@ static void std_init_compound(const struct v4l2_ctrl
> *ctrl, u32 idx,
> struct v4l2_ctrl_mpeg2_picture *p_mpeg2_picture;
> struct v4l2_ctrl_mpeg2_quantisation *p_mpeg2_quant;
> struct v4l2_ctrl_vp8_frame *p_vp8_frame;
> + struct v4l2_ctrl_vp9_frame *p_vp9_frame;
> struct v4l2_ctrl_fwht_params *p_fwht_params;
> void *p = ptr.p + idx * ctrl->elem_size;
>
> @@ -152,6 +153,13 @@ static void std_init_compound(const struct v4l2_ctrl
> *ctrl, u32 idx,
> p_vp8_frame = p;
> p_vp8_frame->num_dct_parts = 1;
> break;
> + case V4L2_CTRL_TYPE_VP9_FRAME:
> + p_vp9_frame = p;
> + p_vp9_frame->profile = 0;
> + p_vp9_frame->bit_depth = 8;
> + p_vp9_frame->flags |= V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING |
> + V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING;
> + break;
> case V4L2_CTRL_TYPE_FWHT_PARAMS:
> p_fwht_params = p;
> p_fwht_params->version = V4L2_FWHT_VERSION;
> --
> 2.25.1
>
Re: [PATCH v9, 06/19] media: mtk-vcodec: Manage multi hardware information
On Thu, Nov 11, 2021 at 11:49 AM yunfei.d...@mediatek.com wrote: > > Hi Tzung-Bi, > > Thanks for your suggestion. > On Wed, 2021-11-10 at 18:30 +0800, Tzung-Bi Shih wrote: > > On Tue, Nov 09, 2021 at 08:50:17PM +0800, Yunfei Dong wrote: > > > Manage each hardware information which includes irq/power/clk. > > > The hardware includes LAT0, LAT1 and CORE. > > > > The commit message doesn't explain the code. Could you provide some > > explanations about how the async mechanism works? (e.g. A bitmap for > > all sub-devices' readiness ...) > > > add more detail description for commit message. > > > Reported-by: kernel test robot > > > > Apparently wrong tag. > > > Remove > > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > > index b7a51e96d4ba..eb2af42aa102 100644 > > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > > @@ -18,19 +18,49 @@ > > > > > > #include "mtk_vcodec_drv.h" > > > #include "mtk_vcodec_dec.h" > > > +#include "mtk_vcodec_dec_hw.h" > > > #include "mtk_vcodec_dec_pm.h" > > > #include "mtk_vcodec_intr.h" > > > -#include "mtk_vcodec_util.h" > > > > Why does mtk_vcodec_util.h need to remove? > > > Put #include "mtk_vcodec_util.h" in mtk_vcodec_dec_hw.h. If this file directly uses anything from that header file, it should include it directly, instead of depending on some transitive inclusion. This would avoid having to deal with breakage if/when the includes from header files change beneath you. ChenYu
Re: [PATCH v2 5/6] dt-bindings: display: sun8i-a83t-dw-hdmi: Reference dw-hdmi YAML schema
On Mon, Dec 21, 2020 at 4:03 AM Laurent Pinchart wrote: > > Replace the reference to the DWC HDMI text DT binding with a reference > to the YAML equivalent. > > Signed-off-by: Laurent Pinchart > Acked-by: Rob Herring Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] phy: mediatek: phy-mtk-mipi-dsi: Reorder and stop implicit header inclusion
On Thu, Jan 6, 2022 at 4:48 PM Chunfeng Yun wrote:
>
> On Mon, 2022-01-03 at 15:53 +0100, AngeloGioacchino Del Regno wrote:
> > All the headers for phy-mtk-mipi-{dsi,dsi-mt8173,dsi-mt8183}.c were
> > included from phy-mtk-mipi-dsi.h, but this isn't optimal: in order to
> > increase readability and sensibly reduce build times, the inclusions
> > should be done per-file, also avoiding to include unused headers and
> > should not be implicit.
> >
> > For this reason, move the inclusions to each file and remove unused
> > ones.
> >
> > Signed-off-by: AngeloGioacchino Del Regno <
> > angelogioacchino.delre...@collabora.com>
> > ---
> > drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c | 4
> > drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c | 4
> > drivers/phy/mediatek/phy-mtk-mipi-dsi.c| 7 +++
> > drivers/phy/mediatek/phy-mtk-mipi-dsi.h| 10 ++
> > 4 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > index 95a0d9a3cca7..59f028da9d3e 100644
> > --- a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8173.c
> > @@ -4,7 +4,11 @@
> > * Author: jitao.shi
> > */
> >
> > +#include
> > +#include
> > +#include
> > #include
> > +#include
> > #include "phy-mtk-mipi-dsi.h"
> >
> > #define MIPITX_DSI_CON 0x00
> > diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> > b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> > index 01b59527669e..6c6b192485ba 100644
> > --- a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> > +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
> > @@ -4,7 +4,11 @@
> > * Author: jitao.shi
> > */
> >
> > +#include
> > +#include
> > +#include
> > #include
> > +#include
> > #include "phy-mtk-mipi-dsi.h"
> >
> > #define MIPITX_LANE_CON 0x000c
> > diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
> > b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
> > index 51b1b1d4ad38..6f7425b0bf5b 100644
> > --- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
> > +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
> > @@ -3,7 +3,14 @@
> > * Copyright (c) 2015 MediaTek Inc.
> > */
> >
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > #include
> > +#include
> > #include "phy-mtk-mipi-dsi.h"
> >
> > inline struct mtk_mipi_tx *mtk_mipi_tx_from_clk_hw(struct clk_hw
> > *hw)
> > diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
> > b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
> > index 8d32e9027a15..4eb5fc91e083 100644
> > --- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
> > +++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.h
> > @@ -7,16 +7,10 @@
> > #ifndef _MTK_MIPI_TX_H
> > #define _MTK_MIPI_TX_H
> >
> > -#include
> > #include
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > +#include
> > +#include
> > #include
> > -#include
> >
> I don't think it's good idea to move the common headers into .c files
Header files should be included directly by the file that uses facilities
provided by said header file. Required ones should not be transitively
included through other header files, as that introduces a subtle dependency.
Also, needlessly including header files in places that aren't using them
increases build time. See the 2000+ patch series from Ingo Molnar [1]
increasing build performance by cleaning up header files.
ChenYu
[1] https://lwn.net/ml/linux-kernel/ydifz+lmewets...@gmail.com/
> > struct mtk_mipitx_data {
> > const u32 mppll_preserve;
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
[PATCH] drm/rockchip: Support YUV formats with U/V swapped
The VOP in Rockchip SoCs that support YUV planes also support swapping
of the U and V elements. Supporting the swapped variants, especially
NV21, would be beneficial for multimedia applications, as the hardware
video decoders only output NV21, and supporting this pixel format in
the display pipeline would allow the decoded video frames to be output
directly.
Add support for this to support the various formats that have U/V
swapped.
Signed-off-by: Chen-Yu Tsai
---
This was tested on an ROC-RK3399-PC with modetest only. Changes to all
other SoC platforms were based on their respective TRMs.
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 +++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 11 +++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 3e8d9e2d1b67..c75b39474977 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -262,6 +262,18 @@ static bool has_rb_swapped(uint32_t format)
}
}
+static bool has_uv_swapped(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV21:
+ case DRM_FORMAT_NV61:
+ case DRM_FORMAT_NV42:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -277,10 +289,13 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV21:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV61:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV42:
return VOP_FMT_YUV444SP;
default:
DRM_ERROR("unsupported format[%08x]\n", format);
@@ -899,7 +914,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
unsigned long offset;
dma_addr_t dma_addr;
uint32_t val;
- bool rb_swap;
+ bool rb_swap, uv_swap;
int win_index = VOP_WIN_TO_INDEX(vop_win);
int format;
int is_yuv = fb->format->is_yuv;
@@ -988,6 +1003,9 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
y2r_coefficients[i],
bt601_yuv2rgb[i]);
}
+
+ uv_swap = has_uv_swapped(fb->format->format);
+ VOP_WIN_SET(vop, win, uv_swap, uv_swap);
}
if (win->phy->scl)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 857d97cdc67c..3aa95fdd427d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -166,6 +166,7 @@ struct vop_win_phy {
struct vop_reg gate;
struct vop_reg format;
struct vop_reg rb_swap;
+ struct vop_reg uv_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
struct vop_reg dsp_st;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 1f7353f0684a..af2b07fafadf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -46,8 +46,11 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_RGB565,
DRM_FORMAT_BGR565,
DRM_FORMAT_NV12,
+ DRM_FORMAT_NV21,
DRM_FORMAT_NV16,
+ DRM_FORMAT_NV61,
DRM_FORMAT_NV24,
+ DRM_FORMAT_NV42,
};
static const uint64_t format_modifiers_win_full[] = {
@@ -272,6 +275,7 @@ static const struct vop_win_phy px30_win0_data = {
.enable = VOP_REG(PX30_WIN0_CTRL0, 0x1, 0),
.format = VOP_REG(PX30_WIN0_CTRL0, 0x7, 1),
.rb_swap = VOP_REG(PX30_WIN0_CTRL0, 0x1, 12),
+ .uv_swap = VOP_REG(PX30_WIN0_CTRL0, 0x1, 15),
.act_info = VOP_REG(PX30_WIN0_ACT_INFO, 0x, 0),
.dsp_info = VOP_REG(PX30_WIN0_DSP_INFO, 0x, 0),
.dsp_st = VOP_REG(PX30_WIN0_DSP_ST, 0x, 0),
@@ -291,6 +295,7 @@ static const struct vop_win_phy px30_win1_data = {
.enable = VOP_REG(PX30_WIN1_CTRL0, 0x1, 0),
.format = VOP_REG(PX30_WIN1_CTRL0, 0x7, 4),
.rb_swap = VOP_REG(PX30_WIN1_CTRL0, 0x1, 12),
+ .uv_swap = VOP_REG(PX30_WIN1_CTRL0, 0x1, 15),
.dsp_info = VOP_REG(PX30_WIN1_DSP_INFO, 0x, 0),
.dsp_st = VOP_REG(PX30_WIN1_DSP_ST, 0x, 0),
.yrgb_mst = VOP_REG(PX30_WIN1_MST, 0x, 0),
@@ -368,6 +373,7 @@ static const struct vop_win_phy rk3066_win0_data = {
.enable = VOP_REG(RK3066_SYS_CTRL1, 0x1, 0),
.format = VOP_
Re: [linux-sunxi] [PATCH v4 5/8] arm64: dts: allwinner: Add mali GPU supply for Pine H64
On Mon, May 13, 2019 at 2:28 AM Jagan Teki wrote:
>
> On Sun, May 12, 2019 at 11:16 PM wrote:
> >
> > From: Clément Péron
> >
> > Enable and add supply to the Mali GPU node on the
> > Pine H64 board.
> >
> > Signed-off-by: Clément Péron
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> > index 4802902e128f..e16a8c6738f9 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> > @@ -85,6 +85,11 @@
> > status = "okay";
> > };
> >
> > +&gpu {
> > + mali-supply = <®_dcdcc>;
> > + status = "okay";
> > +};
>
> I think we can squash all these board dts changes into single patch.
Yes. Please do so for all patches with the same changes applied to different
boards, and authored by the same person.
ChenYu
Re: [PATCH v2 3/4] arm64: DTS: allwinner: a64: Enable audio on Teres-I
On Thu, May 16, 2019 at 11:52 PM Torsten Duwe wrote: > > From: Harald Geyer > > The TERES-I has internal speakers (left, right), internal microphone > and a headset combo jack (headphones + mic), "CTIA" (android) pinout. > > The headphone and mic detect lines of the A64 are connected properly, > but AFAIK currently unsupported by the driver. > > Signed-off-by: Harald Geyer > Signed-off-by: Torsten Duwe Looks good to me. Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm/bridge: extract some Analogix I2C DP common code
On Thu, May 23, 2019 at 2:54 PM Torsten Duwe wrote: > > From: Icenowy Zheng > > Some code can be shared within different DP bridges by Analogix. > > Extract them to a new module. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Vasily Khoruzhick > Signed-off-by: Torsten Duwe > --- > drivers/gpu/drm/bridge/analogix/Kconfig| 4 + > drivers/gpu/drm/bridge/analogix/Makefile | 2 + > drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +- > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 169 > + > .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 2 + > 5 files changed, 178 insertions(+), 145 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > ... > static int anx78xx_set_hpd(struct anx78xx *anx78xx) > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > new file mode 100644 > index ..9cb30962032e > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c > @@ -0,0 +1,169 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright(c) 2017 Icenowy Zheng > + * > + * Based on analogix-anx78xx.c, which is: > + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved. If this was simple code movement, then the original copyright still applies. A different copyright notice should not be used. I suppose the same applies to the module author. ChenYu
Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard wrote: > > On Sat, Apr 06, 2019 at 01:45:04AM +0200, meg...@megous.com wrote: > > From: Ondrej Jirman > > > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected > > transistors, before it can be used. Model this as a power supply for DDC > > (via regulator framework). > > > > Signed-off-by: Ondrej Jirman > > The DDC bus itself is usually attached to the HDMI connector, so it > would make sense to make the supply also a property of the connector. I believe these are separate things. What this patch covers is power for a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's 5V supply to power the remote DDC chip is something else. And on the Orange Pi 3 they are indeed separate supplies. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller
On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard wrote: > > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote: > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote: > > > Hi, > > > > > > We've had for quite some time to hack around in our drivers to take into > > > account the fact that our DMA accesses are not done through the parent > > > node, but through another bus with a different mapping than the CPU for > > > the > > > RAM (0 instead of 0x4000 for most SoCs). > > > > > > After some discussion after the submission of a camera device suffering of > > > the same hacks, I've decided to put together a serie that introduce a > > > special interconnect name called "dma" that that allows to express the DMA > > > relationship between a master and its bus, even if they are not direct > > > parents in the DT. > > > > > > Let me know what you think, > > > Maxime > > > > LGTM. > > > > How do you propose merging this? I can take 1-5, and 6 and 7 thru > > arm-soc? > > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through > arm-soc Wouldn't there be some runtime dependency between 3, 4, and 5? ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller
On Mon, Apr 8, 2019 at 4:21 PM Maxime Ripard wrote: > > On Mon, Apr 08, 2019 at 04:14:53PM +0800, Chen-Yu Tsai wrote: > > On Mon, Apr 8, 2019 at 4:11 PM Maxime Ripard > > wrote: > > > > > > On Sat, Apr 06, 2019 at 01:06:07AM -0500, Rob Herring wrote: > > > > On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote: > > > > > Hi, > > > > > > > > > > We've had for quite some time to hack around in our drivers to take > > > > > into > > > > > account the fact that our DMA accesses are not done through the parent > > > > > node, but through another bus with a different mapping than the CPU > > > > > for the > > > > > RAM (0 instead of 0x4000 for most SoCs). > > > > > > > > > > After some discussion after the submission of a camera device > > > > > suffering of > > > > > the same hacks, I've decided to put together a serie that introduce a > > > > > special interconnect name called "dma" that that allows to express > > > > > the DMA > > > > > relationship between a master and its bus, even if they are not direct > > > > > parents in the DT. > > > > > > > > > > Let me know what you think, > > > > > Maxime > > > > > > > > LGTM. > > > > > > > > How do you propose merging this? I can take 1-5, and 6 and 7 thru > > > > arm-soc? > > > > > > You can merge 1-4, and I'll merge 5 through drm-misc and 6-7 through > > > arm-soc > > > > Wouldn't there be some runtime dependency between 3, 4, and 5? > > What issue did you have in mind? > > I guess the only issue would be if we have the new DT properties, but > not the new core code. But that seems pretty unlikely, since each of > the trees will work independently, and next should have all of them. I got it wrong. Even in your case since the interconnect property is ignored, and the driver would just fall back to using the fixed offset. Sorry for the noise. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 00/11] Add support for Orange Pi 3
On Thu, Apr 11, 2019 at 6:19 PM megous via linux-sunxi wrote: > > From: Ondrej Jirman > > This series implements support for Xunlong Orange Pi 3 board. > > Unfortunately, this board needs some small driver patches, so I have > split the boards DT patch into chunks that require patches for drivers > in various subsystems. > > Suggested merging plan/dependencies: > > - Pinctrl and stmmac patches are needed for ethernet support. > (patches 1-5) > - HDMI support was changed, please review. (patches 6-8) > - brcmfmac patch 9, fixing firmware file selection, can be merged > now, after review, as it doesn't depend on anything (please > review :)) > - mmc1 pinconf (patch 10) can probably be merged now, too (it will > certainly be used soon by all the other WiFi featuring boards > based on H6) > - WiFi dts patch will have to wait for H6 RTC patches, which in turn > depend on ChenYu's RTC series, to be merged. That will take a > while yet. I'm just keeping it in the series for completness. > (patch 11) Unfortunately I will not have time to tackle this for the next release. Furthermore, I'd like to do this after the new clk parenting stuff lands. Otherwise it's going to be a mess, as the clock tree is a bit convoluted compared to previous SoCs. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 3/3] drm/sun4i: Fix component unbinding and component master deletion
On Thu, Apr 18, 2019 at 6:27 AM Paul Kocialkowski
wrote:
>
> For our component-backed driver to be properly removed, we need to
> delete the component master in sun4i_drv_remove and make sure to call
> component_unbind_all in the master's unbind so that all components are
> unbound when the master is.
>
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index af07291544a4..0ea365e54de1 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -137,6 +137,8 @@ static void sun4i_drv_unbind(struct device *dev)
> drm_mode_config_cleanup(drm);
> of_reserved_mem_device_release(dev);
> drm_dev_put(drm);
> +
> + component_unbind_all(dev, NULL);
Shouldn't this be before drm_dev_put? Everything being in reverse order
of the complement calls in the bind function and all. The component
drivers might still be using the drm dev before they are unbound.
ChenYu
> }
>
> static const struct component_master_ops sun4i_drv_master_ops = {
> @@ -385,6 +387,8 @@ static int sun4i_drv_probe(struct platform_device *pdev)
>
> static int sun4i_drv_remove(struct platform_device *pdev)
> {
> + component_master_del(&pdev->dev, &sun4i_drv_master_ops);
> +
> return 0;
> }
>
> --
> 2.21.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind
On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
wrote:
>
> Our components may still be using the DRM device driver (if only to
> access our driver's private data), so make sure to unbind them before
> the final drm_dev_put.
>
> Also release our resserved memory adter unbind to match reverse
typos...
> creation order.
>
> Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component master
> deletion")
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 843b86661833..29258b404e54 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
> drm_kms_helper_poll_fini(drm);
> drm_atomic_helper_shutdown(drm);
> drm_mode_config_cleanup(drm);
> - of_reserved_mem_device_release(dev);
> - drm_dev_put(drm);
>
> component_unbind_all(dev, NULL);
> + of_reserved_mem_device_release(dev);
You should probably mention this change in the commit log as well.
Otherwise,
Reviewed-by: Chen-Yu Tsai
> +
> + drm_dev_put(drm);
> }
>
> static const struct component_master_ops sun4i_drv_master_ops = {
> --
> 2.21.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind
On Tue, Apr 23, 2019 at 10:06 AM Paul Kocialkowski
wrote:
>
> Hi,
>
> Le vendredi 19 avril 2019 à 19:10 +0200, Paul Kocialkowski a écrit :
> > Hi,
> >
> > On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> > > On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
> > > wrote:
> > > > Our components may still be using the DRM device driver (if only to
> > > > access our driver's private data), so make sure to unbind them before
> > > > the final drm_dev_put.
> > > >
> > > > Also release our resserved memory adter unbind to match reverse
> > >
> > > typos...
> >
> > I'll probably spin up a v2 to fix them, they annoy me as well.
> >
> > > > creation order.
> > > >
> > > > Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component
> > > > master deletion")
> > > > Signed-off-by: Paul Kocialkowski
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > index 843b86661833..29258b404e54 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > > > @@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
> > > > drm_kms_helper_poll_fini(drm);
> > > > drm_atomic_helper_shutdown(drm);
> > > > drm_mode_config_cleanup(drm);
> > > > - of_reserved_mem_device_release(dev);
> > > > - drm_dev_put(drm);
> > > >
> > > > component_unbind_all(dev, NULL);
> > > > + of_reserved_mem_device_release(dev);
> > >
> > > You should probably mention this change in the commit log as well.
> >
> > That's what I meant with the line that has typos. Maybe I should make
> > it slightly more explicit as:
> >
> > Also released our reserved memory after component unbind instead of
> > before to match reverse creation order.
> >
> > What do you think?
Forgot to reply ...
Looking again, the original already made sense. I'm not sure what I
was doing ...
> > > Otherwise,
> > >
> > > Reviewed-by: Chen-Yu Tsai
> >
> > Thanks for the review!
>
> Unless you have objections at this point, I'll send out the patch with
> your Reviewed-by soon to get the patch out ASAP.
Works for me. Thanks!
ChenYu
> Cheers,
>
> Paul
>
> > Cheers,
> >
> > Paul
> >
> > > > +
> > > > + drm_dev_put(drm);
> > > > }
> > > >
> > > > static const struct component_master_ops sun4i_drv_master_ops = {
> > > > --
> > > > 2.21.0
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups "linux-sunxi" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an email to linux-sunxi+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
On Tue, Jan 22, 2019 at 1:18 AM Jernej Škrabec wrote: > > Dne ponedeljek, 21. januar 2019 ob 16:07:28 CET je Priit Laes napisal(a): > > On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote: > > > On Fri, Jan 18, 2019 at 02:51:26PM +, Priit Laes wrote: > > > > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote: > > > > > On Fri, Jan 18, 2019 at 10:10:53AM +, Priit Laes wrote: > > > > > > > > > > > It doesn't look related to the clock rate itself, since it > > > > > > > > > > > doesn't > > > > > > > > > > > change between the two cases. However, in one case the DDC > > > > > > > > > > > clock is > > > > > > > > > > > enabled and in the other it's disabled. > > > > > > > > > > > > > > > > > > > > > > Was it taken at the same time? Maybe you can try with that > > > > > > > > > > > patch? > > > > > > > > > > > http://code.bulix.org/z7jmkm-555344?raw > > > > > > > > > > > > > > > > > > > > Thanks, after doing ~50+ boots I haven't seen a single > > > > > > > > > > failure. > > > > > > > > > > > > > > > > > > > > Previously I had following failure cases which are now both > > > > > > > > > > fixed: > > > > > > > > > > > > > > > > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots > > > > > > > > > > failed. > > > > > > > > > > b) u--boot with hdmi enabled switching to simplefb and then > > > > > > > > > > switching > > > > > > > > > > to kms, where previously all boots ended up with garbled > > > > > > > > > > screen. > > > > > > > > > > > > > > > > > > So it's not really a fix, but it really looks like the clock > > > > > > > > > is not > > > > > > > > > enabled when it should. > > > > > > > > > > > > > > > > > > Can you describe your test scenario a bit more? What are you > > > > > > > > > doing > > > > > > > > > exactly, just booting? When do you start using the display? > > > > > > > > > When did > > > > > > > > > you capture the debugfs output that you pasted? > > > > > > > > > > > > > > > > Display is already connected via HDMI to the board. I don't > > > > > > > > really > > > > > > > > remove it, I just boot the device and let it start Xorg. > > > > > > > > Meanwhile I just ssh into the device and capture debugfs output. > > > > > > > > See my 3 testing scenarios below. > > > > > > > > > > > > > > > > Kernel also includes one extra patch to fall back to DDC, in > > > > > > > > case HPD > > > > > > > > fails. Mostly the same I already submitted last November [1]. > > > > > > > > > > > > > > Do you have the same issue without that patch? > > > > > > > > > > > > Can't really test this display without this patch and I do not have > > > > > > other > > > > > > HDMI/DVI screens. And this issue does not happen with other HDMI > > > > > > displays > > > > > > that I have here. > > > > > > > > > > Can't you just force the monitor to be reported as present? It's not > > > > > great and we don't want to merge it, but that would allow you to test > > > > > that setup without too many interferences. > > > > > > > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > > > > > > > 1) Booting Linux with drm.debug=0xe > > > > > > > > * Linux does not detect/enable display > > > > > > > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > > > > > * Linux detects display, but display is garbled, and proper edid data is > > > > detected: > > > > > > > > [snip] > > > > pll-video1 000 32700 > > > > 0 0 5> > > > > >pll-video1-2x 000 65400 > > > >0 0 5> > > > > > hdmi-tmds00025153846 > > > > 0 0 5> > > > > > hdmi-ddc 000 89835 > > > > 0 0 5> > > > > > [/snip] > > > > > > > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > And also one extra patch for Linux where HDMI DDC clock marked as > > > > critical > > > > > > > > Linux detects and initializes display properly: > > > > [snip] > > > > pll-video1 110 32700 > > > > 0 0 5> > > > > >pll-video1-2x 110 65400 > > > >0 0 5> > > > > > hdmi-tmds11025153846 > > > > 0 0 5> > > > > > hdmi-ddc 110 89835 > > > > 0 0 5> > > > > > [/snip] > > > > > > I guess you'll need to track down when the hdmi-tmds and hdmi-ddc are > > > enabled and disabled, and if it makes sense :/ > > > > OK, figured out the cause. > > > > Apparently, for each ddc poll we enable ddc clock which is a child of TMDS > > clock. After transfer is done, we disable the clock and this also tears down > > the parent because its only user has gone missing.. :( > > > > > > So basically, patch below also works, but I guess we should override > > the sun4i_tmds_ops.disable to properly account for
[PATCH 01/11] clk: sunxi-ng: sun8i-a23: Enable PLL-MIPI LDOs when ungating it
The PLL-MIPI clock is somewhat special as it has its own LDOs which
need to be turned on for this PLL to actually work and output a clock
signal.
Add the 2 LDO enable bits to the gate bits.
Fixes: 5690879d93e8 ("clk: sunxi-ng: Add A23 CCU")
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index a4fa2945f230..4b5f8f4e4ab8 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -144,7 +144,7 @@ static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_mipi_clk,
"pll-mipi",
8, 4, /* N */
4, 2, /* K */
0, 4, /* M */
- BIT(31),/* gate */
+ BIT(31) | BIT(23) | BIT(22), /* gate */
BIT(28),/* lock */
CLK_SET_RATE_UNGATE);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] dt-bindings: display: sun4i-drm: Add compatible strings for A23 display
The A23's display pipeline is similar to the A33. Differences include: - Display backend supports larger layers, 8192x8192 instead of 2048x2048 - TCON has DMA input - There is no SAT module packed in the display backend Add compatible strings for the display pipeline and its components. As the MIPI DSI output device is not officially documented, and there are no A23 reference devices to test it, it is not covered by this patch. Signed-off-by: Chen-Yu Tsai --- .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index f426bdb42f18..31ab72cba3d4 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -156,6 +156,7 @@ Required properties: * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon * allwinner,sun7i-a20-tcon + * allwinner,sun8i-a23-tcon * allwinner,sun8i-a33-tcon * allwinner,sun8i-a83t-tcon-lcd * allwinner,sun8i-a83t-tcon-tv @@ -276,6 +277,7 @@ Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-drc * allwinner,sun6i-a31s-drc +* allwinner,sun8i-a23-drc * allwinner,sun8i-a33-drc * allwinner,sun9i-a80-drc - reg: base address and size of the memory-mapped region. @@ -303,6 +305,7 @@ Required properties: * allwinner,sun5i-a13-display-backend * allwinner,sun6i-a31-display-backend * allwinner,sun7i-a20-display-backend +* allwinner,sun8i-a23-display-backend * allwinner,sun8i-a33-display-backend * allwinner,sun9i-a80-display-backend - reg: base address and size of the memory-mapped region. @@ -360,6 +363,7 @@ Required properties: * allwinner,sun5i-a13-display-frontend * allwinner,sun6i-a31-display-frontend * allwinner,sun7i-a20-display-frontend +* allwinner,sun8i-a23-display-frontend * allwinner,sun8i-a33-display-frontend * allwinner,sun9i-a80-display-frontend - reg: base address and size of the memory-mapped region. @@ -419,6 +423,7 @@ Required properties: * allwinner,sun6i-a31-display-engine * allwinner,sun6i-a31s-display-engine * allwinner,sun7i-a20-display-engine +* allwinner,sun8i-a23-display-engine * allwinner,sun8i-a33-display-engine * allwinner,sun8i-a83t-display-engine * allwinner,sun8i-h3-display-engine -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] ARM: dts: sun8i-a23: Add compatible strings to display pipeline device nodes
Now that the compatible strings for the display pipeline on the A23 have
been added to the bindings, add the corresponding compatibles to the
device nodes already in the A23/A33 shared dtsi.
While the A23 has the TCON ch1 clock defined in the CCU, and the channel
1 registers are available, it does not have any means to use channel 1
due to a lack of downstream encoders, and the enable bit for channel 1 is
hard-wired to 0 (off). Hence the ch1 clock is left out.
As the MIPI DSI output device is not officially documented, and there
are no reference devices to test it, it is not covered by this patch.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a23.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index d00055e9eef5..a5e884a8b2ae 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -62,10 +62,26 @@
};
};
+&be0 {
+ compatible = "allwinner,sun8i-a23-display-backend";
+};
+
&ccu {
compatible = "allwinner,sun8i-a23-ccu";
};
+&de {
+ compatible = "allwinner,sun8i-a23-display-engine";
+};
+
+&drc0 {
+ compatible = "allwinner,sun8i-a23-drc";
+};
+
+&fe0 {
+ compatible = "allwinner,sun8i-a23-display-frontend";
+};
+
&pio {
compatible = "allwinner,sun8i-a23-pinctrl";
interrupts = ,
@@ -73,6 +89,10 @@
;
};
+&tcon0 {
+ compatible = "allwinner,sun8i-a23-tcon";
+};
+
&usb_otg {
compatible = "allwinner,sun6i-a31-musb";
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/11] drm/sun4i: Add support for A23 display pipeline
The A23's display pipeline is similar to the A33. Differences include:
- Display backend supports larger layers, 8192x8192 instead of 2048x2048
- TCON has DMA input
- There is no SAT module packed in the display backend
Add support for the display pipeline and its components.
As the MIPI DSI output device is not officially documented, and there
are no A23 reference devices to test it, it is not covered by this
patch.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_frontend.c | 4
drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
drivers/gpu/drm/sun4i/sun6i_drc.c | 1 +
5 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 85e64d02fb5f..2ada915a877e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -1012,6 +1012,10 @@ static const struct of_device_id
sun4i_backend_of_table[] = {
.compatible = "allwinner,sun7i-a20-display-backend",
.data = &sun7i_backend_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-a23-display-backend",
+ .data = &sun8i_a33_backend_quirks,
+ },
{
.compatible = "allwinner,sun8i-a33-display-backend",
.data = &sun8i_a33_backend_quirks,
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 93da837194cf..477957a865fb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -165,6 +165,7 @@ static bool sun4i_drv_node_is_frontend(struct device_node
*node)
of_device_is_compatible(node,
"allwinner,sun5i-a13-display-frontend") ||
of_device_is_compatible(node,
"allwinner,sun6i-a31-display-frontend") ||
of_device_is_compatible(node,
"allwinner,sun7i-a20-display-frontend") ||
+ of_device_is_compatible(node,
"allwinner,sun8i-a23-display-frontend") ||
of_device_is_compatible(node,
"allwinner,sun8i-a33-display-frontend") ||
of_device_is_compatible(node,
"allwinner,sun9i-a80-display-frontend");
}
@@ -404,6 +405,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-display-engine" },
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun7i-a20-display-engine" },
+ { .compatible = "allwinner,sun8i-a23-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
{ .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-h3-display-engine" },
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index e8239d4d4dd5..346c8071bd38 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -719,6 +719,10 @@ const struct of_device_id sun4i_frontend_of_table[] = {
.compatible = "allwinner,sun7i-a20-display-frontend",
.data = &sun4i_a10_frontend
},
+ {
+ .compatible = "allwinner,sun8i-a23-display-frontend",
+ .data = &sun8i_a33_frontend
+ },
{
.compatible = "allwinner,sun8i-a33-display-frontend",
.data = &sun8i_a33_frontend
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0420f5c978b9..565955a46b0b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1494,6 +1494,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks },
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks
},
{ .compatible = "allwinner,sun7i-a20-tcon", .data = &sun7i_a20_quirks },
+ { .compatible = "allwinner,sun8i-a23-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
&sun8i_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-tv", .data =
&sun8i_a83t_tv_quirks },
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c
b/drivers/gpu/drm/sun4i/sun6i_drc.c
index 88eb268fdf73..442094a4af7a 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -101,6 +101,7 @@ static int sun6i_drc_remove(struct platform_device *pdev)
static const struct of_device
[PATCH 04/11] drm/sun4i: layer: Assign backend pointer before calling DRM helpers
We might want to use the backend pointer from DRM callbacks that get called within drm_universal_plane_init(), such as the .format_mod_supported callback. Move the assignment of the layer's backend pointer to right after the structure is allocated. Signed-off-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_layer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c index c5a999ca1d72..95d4aaa51a5c 100644 --- a/drivers/gpu/drm/sun4i/sun4i_layer.c +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c @@ -182,6 +182,8 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm, if (!layer) return ERR_PTR(-ENOMEM); + layer->backend = backend; + /* possible crtcs are set later */ ret = drm_universal_plane_init(drm, &layer->plane, 0, &sun4i_backend_layer_funcs, @@ -195,7 +197,6 @@ static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm, drm_plane_helper_add(&layer->plane, &sun4i_backend_layer_helper_funcs); - layer->backend = backend; drm_plane_create_alpha_property(&layer->plane); drm_plane_create_zpos_property(&layer->plane, 0, 0, -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/sun4i: backend: Remove BGRX8888 from list of supported formats
The display backend does not support BGRX. There is also no trace
of this in the original list of supported formats before the commit
b636d3f97d04 ("drm/sun4i: frontend: Add support for the BGRX input
format"). Nor do the backend configuration helpers handle this format.
Remove BGRX from list of supported formats by the backend.
Fixes: 3d4265f89d06 ("drm/sun4i: backend: Add a helper and a list for supported
formats")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index c17ec850b614..85e64d02fb5f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -141,7 +141,6 @@ static const uint32_t sun4i_backend_formats[] = {
DRM_FORMAT_ARGB1555,
DRM_FORMAT_ARGB,
DRM_FORMAT_ARGB,
- DRM_FORMAT_BGRX,
DRM_FORMAT_RGB565,
DRM_FORMAT_RGB888,
DRM_FORMAT_RGBA,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] ARM: dts: sun8i-q8-common: Enable display pipeline with RGB LCD panel
The Q8 design for A23/A33 tablets have an 18-bit RGB LCD panel connected
to the LCD interface on the SoC, the DC1SW output on the PMIC providing
power for the LCD, and PH7 toggling the reset pin for the panel.
This patch adds a device node for the panel, describing the above, and
enables the display pipeline.
The actual model or compatible string for the panel should be added in
the tablet device tree file.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-q8-common.dtsi | 37 ++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi
b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 719ad769b837..53104f4ccacc 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -49,6 +49,26 @@
ethernet0 = &sdio_wifi;
};
+ panel: panel {
+ /* Tablet dts should provide panel compatible */
+ backlight = <&backlight>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ power-supply = <®_dc1sw>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
/*
@@ -64,6 +84,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -90,6 +114,19 @@
};
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
&usbphy {
usb1_vbus-supply = <®_dldo1>;
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] ARM: dts: sun8i-a23-q8: Set compatible string for LCD panel
The Q8 tablets follow the A23/A33 tablet reference design, and normally
use a "generic" 800x480 LCD panel. The actual panel may vary between
production runs, and there are no visible markings denoting its model.
This patch uses a panel that has the same dimensions and timings that
are close to what was provided in the vendor fex files.
Since there are also A33 Q8 tablets with 1024x600 panels, this patch
only sets the compatible string for A23 Q8 tablets.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
index b6958e8f2f01..d4dab7c28398 100644
--- a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
+++ b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
@@ -61,3 +61,7 @@
"Headset Mic", "HBIAS";
status = "okay";
};
+
+&panel {
+ compatible = "bananapi,s070wv20-ct16", "simple-panel";
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/11] ARM: dts: sun8i-a33: Move display pipeline nodes to a23/a33 common dtsi
The display pipeline has the same structure, resources and connections
on both the A23 and A33. The differences include:
- compatible strings
- extra clock, reset control, and IO region for SAT in the backend
only found on the A33
- missing ch1 clock for the TCON
However, while the A23 has the TCON ch1 clock defined in the CCU, and
the channel 1 registers are available, it does not have any means to
use channel 1 due to a lack of downstream encoders, and the enable bit
for channel 1 is hard-wired to 0 (off).
As the MIPI DSI output device is not officially documented, and there
are no A23 reference devices to test it, it is not covered by this
patch.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 147
arch/arm/boot/dts/sun8i-a33.dtsi | 194 ++-
2 files changed, 185 insertions(+), 156 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 97ec8b8cec09..43fe215e83ea 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -68,6 +68,12 @@
};
};
+ de: display-engine {
+ /* compatible gets set in SoC specific dtsi file */
+ allwinner,pipelines = <&fe0>;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -168,6 +174,42 @@
#size-cells = <0>;
};
+ tcon0: lcd-controller@1c0c000 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_LCD>,
+<&ccu CLK_LCD_CH0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_LCD>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_drc0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&drc0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -570,6 +612,111 @@
interrupts = ;
};
+ fe0: display-frontend@1e0 {
+ /* compatible gets set in SoC specific dtsi file */
+ reg = <0x01e0 0x2>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_DE_FE>, <&ccu CLK_DE_FE>,
+<&ccu CLK_DRAM_DE_FE>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_BUS_DE_FE>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ fe0_out_be0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&be0_in_fe0>;
+ };
+ };
+ };
+ };
+
+ be0: display-backend@1e6 {
+ /* compatible gets set in SoC specific dts
[PATCH 00/11] ARM: sun8i: a23: Enable display pipeline
Hi everyone, This series enables the display pipeline on the Allwinner A23 SoC. A few fixes are included for corner cases when the frontend isn't enabled. The A23 display pipeline is very much the same as the A33, except that the A23 does not have the SAT IP block embedded within the display backend. MIPI DSI is not covered as I do not have a device that uses it. Patch 1 fixes the pll-mipi clock on the A23. Patch 2 adds compatible strings for the various hardware blocks of the A23 display pipeline. Patch 3 through 5 fix some issues in our DRM plane support, namely declaring support for formats when we shouldn't. Patch 6 adds support for the A23 display pipeline to the driver. Patch 7 is a small cleanup before moving the display pipeline device nodes. Patch 8 moves the display nodes from the A33-specific dtsi file to the A23-A33 shared dtsi file. Note that the MIPI DSI device nodes are not moved. Patch 9 adds compatible strings to the display nodes in the A23-specific dtsi file. Patch 10 enables the display pipeline for the shared A23/A33 Q8 tablet dtsi file. The compatible string should be filled in by the tablet dts files. Patch 11 fills in the compatible string for the standard A23 Q8 tablet. Note the compatible string is not for the specific model used in the tablet, as it varies between production runs. Rather it is just one that works. Please have a look. Patch 3 might be worth applying as a fix, but might not be worth the trouble. It could just as easily be applied for -next and then backported. Also, the fixes tags are no longer line wrapped, unlike patches I've sent in the past. Regards ChenYu Chen-Yu Tsai (11): clk: sunxi-ng: sun8i-a23: Enable PLL-MIPI LDOs when ungating it dt-bindings: display: sun4i-drm: Add compatible strings for A23 display drm/sun4i: backend: Remove BGRX from list of supported formats drm/sun4i: layer: Assign backend pointer before calling DRM helpers drm/sun4i: layer: support just backend formats when frontend is unavailable drm/sun4i: Add support for A23 display pipeline ARM: dts: sun8i-a23-a33: Move NAND controller device node to sort by address ARM: dts: sun8i-a33: Move display pipeline nodes to a23/a33 common dtsi ARM: dts: sun8i-a23: Add compatible strings to display pipeline device nodes ARM: dts: sun8i-q8-common: Enable display pipeline with RGB LCD panel ARM: dts: sun8i-a23-q8: Set compatible string for LCD panel .../bindings/display/sunxi/sun4i-drm.txt | 5 + arch/arm/boot/dts/sun8i-a23-a33.dtsi | 175 ++-- arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 4 + arch/arm/boot/dts/sun8i-a23.dtsi | 20 ++ arch/arm/boot/dts/sun8i-a33.dtsi | 194 -- arch/arm/boot/dts/sun8i-q8-common.dtsi| 37 drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 2 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 + drivers/gpu/drm/sun4i/sun4i_frontend.c| 4 + drivers/gpu/drm/sun4i/sun4i_layer.c | 37 +++- drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + drivers/gpu/drm/sun4i/sun6i_drc.c | 1 + 13 files changed, 310 insertions(+), 177 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/11] drm/sun4i: layer: support just backend formats when frontend is unavailable
In some cases, such as running a new kernel with an old device tree that
has the frontend disabled, the backend's matching frontend might be
unavailable.
When this happens, the layers should only declare support for formats
that the backend support. This partially reverts commit 1c29d263f624
("drm/sun4i: Rename sun4i_backend_layer_formats to sun4i_layer_formats")
by bringing back sun4i_backend_layer_formats, and passing it to
drm_universal_plane_init, while also dropping the modifiers list,
in the event no frontend is available.
Fixes: b636d3f97d04 ("drm/sun4i: frontend: Add support for the BGRX input
format")
Fixes: 9afe52d54bb0 ("drm/sun4i: frontend: Add support for semi-planar YUV
input formats")
Fixes: 8c8152bf4db6 ("drm/sun4i: frontend: Add support for planar YUV input
formats")
Fixes: b2ddf277ab5e ("drm/sun4i: layer: Add tiled modifier support and helper")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 34 ++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 95d4aaa51a5c..a514fe88d441 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -117,6 +117,11 @@ static void sun4i_backend_layer_atomic_update(struct
drm_plane *plane,
static bool sun4i_layer_format_mod_supported(struct drm_plane *plane,
uint32_t format, uint64_t modifier)
{
+ struct sun4i_layer *layer = plane_to_sun4i_layer(plane);
+
+ if (IS_ERR_OR_NULL(layer->backend->frontend))
+ sun4i_backend_format_is_supported(format, modifier);
+
return sun4i_backend_format_is_supported(format, modifier) ||
sun4i_frontend_format_is_supported(format, modifier);
}
@@ -165,6 +170,21 @@ static const uint32_t sun4i_layer_formats[] = {
DRM_FORMAT_YVYU,
};
+static const uint32_t sun4i_backend_layer_formats[] = {
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_RGBA,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+};
+
static const uint64_t sun4i_layer_modifiers[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_ALLWINNER_TILED,
@@ -175,6 +195,9 @@ static struct sun4i_layer *sun4i_layer_init_one(struct
drm_device *drm,
struct sun4i_backend *backend,
enum drm_plane_type type)
{
+ const uint64_t *modifiers = sun4i_layer_modifiers;
+ const uint32_t *formats = sun4i_layer_formats;
+ unsigned int formats_len = ARRAY_SIZE(sun4i_layer_formats);
struct sun4i_layer *layer;
int ret;
@@ -184,12 +207,17 @@ static struct sun4i_layer *sun4i_layer_init_one(struct
drm_device *drm,
layer->backend = backend;
+ if (IS_ERR_OR_NULL(backend->frontend)) {
+ formats = sun4i_backend_layer_formats;
+ formats_len = ARRAY_SIZE(sun4i_backend_layer_formats);
+ modifiers = NULL;
+ }
+
/* possible crtcs are set later */
ret = drm_universal_plane_init(drm, &layer->plane, 0,
&sun4i_backend_layer_funcs,
- sun4i_layer_formats,
- ARRAY_SIZE(sun4i_layer_formats),
- sun4i_layer_modifiers, type, NULL);
+ formats, formats_len,
+ modifiers, type, NULL);
if (ret) {
dev_err(drm->dev, "Couldn't initialize layer\n");
return ERR_PTR(ret);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] ARM: dts: sun8i-a23-a33: Move NAND controller device node to sort by address
The NAND controller device node was inserted into the wrong position,
probably due to a rebase or merge, as the file's structure does not
provide enough context for git to accurately match the previous device
node block.
Fixes: d7b843df13ea ("ARM: dts: sun8i: add NAND controller node for A23/A33")
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index a9c123de5d2c..97ec8b8cec09 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -155,6 +155,19 @@
#dma-cells = <1>;
};
+ nfc: nand@1c03000 {
+ compatible = "allwinner,sun4i-a10-nand";
+ reg = <0x01c03000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_NAND>, <&ccu CLK_NAND>;
+ clock-names = "ahb", "mod";
+ resets = <&ccu RST_BUS_NAND>;
+ reset-names = "ahb";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -214,21 +227,6 @@
#size-cells = <0>;
};
- nfc: nand@1c03000 {
- compatible = "allwinner,sun4i-a10-nand";
- reg = <0x01c03000 0x1000>;
- interrupts = ;
- clocks = <&ccu CLK_BUS_NAND>, <&ccu CLK_NAND>;
- clock-names = "ahb", "mod";
- resets = <&ccu RST_BUS_NAND>;
- reset-names = "ahb";
- pinctrl-names = "default";
- pinctrl-0 = <&nand_pins &nand_pins_cs0 &nand_pins_rb0>;
- status = "disabled";
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
usb_otg: usb@1c19000 {
/* compatible gets set in SoC specific dtsi file */
reg = <0x01c19000 0x0400>;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state
gpiod_get_value() gives out a warning if access to the underlying gpiochip
requires sleeping, which is common for I2C based chips:
WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500
gpiod_get_value+0xd0/0x100
Modules linked in:
CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted
4.14.0-rc3-00589-gf32897915d48-dirty #90
Hardware name: Allwinner sun4i/sun5i Families
Workqueue: events deferred_probe_work_func
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x88/0x9c)
[] (dump_stack) from [] (__warn+0xe8/0x100)
[] (__warn) from [] (warn_slowpath_null+0x20/0x28)
[] (warn_slowpath_null) from []
(gpiod_get_value+0xd0/0x100)
[] (gpiod_get_value) from []
(pwm_backlight_probe+0x238/0x508)
[] (pwm_backlight_probe) from []
(platform_drv_probe+0x50/0xac)
[] (platform_drv_probe) from []
(driver_probe_device+0x238/0x2e8)
[] (driver_probe_device) from []
(bus_for_each_drv+0x44/0x94)
[] (bus_for_each_drv) from []
(__device_attach+0xb0/0x114)
[] (__device_attach) from []
(bus_probe_device+0x84/0x8c)
[] (bus_probe_device) from []
(deferred_probe_work_func+0x50/0x14c)
[] (deferred_probe_work_func) from []
(process_one_work+0x1ec/0x414)
[] (process_one_work) from []
(worker_thread+0x2b0/0x5a0)
[] (worker_thread) from [] (kthread+0x14c/0x154)
[] (kthread) from [] (ret_from_fork+0x14/0x24)
This was missed in commit 0c9501f823a4 ("backlight: pwm_bl: Handle gpio
that can sleep"). The code was then moved to a separate function in
commit 7613c922315e ("backlight: pwm_bl: Move the checks for initial power
state to a separate function").
The only usage of gpiod_get_value() is during the probe stage, which is
safe to sleep in. Switch to gpiod_get_value_cansleep().
Fixes: 0c9501f823a4 ("backlight: pwm_bl: Handle gpio that can sleep")
Signed-off-by: Chen-Yu Tsai
---
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index feb90764a811..53b8ceea9bde 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -435,7 +435,7 @@ static int pwm_backlight_initial_power_state(const struct
pwm_bl_data *pb)
*/
/* if the enable GPIO is disabled, do not enable the backlight */
- if (pb->enable_gpio && gpiod_get_value(pb->enable_gpio) == 0)
+ if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0)
return FB_BLANK_POWERDOWN;
/* The regulator is disabled, do not enable the backlight */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/sun4i: dsi: Change the start delay calculation
On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
wrote:
>
> The current calculation for the video start delay in the current DSI driver
> is that it is the total vertical size, minus the backporch and sync length,
> plus 1.
>
> However, the Allwinner code has it as the active vertical size, plus the
> back porch and the sync length. This doesn't make any difference on the
> only panel it has been tested with so far, since in that particular case
> the front porch is equal to the sum of the back porch and sync length.
>
> This is not the case for all panels, obviously, so we need to fix it. Since
> the Allwinner code has a bunch of extra code to deal with out of bounds
> values, so let's add them as well.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 380fc527a707..e3e4ba90c059 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -357,7 +357,12 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
>struct drm_display_mode *mode)
> {
> - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
According to the diagram in include/drm/drm_modes.h ,
This is active region plus back porch plus 1, as
sync_end - display = length of front porch and sync
> + u16 delay = (mode->vsync_end + 1) % mode->vtotal;
And this actually means
(length of active region and front porch and sync pulse plus 1) %
total length
So I don't really understand what's happening here. And the modulus
is unexplained.
> +
> + if (!delay)
> + delay = 1;
Same comment as Paul.
ChenYu
> +
> + return delay;
> }
>
> static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
> --
> git-series 0.9.1
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/sun4i: dsi: Change the start delay calculation
On Wed, Jan 30, 2019 at 11:23 AM Chen-Yu Tsai wrote:
>
> On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
> wrote:
> >
> > The current calculation for the video start delay in the current DSI driver
> > is that it is the total vertical size, minus the backporch and sync length,
> > plus 1.
> >
> > However, the Allwinner code has it as the active vertical size, plus the
> > back porch and the sync length. This doesn't make any difference on the
> > only panel it has been tested with so far, since in that particular case
> > the front porch is equal to the sum of the back porch and sync length.
> >
> > This is not the case for all panels, obviously, so we need to fix it. Since
> > the Allwinner code has a bunch of extra code to deal with out of bounds
> > values, so let's add them as well.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 380fc527a707..e3e4ba90c059 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -357,7 +357,12 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> > static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> >struct drm_display_mode *mode)
> > {
> > - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
>
> According to the diagram in include/drm/drm_modes.h ,
> This is active region plus back porch plus 1, as
>
> sync_end - display = length of front porch and sync
>
> > + u16 delay = (mode->vsync_end + 1) % mode->vtotal;
>
> And this actually means
>
> (length of active region and front porch and sync pulse plus 1) %
> total length
>
> So I don't really understand what's happening here. And the modulus
> is unexplained.
Attempting to make sense of this. Allwinner's A64 BSP the following
which uses their definitions for y, vbp, vt:
s32 start_delay = panel->lcd_vt - panel->lcd_y -10;
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
u32 dsi_start_delay;
/* put start_delay to tcon. set ready sync early to dramfreq, so
set start_delay 1 */
start_delay = 1;
dsi_start_delay = panel->lcd_vt - vfp + start_delay;
if (dsi_start_delay > panel->lcd_vt)
dsi_start_delay -= panel->lcd_vt;
if (dsi_start_delay==0)
dsi_start_delay = 1;
This can be converted to
dsi_start_delay = max(1, (mode->vtotal - (mode->vtotal -
mode->vdisplay - (mode->vtotal - mode->vsync_start)) + 1) %
mode->vtotal)
and simplified to
dsi_start_delay = max(1, (mode->vtotal + mode->vdisplay -
mode->vsync_start) + 1) % mode->vtotal)
and reordered to the following
dsi_start_delay = max(1, (mode->vtotal - (mode->vsync_start -
mode->vdisplay) + 1) % mode->vtotal)
which means total length minus front porch, or length of active
portion plus back porch plus sync.
Based on your commit message, the last derivation is what you want.
ChenYu
> > +
> > + if (!delay)
> > + delay = 1;
>
> Same comment as Paul.
>
> ChenYu
>
> > +
> > + return delay;
> > }
> >
> > static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
> > --
> > git-series 0.9.1
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/sun4i: dsi: Add burst support
On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
wrote:
>
> From: Konstantin Sudakov
>
> The current driver doesn't support the DSI burst operation mode.
>
> Let's add the needed quirks to make it work.
>
> Signed-off-by: Konstantin Sudakov
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 178 +++---
> 1 file changed, 136 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index e3e4ba90c059..6840b3512a45 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -23,7 +23,9 @@
> #include
> #include
>
> +#include "sun4i_crtc.h"
> #include "sun4i_drv.h"
> +#include "sun4i_tcon.h"
> #include "sun6i_mipi_dsi.h"
>
> #include
> @@ -32,6 +34,8 @@
> #define SUN6I_DSI_CTL_EN BIT(0)
>
> #define SUN6I_DSI_BASIC_CTL_REG0x00c
> +#define SUN6I_DSI_BASIC_CTL_TRAIL_INV(n) (((n) & 0xf) << 4)
> +#define SUN6I_DSI_BASIC_CTL_TRAIL_FILL BIT(3)
> #define SUN6I_DSI_BASIC_CTL_HBP_DISBIT(2)
> #define SUN6I_DSI_BASIC_CTL_HSA_HSE_DISBIT(1)
> #define SUN6I_DSI_BASIC_CTL_VIDEO_BURSTBIT(0)
> @@ -152,6 +156,8 @@
>
> #define SUN6I_DSI_CMD_TX_REG(n)(0x300 + (n) * 0x04)
>
> +#define SUN6I_DSI_SYNC_POINT 40
> +
> enum sun6i_dsi_start_inst {
> DSI_START_LPRX,
> DSI_START_LPTX,
> @@ -365,31 +371,101 @@ static u16 sun6i_dsi_get_video_start_delay(struct
> sun6i_dsi *dsi,
> return delay;
> }
>
> +static u16 sun6i_dsi_get_line_num(struct sun6i_dsi *dsi,
> + struct drm_display_mode *mode)
> +{
> + struct mipi_dsi_device *device = dsi->device;
> + unsigned Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
> +
> + return mode->htotal * Bpp / device->lanes;
> +}
> +
> +static u16 sun6i_dsi_get_drq_edge0(struct sun6i_dsi *dsi,
> + struct drm_display_mode *mode,
> + u16 line_num, u16 edge1)
> +{
> + u16 edge0 = edge1;
> +
> + edge0 += (mode->hdisplay + 40) * SUN6I_DSI_TCON_DIV / 8;
> +
> + if (edge0 > line_num)
> + return edge0 - line_num;
> +
> + return 1;
> +}
> +
> +static u16 sun6i_dsi_get_drq_edge1(struct sun6i_dsi *dsi,
> + struct drm_display_mode *mode,
> + u16 line_num)
> +{
> + struct mipi_dsi_device *device = dsi->device;
> + unsigned Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
> + unsigned hbp = mode->htotal - mode->hsync_end;
Allwinner's hbp is actually horizontal back porch plus sync pulse.
So this should be
hbp = mode->htotal - mode->hsync_start;
> + u16 edge1;
> +
> +
> + edge1 = SUN6I_DSI_SYNC_POINT;
> + edge1 += mode->hdisplay + hbp + 20;
> + edge1 = edge1 * Bpp / device->lanes;
Compared to the A64 BSP, this seems to be incorrect. The original code was
edge1 = sync_point +
(panel->lcd_x + panel->lcd_hbp + 20) *
dsi_pixel_bits[panel->lcd_dsi_format] /
(8 * panel->lcd_dsi_lane);
Note that sync_point is outside of the parentheses and should not be
multiplied and divided.
This would make sense if sync_point is a fixed delay that is needed
regardless of the timings.
> +
> + if (edge1 > line_num)
> + return line_num;
> +
> + return edge1;
> +}
> +
> static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
> struct drm_display_mode *mode)
> {
> struct mipi_dsi_device *device = dsi->device;
> - u32 val = 0;
> + u32 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> + u32 tcon0_drq = 0;
> +
> + if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> + u16 line_num = sun6i_dsi_get_line_num(dsi, mode);
> + u16 edge0, edge1;
> +
> + edge1 = sun6i_dsi_get_drq_edge1(dsi, mode, line_num);
> + edge0 = sun6i_dsi_get_drq_edge0(dsi, mode, line_num, edge1);
>
> - if ((mode->hsync_end - mode->hdisplay) > 20) {
> + regmap_write(dsi->regs, SUN6I_DSI_BURST_DRQ_REG,
> +SUN6I_DSI_BURST_DRQ_EDGE0(edge0) |
> +SUN6I_DSI_BURST_DRQ_EDGE1(edge1));
> +
> + regmap_write(dsi->regs, SUN6I_DSI_BURST_LINE_REG,
> +SUN6I_DSI_BURST_LINE_NUM(line_num) |
> +
> SUN6I_DSI_BURST_LINE_SYNC_POINT(SUN6I_DSI_SYNC_POINT));
> +
> + tcon0_drq = SUN6I_DSI_TCON_DRQ_ENABLE_MODE;
> + } else if ((mode->hsync_end - mode->hdisplay) > 20) {
> /* Maagic */
> u16 drq = (mode->hsync_end - mode->hdisplay) - 20;
This and the above if clause should use hsync_start ins
Re: [PATCH 2/4] drm/sun4i: dsi: Change the start delay calculation
On Wed, Feb 6, 2019 at 10:12 PM Maxime Ripard wrote:
>
> Hi Chen-Yu,
>
> On Wed, Feb 06, 2019 at 12:48:21AM +0800, Chen-Yu Tsai wrote:
> > On Wed, Jan 30, 2019 at 11:23 AM Chen-Yu Tsai wrote:
> > >
> > > On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
> > > wrote:
> > > >
> > > > The current calculation for the video start delay in the current DSI
> > > > driver
> > > > is that it is the total vertical size, minus the backporch and sync
> > > > length,
> > > > plus 1.
> > > >
> > > > However, the Allwinner code has it as the active vertical size, plus the
> > > > back porch and the sync length. This doesn't make any difference on the
> > > > only panel it has been tested with so far, since in that particular case
> > > > the front porch is equal to the sum of the back porch and sync length.
> > > >
> > > > This is not the case for all panels, obviously, so we need to fix it.
> > > > Since
> > > > the Allwinner code has a bunch of extra code to deal with out of bounds
> > > > values, so let's add them as well.
> > > >
> > > > Signed-off-by: Maxime Ripard
> > > > ---
> > > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > index 380fc527a707..e3e4ba90c059 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > > @@ -357,7 +357,12 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi
> > > > *dsi,
> > > > static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> > > >struct drm_display_mode
> > > > *mode)
> > > > {
> > > > - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
> > >
> > > According to the diagram in include/drm/drm_modes.h ,
> > > This is active region plus back porch plus 1, as
> > >
> > > sync_end - display = length of front porch and sync
> > >
> > > > + u16 delay = (mode->vsync_end + 1) % mode->vtotal;
> > >
> > > And this actually means
> > >
> > > (length of active region and front porch and sync pulse plus 1) %
> > > total length
> > >
> > > So I don't really understand what's happening here. And the modulus
> > > is unexplained.
> >
> > Attempting to make sense of this.
>
> Sorry for dragging you into this
>
> > Allwinner's A64 BSP the following which uses their definitions for
> > y, vbp, vt:
> >
> > s32 start_delay = panel->lcd_vt - panel->lcd_y -10;
> > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
> > u32 dsi_start_delay;
> >
> > /* put start_delay to tcon. set ready sync early to dramfreq, so
> > set start_delay 1 */
> > start_delay = 1;
> >
> > dsi_start_delay = panel->lcd_vt - vfp + start_delay;
> > if (dsi_start_delay > panel->lcd_vt)
> >dsi_start_delay -= panel->lcd_vt;
> > if (dsi_start_delay==0)
> >dsi_start_delay = 1;
> >
> > This can be converted to
> >
> > dsi_start_delay = max(1, (mode->vtotal - (mode->vtotal -
> > mode->vdisplay - (mode->vtotal - mode->vsync_start)) + 1) %
> > mode->vtotal)
> >
> > and simplified to
> >
> > dsi_start_delay = max(1, (mode->vtotal + mode->vdisplay -
> > mode->vsync_start) + 1) % mode->vtotal)
> >
> > and reordered to the following
> >
> > dsi_start_delay = max(1, (mode->vtotal - (mode->vsync_start -
> > mode->vdisplay) + 1) % mode->vtotal)
>
> Where did you find that Allwinner's back porch is including the sync
> length?
I believe that was the case with the TCON? And since Allwinner's code
take the values from the FEX files directly for both TCON and DSI,
it should be the same.
There's also some dead code in the BSP that alludes to it, such as the
function tcon1_cfg_ex() in drivers/video/de/lowlevel_sun50iw1/de_lcd.c
from the A64 BSP.
> If we treat the bp as vtotal - vsync_end as we should (and yet I often
> fail to), then we end up with (leaving out the modulo for now):
>
> dsi_
Re: [PATCH v3 1/7] dt-bindings: interconnect: Add a dma interconnect name
On Thu, Mar 7, 2019 at 11:48 PM Maxime Ripard wrote: > > On Thu, Mar 07, 2019 at 05:15:20PM +0200, Georgi Djakov wrote: > > Hi, > > > > On 3/5/19 18:14, Robin Murphy wrote: > > > On 05/03/2019 15:53, Maxime Ripard wrote: > > >> Hi, > > >> > > >> On Fri, Mar 01, 2019 at 07:48:15PM +0200, Georgi Djakov wrote: > > >>> On 2/11/19 17:02, Maxime Ripard wrote: > > The current DT bindings assume that the DMA will be performed by the > > devices through their parent DT node, and rely on that assumption > > for the > > address translation using dma-ranges. > > > > However, some SoCs have devices that will perform DMA through > > another bus, > > with separate address translation rules. We therefore need to > > express that > > relationship, through the special interconnect name "dma". > > > > Signed-off-by: Maxime Ripard > > --- > > Documentation/devicetree/bindings/interconnect/interconnect.txt | > > 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > index 5a3c575b387a..e69fc2d992c3 100644 > > --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > @@ -51,6 +51,9 @@ interconnect-names : List of interconnect path > > name strings sorted in the same > > interconnect-names to match interconnect paths with > > interconnect > > specifier pairs. > > + Reserved interconnect names: > > + * dma: Path from the device to the main > > memory of the system > > >>> > > >>> Bikeshed: As it's from the device to the main memory, maybe here we can > > >>> also denote this my calling the path dma-mem or dma-memory. For other > > >>> paths, we are trying to mention both the source and the destination and > > >>> maybe it would be good to be consistent although this is special one. > > >> > > >> I'm not sure I understand what you mean. You'd like two interconnect > > >> names, one called dma-memory, and one memory-dma? > > > > > > Hmm, yes, it's not like "dma" describes an actual source or destination > > > either :/ > > > > IIUC, it's a path (bus) that a dma device use to access some memory > > (read or/and write). So i have used source-destination above more in the > > sense of initiator-target or master-slave. My suggestion was just to > > change the reserved interconnect name from "dma" to "dma-mem" or > > "dma-memory". > > If dma is an issue in itself, maybe we can call it "device-memory" ? Might I ask what happens if the device can both DMA to and from memory? IIRC the display frontends, backends, and mixers all have writeback capability, using the same interconnect port. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/7] dt-bindings: interconnect: Add a dma interconnect name
On Mon, Mar 11, 2019 at 6:11 PM Maxime Ripard wrote: > > On Fri, Mar 08, 2019 at 12:09:47AM +0800, Chen-Yu Tsai wrote: > > On Thu, Mar 7, 2019 at 11:48 PM Maxime Ripard > > wrote: > > > > > > On Thu, Mar 07, 2019 at 05:15:20PM +0200, Georgi Djakov wrote: > > > > Hi, > > > > > > > > On 3/5/19 18:14, Robin Murphy wrote: > > > > > On 05/03/2019 15:53, Maxime Ripard wrote: > > > > >> Hi, > > > > >> > > > > >> On Fri, Mar 01, 2019 at 07:48:15PM +0200, Georgi Djakov wrote: > > > > >>> On 2/11/19 17:02, Maxime Ripard wrote: > > > > >>>> The current DT bindings assume that the DMA will be performed by > > > > >>>> the > > > > >>>> devices through their parent DT node, and rely on that assumption > > > > >>>> for the > > > > >>>> address translation using dma-ranges. > > > > >>>> > > > > >>>> However, some SoCs have devices that will perform DMA through > > > > >>>> another bus, > > > > >>>> with separate address translation rules. We therefore need to > > > > >>>> express that > > > > >>>> relationship, through the special interconnect name "dma". > > > > >>>> > > > > >>>> Signed-off-by: Maxime Ripard > > > > >>>> --- > > > > >>>> Documentation/devicetree/bindings/interconnect/interconnect.txt | > > > > >>>> 3 +++ > > > > >>>> 1 file changed, 3 insertions(+) > > > > >>>> > > > > >>>> diff --git > > > > >>>> a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > > > >>>> b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > > > >>>> index 5a3c575b387a..e69fc2d992c3 100644 > > > > >>>> --- > > > > >>>> a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > > > >>>> +++ > > > > >>>> b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > > > >>>> @@ -51,6 +51,9 @@ interconnect-names : List of interconnect path > > > > >>>> name strings sorted in the same > > > > >>>>interconnect-names to match interconnect paths with > > > > >>>> interconnect > > > > >>>>specifier pairs. > > > > >>>> + Reserved interconnect names: > > > > >>>> + * dma: Path from the device to the main > > > > >>>> memory of the system > > > > >>> > > > > >>> Bikeshed: As it's from the device to the main memory, maybe here we > > > > >>> can > > > > >>> also denote this my calling the path dma-mem or dma-memory. For > > > > >>> other > > > > >>> paths, we are trying to mention both the source and the destination > > > > >>> and > > > > >>> maybe it would be good to be consistent although this is special > > > > >>> one. > > > > >> > > > > >> I'm not sure I understand what you mean. You'd like two interconnect > > > > >> names, one called dma-memory, and one memory-dma? > > > > > > > > > > Hmm, yes, it's not like "dma" describes an actual source or > > > > > destination > > > > > either :/ > > > > > > > > IIUC, it's a path (bus) that a dma device use to access some memory > > > > (read or/and write). So i have used source-destination above more in the > > > > sense of initiator-target or master-slave. My suggestion was just to > > > > change the reserved interconnect name from "dma" to "dma-mem" or > > > > "dma-memory". > > > > > > If dma is an issue in itself, maybe we can call it "device-memory" ? > > > > Might I ask what happens if the device can both DMA to and from memory? > > We can create another one called memory-device if that's needed? Works for me as long as it doesn't get confusing. BTW I think it should be X-to-Y, instead of X-Y, as the latter can be taken as a noun-phrase. > > IIRC the display frontends, backends, and mixers all have writeback > > capability, using the same interconnect port. > > I think in both cases it's the same path. The camera driver also need > to have that offset, even though it's a producer and not a consumer, > and the VPU does too. Yeah. The VPU is the obvious bi-directional example. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: Convert Allwinner DSI to a schema
On Mon, May 27, 2019 at 8:09 PM Maxime Ripard wrote: > > The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in > Linux, with a matching Device Tree binding. > > Now that we have the DT validation in place, let's convert the device tree > bindings for that controller over to a YAML schemas. > > Signed-off-by: Maxime Ripard Looks good to me. However not sure why you replaced the clock index macros with raw numbers. Reviewed-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: Convert Allwinner DSI to a schema
On Fri, May 31, 2019 at 2:54 AM Maxime Ripard wrote: > > Hi, > > On Thu, May 30, 2019 at 09:48:02PM +0800, Chen-Yu Tsai wrote: > > On Mon, May 27, 2019 at 8:09 PM Maxime Ripard > > wrote: > > > > > > The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in > > > Linux, with a matching Device Tree binding. > > > > > > Now that we have the DT validation in place, let's convert the device tree > > > bindings for that controller over to a YAML schemas. > > > > > > Signed-off-by: Maxime Ripard > > > > Looks good to me. However not sure why you replaced the clock index macros > > with raw numbers. > > The examples are compiled now, and unfortunately we can't use the > defines at this point. That was what I suspected. Thanks. My Reviewed-by still stands. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 1/9] dt-bindings: display: Add TCON LCD compatible for R40
On Fri, Jun 14, 2019 at 2:53 AM Jagan Teki wrote: > > Like TCON TV0, TV1 allwinner R40 has TCON LCD0, LCD1 which > are managed via TCON TOP. > > Add tcon lcd compatible R40, the same compatible can handle > TCON LCD0, LCD1. > > Cc: Rob Herring > Cc: Mark Rutland > Signed-off-by: Jagan Teki Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 2/9] drm/sun4i: tcon: Add TCON LCD support for R40
On Fri, Jun 14, 2019 at 2:53 AM Jagan Teki wrote: > > TCON LCD0, LCD1 in allwinner R40, are used for managing > LCD interfaces like RGB, LVDS and DSI. > > Like TCON TV0, TV1 these LCD0, LCD1 are also managed via > tcon top. > > Add support for it, in tcon driver. > > Signed-off-by: Jagan Teki Reviewed-by: Chen-Yu Tsai
Re: [PATCH 3/9] ARM: dts: sun8i: r40: Use tcon top clock index macros
On Fri, Jun 14, 2019 at 2:54 AM Jagan Teki wrote: > > tcon_tv0, tcon_tv1 nodes have a clock names of tcon-ch0, > tcon-ch1 which are referring tcon_top clocks via index > numbers like 0, 1 with CLK_TCON_TV0 and CLK_TCON_TV1 > respectively. > > Use the macro in place of index numbers, for more code > readability. > > Signed-off-by: Jagan Teki Reviewed-by: Chen-Yu Tsai
Re: [PATCH 4/9] drm/sun4i: tcon_top: Use clock name index macros
On Fri, Jun 14, 2019 at 2:54 AM Jagan Teki wrote: > > TCON TOP mux blocks in R40 are registering clock using > tcon top clock index numbers. > > Right now the code is using, real numbers start with 0, but > we have proper macros that defined these name index numbers. > > Use the existing macros, instead of real numbers for more > code readability. > > Signed-off-by: Jagan Teki Reviewed-by: Chen-Yu Tsai However, you might want to rename the clock first, then switch to using the index macros? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 2/9] drm/sun4i: tcon: Add TCON LCD support for R40
On Fri, Jun 14, 2019 at 11:19 AM Chen-Yu Tsai wrote: > > On Fri, Jun 14, 2019 at 2:53 AM Jagan Teki wrote: > > > > TCON LCD0, LCD1 in allwinner R40, are used for managing > > LCD interfaces like RGB, LVDS and DSI. > > > > Like TCON TV0, TV1 these LCD0, LCD1 are also managed via > > tcon top. > > > > Add support for it, in tcon driver. > > > > Signed-off-by: Jagan Teki > > Reviewed-by: Chen-Yu Tsai I take that back. The TCON output muxing (which selects whether TCON LCD or TCON TV outputs to the GPIO pins) is not supported yet. Please at least add TODO notes, or ideally, block RGB output from being used. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] ARM: dts: sun8i: r40: Add TCON TOP LCD clocking
On Fri, Jun 14, 2019 at 2:54 AM Jagan Teki wrote: > > According to Fig 7-2. TCON Top Block Diagram in User manual. > > TCON TOP can have an hierarchy for TCON_LCD0, LCD1 like > TCON_TV0, TV1 so, the tcon top would handle the clocks of > TCON_LCD0, LCD1 similar like TV0, TV1. That is not guaranteed. The diagram shows the pixel data path, not necessarily the clocks. In addition, the LCD TCONs have an internal clock gate for the dot-clock output, which the TV variants do not. That might explain the need for the gates in TCON TOP. > But, the current tcon_top node is using dsi clock name with > CLK_DSI_DPHY which is ideally handle via dphy which indeed > a separate interface block. > > So, use tcon-lcd0 instead of dsi which would refer the > CLK_TCON_LCD0 similar like CLK_TCON_TV0 with tcon-tv0. > > This way we can refer CLK_TCON_LCD0 from tcon_top clock in > tcon_lcd0 node and the actual DSI_DPHY clock node would > refer in dphy node. That doesn't make sense. What about TCON_LCD1? The CCU already has CLK_TCON_LCD0 and CLK_TCON_LCD1. What makes you think that the TCONs don't use them directly? Or maybe they do go through TCON_TOP, but there's no gate, so we don't know about it. You need to rethink this. What are you trying to deal with? > Signed-off-by: Jagan Teki > --- > arch/arm/boot/dts/sun8i-r40.dtsi | 6 +++--- > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 6 +++--- > include/dt-bindings/clock/sun8i-tcon-top.h | 2 +- This is going to be a pain to merge. First, you need to split the driver parts from the DT parts. Second, you might need to revert CLK_DSI_DPHY back to a raw number for now, so that when the patches get merged through different trees, nothing breaks. Third, you'll come back after everything is merged, and change the raw number to the new macro. ChenYu
Re: [PATCH 5/9] ARM: dts: sun8i: r40: Add TCON TOP LCD clocking
On Fri, Jun 14, 2019 at 5:48 PM Jagan Teki wrote:
>
> On Fri, Jun 14, 2019 at 9:16 AM Chen-Yu Tsai wrote:
> >
> > On Fri, Jun 14, 2019 at 2:54 AM Jagan Teki
> > wrote:
> > >
> > > According to Fig 7-2. TCON Top Block Diagram in User manual.
> > >
> > > TCON TOP can have an hierarchy for TCON_LCD0, LCD1 like
> > > TCON_TV0, TV1 so, the tcon top would handle the clocks of
> > > TCON_LCD0, LCD1 similar like TV0, TV1.
> >
> > That is not guaranteed. The diagram shows the pixel data path,
> > not necessarily the clocks. In addition, the LCD TCONs have an
> > internal clock gate for the dot-clock output, which the TV variants
> > do not. That might explain the need for the gates in TCON TOP.
>
> Correct, the actual idea about explanation here is to mention the
> clocks definition in tcon top level and internal tv and lcd can handle
> as you explained.
>
> >
> > > But, the current tcon_top node is using dsi clock name with
> > > CLK_DSI_DPHY which is ideally handle via dphy which indeed
> > > a separate interface block.
> > >
> > > So, use tcon-lcd0 instead of dsi which would refer the
> > > CLK_TCON_LCD0 similar like CLK_TCON_TV0 with tcon-tv0.
> > >
> > > This way we can refer CLK_TCON_LCD0 from tcon_top clock in
> > > tcon_lcd0 node and the actual DSI_DPHY clock node would
> > > refer in dphy node.
> >
> > That doesn't make sense. What about TCON_LCD1?
> >
> > The CCU already has CLK_TCON_LCD0 and CLK_TCON_LCD1. What makes
> > you think that the TCONs don't use them directly?
> >
> > Or maybe they do go through TCON_TOP, but there's no gate,
> > so we don't know about it.
> >
> > You need to rethink this. What are you trying to deal with?
>
> Yes, I understand what your asking for and indeed this is where I get
> confused and tried this way initially and attach the dsi reference in
> dphy something like
>
> tcon_lcd0 {
> clocks = <&ccu CLK_BUS_TCON_LCD0>, <&ccu CLK_TCON_LCD0>;
> clock-names = "ahb", "tcon-ch0";
> };
>
> dphy {
>clocks = <&ccu CLK_BUS_MIPI_DSI>,
> <&tcon_top CLK_TCON_TOP_DSI>;
>clock-names = "bus", "mod";
> };
>
> This would ended-up, phy wont getting the mod clock keep probing for
> -EPROBE-DEFER since tcon top driver might not be loaded at the time
> mipi driver. This way we have tv0, tv1 and dsi gates supported as
> existed. Does it make sense?
Looks like that happens because the clocks are only registered at
the component bind phase, rather than the probe phase. And to bind
all the components, the DSI controller wants the DPHY available,
which isn't because it's still waiting for the clock.
So you could try moving the bits that register the clocks in the
TCON TOP driver to the probe function, and see if that solves
the circular dependency issue.
ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 2/9] drm/sun4i: tcon: Add TCON LCD support for R40
On Fri, Jun 14, 2019 at 6:56 PM Jagan Teki wrote: > > On Fri, Jun 14, 2019 at 9:05 AM Chen-Yu Tsai wrote: > > > > On Fri, Jun 14, 2019 at 11:19 AM Chen-Yu Tsai wrote: > > > > > > On Fri, Jun 14, 2019 at 2:53 AM Jagan Teki > > > wrote: > > > > > > > > TCON LCD0, LCD1 in allwinner R40, are used for managing > > > > LCD interfaces like RGB, LVDS and DSI. > > > > > > > > Like TCON TV0, TV1 these LCD0, LCD1 are also managed via > > > > tcon top. > > > > > > > > Add support for it, in tcon driver. > > > > > > > > Signed-off-by: Jagan Teki > > > > > > Reviewed-by: Chen-Yu Tsai > > > > I take that back. > > > > The TCON output muxing (which selects whether TCON LCD or TCON TV > > outputs to the GPIO pins) > > is not supported yet. Please at least add TODO notes, or ideally, > > Are you referring about port selection? it is support in > sun8i_tcon_top_de_config. No. That's supported as you already pointed out. That only selects which mixer outputs to which TCON. I'm talking about the GPIOD and GPIOH bits, which select which of LCD or TV TCON outputs to the LCD function pins. Keep in mind that the TV TCON's H/V SYNC signals are used in combination with the TV encoder RGB outputs for VGA. ChenYu
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki wrote:
>
> TCON TOP have clock gates for TV0, TV1, dsi and right
> now these are register during bind call.
>
> Of which, dsi clock gate would required during DPHY probe
> but same can miss to get since tcon top is not bound at
> that time.
>
> To solve, this circular dependency move the clock gate
> registration from bind to probe so-that DPHY can get the
> dsi gate clock on time.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94 ++
> 1 file changed, 49 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> index 465e9b0cdfee..a8978b3fe851 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> @@ -124,7 +124,53 @@ static struct clk_hw
> *sun8i_tcon_top_register_gate(struct device *dev,
> static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
>void *data)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = reset_control_deassert(tcon_top->rst);
> + if (ret) {
> + dev_err(dev, "Could not deassert ctrl reset control\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(tcon_top->bus);
> + if (ret) {
> + dev_err(dev, "Could not enable bus clock\n");
> + goto err_assert_reset;
> + }
You have to de-assert the reset control and enable the clock before the
clocks it provides are registered. Otherwise a consumer may come in and
ask for the provided clock to be enabled, but since the TCON TOP's own
reset and clock are still disabled, you can't actually access the registers
that controls the provided clock.
> +
> + return 0;
> +
> +err_assert_reset:
> + reset_control_assert(tcon_top->rst);
> +
> + return ret;
> +}
> +
> +static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
> + void *data)
> +{
> + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> + struct clk_hw_onecell_data *clk_data = tcon_top->clk_data;
> + int i;
> +
> + of_clk_del_provider(dev->of_node);
> + for (i = 0; i < CLK_NUM; i++)
> + if (clk_data->hws[i])
> + clk_hw_unregister_gate(clk_data->hws[i]);
And this should be in the remove function.
So instead, just move _everything_ to the probe and remove functions,
and provide empty bind/unbind functions so the component system still
works.
ChenYu
> +
> + clk_disable_unprepare(tcon_top->bus);
> + reset_control_assert(tcon_top->rst);
> +}
> +
> +static const struct component_ops sun8i_tcon_top_ops = {
> + .bind = sun8i_tcon_top_bind,
> + .unbind = sun8i_tcon_top_unbind,
> +};
> +
> +static int sun8i_tcon_top_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> struct clk_hw_onecell_data *clk_data;
> struct sun8i_tcon_top *tcon_top;
> const struct sun8i_tcon_top_quirks *quirks;
> @@ -132,7 +178,7 @@ static int sun8i_tcon_top_bind(struct device *dev, struct
> device *master,
> void __iomem *regs;
> int ret, i;
>
> - quirks = of_device_get_match_data(&pdev->dev);
> + quirks = of_device_get_match_data(dev);
>
> tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
> if (!tcon_top)
> @@ -164,18 +210,6 @@ static int sun8i_tcon_top_bind(struct device *dev,
> struct device *master,
> if (IS_ERR(regs))
> return PTR_ERR(regs);
>
> - ret = reset_control_deassert(tcon_top->rst);
> - if (ret) {
> - dev_err(dev, "Could not deassert ctrl reset control\n");
> - return ret;
> - }
> -
> - ret = clk_prepare_enable(tcon_top->bus);
> - if (ret) {
> - dev_err(dev, "Could not enable bus clock\n");
> - goto err_assert_reset;
> - }
> -
> /*
> * At least on H6, some registers have some bits set by default
> * which may cause issues. Clear them here.
> @@ -226,45 +260,15 @@ static int sun8i_tcon_top_bind(struct device *dev,
> struct device *master,
>
> dev_set_drvdata(dev, tcon_top);
>
> - return 0;
> + return component_add(dev, &sun8i_tcon_top_ops);
>
> err_unregister_gates:
> for (i = 0; i < CLK_NUM; i++)
> if (!IS_ERR_OR_NULL(clk_data->hws[i]))
> clk_hw_unregister_gate(clk_data->hws[i]);
> - clk_disable_unprepare(tcon_top->bus);
> -err_assert_reset:
> - reset_control_assert(tcon_top->rst);
> -
> return ret;
> }
>
> -static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
> - vo
Re: [linux-sunxi] Re: [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Mon, Jun 17, 2019 at 7:45 PM Maxime Ripard wrote: > > On Fri, Jun 14, 2019 at 10:13:20PM +0530, Jagan Teki wrote: > > TCON TOP have clock gates for TV0, TV1, dsi and right > > now these are register during bind call. > > > > Of which, dsi clock gate would required during DPHY probe > > but same can miss to get since tcon top is not bound at > > that time. > > > > To solve, this circular dependency move the clock gate > > registration from bind to probe so-that DPHY can get the > > dsi gate clock on time. > > It's not really clear to me what the circular dependency is? > > if you have a chain that is: > > tcon-top +-> DSI > +-> D-PHY > > There's no loop, right? Looking at how the DTSI patch structures things (without going into whether it is correct or accurate): The D-PHY is not part of the component graph. However it requests the DSI gate clock from the TCON-TOP. The TCON-TOP driver, in its current form, only registers the clocks it provides at component bind time. Thus the D-PHY can't successfully probe until the TCON-TOP has been bound. The DSI interface requires the D-PHY to bind. It will return -EPROBE_DEFER if it cannot request it. This in turn goes into the error path of component_bind_all, which unbinds all previous components. So it's actually D-PHY -> TCON-TOP -> DSI ^ | | I've not checked, but I suspect there's no possibility of having other drivers probe (to deal with deferred probing) within component_bind_all. Otherwise we shouldn't run into this weird circular dependency issue. So the question for Jagan is that is this indeed the case? Does this patch solve it, or at least work around it. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki wrote:
>
> On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> >
> > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > wrote:
> > >
> > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > now these are register during bind call.
> > >
> > > Of which, dsi clock gate would required during DPHY probe
> > > but same can miss to get since tcon top is not bound at
> > > that time.
> > >
> > > To solve, this circular dependency move the clock gate
> > > registration from bind to probe so-that DPHY can get the
> > > dsi gate clock on time.
> > >
> > > Signed-off-by: Jagan Teki
> > > ---
> > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94 ++
> > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > index 465e9b0cdfee..a8978b3fe851 100644
> > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
> > >void *data)
> > > {
> > > - struct platform_device *pdev = to_platform_device(dev);
> > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > + int ret;
> > > +
> > > + ret = reset_control_deassert(tcon_top->rst);
> > > + if (ret) {
> > > + dev_err(dev, "Could not deassert ctrl reset control\n");
> > > + return ret;
> > > + }
> > > +
> > > + ret = clk_prepare_enable(tcon_top->bus);
> > > + if (ret) {
> > > + dev_err(dev, "Could not enable bus clock\n");
> > > + goto err_assert_reset;
> > > + }
> >
> > You have to de-assert the reset control and enable the clock before the
> > clocks it provides are registered. Otherwise a consumer may come in and
> > ask for the provided clock to be enabled, but since the TCON TOP's own
> > reset and clock are still disabled, you can't actually access the registers
> > that controls the provided clock.
>
> These rst and bus are common reset and bus clocks not tcon top clocks
> that are trying to register here. ie reason I have not moved it in
> top.
And you're sure that toggling bits in the TCON TOP block doesn't require
the reset to be de-asserted and the bus clock enabled?
Somehow I doubt that.
Once the driver register the clocks it provides, they absolutely must work.
They can't only work after the bind phase when the reset gets de-asserted
and the bus clock enabled. Or you should provide proper error reporting
in the clock ops. I doubt you want to go that way either.
ChenYu
Re: [linux-sunxi] Re: [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 3:12 PM Jagan Teki wrote: > > On Mon, Jun 17, 2019 at 6:31 PM Chen-Yu Tsai wrote: > > > > On Mon, Jun 17, 2019 at 7:45 PM Maxime Ripard > > wrote: > > > > > > On Fri, Jun 14, 2019 at 10:13:20PM +0530, Jagan Teki wrote: > > > > TCON TOP have clock gates for TV0, TV1, dsi and right > > > > now these are register during bind call. > > > > > > > > Of which, dsi clock gate would required during DPHY probe > > > > but same can miss to get since tcon top is not bound at > > > > that time. > > > > > > > > To solve, this circular dependency move the clock gate > > > > registration from bind to probe so-that DPHY can get the > > > > dsi gate clock on time. > > > > > > It's not really clear to me what the circular dependency is? > > > > > > if you have a chain that is: > > > > > > tcon-top +-> DSI > > > +-> D-PHY > > > > > > There's no loop, right? > > > > Looking at how the DTSI patch structures things (without going into > > whether it is correct or accurate): > > > > The D-PHY is not part of the component graph. However it requests > > the DSI gate clock from the TCON-TOP. > > > > The TCON-TOP driver, in its current form, only registers the clocks > > it provides at component bind time. Thus the D-PHY can't successfully > > probe until the TCON-TOP has been bound. > > > > The DSI interface requires the D-PHY to bind. It will return -EPROBE_DEFER > > if it cannot request it. This in turn goes into the error path of > > component_bind_all, which unbinds all previous components. > > > > So it's actually > > > > D-PHY -> TCON-TOP -> DSI > > ^ | > > | > > > > I've not checked, but I suspect there's no possibility of having other > > drivers probe (to deal with deferred probing) within component_bind_all. > > Otherwise we shouldn't run into this weird circular dependency issue. > > > > So the question for Jagan is that is this indeed the case? Does this > > patch solve it, or at least work around it. > > Yes, this is what I was mentioned in initial version, since the "dsi" > gate in tcon top is registering during bind, the dphy of dsi > controller won't get the associated clock for "mod" so it is keep on > returning -EPROBE_DEFER. By moving the clock gate registration to > probe, everything bound as expected. I believe you failed to mention the DSI block, which is the part that completes the circular dependency. Don't expect others to have full awareness of the context. You have to provide it in your commit log. ChenYu
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> >
> > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > wrote:
> > >
> > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> > > >
> > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > wrote:
> > > > >
> > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > now these are register during bind call.
> > > > >
> > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > but same can miss to get since tcon top is not bound at
> > > > > that time.
> > > > >
> > > > > To solve, this circular dependency move the clock gate
> > > > > registration from bind to probe so-that DPHY can get the
> > > > > dsi gate clock on time.
> > > > >
> > > > > Signed-off-by: Jagan Teki
> > > > > ---
> > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > ++
> > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > static int sun8i_tcon_top_bind(struct device *dev, struct device
> > > > > *master,
> > > > >void *data)
> > > > > {
> > > > > - struct platform_device *pdev = to_platform_device(dev);
> > > > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > > > + int ret;
> > > > > +
> > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > + if (ret) {
> > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > control\n");
> > > > > + return ret;
> > > > > + }
> > > > > +
> > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > + if (ret) {
> > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > + goto err_assert_reset;
> > > > > + }
> > > >
> > > > You have to de-assert the reset control and enable the clock before the
> > > > clocks it provides are registered. Otherwise a consumer may come in and
> > > > ask for the provided clock to be enabled, but since the TCON TOP's own
> > > > reset and clock are still disabled, you can't actually access the
> > > > registers
> > > > that controls the provided clock.
> > >
> > > These rst and bus are common reset and bus clocks not tcon top clocks
> > > that are trying to register here. ie reason I have not moved it in
> > > top.
> >
> > And you're sure that toggling bits in the TCON TOP block doesn't require
> > the reset to be de-asserted and the bus clock enabled?
> >
> > Somehow I doubt that.
> >
> > Once the driver register the clocks it provides, they absolutely must work.
> > They can't only work after the bind phase when the reset gets de-asserted
> > and the bus clock enabled. Or you should provide proper error reporting
> > in the clock ops. I doubt you want to go that way either.
>
> Why would they won't work after bind phase? unlike tcon top gates,
> these reset, and bus are common like what we have in other DE block
> so enable them in bind won't be an issue as per as I understand. let
> me know if you want me to check in other directions.
You misunderstood. When you moved the clock registering parts to the probe
phase, but didn't move the clock enable and reset de-assert parts to go with,
the clock ops will not work as expected between probe and bind time.
Simple way to verify it: Just use devmem to disable the TCON TOP bus gate
and/or assert its reset control. Then try to toggle any of the bits in the
TCON TOP block and see if it works, or if the bits stick.
Whether another driver actual
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Tue, Jun 18, 2019 at 6:34 PM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 1:23 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki
> > wrote:
> > >
> > > On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> > > >
> > > > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > > > wrote:
> > > > >
> > > > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai wrote:
> > > > > >
> > > > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > > > wrote:
> > > > > > >
> > > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > > > now these are register during bind call.
> > > > > > >
> > > > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > > > but same can miss to get since tcon top is not bound at
> > > > > > > that time.
> > > > > > >
> > > > > > > To solve, this circular dependency move the clock gate
> > > > > > > registration from bind to probe so-that DPHY can get the
> > > > > > > dsi gate clock on time.
> > > > > > >
> > > > > > > Signed-off-by: Jagan Teki
> > > > > > > ---
> > > > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > > > ++
> > > > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > > > static int sun8i_tcon_top_bind(struct device *dev, struct device
> > > > > > > *master,
> > > > > > >void *data)
> > > > > > > {
> > > > > > > - struct platform_device *pdev = to_platform_device(dev);
> > > > > > > + struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > > > control\n");
> > > > > > > + return ret;
> > > > > > > + }
> > > > > > > +
> > > > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > > > + if (ret) {
> > > > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > > > + goto err_assert_reset;
> > > > > > > + }
> > > > > >
> > > > > > You have to de-assert the reset control and enable the clock before
> > > > > > the
> > > > > > clocks it provides are registered. Otherwise a consumer may come in
> > > > > > and
> > > > > > ask for the provided clock to be enabled, but since the TCON TOP's
> > > > > > own
> > > > > > reset and clock are still disabled, you can't actually access the
> > > > > > registers
> > > > > > that controls the provided clock.
> > > > >
> > > > > These rst and bus are common reset and bus clocks not tcon top clocks
> > > > > that are trying to register here. ie reason I have not moved it in
> > > > > top.
> > > >
> > > > And you're sure that toggling bits in the TCON TOP block doesn't require
> > > > the reset to be de-asserted and the bus clock enabled?
> > > >
> > > > Somehow I doubt that.
> > > >
> > > > Once the driver register the clocks it provides, they absolutely must
> > > > work.
> > > >
Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki wrote: > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard > wrote: > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > > wrote: > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote: > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote: > > > > > > > > > > > According to "DRM kernel-internal display mode structure" > > > > > > > > > > > in > > > > > > > > > > > include/drm/drm_modes.h the current driver is trying to > > > > > > > > > > > include > > > > > > > > > > > sync timings along with front porch value while checking > > > > > > > > > > > and > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal front > > > > > > > > > > > porch + sync > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi controller > > > > > > > > > > > leads to > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" panel > > > > > > > > > > > which indeed > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > Modules linked in: > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > [] (unwind_backtrace) from [] > > > > > > > > > > > (show_stack+0x10/0x14) > > > > > > > > > > > [] (show_stack) from [] > > > > > > > > > > > (dump_stack+0x84/0x98) > > > > > > > > > > > [] (dump_stack) from [] > > > > > > > > > > > (__warn+0xfc/0x114) > > > > > > > > > > > [] (__warn) from [] > > > > > > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > > [] (warn_slowpath_fmt) from [] > > > > > > > > > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > > > > > > > > > [] (drm_atomic_helper_wait_for_vblanks.part.1) > > > > > > > > > > > from [] > > > > > > > > > > > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > > > > > > > > > [] (drm_atomic_helper_commit_tail_rpm) from > > > > > > > > > > > [] (commit_tail+0x40/0x6c) > > > > > > > > > > > [] (commit_tail) from [] > > > > > > > > > > > (drm_atomic_helper_commit+0xbc/0x128) > > > > > > > > > > > [] (drm_atomic_helper_commit) from > > > > > > > > > > > [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > > > > > > > > > [] (restore_fbdev_mode_atomic) from > > > > > > > > > > > [] > > > > > > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > > > > > > > > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) > > > > > > > > > > > from [] (drm_fb_helper_set_par+0x30/0x54) > > > > > > > > > > > [] (drm_fb_helper_set_par) from [] > > > > > > > > > > > (fbcon_init+0x560/0x5ac) > > > > > > > > > > > [] (fbcon_init) from [] > > > > > > > > > > > (visual_init+0xbc/0x104) > > > > > > > > > > > [] (visual_init) from [] > > > > > > > > > > > (do_bind_con_driver+0x1b0/0x390) > > > > > > > > > > > [] (do_bind_con_driver) from [] > > > > > > > > > > > (do_take_over_console+0x13c/0x1c4) > > > > > > > > > > > [] (do_take_over_console) from [] > > > > > > > > > > > (do_fbcon_takeover+0x74/0xcc) > > > > > > > > > > > [] (do_fbcon_takeover) from [] > > > > > > > > > > > (notifier_call_chain+0x44/0x84) > > > > > > > > > > > [] (notifier_call_chain) from [] > > > > > > > > > > > (__blocking_notifier_call_chain+0x48/0x60) > > > > > > > > > > > [] (__blocking_notifier_call_chain) from > > > > > > > > > > > [] (blocking_notifier_call_chain+0x18/0x20) > > > > > > > > > > > [] (blocking_notifier_call_chain) from > > > > > > > > > > > [] (register_framebuffer+0x1e0/0x2f8) > > > > > > > > > > > [] (register_framebuffer) from [] > > > > > > > > > > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > > > > > > > > > > [] (__drm_fb_helper_initial_config_and_unlock) > > > > > > > > > > > from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) > > > > > > > > > > > [] (drm_fbdev_client_hotplug) from > > > > > > > > > > > [] (drm_fbdev_generic_setup+0x88/0x118) > > > >
Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Tue, Jun 18, 2019 at 8:11 PM Jagan Teki wrote: > > On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote: > > > > On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki > > wrote: > > > > > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard > > > wrote: > > > > > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote: > > > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki > > > > > > > > > > > > wrote: > > > > > > > > > > > > > According to "DRM kernel-internal display mode > > > > > > > > > > > > > structure" in > > > > > > > > > > > > > include/drm/drm_modes.h the current driver is trying > > > > > > > > > > > > > to include > > > > > > > > > > > > > sync timings along with front porch value while > > > > > > > > > > > > > checking and > > > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal front > > > > > > > > > > > > > porch + sync > > > > > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi > > > > > > > > > > > > > controller leads to > > > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" panel > > > > > > > > > > > > > which indeed > > > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > > > Modules linked in: > > > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > > > [] (unwind_backtrace) from [] > > > > > > > > > > > > > (show_stack+0x10/0x14) > > > > > > > > > > > > > [] (show_stack) from [] > > > > > > > > > > > > > (dump_stack+0x84/0x98) > > > > > > > > > > > > > [] (dump_stack) from [] > > > > > > > > > > > > > (__warn+0xfc/0x114) > > > > > > > > > > > > > [] (__warn) from [] > > > > > > > > > > > > > (warn_slowpath_fmt+0x44/0x68) > > > > > > > > > > > > > [] (warn_s
Re: [linux-sunxi] Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Fri, Jun 21, 2019 at 2:51 AM Jagan Teki wrote: > > On Tue, Jun 18, 2019 at 8:15 PM Chen-Yu Tsai wrote: > > > > On Tue, Jun 18, 2019 at 8:11 PM Jagan Teki > > wrote: > > > > > > On Tue, Jun 18, 2019 at 5:13 PM Chen-Yu Tsai wrote: > > > > > > > > On Tue, Jun 18, 2019 at 6:51 PM Jagan Teki > > > > wrote: > > > > > > > > > > On Fri, Jun 14, 2019 at 8:15 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote: > > > > > > > On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote: > > > > > > > > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, May 29, 2019 at 11:44:56PM +0530, Jagan Teki wrote: > > > > > > > > > > > On Wed, May 29, 2019 at 8:24 PM Maxime Ripard > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Fri, May 24, 2019 at 2:04 AM Maxime Ripard > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan > > > > > > > > > > > > > > Teki wrote: > > > > > > > > > > > > > > > According to "DRM kernel-internal display mode > > > > > > > > > > > > > > > structure" in > > > > > > > > > > > > > > > include/drm/drm_modes.h the current driver is > > > > > > > > > > > > > > > trying to include > > > > > > > > > > > > > > > sync timings along with front porch value while > > > > > > > > > > > > > > > checking and > > > > > > > > > > > > > > > computing drq set bits in non-burst mode. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > mode->hsync_end - mode->hdisplay => horizontal > > > > > > > > > > > > > > > front porch + sync > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With adding additional sync timings, the dsi > > > > > > > > > > > > > > > controller leads to > > > > > > > > > > > > > > > wrong drq set bits for "bananapi,s070wv20-ct16" > > > > > > > > > > > > > > > panel which indeed > > > > > > > > > > > > > > > trigger panel flip_done timed out as: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 31 at > > > > > > > > > > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1429 > > > > > > > > > > > > > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > > > > > > > > > > > > > [CRTC:46:crtc-0] vblank wait timed out > > > > > > > > > > > > > > > Modules linked in: > > > > > > > > > > > > > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > > > > > > > > > > > > > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > > > > > > > > > > > > > > > Hardware name: Allwinner sun8i Family > > > > > > > > > > > > > > > Workqueue: events deferred_probe_work_func > > > > > > > > > > > > > > > [] (unwind_backtrace) from > &
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Fri, Jun 21, 2019 at 12:24 AM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 4:24 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Jun 18, 2019 at 6:34 PM Jagan Teki
> > wrote:
> > >
> > > On Tue, Jun 18, 2019 at 1:23 PM Chen-Yu Tsai wrote:
> > > >
> > > > On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki
> > > > wrote:
> > > > >
> > > > > On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> > > > > >
> > > > > > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > > > > > wrote:
> > > > > > >
> > > > > > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > > > > > now these are register during bind call.
> > > > > > > > >
> > > > > > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > > > > > but same can miss to get since tcon top is not bound at
> > > > > > > > > that time.
> > > > > > > > >
> > > > > > > > > To solve, this circular dependency move the clock gate
> > > > > > > > > registration from bind to probe so-that DPHY can get the
> > > > > > > > > dsi gate clock on time.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jagan Teki
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > > > > > ++
> > > > > > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > > > > > static int sun8i_tcon_top_bind(struct device *dev, struct
> > > > > > > > > device *master,
> > > > > > > > >void *data)
> > > > > > > > > {
> > > > > > > > > - struct platform_device *pdev =
> > > > > > > > > to_platform_device(dev);
> > > > > > > > > + struct sun8i_tcon_top *tcon_top =
> > > > > > > > > dev_get_drvdata(dev);
> > > > > > > > > + int ret;
> > > > > > > > > +
> > > > > > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > > > > > control\n");
> > > > > > > > > + return ret;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > > > > > + goto err_assert_reset;
> > > > > > > > > + }
> > > > > > > >
> > > > > > > > You have to de-assert the reset control and enable the clock
> > > > > > > > before the
> > > > > > > > clocks it provides are registered. Otherwise a consumer may
> > > > > > > > come in and
> > > > > > > > ask for the provided clock to be en
Re: [linux-sunxi] Re: [PATCH v10 03/11] drm/sun4i: dsi: Fix video start delay computation
On Fri, May 24, 2019 at 6:27 PM Jagan Teki wrote: > > On Fri, May 24, 2019 at 2:18 AM Maxime Ripard > wrote: > > > > On Mon, May 20, 2019 at 02:33:10PM +0530, Jagan Teki wrote: > > > The current code is computing vertical video start delay as > > > > > > delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; > > > > > > On which the second parameter > > > > > > mode->vsync_end - mode->vdisplay = front porch + sync timings > > > > > > according to "DRM kernel-internal display mode structure" in > > > include/drm/drm_modes.h > > > > > > With adding additional sync timings, the desired video start delay > > > value as 510 for "bananapi,s070wv20-ct16" panel timings which indeed > > > trigger panel flip_done timed out as: > > > > > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > [CRTC:46:crtc-0] vblank wait timed out > > > Modules linked in: > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 > > > Hardware name: Allwinner sun8i Family > > > Workqueue: events deferred_probe_work_func > > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > > > [] (warn_slowpath_fmt) from [] > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from > > > [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > [] (drm_atomic_helper_commit_tail_rpm) from [] > > > (commit_tail+0x40/0x6c) > > > [] (commit_tail) from [] > > > (drm_atomic_helper_commit+0xbc/0x128) > > > [] (drm_atomic_helper_commit) from [] > > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > [] (restore_fbdev_mode_atomic) from [] > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from > > > [] (drm_fb_helper_set_par+0x30/0x54) > > > [] (drm_fb_helper_set_par) from [] > > > (fbcon_init+0x560/0x5ac) > > > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > > > [] (visual_init) from [] > > > (do_bind_con_driver+0x1b0/0x390) > > > [] (do_bind_con_driver) from [] > > > (do_take_over_console+0x13c/0x1c4) > > > [] (do_take_over_console) from [] > > > (do_fbcon_takeover+0x74/0xcc) > > > [] (do_fbcon_takeover) from [] > > > (notifier_call_chain+0x44/0x84) > > > [] (notifier_call_chain) from [] > > > (__blocking_notifier_call_chain+0x48/0x60) > > > [] (__blocking_notifier_call_chain) from [] > > > (blocking_notifier_call_chain+0x18/0x20) > > > [] (blocking_notifier_call_chain) from [] > > > (register_framebuffer+0x1e0/0x2f8) > > > [] (register_framebuffer) from [] > > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > > [] (__drm_fb_helper_initial_config_and_unlock) from > > > [] (drm_fbdev_client_hotplug+0xe8/0x1b8) > > > [] (drm_fbdev_client_hotplug) from [] > > > (drm_fbdev_generic_setup+0x88/0x118) > > > [] (drm_fbdev_generic_setup) from [] > > > (sun4i_drv_bind+0x128/0x160) > > > [] (sun4i_drv_bind) from [] > > > (try_to_bring_up_master+0x164/0x1a0) > > > [] (try_to_bring_up_master) from [] > > > (__component_add+0x94/0x140) > > > [] (__component_add) from [] > > > (sun6i_dsi_probe+0x144/0x234) > > > [] (sun6i_dsi_probe) from [] > > > (platform_drv_probe+0x48/0x9c) > > > [] (platform_drv_probe) from [] > > > (really_probe+0x1dc/0x2c8) > > > [] (really_probe) from [] > > > (driver_probe_device+0x60/0x160) > > > [] (driver_probe_device) from [] > > > (bus_for_each_drv+0x74/0xb8) > > > [] (bus_for_each_drv) from [] > > > (__device_attach+0xd0/0x13c) > > > [] (__device_attach) from [] > > > (bus_probe_device+0x84/0x8c) > > > [] (bus_probe_device) from [] > > > (deferred_probe_work_func+0x64/0x90) > > > [] (deferred_probe_work_func) from [] > > > (process_one_work+0x204/0x420) > > > [] (process_one_work) from [] > > > (worker_thread+0x274/0x5a0) > > > [] (worker_thread) from [] (kthread+0x11c/0x14c) > > > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > > > Exception stack(0xde539fb0 to 0xde539ff8) > > > 9fa0: > > > > > > 9fc0: > > > > > > 9fe0: 0013 > > > ---[ end trace 495200a78b24980e ]--- > > > random: fast init done > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > > > flip_done timed out > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > > [CONNECTOR:48:DSI-1] flip_done timed out > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > > > flip_done timed out > > > > > > But the expected video start delay value is 513 which states that > > > the second parameter on the computation is "fron
Re: [PATCH v10 02/11] drm/sun4i: dsi: Update start value in video start delay
Hi,
On Mon, May 20, 2019 at 5:07 PM Jagan Teki wrote:
>
> start value in video start delay computation done in below commit
> is as per the legacy bsp drivers/video/sunxi/legacy..
> "drm/sun4i: dsi: Change the start delay calculation"
> (sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2)
There is a standard format for referencing commits. Please use it.
The format is:
... commit ("commit subject") ...
So your commit message should read:
start value in video start delay was changed in commit
da676c6aa641 ("drm/sun4i:
dsi: Change the start delay calculation") to match the legacy BSP
driver [1].
>
> This existing start delay computation gives start value of 35,
> for "bananapi,s070wv20-ct16" panel timings which indeed trigger
> panel flip_done timed out as:
>
> WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429
> drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0
> [CRTC:46:crtc-0] vblank wait timed out
> Modules linked in:
> CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW
> 5.1.0-next-20190514-00025-gf928bc7cc146 #15
> Hardware name: Allwinner sun8i Family
> Workqueue: events deferred_probe_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0x98)
> [] (dump_stack) from [] (__warn+0xfc/0x114)
> [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68)
> [] (warn_slowpath_fmt) from []
> (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0)
> [] (drm_atomic_helper_wait_for_vblanks.part.1) from []
> (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c)
> [] (drm_atomic_helper_commit_tail_rpm) from []
> (commit_tail+0x40/0x6c)
> [] (commit_tail) from []
> (drm_atomic_helper_commit+0xbc/0x128)
> [] (drm_atomic_helper_commit) from []
> (restore_fbdev_mode_atomic+0x1cc/0x1dc)
> [] (restore_fbdev_mode_atomic) from []
> (drm_fb_helper_pan_display+0xac/0x1d0)
> [] (drm_fb_helper_pan_display) from []
> (fb_pan_display+0xcc/0x134)
> [] (fb_pan_display) from [] (bit_update_start+0x14/0x30)
> [] (bit_update_start) from [] (fbcon_switch+0x3d8/0x4e0)
> [] (fbcon_switch) from [] (redraw_screen+0x174/0x238)
> [] (redraw_screen) from []
> (fbcon_prepare_logo+0x3c4/0x400)
> [] (fbcon_prepare_logo) from [] (fbcon_init+0x3c8/0x5ac)
> [] (fbcon_init) from [] (visual_init+0xbc/0x104)
> [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390)
> [] (do_bind_con_driver) from []
> (do_take_over_console+0x13c/0x1c4)
> [] (do_take_over_console) from []
> (do_fbcon_takeover+0x74/0xcc)
> [] (do_fbcon_takeover) from []
> (notifier_call_chain+0x44/0x84)
> [] (notifier_call_chain) from []
> (__blocking_notifier_call_chain+0x48/0x60)
> [] (__blocking_notifier_call_chain) from []
> (blocking_notifier_call_chain+0x18/0x20)
> [] (blocking_notifier_call_chain) from []
> (register_framebuffer+0x1e0/0x2f8)
> [] (register_framebuffer) from []
> (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c)
> [] (__drm_fb_helper_initial_config_and_unlock) from []
> (drm_fbdev_client_hotplug+0xe8/0x1b8)
> [] (drm_fbdev_client_hotplug) from []
> (drm_fbdev_generic_setup+0x88/0x118)
> [] (drm_fbdev_generic_setup) from []
> (sun4i_drv_bind+0x128/0x160)
> [] (sun4i_drv_bind) from []
> (try_to_bring_up_master+0x164/0x1a0)
> [] (try_to_bring_up_master) from []
> (__component_add+0x94/0x140)
> [] (__component_add) from []
> (sun6i_dsi_probe+0x144/0x234)
> [] (sun6i_dsi_probe) from []
> (platform_drv_probe+0x48/0x9c)
> [] (platform_drv_probe) from []
> (really_probe+0x1dc/0x2c8)
> [] (really_probe) from []
> (driver_probe_device+0x60/0x160)
> [] (driver_probe_device) from []
> (bus_for_each_drv+0x74/0xb8)
> [] (bus_for_each_drv) from []
> (__device_attach+0xd0/0x13c)
> [] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
> [] (bus_probe_device) from []
> (deferred_probe_work_func+0x64/0x90)
> [] (deferred_probe_work_func) from []
> (process_one_work+0x204/0x420)
> [] (process_one_work) from [] (worker_thread+0x274/0x5a0)
> [] (worker_thread) from [] (kthread+0x11c/0x14c)
> [] (kthread) from [] (ret_from_fork+0x14/0x2c)
> Exception stack(0xde539fb0 to 0xde539ff8)
> 9fa0:
> 9fc0:
> 9fe0: 0013
> ---[ end trace 755e10f62b83f396 ]---
> Console: switching to colour frame buffer device 100x30
> [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0]
> flip_done timed out
> [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1]
> flip_done timed out
> [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0]
> flip_done timed out
>
> But the expected start delay value is 1 which is confirmed from
> new bsp [2].
>
> The important and unclear note on legacy and new bsp codes [1] [2]
> is both use similar start computation initially but it later reassign
Re: [PATCH 4/4] drm/sun4i: Enable DRM InfoFrame support on H6
On Mon, Jun 24, 2019 at 11:49 PM Andrzej Hajda wrote:
>
> On 24.06.2019 17:05, Jernej Škrabec wrote:
> > Dne ponedeljek, 24. junij 2019 ob 17:03:31 CEST je Andrzej Hajda napisal(a):
> >> On 26.05.2019 23:20, Jonas Karlman wrote:
> >>> This patch enables Dynamic Range and Mastering InfoFrame on H6.
> >>>
> >>> Cc: Maxime Ripard
> >>> Cc: Jernej Skrabec
> >>> Signed-off-by: Jonas Karlman
> >>> ---
> >>>
> >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
> >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> >>> 2 files changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index 39d8509d96a0..b80164dd8ad8
> >>> 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> >>> @@ -189,6 +189,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> >>> struct device *master,>
> >>> sun8i_hdmi_phy_init(hdmi->phy);
> >>>
> >>> plat_data->mode_valid = hdmi->quirks->mode_valid;
> >>>
> >>> + plat_data->drm_infoframe = hdmi->quirks->drm_infoframe;
> >>>
> >>> sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
> >>>
> >>> platform_set_drvdata(pdev, hdmi);
> >>>
> >>> @@ -255,6 +256,7 @@ static const struct sun8i_dw_hdmi_quirks
> >>> sun8i_a83t_quirks = {>
> >>> static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
> >>>
> >>> .mode_valid = sun8i_dw_hdmi_mode_valid_h6,
> >>>
> >>> + .drm_infoframe = true,
> >>>
> >>> };
> >>>
> >>> static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 720c5aa8adc1..2a0ec08ee236
> >>> 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> @@ -178,6 +178,7 @@ struct sun8i_dw_hdmi_quirks {
> >>>
> >>> enum drm_mode_status (*mode_valid)(struct drm_connector
> > *connector,
> >>>
> >>>const struct
> > drm_display_mode *mode);
> >>>
> >>> unsigned int set_rate : 1;
> >>>
> >>> + unsigned int drm_infoframe : 1;
> >> Again, drm_infoframe suggests it contains inforframe, but in fact it
> >> just informs infoframe can be used, so again my suggestion
> >> use_drm_infoframe.
> >>
> >> Moreover bool type seems more appropriate here.
> > checkpatch will give warning if bool is used.
>
>
> Then I would say "fix/ignore checkpatch" :)
>
> But maybe there is a reason.
Here's an old one from Linus: https://lkml.org/lkml/2013/9/1/154
I'd say that bool in a struct is a waste of space compared to a 1 bit bitfield,
especially when there already are other bitfields in the same struct.
> Anyway I've tested and I do not see the warning, could you elaborate it.
Maybe checkpatch.pl --strict?
ChenYu
Re: [PATCH 4/4] drm/sun4i: Enable DRM InfoFrame support on H6
On Tue, Jun 25, 2019 at 12:03 AM Jernej Škrabec wrote:
>
> Dne ponedeljek, 24. junij 2019 ob 17:56:30 CEST je Chen-Yu Tsai napisal(a):
> > On Mon, Jun 24, 2019 at 11:49 PM Andrzej Hajda wrote:
> > > On 24.06.2019 17:05, Jernej Škrabec wrote:
> > > > Dne ponedeljek, 24. junij 2019 ob 17:03:31 CEST je Andrzej Hajda
> napisal(a):
> > > >> On 26.05.2019 23:20, Jonas Karlman wrote:
> > > >>> This patch enables Dynamic Range and Mastering InfoFrame on H6.
> > > >>>
> > > >>> Cc: Maxime Ripard
> > > >>> Cc: Jernej Skrabec
> > > >>> Signed-off-by: Jonas Karlman
> > > >>> ---
> > > >>>
> > > >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
> > > >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
> > > >>> 2 files changed, 3 insertions(+)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c index
> > > >>> 39d8509d96a0..b80164dd8ad8
> > > >>> 100644
> > > >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> > > >>> @@ -189,6 +189,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev,
> > > >>> struct device *master,>
> > > >>>
> > > >>> sun8i_hdmi_phy_init(hdmi->phy);
> > > >>>
> > > >>> plat_data->mode_valid = hdmi->quirks->mode_valid;
> > > >>>
> > > >>> + plat_data->drm_infoframe = hdmi->quirks->drm_infoframe;
> > > >>>
> > > >>> sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
> > > >>>
> > > >>> platform_set_drvdata(pdev, hdmi);
> > > >>>
> > > >>> @@ -255,6 +256,7 @@ static const struct sun8i_dw_hdmi_quirks
> > > >>> sun8i_a83t_quirks = {>
> > > >>>
> > > >>> static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
> > > >>>
> > > >>> .mode_valid = sun8i_dw_hdmi_mode_valid_h6,
> > > >>>
> > > >>> + .drm_infoframe = true,
> > > >>>
> > > >>> };
> > > >>>
> > > >>> static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > > >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index
> > > >>> 720c5aa8adc1..2a0ec08ee236
> > > >>> 100644
> > > >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > > >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > > >>> @@ -178,6 +178,7 @@ struct sun8i_dw_hdmi_quirks {
> > > >>>
> > > >>> enum drm_mode_status (*mode_valid)(struct drm_connector
> > > >
> > > > *connector,
> > > >
> > > >>>const struct
> > > >
> > > > drm_display_mode *mode);
> > > >
> > > >>> unsigned int set_rate : 1;
> > > >>>
> > > >>> + unsigned int drm_infoframe : 1;
> > > >>
> > > >> Again, drm_infoframe suggests it contains inforframe, but in fact it
> > > >> just informs infoframe can be used, so again my suggestion
> > > >> use_drm_infoframe.
> > > >>
> > > >> Moreover bool type seems more appropriate here.
> > > >
> > > > checkpatch will give warning if bool is used.
> > >
> > > Then I would say "fix/ignore checkpatch" :)
> > >
> > > But maybe there is a reason.
> >
> > Here's an old one from Linus: https://lkml.org/lkml/2013/9/1/154
> >
> > I'd say that bool in a struct is a waste of space compared to a 1 bit
> > bitfield, especially when there already are other bitfields in the same
> > struct.
> > > Anyway I've tested and I do not see the warning, could you elaborate it.
> >
> > Maybe checkpatch.pl --strict?
>
> It seems they removed that check:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?
> id=7967656ffbfa493f5546c0f1
>
> After reading that block of text, I'm not sure what would be prefered way for
> this case.
This:
+If a structure has many true/false values, consider consolidating them into a
+bitfield with 1 bit members, or using an appropriate fixed width type, such as
+u8.
would suggest using a bitfield, or flags within a fixed width type?
ChenYu
Re: [PATCH v2 08/13] ARM: dts: sun8i: a23/a33: Fix Display Engine DTC warnings
drc0_in_be0: endpoint {
> remote-endpoint =
> <&be0_out_drc0>;
> };
> };
>
> drc0_out: port@1 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <1>;
>
> - drc0_out_tcon0: endpoint@0 {
> - reg = <0>;
> + drc0_out_tcon0: endpoint {
> remote-endpoint =
> <&tcon0_in_drc0>;
> };
> };
> diff --git a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
> b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
> index d4dab7c28398..5659c63d7d77 100644
> --- a/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
> +++ b/arch/arm/boot/dts/sun8i-a23-q8-tablet.dts
> @@ -65,3 +65,9 @@
> &panel {
> compatible = "bananapi,s070wv20-ct16", "simple-panel";
> };
> +
> +&tcon0_out {
> + tcon0_out_lcd: endpoint {
> + remote-endpoint = <&panel_input>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
> b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
> index b0bc2360f8c4..9c5750c25613 100644
> --- a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
> +++ b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
> @@ -48,3 +48,10 @@
> model = "Q8 A33 Tablet";
> compatible = "allwinner,q8-a33", "allwinner,sun8i-a33";
> };
> +
> +&tcon0_out {
> + tcon0_out_lcd: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&panel_input>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
> b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
> index f3667268adde..785798e3a104 100644
> --- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
> +++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
> @@ -63,16 +63,9 @@
>
> panel {
> compatible = "netron-dy,e231732";
> - #address-cells = <1>;
> - #size-cells = <0>;
>
> - port@0 {
> - reg = <0>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - panel_input: endpoint@0 {
> - reg = <0>;
> + port {
> + panel_input: endpoint {
> remote-endpoint = <&tcon0_out_panel>;
> };
> };
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi
> b/arch/arm/boot/dts/sun8i-a33.dtsi
> index a6498102..4484d76c88b5 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -266,18 +266,9 @@
> phy-names = "dphy";
> status = "disabled";
>
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0>;
> -
> - dsi_in_tcon0: endpoint {
> - remote-endpoint =
> <&tcon0_out_dsi>;
> - };
> + port {
> + dsi_in_tcon0: endpoint {
> + remote-endpoint = <&tcon0_out_dsi>;
Shouldn't we expect to see an output port as well?
> };
> };
> };
> @@ -420,6 +411,9 @@
> };
>
> &tcon0_out {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> tcon0_out_dsi: endpoint@1 {
> reg = <1>;
> remote-endpoint = <&dsi_in_tcon0>;
> diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi
> b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> index 53104f4ccacc..3d9a1524e17e 100644
> --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
> +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
Re: [PATCH v2 05/13] ARM: dts: sun5i: Fix display pipeline endpoint warnings in DTC
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Since most of the display IPs have a single endpoint, having a reg > property, a unit-address and #address-cells and #size-cells will emit a > warning. > > Let's remove those. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/13] ARM: dts: sun6i: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/13] ARM: dts: sun5i: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/13] ARM: dts: sun8i: v3s: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/13] ARM: dts: sun8i: a83t: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai but we're going to end up adding it back if DSI gets added. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/13] ARM: dts: sun8i: r40: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/13] ARM: dts: sun9i: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
