dri-devel May 2018

dri-devel@lists.freedesktop.org

268 participants
1833 discussions

[PATCH] drm/exynos/dsi: remove mode_set callback
by Andrzej Hajda 07 May '18

07 May '18

The callback was used only to copy provided mode to context for later usage. Since the mode is always available from crtc atomic state this code can be removed. Signed-off-by: Andrzej Hajda <a.hajda(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 40 +++++++------------------ 1 file changed, 10 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index 7904ffa9abfb..eae44fd714f0 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -270,7 +270,6 @@ struct exynos_dsi { u32 lanes; u32 mode_flags; u32 format; - struct videomode vm; int state; struct drm_property *brightness; @@ -881,30 +880,30 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi) static void exynos_dsi_set_display_mode(struct exynos_dsi *dsi) { - struct videomode *vm = &dsi->vm; + struct drm_display_mode *m = &dsi->encoder.crtc->state->adjusted_mode; unsigned int num_bits_resol = dsi->driver_data->num_bits_resol; u32 reg; if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) { reg = DSIM_CMD_ALLOW(0xf) - | DSIM_STABLE_VFP(vm->vfront_porch) - | DSIM_MAIN_VBP(vm->vback_porch); + | DSIM_STABLE_VFP(m->vsync_start - m->vdisplay) + | DSIM_MAIN_VBP(m->vtotal - m->vsync_end); exynos_dsi_write(dsi, DSIM_MVPORCH_REG, reg); - reg = DSIM_MAIN_HFP(vm->hfront_porch) - | DSIM_MAIN_HBP(vm->hback_porch); + reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay) + | DSIM_MAIN_HBP(m->htotal - m->hsync_end); exynos_dsi_write(dsi, DSIM_MHPORCH_REG, reg); - reg = DSIM_MAIN_VSA(vm->vsync_len) - | DSIM_MAIN_HSA(vm->hsync_len); + reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start) + | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start); exynos_dsi_write(dsi, DSIM_MSYNC_REG, reg); } - reg = DSIM_MAIN_HRESOL(vm->hactive, num_bits_resol) | - DSIM_MAIN_VRESOL(vm->vactive, num_bits_resol); + reg = DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) | + DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol); exynos_dsi_write(dsi, DSIM_MDRESOL_REG, reg); - dev_dbg(dsi->dev, "LCD size = %dx%d\n", vm->hactive, vm->vactive); + dev_dbg(dsi->dev, "LCD size = %dx%d\n", m->hdisplay, m->vdisplay); } static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable) @@ -1485,26 +1484,7 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder) return 0; } -static void exynos_dsi_mode_set(struct drm_encoder *encoder, - struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode) -{ - struct exynos_dsi *dsi = encoder_to_dsi(encoder); - struct videomode *vm = &dsi->vm; - struct drm_display_mode *m = adjusted_mode; - - vm->hactive = m->hdisplay; - vm->vactive = m->vdisplay; - vm->vfront_porch = m->vsync_start - m->vdisplay; - vm->vback_porch = m->vtotal - m->vsync_end; - vm->vsync_len = m->vsync_end - m->vsync_start; - vm->hfront_porch = m->hsync_start - m->hdisplay; - vm->hback_porch = m->htotal - m->hsync_end; - vm->hsync_len = m->hsync_end - m->hsync_start; -} - static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = { - .mode_set = exynos_dsi_mode_set, .enable = exynos_dsi_enable, .disable = exynos_dsi_disable, }; -- 2.17.0

1 0

[GIT PULL] mediatek drm next for 4.18
by CK Hu 07 May '18

07 May '18

Hi, Dave: This include two refined patches. Please kindly let me know if there is any problem. Regards, CK The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git mediatek-drm-next-4.18 for you to fetch changes up to 72ac6969033dc9f5e526566240a3a7934f0916ee: drm/mediatek: Using the function drm_display_mode_to_videomode (2018-05-02 14:20:47 +0800) ---------------------------------------------------------------- Gomonovych, Vasyl (1): drm/mediatek: Use ERR_CAST instead of ERR_PTR(PTR_ERR()) Satendra Singh Thakur (1): drm/mediatek: Using the function drm_display_mode_to_videomode drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/mtk_dpi.c | 60 +++++++++++++++++----------------- drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 14 ++------ 4 files changed, 34 insertions(+), 43 deletions(-)

1 0

[drm_hwc] PSA: drm_hwc submissions via gitlab
by Sean Paul 07 May '18

07 May '18

Hey all, Apologies for the direct ping. I've harvested your emails from drm_hwc git logs, and didn't want to leave anyone out. The good news is that your email address will forever be remembered in the annals of drm_hwcomposer! Anyways, back to the point. Now that we have our shiny freedesktop gitlab instance [1], we should really start using it to its fullest extent. This means 2 things: 1- When you send patches, please consider using gitlab merge requests instead of git send-email. This is not mandatory, but dri-devel is so busy, I want to make sure things aren't lost. Further, there might be some who are not interested in reading dri-devel *gasp*, but who are interested in drm_hwc. 2- If you're interested in being notified of merge requests (since dri-devel can not be cc'd), please consider clicking "Watch" on the project and choose your desired notification level. If you're still reading, I'll point out a couple other things: - There is a bug tracker on the gitlab instance, feel free to add bugs/features/etc to it. - I've added a TODO list to the wiki, but in typing this, realized it's probably better to file bugs for each item. So please ignore the TODO wiki entry. Thanks for reading, Sean [1]- https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer -- Sean Paul, Software Engineer, Google / Chromium OS

7 14

Re: [PATCH] drm/kms/mode: added a new helper for calculating videomode from crtc's display mode
by Liviu Dudau 07 May '18

07 May '18

On Thu, May 03, 2018 at 11:28:37AM +0530, Satendra Singh Thakur wrote: > 1. > -Added a new helper drm_display_mode_crtc_to_videomode > -This helper calculates mode parameters like > horizontal front_porch, back_porch, sync length > vertical front_porch, back_porch, sync length > using crtc_* fields of struct drm_display_mode > -It uses following fields of crtc mode > horizontal sync start/end, active and total length > vertical sync start/end, active and total length > 2. > -Most of the driver use user-supplied mode for calculating videomode > -However, few drivers use HW (crtc) mode for calculating videomode > -This helper will be useful for such drivers > 3. > -Currently following drivers will be using this new helper > -arm hdlcd > -atmel hlcdc > -exynos 5433 decon > -exynos7 decon > -exynos fimd > 4. > -This patch removes related duplicate code from above mentioned drivers > > Signed-off-by: Satendra Singh Thakur <satendra.t(a)samsung.com> > Cc: Madhur Verma <madhur.verma(a)samsung.com> > Cc: Hemanshu Srivastava <hemanshu.s(a)samsung.com> > --- > drivers/gpu/drm/arm/hdlcd_crtc.c | 8 +------- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 +------ > drivers/gpu/drm/drm_modes.c | 20 ++++++++++++++++++++ > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 22 ++++++++++------------ > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 23 ++++++++++------------- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 +++++++++------------- > include/drm/drm_modes.h | 2 ++ > 7 files changed, 53 insertions(+), 51 deletions(-) > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c > index cf5cbd6..d20e471 100644 > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c > @@ -130,13 +130,7 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc) > struct videomode vm; > unsigned int polarities, err; > > - vm.vfront_porch = m->crtc_vsync_start - m->crtc_vdisplay; > - vm.vback_porch = m->crtc_vtotal - m->crtc_vsync_end; > - vm.vsync_len = m->crtc_vsync_end - m->crtc_vsync_start; > - vm.hfront_porch = m->crtc_hsync_start - m->crtc_hdisplay; > - vm.hback_porch = m->crtc_htotal - m->crtc_hsync_end; > - vm.hsync_len = m->crtc_hsync_end - m->crtc_hsync_start; > - > + drm_display_mode_crtc_to_videomode(m, &vm); > polarities = HDLCD_POLARITY_DATAEN | HDLCD_POLARITY_DATA; > > if (m->flags & DRM_MODE_FLAG_PHSYNC) For the HDLCD part: Acked-by: Liviu Dudau <liviu.dudau(a)arm.com> If you're not sending the final version through drm-misc then let me know and I can pick up the HDLCD part separately. Best regards, Liviu > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > index d732810..bafcef6 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c > @@ -81,12 +81,7 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c) > unsigned int cfg; > int div; > > - vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay; > - vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end; > - vm.vsync_len = adj->crtc_vsync_end - adj->crtc_vsync_start; > - vm.hfront_porch = adj->crtc_hsync_start - adj->crtc_hdisplay; > - vm.hback_porch = adj->crtc_htotal - adj->crtc_hsync_end; > - vm.hsync_len = adj->crtc_hsync_end - adj->crtc_hsync_start; > + drm_display_mode_crtc_to_videomode(adj, &vm); > > regmap_write(regmap, ATMEL_HLCDC_CFG(1), > (vm.hsync_len - 1) | ((vm.vsync_len - 1) << 16)); > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index e82b61e..a406749 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -654,6 +654,26 @@ void drm_display_mode_to_videomode(const struct drm_display_mode *dmode, > vm->flags |= DISPLAY_FLAGS_DOUBLECLK; > } > EXPORT_SYMBOL_GPL(drm_display_mode_to_videomode); > +/** > + * drm_display_mode_crtc_to_videomode - fill in @vm using crtc fields of@dmode, > + * @dmode: drm_display_mode structure to use as source > + * @vm: videomode structure to use as destination > + * > + * Fills out @vm using the crtc display mode specified in @dmode. > + */ > +void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode, > + struct videomode *vm) > +{ > + vm->hfront_porch = dmode->crtc_hsync_start - dmode->crtc_hdisplay; > + vm->hsync_len = dmode->crtc_hsync_end - dmode->crtc_hsync_start; > + vm->hback_porch = dmode->crtc_htotal - dmode->crtc_hsync_end; > + > + vm->vfront_porch = dmode->crtc_vsync_start - dmode->crtc_vdisplay; > + vm->vsync_len = dmode->crtc_vsync_end - dmode->crtc_vsync_start; > + vm->vback_porch = dmode->crtc_vtotal - dmode->crtc_vsync_end; > + > +} > +EXPORT_SYMBOL_GPL(drm_display_mode_crtc_to_videomode); > > /** > * drm_bus_flags_from_videomode - extract information about pixelclk and > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > index 1c330f2..1ba73a8 100644 > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > @@ -20,6 +20,7 @@ > #include <linux/of_gpio.h> > #include <linux/pm_runtime.h> > #include <linux/regmap.h> > +#include <video/videomode.h> > > #include "exynos_drm_drv.h" > #include "exynos_drm_crtc.h" > @@ -225,26 +226,23 @@ static void decon_commit(struct exynos_drm_crtc *crtc) > writel(val, ctx->addr + DECON_VIDTCON2); > > if (!crtc->i80_mode) { > - int vbp = m->crtc_vtotal - m->crtc_vsync_end; > - int vfp = m->crtc_vsync_start - m->crtc_vdisplay; > + struct videomode vm; > > + drm_display_mode_crtc_to_videomode(m, &vm); > if (interlaced) > - vbp = vbp / 2 - 1; > - val = VIDTCON00_VBPD_F(vbp - 1) | VIDTCON00_VFPD_F(vfp - 1); > + vm.vback_porch = (vm.vback_porch >> 1) - 1; > + val = VIDTCON00_VBPD_F(vm.vback_porch - 1) | > + VIDTCON00_VFPD_F(vm.vfront_porch - 1); > writel(val, ctx->addr + DECON_VIDTCON00); > > - val = VIDTCON01_VSPW_F( > - m->crtc_vsync_end - m->crtc_vsync_start - 1); > + val = VIDTCON01_VSPW_F(vm.vsync_len - 1); > writel(val, ctx->addr + DECON_VIDTCON01); > > - val = VIDTCON10_HBPD_F( > - m->crtc_htotal - m->crtc_hsync_end - 1) | > - VIDTCON10_HFPD_F( > - m->crtc_hsync_start - m->crtc_hdisplay - 1); > + val = VIDTCON10_HBPD_F(vm.hback_porch - 1) | > + VIDTCON10_HFPD_F(vm.hfront_porch - 1); > writel(val, ctx->addr + DECON_VIDTCON10); > > - val = VIDTCON11_HSPW_F( > - m->crtc_hsync_end - m->crtc_hsync_start - 1); > + val = VIDTCON11_HSPW_F(vm.hsync_len - 1); > writel(val, ctx->addr + DECON_VIDTCON11); > } > > diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c > index 3931d5e..148daae 100644 > --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c > +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c > @@ -25,6 +25,7 @@ > > #include <video/of_display_timing.h> > #include <video/of_videomode.h> > +#include <video/videomode.h> > > #include "exynos_drm_crtc.h" > #include "exynos_drm_plane.h" > @@ -168,28 +169,24 @@ static void decon_commit(struct exynos_drm_crtc *crtc) > return; > > if (!ctx->i80_if) { > - int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd; > + struct videomode vm; > + > + drm_display_mode_crtc_to_videomode(mode, &vm); > /* setup vertical timing values. */ > - vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start; > - vbpd = mode->crtc_vtotal - mode->crtc_vsync_end; > - vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay; > > - val = VIDTCON0_VBPD(vbpd - 1) | VIDTCON0_VFPD(vfpd - 1); > + val = VIDTCON0_VBPD(vm.vback_porch - 1) | > + VIDTCON0_VFPD(vm.vfront_porch - 1); > writel(val, ctx->regs + VIDTCON0); > > - val = VIDTCON1_VSPW(vsync_len - 1); > + val = VIDTCON1_VSPW(vm.vsync_len - 1); > writel(val, ctx->regs + VIDTCON1); > > /* setup horizontal timing values. */ > - hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start; > - hbpd = mode->crtc_htotal - mode->crtc_hsync_end; > - hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay; > - > - /* setup horizontal timing values. */ > - val = VIDTCON2_HBPD(hbpd - 1) | VIDTCON2_HFPD(hfpd - 1); > + val = VIDTCON2_HBPD(vm.hback_porch - 1) | > + VIDTCON2_HFPD(vm.hfront_porch - 1); > writel(val, ctx->regs + VIDTCON2); > > - val = VIDTCON3_HSPW(hsync_len - 1); > + val = VIDTCON3_HSPW(vm.hsync_len - 1); > writel(val, ctx->regs + VIDTCON3); > } > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > index d42ae2b..b3ab89d 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c > @@ -25,6 +25,7 @@ > > #include <video/of_display_timing.h> > #include <video/of_videomode.h> > +#include <video/videomode.h> > #include <video/samsung_fimd.h> > #include <drm/exynos_drm.h> > > @@ -463,7 +464,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc) > return; > } > } else { > - int vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd; > + struct videomode vm; > u32 vidcon1; > > /* setup polarity values */ > @@ -474,24 +475,19 @@ static void fimd_commit(struct exynos_drm_crtc *crtc) > vidcon1 |= VIDCON1_INV_HSYNC; > writel(vidcon1, ctx->regs + driver_data->timing_base + VIDCON1); > > + drm_display_mode_crtc_to_videomode(mode, &vm); > /* setup vertical timing values. */ > - vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start; > - vbpd = mode->crtc_vtotal - mode->crtc_vsync_end; > - vfpd = mode->crtc_vsync_start - mode->crtc_vdisplay; > > - val = VIDTCON0_VBPD(vbpd - 1) | > - VIDTCON0_VFPD(vfpd - 1) | > - VIDTCON0_VSPW(vsync_len - 1); > + val = VIDTCON0_VBPD(vm.vback_porch - 1) | > + VIDTCON0_VFPD(vm.vfront_porch - 1) | > + VIDTCON0_VSPW(vm.vsync_len - 1); > writel(val, ctx->regs + driver_data->timing_base + VIDTCON0); > > /* setup horizontal timing values. */ > - hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start; > - hbpd = mode->crtc_htotal - mode->crtc_hsync_end; > - hfpd = mode->crtc_hsync_start - mode->crtc_hdisplay; > > - val = VIDTCON1_HBPD(hbpd - 1) | > - VIDTCON1_HFPD(hfpd - 1) | > - VIDTCON1_HSPW(hsync_len - 1); > + val = VIDTCON1_HBPD(vm.hback_porch - 1) | > + VIDTCON1_HFPD(vm.hfront_porch - 1) | > + VIDTCON1_HSPW(vm.hsync_len - 1); > writel(val, ctx->regs + driver_data->timing_base + VIDTCON1); > } > > diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h > index 0d310be..9ac764b 100644 > --- a/include/drm/drm_modes.h > +++ b/include/drm/drm_modes.h > @@ -473,6 +473,8 @@ void drm_display_mode_from_videomode(const struct videomode *vm, > struct drm_display_mode *dmode); > void drm_display_mode_to_videomode(const struct drm_display_mode *dmode, > struct videomode *vm); > +void drm_display_mode_crtc_to_videomode(const struct drm_display_mode *dmode, > + struct videomode *vm); > void drm_bus_flags_from_videomode(const struct videomode *vm, u32 *bus_flags); > int of_get_drm_display_mode(struct device_node *np, > struct drm_display_mode *dmode, u32 *bus_flags, > -- > 2.7.4 > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯

3 5

[PATCH 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
by Paul Kocialkowski 06 May '18

06 May '18

This adds timings for the RGB666 variant of the Innolux AT070TN90 panel, as found on the Ainol AW1 tablet. The panel also supports RGB888 output. When RGB666 mode is used instead, the two extra lanes per component are grounded. In the future, it might become necessary to introduce a dedicated device-tree property to specify the bus format and maybe specify it in the mode description instead of panel description so that the appropriate mode can be selected for each bus format. Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index cbf1ab404ee7..351742df8ee1 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -1086,6 +1086,29 @@ static const struct panel_desc innolux_at070tn92 = { .bus_format = MEDIA_BUS_FMT_RGB888_1X24, }; +static const struct drm_display_mode innolux_at070tn90_mode = { + .clock = 40000, + .hdisplay = 800, + .hsync_start = 800 + 112, + .hsync_end = 800 + 112 + 1, + .htotal = 800 + 112 + 1 + 87, + .vdisplay = 480, + .vsync_start = 480 + 141, + .vsync_end = 480 + 141 + 1, + .vtotal = 480 + 141 + 1 + 38, + .vrefresh = 60, +}; + +static const struct panel_desc innolux_at070tn90 = { + .modes = &innolux_at070tn90_mode, + .num_modes = 1, + .size = { + .width = 154, + .height = 86, + }, + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, +}; + static const struct display_timing innolux_g101ice_l01_timing = { .pixelclock = { 60400000, 71100000, 74700000 }, .hactive = { 1280, 1280, 1280 }, @@ -2154,6 +2177,9 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "innolux,at070tn92", .data = &innolux_at070tn92, + }, { + .compatible = "innolux,at070tn90", + .data = &innolux_at070tn90, }, { .compatible ="innolux,g101ice-l01", .data = &innolux_g101ice_l01 -- 2.17.0

1 3

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.
by bugzilla-daemon＠bugzilla.kernel.org 06 May '18

06 May '18

https://bugzilla.kernel.org/show_bug.cgi?id=199025 Paul van Maaren (kernel(a)vanmaaren.org) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kernel(a)vanmaaren.org --- Comment #21 from Paul van Maaren (kernel(a)vanmaaren.org) --- I have the same problem on an Acer E13 (ES1-311-C4Q6), suspend was working as ex pected on 4.14.18 and hangs on all newer kernels I have tried. Was running Fedor a 27, just upgraded to 28 and no change. Working driver: # modinfo -F filename `lshw -c video | awk '/configuration: driver/{print $2}' | cut -d= -f2` /lib/modules/4.14.18-300.fc27.x86_64/kernel/drivers/gpu/drm/i915/i915.ko.xz -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[PATCH v3 0/8] R-Car DU: Support CRC calculation
by Laurent Pinchart 06 May '18

06 May '18

Hello, (Dave, there's a request for you below) This patch series adds support for CRC calculation to the rcar-du-drm driver. CRC calculation is supported starting at the Renesas R-Car Gen3 SoCs, as earlier versions don't have the necessary hardware. On Gen3 SoCs, the CRC is computed by the DISCOM module part of the VSP-D and VSP-DL. The DISCOM is interfaced to the VSP through the UIF glue and appears as a VSP entity with a sink pad and a source pad. The series starts with a switch to SPDX license headers in patch 1/8, prompted by a checkpatch.pl warning for a later patch that complained about missing SPDX license headers. It then continues with cleanup and refactoring. Patches 2/8 and 3/8 prepare for DISCOM and UIF support by extending generic code to make it usable for the UIF. Patch 4/8 documents a structure that will receive new fields. Patch 5/8 then extends the API exposed by the VSP driver to the DU driver to support CRC computation configuration and reporting. The patch unfortunately needs to touch both the VSP and DU drivers, so the whole series will need to be merged through a single tree. Patch 5/8 adds support for the DISCOM and UIF in the VSP driver, patch 7/8 integrates it in the DRM pipeline, and patch 8/8 finally implements the CRC API in the DU driver to expose CRC computation to userspace. The hardware supports computing the CRC at any arbitrary point in the pipeline on a configurable window of the frame. This patch series supports CRC computation on input planes or pipeline output, but on the full frame only. Support for CRC window configuration can be added later if needed but will require extending the userspace API, as the DRM/KMS CRC API doesn't support this feature. Compared to v1, the CRC source names for plane inputs are now constructed from plane IDs instead of plane indices. This allows userspace to match CRC sources with planes. Compared to v2, various small issues reported by reviewers have been fixed. I believe the series to now be ready for upstream merge. Note that exposing the DISCOM and UIF though the V4L2 API isn't supported as the module is only found in VSP-D and VSP-DL instances that are not exposed through V4L2. It is possible to expose those instances through V4L2 with a small modification to the driver for testing purpose. If the need arises to test DISCOM and UIF with such an out-of-tree patch, support for CRC reporting through a V4L2 control can be added later without affecting how CRC is exposed through the DRM/KMS API. The patches are based on top of the "[PATCH v2 00/15] R-Car VSP1: Dynamically assign blend units to display pipelines" patch series, itself based on top of the Linux media master branch and scheduled for merge in v4.18. The new base caused heavy conflicts, requiring this series to be merged through the V4L2 tree. Dave, I have verified that this series merges cleanly with your drm-next and drm-fixes branches, with the drm-misc-next and drm-misc-fixes branches, and with the R-Car DU patches I would like to get merged in v4.18 through your tree. Could I get your ack to merge this through the V4L2 tree ? For convenience the patches are available at git://linuxtv.org/pinchartl/media.git vsp1-discom-v3-20180428 The code has been tested through the kms-test-crc.py script part of the DU test suite available at git://git.ideasonboard.com/renesas/kms-tests.git discom Laurent Pinchart (8): v4l: vsp1: Use SPDX license headers v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper v4l: vsp1: Document the vsp1_du_atomic_config structure v4l: vsp1: Extend the DU API to support CRC computation v4l: vsp1: Add support for the DISCOM entity v4l: vsp1: Integrate DISCOM in display pipeline drm: rcar-du: Add support for CRC computation drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 156 ++++++++++++++++- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 15 ++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 +- drivers/media/platform/vsp1/Makefile | 2 +- drivers/media/platform/vsp1/vsp1.h | 10 +- drivers/media/platform/vsp1/vsp1_brx.c | 6 +- drivers/media/platform/vsp1/vsp1_brx.h | 6 +- drivers/media/platform/vsp1/vsp1_clu.c | 71 ++------ drivers/media/platform/vsp1/vsp1_clu.h | 6 +- drivers/media/platform/vsp1/vsp1_dl.c | 8 +- drivers/media/platform/vsp1/vsp1_dl.h | 6 +- drivers/media/platform/vsp1/vsp1_drm.c | 127 ++++++++++++-- drivers/media/platform/vsp1/vsp1_drm.h | 15 +- drivers/media/platform/vsp1/vsp1_drv.c | 26 ++- drivers/media/platform/vsp1/vsp1_entity.c | 103 +++++++++++- drivers/media/platform/vsp1/vsp1_entity.h | 13 +- drivers/media/platform/vsp1/vsp1_hgo.c | 6 +- drivers/media/platform/vsp1/vsp1_hgo.h | 6 +- drivers/media/platform/vsp1/vsp1_hgt.c | 6 +- drivers/media/platform/vsp1/vsp1_hgt.h | 6 +- drivers/media/platform/vsp1/vsp1_histo.c | 65 +------ drivers/media/platform/vsp1/vsp1_histo.h | 6 +- drivers/media/platform/vsp1/vsp1_hsit.c | 6 +- drivers/media/platform/vsp1/vsp1_hsit.h | 6 +- drivers/media/platform/vsp1/vsp1_lif.c | 71 ++------ drivers/media/platform/vsp1/vsp1_lif.h | 6 +- drivers/media/platform/vsp1/vsp1_lut.c | 71 ++------ drivers/media/platform/vsp1/vsp1_lut.h | 6 +- drivers/media/platform/vsp1/vsp1_pipe.c | 6 +- drivers/media/platform/vsp1/vsp1_pipe.h | 6 +- drivers/media/platform/vsp1/vsp1_regs.h | 46 ++++- drivers/media/platform/vsp1/vsp1_rpf.c | 6 +- drivers/media/platform/vsp1/vsp1_rwpf.c | 6 +- drivers/media/platform/vsp1/vsp1_rwpf.h | 6 +- drivers/media/platform/vsp1/vsp1_sru.c | 6 +- drivers/media/platform/vsp1/vsp1_sru.h | 6 +- drivers/media/platform/vsp1/vsp1_uds.c | 6 +- drivers/media/platform/vsp1/vsp1_uds.h | 6 +- drivers/media/platform/vsp1/vsp1_uif.c | 271 ++++++++++++++++++++++++++++++ drivers/media/platform/vsp1/vsp1_uif.h | 32 ++++ drivers/media/platform/vsp1/vsp1_video.c | 6 +- drivers/media/platform/vsp1/vsp1_video.h | 6 +- drivers/media/platform/vsp1/vsp1_wpf.c | 6 +- include/media/vsp1.h | 45 ++++- 44 files changed, 892 insertions(+), 417 deletions(-) create mode 100644 drivers/media/platform/vsp1/vsp1_uif.c create mode 100644 drivers/media/platform/vsp1/vsp1_uif.h -- Regards, Laurent Pinchart

6 16

[Bug 99549] pp: Failed to translate a shader
by bugzilla-daemon＠freedesktop.org 05 May '18

05 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=99549 Bug ID: 99549 Summary: pp: Failed to translate a shader Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: lonewolf(a)xs4all.nl QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 129162 --> https://bugs.freedesktop.org/attachment.cgi?id=129162&action=edit glxinfo > glxinfo.txt Many applications including glxinfo show these messages in console : pp: Failed to translate a shader for depth1fs pp: Failed to translate a shader for blend2fs pp: Failed to translate a shader for color1fs pp: Failed to translate a shader for blend2fs I was unable to figure out what component pp belongs to, so choose the driver for my card. mesa-git master, commit f8f7ea508b . ./autogen.sh --prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=i915,ilo,r300,r600,radeonsi,nouveau,svga,swrast,virgl \ --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \ --with-egl-platforms=x11,drm,wayland \ --with-vulkan-drivers=intel,radeon \ --with-sha1=libnettle \ --enable-texture-float \ --enable-osmesa \ --enable-xa \ --enable-nine \ --disable-xvmc \ --enable-vdpau \ --enable-omx \ --enable-opencl \ --enable-opencl-icd \ --enable-glx-tls glxinfo output (without the pp messages) attached -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
by bugzilla-daemon＠freedesktop.org 05 May '18

05 May '18

https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #69 from iive(a)yahoo.com --- I'm really out of ideas... Could you try using only the radeon kernel driver, just blacklist amdgpu one. See if the blender trace hangs and netconsole still doesn't give any warnings. See if you can completely disable iommu, when using radeon.ko. I've asked you at least 3 times to test "export mesa_glthread=false", but you never included it in your list of things you've tried. Same for `export RADEON_THREAD=false`. I haven't asked you, but add `MESA_DEBUG=flush` to the things to test. Now, if you have run out of things to test. You can try a prolonged experiment, that might not even bring usable result. If we had a case that hanged reliably, one thing to do is to locate the exact operation that causes the hang. So, you start `qapitrace` with the blender trace. You then do a binary search for the frame that causes hang. It's done by "Lookup State" at a frame number, it would replay the trace to that frame. You start with the full range, let's say [0 - 10000], so you pick the frame from the middle of that range, in this case frame#5000. If it hangs during replay, you use [0 - 5000] as interval, if it doesn't hang, then you use the other half [5000-10000] (because the cause of hang mush be there). Then you pick the middle of the new interval and repeat the experiment. (e.g. [0 - 2500]; [1250 - 2500]; [1250 - 1875]. Once you locate the exact frame that could cause the first hang, you can do the binary search, but this time on the draw operations inside that frame. It can help if you set: "qapitrace->Trace->Options->Only_show_the_following_events->Draw_events". Now, since crashing to you is kind of random, you might try to disable all threaded options (all options from above) and run same lookup a dozen of times. If it crashes even once, then it crashes. Also, be sure to write down the current range, as to not loose it at reboot. I also strongly encourage you to at least try some other distribution, something you can start from life-cd or something. Or build your own vanilla kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[GIT PULL FOR v4.18] R-Car DU changes
by Laurent Pinchart 05 May '18

05 May '18

Hi Dave, The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e: Linux 4.17-rc2 (2018-04-22 19:20:09 -0700) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git drm/du/next for you to fetch changes up to b06078de418d6f77c81aa74516f787663f51a262: drm: rcar-du: Track dma-buf fences (2018-05-05 17:12:46 +0300) I have verified that this does not conflict with any series touching the R-Car DU driver and scheduled to be merged through the linux-media tree. ---------------------------------------------------------------- Emre Ucan (1): drm: rcar-du: Track dma-buf fences Kieran Bingham (9): drm: rcar-du: of: Include header to define prototypes drm: rcar-du: Use NULL for table initialisation dt-bindings: display: renesas: du: Increase indent in output table dt-bindings: display: renesas: du: Document the r8a77965 bindings drm: rcar-du: Use the correct naming for ODPM fields in DEFR6 dt-bindings: display: renesas: Add R-Car M3-N HDMI TX DT bindings drm: rcar-du: Split CRTC handling to support hardware indexing drm: rcar-du: Allow DU groups to work with hardware indexing drm: rcar-du: Add R8A77965 support Laurent Pinchart (1): drm: rcar-du: Zero-out sg_tables when duplicating plane state .../bindings/display/bridge/renesas,dw-hdmi.txt | 1 + .../devicetree/bindings/display/renesas,du.txt | 28 +++++++------- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 26 +++++++------ drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 3 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 51 +++++++++++++--- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 +- drivers/gpu/drm/rcar-du/rcar_du_group.c | 16 +++++--- drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 25 ++++++++---- drivers/gpu/drm/rcar-du/rcar_du_of.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_regs.h | 16 ++++---- drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 10 +++-- 12 files changed, 120 insertions(+), 63 deletions(-) -- Regards, Laurent Pinchart

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2018