[Bug 101961] Serious Sam Fusion hangs system completely
https://bugs.freedesktop.org/show_bug.cgi?id=101961 --- Comment #10 from network...@rkmail.ru --- (In reply to Samuel Pitoiset from comment #9) > By the way, do you have some hints about how to reproduce, like which > settings, which steps, etc? Also, what version is exactly, I mean the Steam > appid? It's Serious Sam Fusion 2017 steam current version. Steam AppID: 564310 DLC: 564324 564323 612560 564321 564322 564320 Graphics options Graphics API: OpenGL Resolution: 1920x1200 Window Mode: Fullscreen Max 3D Rendering MPIX: 3.7(QHD 1440) MSAA: Medium 4x VSync: disabled Performance options CPU Speed: Medium GPU Speed: Medium GPU Memory: Medium Level Caching: High MAX FPS: Unlimited The last time it crashed yesterday I was playing multiplayer, but it should crash on 'Death Canyon' map in single player too (Single Player -> Survival -> Multiplayer Levels BFE -> Death Canyon). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] radeon: add fallthrough annotation
On Monday, 2017-07-31 03:05:47 +, Michel Dänzer wrote:
> On 31/07/17 05:34 AM, Eric Engestrom wrote:
> > GCC 7 started warning when a switch case has neither a `break` nor
> > a "fallthrough" comment.
> > Let's be explicit that we meant to fall through here.
> >
> > Signed-off-by: Eric Engestrom
> > ---
> > radeon/radeon_surface.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> > index 965be24c..04df77d6 100644
> > --- a/radeon/radeon_surface.c
> > +++ b/radeon/radeon_surface.c
> > @@ -2503,6 +2503,7 @@ static int radeon_surface_sanity(struct
> > radeon_surface_manager *surf_man,
> > if (surf->npix_y > 1) {
> > return -EINVAL;
> > }
> > +/* fallthrough */
> > case RADEON_SURF_TYPE_2D:
> > if (surf->npix_z > 1) {
> > return -EINVAL;
> >
>
> Reviewed-by: Michel Dänzer
Thanks!
>
> P.S. Patches touching the radeon (and amdgpu) directory should (also) be
> sent to the amd-gfx mailing list for review.
Sure, making a note.
Do we want a `scripts/get_(maintainer|reviewer).pl` for libdrm?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1.1] drm/rockchip: fix race with kms hotplug and fbdev
According to the kerneldoc[0], should do fbdev setup before calling drm_kms_helper_poll_init(), otherwise, Kms hotplug event may race into fbdev helper initial, and fb_helper->dev may be NULL pointer, that would cause the bug: [0.735411] [0200] *pgd=f6ffe003, *pud=f6ffe003, *pmd= [0.736156] Internal error: Oops: 9605 [#1] PREEMPT SMP [0.736648] Modules linked in: [0.736930] CPU: 2 PID: 20 Comm: kworker/2:0 Not tainted 4.4.41 #20 [0.737480] Hardware name: Rockchip RK3399 Board rev2 (BOX) (DT) [0.738020] Workqueue: events cdn_dp_pd_event_work [0.738447] task: ffc0f21f3100 ti: ffc0f2218000 task.ti: ffc0f2218000 [0.739109] PC is at mutex_lock+0x14/0x44 [0.739469] LR is at drm_fb_helper_hotplug_event+0x30/0x114 [0.756253] [] mutex_lock+0x14/0x44 [0.756260] [] drm_fb_helper_hotplug_event+0x30/0x114 [0.756271] [] rockchip_drm_output_poll_changed+0x18/0x20 [0.756280] [] drm_kms_helper_hotplug_event+0x28/0x34 [0.756286] [] cdn_dp_pd_event_work+0x394/0x3c4 [0.756295] [] process_one_work+0x218/0x3e0 [0.756302] [] worker_thread+0x2e8/0x404 [0.756308] [] kthread+0xe8/0xf0 [0.756316] [] ret_from_fork+0x10/0x40 [0]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms-helpers.html Signed-off-by: Mark Yao --- Changes in v1.1: - According to the kerneldoc, fix the race bug in generic way. drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 848edcf..c41f48a 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -161,22 +161,21 @@ static int rockchip_drm_bind(struct device *dev) */ drm_dev->irq_enabled = true; - /* init kms poll for handling hpd */ - drm_kms_helper_poll_init(drm_dev); - ret = rockchip_drm_fbdev_init(drm_dev); if (ret) - goto err_kms_helper_poll_fini; + goto err_unbind_all; + + /* init kms poll for handling hpd */ + drm_kms_helper_poll_init(drm_dev); ret = drm_dev_register(drm_dev, 0); if (ret) - goto err_fbdev_fini; + goto err_kms_helper_poll_fini; return 0; -err_fbdev_fini: - rockchip_drm_fbdev_fini(drm_dev); err_kms_helper_poll_fini: drm_kms_helper_poll_fini(drm_dev); + rockchip_drm_fbdev_fini(drm_dev); err_unbind_all: component_unbind_all(dev, drm_dev); err_mode_config_cleanup: -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm/exynos/dsi: refactor panel detection logic
Hi Andrzej,
2017년 04월 18일 21:39에 Andrzej Hajda 이(가) 쓴 글:
> Description of drm_helper_hpd_irq_event clearly states that drivers
> supporting hotplug events per connector should use different helper -
> drm_kms_helper_hotplug_event. To achieve it following changes have
> been performed:
> - moved down all DSI ops - they require exynos_dsi_disable function
> to be defined earlier,
> - simplified exynos_dsi_detect - there is no real detection, it just
> returns if panel is attached,
> - DSI attach/detach callbacks attaches/detaches DRM panel and sets
> connector status and other context fields accordingly, all this is
> performed under mutex, as these callbacks are asynchronous.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 204
>
> 1 file changed, 103 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 3ae459f..515090f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -254,7 +254,6 @@ struct exynos_dsi {
> struct drm_encoder encoder;
> struct mipi_dsi_host dsi_host;
> struct drm_connector connector;
> - struct device_node *panel_node;
> struct drm_panel *panel;
> struct device *dev;
>
> @@ -1329,12 +1328,13 @@ static int exynos_dsi_init(struct exynos_dsi *dsi)
> return 0;
> }
>
> -static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
> +static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi,
> + struct device *panel)
> {
> int ret;
> int te_gpio_irq;
>
> - dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
> + dsi->te_gpio = of_get_named_gpio(panel->of_node, "te-gpios", 0);
> if (dsi->te_gpio == -ENOENT)
> return 0;
>
> @@ -1374,85 +1374,6 @@ static void exynos_dsi_unregister_te_irq(struct
> exynos_dsi *dsi)
> }
> }
>
> -static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> - struct mipi_dsi_device *device)
> -{
> - struct exynos_dsi *dsi = host_to_dsi(host);
> -
> - dsi->lanes = device->lanes;
> - dsi->format = device->format;
> - dsi->mode_flags = device->mode_flags;
> - dsi->panel_node = device->dev.of_node;
> -
> - /*
> - * This is a temporary solution and should be made by more generic way.
> - *
> - * If attached panel device is for command mode one, dsi should register
> - * TE interrupt handler.
> - */
> - if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO)) {
> - int ret = exynos_dsi_register_te_irq(dsi);
> -
> - if (ret)
> - return ret;
> - }
> -
> - if (dsi->connector.dev)
> - drm_helper_hpd_irq_event(dsi->connector.dev);
> -
> - return 0;
> -}
> -
> -static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
> - struct mipi_dsi_device *device)
> -{
> - struct exynos_dsi *dsi = host_to_dsi(host);
> -
> - exynos_dsi_unregister_te_irq(dsi);
> -
> - dsi->panel_node = NULL;
> -
> - if (dsi->connector.dev)
> - drm_helper_hpd_irq_event(dsi->connector.dev);
> -
> - return 0;
> -}
> -
> -static ssize_t exynos_dsi_host_transfer(struct mipi_dsi_host *host,
> - const struct mipi_dsi_msg *msg)
> -{
> - struct exynos_dsi *dsi = host_to_dsi(host);
> - struct exynos_dsi_transfer xfer;
> - int ret;
> -
> - if (!(dsi->state & DSIM_STATE_ENABLED))
> - return -EINVAL;
> -
> - if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
> - ret = exynos_dsi_init(dsi);
> - if (ret)
> - return ret;
> - dsi->state |= DSIM_STATE_INITIALIZED;
> - }
> -
> - ret = mipi_dsi_create_packet(&xfer.packet, msg);
> - if (ret < 0)
> - return ret;
> -
> - xfer.rx_len = msg->rx_len;
> - xfer.rx_payload = msg->rx_buf;
> - xfer.flags = msg->flags;
> -
> - ret = exynos_dsi_transfer(dsi, &xfer);
> - return (ret < 0) ? ret : xfer.rx_done;
> -}
> -
> -static const struct mipi_dsi_host_ops exynos_dsi_ops = {
> - .attach = exynos_dsi_host_attach,
> - .detach = exynos_dsi_host_detach,
> - .transfer = exynos_dsi_host_transfer,
> -};
> -
> static void exynos_dsi_enable(struct drm_encoder *encoder)
> {
> struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> @@ -1508,25 +1429,7 @@ static void exynos_dsi_disable(struct drm_encoder
> *encoder)
> static enum drm_connector_status
> exynos_dsi_detect(struct drm_connector *connector, bool force)
> {
> - struct exynos_dsi *dsi = connector_to_dsi(connector);
> -
> - if (!dsi->panel) {
> - dsi->panel = of_drm_find_panel(dsi->panel_node);
> - if (dsi->panel)
> - drm_panel_attach(dsi->panel
Re: [PATCH 4/7] drm/exynos: propagate info about command mode from panel
2017년 04월 18일 21:40에 Andrzej Hajda 이(가) 쓴 글:
> mipi_dsi framework provides information about panel's mode of work.
> This info should be propagated upstream to configure all elements of
> the pipeline. As CRTC is the common nominator of the pipeline we can put
> such info into its structures.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 +
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 527bf1d..96b9d49 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -165,6 +165,7 @@ struct exynos_drm_crtc {
> const struct exynos_drm_crtc_ops*ops;
> void*ctx;
> struct exynos_drm_clk *pipe_clk;
> + booli80_mode : 1;
> };
>
> static inline void exynos_drm_pipe_clk_enable(struct exynos_drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 515090f..79df1c9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1545,6 +1545,8 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host
> *host,
> drm_panel_attach(dsi->panel, &dsi->connector);
> dsi->connector.status = connector_status_connected;
> }
> + exynos_drm_crtc_get_by_type(drm, EXYNOS_DISPLAY_TYPE_LCD)->i80_mode =
> + !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO);
No place to use i80_mode in this patch. Seems this patch, patch 5 and portion
of using i80_mode in patch 6 should become one patch.
Thanks,
Inki Dae
>
> mutex_unlock(&drm->mode_config.mutex);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 4/7] drm/omapdrm: Fix omap_atomic_wait_for_completion
Op 25-07-17 om 10:27 schreef Daniel Vetter: > On Wed, Jul 19, 2017 at 04:39:17PM +0200, Maarten Lankhorst wrote: >> Use the new iterator macro and look for crtc_state->active instead of >> enable, only crtc_state->enable implies that vblanks will happen. > s/enable/active/, since enable only means logically enabled (aka resources > reserved). With that my r-b holds. > -Daniel Ok thanks. I've pushed patch 1, 4, 5 and 6. I'll wait a bit longer for the conflict in patch 3, and for a better solution on async in patch 2. It seems the nouveau patches caused a bit of a conflict in nv50_disp_atomic_commit_tail because of better event handling compared to drm-misc, I've fixed up drm-tip. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode
Seems you mixed some different changes below with one patch.
1. add checking panel mode with i80_mode.
2. change te_irq to irq_te.
3. add new function, decon_atomic_check.
4. add considering more error cases in decon_conf_irq function.
5. register command and video mode interrupt handlers regardless of panel mode.
And the subject of this patch doesn't say everything to above changes.
Thanks,
Inki Dae
2017년 04월 18일 21:40에 Andrzej Hajda 이(가) 쓴 글:
> Since panel's mode of work is propagated properly from panel to DECON,
> there is no need to use redundant private property. The only issue with
> such approach is that check for required interrupts should be postponed
> until panel communicate its requirements - ie to atomic_check.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 98
> ---
> 1 file changed, 57 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 237b4c9..7a09e03 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -34,9 +34,8 @@
> #define WINDOWS_NR 3
> #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>
> -#define IFTYPE_I80 (1 << 0)
> -#define I80_HW_TRG (1 << 1)
> -#define IFTYPE_HDMI (1 << 2)
> +#define I80_HW_TRG (1 << 0)
> +#define IFTYPE_HDMI (1 << 1)
>
> static const char * const decon_clks_name[] = {
> "pclk",
> @@ -58,7 +57,9 @@ struct decon_context {
> struct regmap *sysreg;
> struct clk *clks[ARRAY_SIZE(decon_clks_name)];
> unsigned intirq;
> - unsigned intte_irq;
> + unsigned intirq_vsync;
> + unsigned intirq_lcd_sys;
> + unsigned intirq_te;
> unsigned long out_type;
> int first_win;
> spinlock_t vblank_lock;
> @@ -91,7 +92,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
> u32 val;
>
> val = VIDINTCON0_INTEN;
> - if (ctx->out_type & IFTYPE_I80)
> + if (crtc->i80_mode)
> val |= VIDINTCON0_FRAMEDONE;
> else
> val |= VIDINTCON0_INTFRMEN | VIDINTCON0_FRAMESEL_FP;
> @@ -100,7 +101,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc
> *crtc)
>
> enable_irq(ctx->irq);
> if (!(ctx->out_type & I80_HW_TRG))
> - enable_irq(ctx->te_irq);
> + enable_irq(ctx->irq_te);
>
> return 0;
> }
> @@ -110,7 +111,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc
> *crtc)
> struct decon_context *ctx = crtc->ctx;
>
> if (!(ctx->out_type & I80_HW_TRG))
> - disable_irq_nosync(ctx->te_irq);
> + disable_irq_nosync(ctx->irq_te);
> disable_irq_nosync(ctx->irq);
>
> writel(0, ctx->addr + DECON_VIDINTCON0);
> @@ -140,7 +141,7 @@ static u32 decon_get_frame_count(struct decon_context
> *ctx, bool end)
>
> switch (status & (VIDCON1_VSTATUS_MASK | VIDCON1_I80_ACTIVE)) {
> case VIDCON1_VSTATUS_VS:
> - if (!(ctx->out_type & IFTYPE_I80))
> + if (!(ctx->crtc->i80_mode))
> --frm;
> break;
> case VIDCON1_VSTATUS_BP:
> @@ -167,7 +168,7 @@ static u32 decon_get_vblank_counter(struct
> exynos_drm_crtc *crtc)
>
> static void decon_setup_trigger(struct decon_context *ctx)
> {
> - if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
> + if (!ctx->crtc->i80_mode && !(ctx->out_type & I80_HW_TRG))
> return;
>
> if (!(ctx->out_type & I80_HW_TRG)) {
> @@ -207,7 +208,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> val = VIDOUT_LCD_ON;
> if (interlaced)
> val |= VIDOUT_INTERLACE_EN_F;
> - if (ctx->out_type & IFTYPE_I80) {
> + if (crtc->i80_mode) {
> val |= VIDOUT_COMMAND_IF;
> } else {
> val |= VIDOUT_RGB_IF;
> @@ -223,7 +224,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> VIDTCON2_HOZVAL(m->hdisplay - 1);
> writel(val, ctx->addr + DECON_VIDTCON2);
>
> - if (!(ctx->out_type & IFTYPE_I80)) {
> + if (!crtc->i80_mode) {
> int vbp = m->crtc_vtotal - m->crtc_vsync_end;
> int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
>
> @@ -456,7 +457,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
> int i;
>
> if (!(ctx->out_type & I80_HW_TRG))
> - synchronize_irq(ctx->te_irq);
> + synchronize_irq(ctx->irq_te);
> synchronize_irq(ctx->irq);
>
> /*
> @@ -511,6 +512,22 @@ static void decon_clear_channels(struct exynos_drm_crtc
> *crtc)
> clk_disable_unprepare(ctx->clks[i]);
> }
>
> +static int decon_atomic_c
Re: [PATCH] drm/omap: Rework the rotation-on-crtc hack
Hi Maarten,
On Tuesday 01 Aug 2017 07:59:13 Maarten Lankhorst wrote:
> Op 31-07-17 om 17:42 schreef Daniel Vetter:
> > I want/need to rework the core property handling, and this hack is
> > getting in the way. But since it's a non-standard propety only used by
> > legacy userspace we know that this will only every be called from
> > ioctl code. And never on some other free-standing state struct, where
> > this old hack wouldn't work either.
> >
> > v2: don't forget zorder and get_property!
> >
> > v3: Shadow the legacy state to avoid locking issues in get_property
> > (Maarten).
> >
> > v4: Review from Laurent
> > - Move struct omap_crtc_state into omap_crtc.c
> > - Clean up comments.
> > - Don't forget to copy the shadowed state over on duplicate.
> >
> > v5: Don't forget to update the reset handler (Maarten).
> >
> > Reviewed-by: Laurent Pinchart (v4)
> > Cc: Maarten Lankhorst
> > Cc: Tomi Valkeinen > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> >
> > drivers/gpu/drm/omapdrm/omap_crtc.c | 109 ---
> > 1 file changed, 72 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> > b/drivers/gpu/drm/omapdrm/omap_crtc.c index 14e8a7738b06..9014085c33df
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
[snip]
> > static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
> > struct drm_crtc_state *state,
> > struct drm_property *property,
> > uint64_t val)
> > {
> > - if (omap_crtc_is_plane_prop(crtc, property)) {
> > - struct drm_plane_state *plane_state;
> > - struct drm_plane *plane = crtc->primary;
> > -
> > - /*
> > -* Delegate property set to the primary plane. Get the plane
> > -* state and set the property directly.
> > -*/
> > -
> > - plane_state = drm_atomic_get_plane_state(state->state, plane);
> > - if (IS_ERR(plane_state))
> > - return PTR_ERR(plane_state);
> > + struct omap_drm_private *priv = crtc->dev->dev_private;
> > + struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
> > + struct drm_plane_state *plane_state;
> >
> > - return drm_atomic_plane_set_property(plane, plane_state,
> > - property, val);
> > + /*
> > +* Delegate property set to the primary plane. Get the plane state and
> > +* set the property directly, but keep a shadow copy for the
> > +* atomic_get_property callback.
> > +*/
> > + plane_state = drm_atomic_get_plane_state(state->state, crtc->primary);
> > + if (IS_ERR(plane_state))
> > + return PTR_ERR(plane_state);
> > +
> > + if (property == crtc->primary->rotation_property) {
> > + plane_state->rotation = val;
> > + omap_state->rotation = val;
> > + } else if (property == priv->zorder_prop) {
> > + plane_state->zpos = val;
> > + omap_state->zpos = val;
>
> With atomic we should try to always make the getprop values accurate, or
> compositors might have troubles restoring.
>
> I would update the shadow values in omap_crtc_atomic_check through
> omap_crtc_atomic_check instead, with something like this:
>
> + pri_state = drm_atomic_get_new_plane_state(crtc->primary,
> state->state);
> + if (pri_state) {
> + struct omap_crtc_state *omap_crtc_state =
> + to_omap_crtc_state(state);
> +
> + omap_crtc_state->zpos = pri_state->zpos;
> + omap_crtc_state->rotation = pri_state->rotation;
> + }
>
> That way even when updating the property through the primary plane, it gets
> reflected correctly. For example when vt switching with fbdev.
Let's not make it over-complicated. This hack is only needed fo the legacy X
OMAP modesetting driver. The CRTC zpos and rotation properties should not be
used through the atomic API.
> > + } else {
> > + return -EINVAL;
> > }
> >
> > - return -EINVAL;
> > + return 0;
> > }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/msm: NULL pointer dereference in drivers/gpu/drm/msm/msm_gem_vma.c
On Sun, Jul 30, 2017 at 8:46 AM, Hans Verkuil wrote: > Hi all, > > While I was testing the upcoming adv7533 CEC support with my Dragonboard c410 > I encountered this NULL pointer dereference: > > [ 17.912822] Unable to handle kernel NULL pointer dereference at virtual > address 00e8 > [ 17.917191] user pgtable: 4k pages, 48-bit VAs, pgd = 800030e9f000 > [ 17.925249] [00e8] *pgd=b0daf003, *pud= > [ 17.931650] Internal error: Oops: 9605 [#1] PREEMPT SMP > [ 17.938395] Modules linked in: btqcomsmd btqca arc4 wcn36xx mac80211 > bluetooth cfg80211 ecdh_generic r8152 snd_soc_hdmi_codec adv7511 cec > qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm > [ 17.943967] CPU: 0 PID: 1684 Comm: Xorg Tainted: GW > 4.13.0-rc1-dragonboard #111 > [ 17.962005] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) > [ 17.970685] task: 800031236c00 task.stack: 800033fbc000 > [ 17.977582] PC is at msm_gem_unmap_vma+0x20/0x80 [msm] > [ 17.983213] LR is at put_iova+0x60/0xb8 [msm] > [ 17.988303] pc : [] lr : [] pstate: > 2145 > [ 17.992733] sp : 800033fbfb30 > [ 18.000193] x29: 800033fbfb30 x28: 800030b5f000 > [ 18.003407] x27: 00b4 x26: 009f8cd8 > [ 18.008789] x25: 0004 x24: dead0100 > [ 18.014085] x23: dead0200 x22: 800030b5fd40 > [ 18.019379] x21: 800030b5fc00 x20: > [ 18.024675] x19: 80003082bf00 x18: > [ 18.029970] x17: b3347e70 x16: 08207638 > [ 18.035265] x15: 0053 x14: > [ 18.040560] x13: 0038 x12: 0101010101010101 > [ 18.045855] x11: 7f7f7f7f7f7f7f7f x10: 0040 > [ 18.051150] x9 : 800030b5f038 x8 : 800031657b50 > [ 18.056446] x7 : 800031657b78 x6 : > [ 18.061740] x5 : x4 : b5c01000 > [ 18.067036] x3 : x2 : 8000337bf300 > [ 18.072330] x1 : 80003082bf00 x0 : > [ 18.077629] Process Xorg (pid: 1684, stack limit = 0x800033fbc000) > [ 18.082925] Stack: (0x800033fbfb30 to 0x800033fc) > [ 18.089262] fb20: 800033fbfb60 > 00ac07c8 > [ 18.095081] fb40: 80003082bf00 800030b5fc90 800030b5fc00 > 00abf4a0 > [ 18.102893] fb60: 800033fbfba0 00ac16b0 800030b5fc00 > 8000338ff870 > [ 18.110706] fb80: 8000338ff800 800030b5fc00 800030b5fda8 > 800033fbfd80 > [ 18.118518] fba0: 800033fbfbe0 009d4244 800030b5fc00 > 800030b5f038 > [ 18.126332] fbc0: 800033fbfbd0 800030b5fc00 800030b5f038 > 009d4840 > [ 18.134144] fbe0: 800033fbfbf0 009d4858 800033fbfc10 > 009d48e4 > [ 18.141955] fc00: 800030b5fc00 8000338ffd98 800033fbfc30 > 009d49a4 > [ 18.149768] fc20: 800030b5fc00 800030b5f000 800033fbfc60 > 009d4a4c > [ 18.157581] fc40: 800030b5f050 800030b5f000 0001 > 800030b5fc00 > [ 18.165394] fc60: 800033fbfca0 009d4ab0 0018 > 800030b5f000 > [ 18.173206] fc80: 009efd28 800033fbfd80 8000338ff800 > 009d56a8 > [ 18.181019] fca0: 800033fbfcb0 009efd54 800033fbfcc0 > 009d56c8 > [ 18.188831] fcc0: 800033fbfd00 009d58e0 009fa6e0 > c00464b4 > [ 18.196643] fce0: 0004 80003082b400 ea1f0e00 > > [ 18.204456] fd00: 800033fbfe00 08206f0c 8335caf8 > 80003082b400 > [ 18.212269] fd20: ea1f0e00 80003082b400 c00464b4 > ea1f0e00 > [ 18.220081] fd40: 0124 001d 089d2000 > 800031236c00 > [ 18.227894] fd60: 800033fbfd80 0004 009efd28 > 800033fbfd80 > [ 18.235706] fd80: 00010001 0081 00180020 > 0001 > [ 18.243518] fda0: 0001 00010001 > > [ 18.251331] fdc0: 0124 0038 089d2000 > 800031236c00 > [ 18.259144] fde0: 800033fbfe40 08214124 800033fbfe30 > 08203290 > [ 18.266956] fe00: 800033fbfe80 082076b4 > 800030d8a000 > [ 18.274768] fe20: 80003082b400 0016 800033fbfe50 > 081f0488 > [ 18.282581] fe40: 800033fbfe80 08207678 > 80003082b400 > [ 18.290393] fe60: 800033fbfe70 082138b0 800033fbfe80 > 08207658 > [ 18.298207] fe80: 08082f84 > 800034a16000 > [ 18.306017] fea0: b3347e7c > 0015 > [ 18.313832] fec0:
Re: WARN_ON in drivers/gpu/drm/msm/msm_gem.c
On Sun, Jul 30, 2017 at 8:42 AM, Hans Verkuil wrote:
> Hi all,
>
> While I was testing the upcoming adv7533 CEC support with my Dragonboard c410
> I encountered this warning several times during boot:
>
> [4.408309] WARNING: CPU: 3 PID: 1347 at drivers/gpu/drm/msm/msm_gem.c:312
> add_vma+0x78/0x88 [msm]
> [4.412951] Modules linked in: snd_soc_hdmi_codec adv7511 cec
> qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm
> [4.421728] CPU: 3 PID: 1347 Comm: kworker/3:3 Not tainted
> 4.13.0-rc1-dragonboard #111
> [4.433090] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> [4.441081] Workqueue: events deferred_probe_work_func
> [4.447929] task: 800031243600 task.stack: 83394000
> [4.453023] PC is at add_vma+0x78/0x88 [msm]
> [4.458823] LR is at _msm_gem_new+0xd4/0x188 [msm]
> [4.463207] pc : [] lr : [] pstate:
> 4145
> [4.467811] sp : 833978a0
> [4.475357] x29: 833978a0 x28: 831dea18
> [4.478572] x27: 83933a00 x26: 83b39800
> [4.483953] x25: 8000338ff800 x24: 0001
> [4.489249] x23: x22: 83b39800
> [4.494544] x21: 8000338ff800 x20:
> [4.499839] x19: 83932600 x18: 0001
> [4.505135] x17: 8969e9e0 x16: 7e0ce7a0
> [4.510429] x15: x14: 8000833977ef
> [4.515724] x13: 833977f3 x12: 0038
> [4.521020] x11: 0101010101010101 x10: ff7f7fff7f7f
> [4.526315] x9 : x8 : 83932800
> [4.531633] x7 : x6 : 003f
> [4.531644] x5 : 0040 x4 :
> [4.531650] x3 : 800031243600 x2 :
> [4.531655] x1 : x0 :
> [4.531670] Call trace:
> [4.531676] Exception stack(0x833976c0 to 0x833977f0)
> [4.531683] 76c0: 83932600 0001 833978a0
> 00ac01f8
> [4.531688] 76e0: 0140 83932550
> 83397780
> [4.531694] 7700: 83397730 08261ce8
> 831d2f80
> [4.531699] 7720: 83397800 081d671c 0140
>
> [4.531705] 7740: 00ac04c0 4003 83397908
> 014080c0
> [4.531710] 7760: 83b39800
>
> [4.531716] 7780: 800031243600
> 0040
> [4.531721] 77a0: 003f 83932800
>
> [4.531726] 77c0: ff7f7fff7f7f 0101010101010101 0038
> 833977f3
> [4.531730] 77e0: 8000833977ef
> [4.531881] [] add_vma+0x78/0x88 [msm]
> [4.532011] [] _msm_gem_new+0xd4/0x188 [msm]
> [4.532134] [] msm_gem_new+0x10/0x18 [msm]
> [4.532260] [] msm_dsi_host_modeset_init+0x17c/0x268
> [msm]
> [4.532384] [] msm_dsi_modeset_init+0x34/0x1b8 [msm]
> [4.532504] [] modeset_init+0x408/0x488 [msm]
> [4.532623] [] mdp5_kms_init+0x2b4/0x338 [msm]
> [4.532745] [] msm_drm_bind+0x218/0x4e8 [msm]
> [4.532755] [] try_to_bring_up_master+0x1f4/0x318
> [4.532762] [] component_add+0x98/0x180
> [4.532887] [] dsi_dev_probe+0x18/0x28 [msm]
> [4.532895] [] platform_drv_probe+0x58/0xc0
> [4.532901] [] driver_probe_device+0x324/0x458
> [4.532907] [] __device_attach_driver+0xac/0x170
> [4.532913] [] bus_for_each_drv+0x4c/0x98
> [4.532918] [] __device_attach+0xc0/0x160
> [4.532924] [] device_initial_probe+0x10/0x18
> [4.532929] [] bus_probe_device+0x94/0xa0
> [4.532934] [] deferred_probe_work_func+0x8c/0xe8
> [4.532941] [] process_one_work+0x1d4/0x330
> [4.532946] [] worker_thread+0x48/0x468
> [4.532952] [] kthread+0x12c/0x130
> [4.532958] [] ret_from_fork+0x10/0x40
> [4.532962] ---[ end trace b1ac6888ec40b0bb ]---
>
> After making this hack:
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 65f35544c1ec..29459be6a4b0 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -928,8 +928,12 @@ static struct drm_gem_object *_msm_gem_new(struct
> drm_device *dev,
> if (use_vram) {
> struct msm_gem_vma *vma;
> struct page **pages;
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> +
> + mutex_lock(&msm_obj->lock);
>
> vma = add_vma(obj, NULL);
> + mutex_unlock(&msm_obj->lock);
> if (IS_ERR(vma)) {
> ret = PTR_ERR(vma);
> goto fail;
>
> it no longer complains. I have no idea how long the lock should be held here,
> but on the off-chance that I am actually right:
yup, this looks like the correct fi
Re: [PATCH] Add drm ioctl DRM_IOCTL_MODE_GETFB2 & associated helpers.
Hi Joe,
Thank you for the patch.
On Monday 31 Jul 2017 11:29:13 Joe Kniss wrote:
> New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric
> with addfb2.
What's the use case for this ? We haven't needed such an ioctl for so long
that it seemed to me that userspace doesn't really need it, but I could be
wrong.
> Also modifies *_fb_create_handle() calls to accept a
> format_plane_index so that handles for each plane can be generated.
> Previously, many *_fb_create_handle() calls simply defaulted to plane 0
> only.
And with this patch the amd/amdgpu, armada, gma500, i915, mediatek, msm,
nouveau and radeon drivers still do. Do none of them support multi-planar
formats ?
> Signed-off-by: Joe Kniss
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +-
> drivers/gpu/drm/armada/armada_fb.c | 1 +
> drivers/gpu/drm/drm_crtc_internal.h | 2 +
> drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++--
> drivers/gpu/drm/drm_framebuffer.c | 79 +-
> drivers/gpu/drm/drm_ioctl.c | 1 +
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 7 ++-
> drivers/gpu/drm/gma500/framebuffer.c| 2 +
> drivers/gpu/drm/i915/intel_display.c| 1 +
> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 1 +
> drivers/gpu/drm/msm/msm_fb.c| 5 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
> drivers/gpu/drm/omapdrm/omap_fb.c | 5 +-
> drivers/gpu/drm/radeon/radeon_display.c | 5 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++-
> drivers/gpu/drm/tegra/fb.c | 9 +++-
> include/drm/drm_framebuffer.h | 1 +
> include/uapi/drm/drm.h | 2 +
> 18 files changed, 127 insertions(+), 17 deletions(-)
[snip]
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c index 28a0108a1ab8..67b3be1bedbc 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include "drm_crtc_internal.h"
[snip]
> +/**
> + * drm_mode_getfb2 - get FB info
> + * @dev: drm device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: drm file for the ioctl call
> + *
> + * Lookup the FB given its ID and return info about it.
> + *
> + * Called by the user via ioctl.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_getfb2(struct drm_device *dev,
> +void *data, struct drm_file *file_priv)
> +{
> + struct drm_mode_fb_cmd2 *r = data;
> + struct drm_framebuffer *fb;
> + int ret, i;
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
> +
> + fb = drm_framebuffer_lookup(dev, r->fb_id);
> + if (!fb)
> + return -ENOENT;
> +
> + r->height = fb->height;
> + r->width = fb->width;
> + r->pixel_format = fb->format->format;
> + for (i = 0; i < 4; ++i) {
> + r->pitches[i] = fb->pitches[i];
> + r->offsets[i] = fb->offsets[i];
> + r->modifier[i] = fb->modifier;
> + r->handles[i] = 0;
> + }
> +
> + for (i = 0; i < fb->format->num_planes; ++i) {
> + if (fb->funcs->create_handle) {
> + if (drm_is_current_master(file_priv) ||
> + capable(CAP_SYS_ADMIN) ||
> + drm_is_control_client(file_priv)) {
> + ret = fb->funcs->create_handle(fb, i,
> file_priv,
> +
> &r->handles[i]);
> + if (ret)
> + break;
> + } else {
> + /* GET_FB() is an unprivileged ioctl so we
> must
> + * not return a buffer-handle to non-master
> + * processes! For backwards-compatibility
> + * reasons, we cannot make GET_FB()
> privileged,
> + * so just return an invalid handle for
> + * non-masters. */
There's no backward compatibility to handle here, just make it privileged if
it has to be.
> + r->handles[i] = 0;
> + ret = 0;
> + }
> + } else {
> + ret = -ENODEV;
> + break;
> + }
> + }
> +
> + /* If handle creation failed, delete/dereference any that were made.
*/
> + if (ret) {
> + for (i = 0; i < 4; ++i) {
> + if (r->handles[i])
> + drm_gem_handle_delete(file_priv, r-
>handles[i]);
My initial reaction to this was to reply that not all drivers use GEM, but
after some investigation it seems they actually do. If that's really th
[Bug 101377] Gigabyte R9 380 card fails to load, kernel reports bug
https://bugs.freedesktop.org/show_bug.cgi?id=101377 --- Comment #10 from Alexander Tsoy --- (In reply to john from comment #9) > unfortunately copying the firmware did not solve the problem. the fan noise > is no longer emitted, however the graphics driver still fails to properly > load. Did you rebuild initramfs after copying the firmware? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=101672 --- Comment #20 from MirceaKitsune --- For the time being, I've decided to test whether this also happens with the RadeonSI scheduler. To make sure I'm applying it to all games across the system, I've added the following line to ~/.profile and restarted: export R600_DEBUG=sisched I managed to play Minecraft for over an hour several times, including in areas with many mobs and therefore skeletal models in view... so far no freeze. However it will take much more testing to be sure this makes a difference, so far there is no real verdict. I'll also follow the advice of testing with Supertux Kart, which should be an easier test case for other developers. If the SI scheduler does turn out to fix the problem, it would mean this is a bug specific to the old scheduler (still default, hence why that environment variable is needed to switch). That would make sense since IIRC the scheduler influences how drawable items are queued and rendered, which is a likely candidate for something causing an error that freezes the system. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH v2 2/2] drm/bridge: adv7511: restrict audio sample sizes
On 01/08/17 09:42, Arnaud Pouliquen wrote:
Hello Srinivas,
On 08/01/2017 12:49 AM, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
ADV7533 only supports audio samples word width from 16-24 bits.
This patch restricts the audio sample sizes to the supported ones,
so that sound card does not report wrong list of supported hwparms.
Without this patch aplay would fail when playing a 32 bit audio.
Signed-off-by: Srinivas Kandagatla
---
drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
index 67469c26bae8..d01d0aa0eef7 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -214,6 +214,8 @@ static struct hdmi_codec_pdata codec_data = {
.ops = &adv7511_codec_ops,
.max_i2s_channels = 2,
.i2s = 1,
+ .formats = (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE),
};
I'm not sure that this limitation is needed.
I already used ADV7513 and i did not observe this limitation.
I had a look to ADV7533 data-sheet. it should support 32 and 64 bits I2S
ADV7511_REG_AUDIO_CFG3(0x14) register definition in datasheet and the
code in this driver suggest that It only supports 16Bit and 24Bit samples.
format bus, with 16 or 24 bits precision sample. So it should support
SNDRV_PCM_FMTBIT_S32_LE and SNDRV_PCM_FMTBIT_S32_BE
As example, if you configure bus in Left justified format with 24 bits
sample length, 32 bits application samples should be truncated to 24
bits samples at ADV7533 I2S interface level (LSB dropped).
May be we can do that to make the user happy but isn't this just
truncate the resolution to 24Bit then?
And it's a false indication that we are supporting 32bit samples.
Which am not very happy with.
Perhaps i missed something... but look like more an I2S bus
configuration issue in your DT card description, that that a miss in the
drivers.
Nothing to do with DT or other driver, adv7533 audio driver does not
support 32 bit sample size which is why it would return -EINVAL from
adv7511_hdmi_hw_params().
This patch is fixing the loose ends, by which I mean the card would
report the exact supported sample sizes to user rather than every thing
in the I2S_FORMATS list.
Thanks,
srini
Regards
Arnaud
int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH v2 2/2] drm/bridge: adv7511: restrict audio sample sizes
On Tue, Aug 01, 2017 at 01:24:03PM +0100, Srinivas Kandagatla wrote: > On 01/08/17 09:42, Arnaud Pouliquen wrote: > > On 08/01/2017 12:49 AM, srinivas.kandaga...@linaro.org wrote: > > I already used ADV7513 and i did not observe this limitation. > > I had a look to ADV7533 data-sheet. it should support 32 and 64 bits I2S > ADV7511_REG_AUDIO_CFG3(0x14) register definition in datasheet and the code > in this driver suggest that It only supports 16Bit and 24Bit samples. The amount of data it pays attention to in the frame is not the same as the size of the frame. > > format bus, with 16 or 24 bits precision sample. So it should support > > SNDRV_PCM_FMTBIT_S32_LE and SNDRV_PCM_FMTBIT_S32_BE > > As example, if you configure bus in Left justified format with 24 bits > > sample length, 32 bits application samples should be truncated to 24 > > bits samples at ADV7533 I2S interface level (LSB dropped). > May be we can do that to make the user happy but isn't this just truncate > the resolution to 24Bit then? > And it's a false indication that we are supporting 32bit samples. > Which am not very happy with. This is what the sample_bits field in the DAI structure is for. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH v2 2/2] drm/bridge: adv7511: restrict audio sample sizes
On 01/08/17 13:28, Mark Brown wrote: On Tue, Aug 01, 2017 at 01:24:03PM +0100, Srinivas Kandagatla wrote: On 01/08/17 09:42, Arnaud Pouliquen wrote: On 08/01/2017 12:49 AM, srinivas.kandaga...@linaro.org wrote: I already used ADV7513 and i did not observe this limitation. I had a look to ADV7533 data-sheet. it should support 32 and 64 bits I2S ADV7511_REG_AUDIO_CFG3(0x14) register definition in datasheet and the code in this driver suggest that It only supports 16Bit and 24Bit samples. The amount of data it pays attention to in the frame is not the same as the size of the frame. I agree. format bus, with 16 or 24 bits precision sample. So it should support SNDRV_PCM_FMTBIT_S32_LE and SNDRV_PCM_FMTBIT_S32_BE As example, if you configure bus in Left justified format with 24 bits sample length, 32 bits application samples should be truncated to 24 bits samples at ADV7533 I2S interface level (LSB dropped). May be we can do that to make the user happy but isn't this just truncate the resolution to 24Bit then? And it's a false indication that we are supporting 32bit samples. Which am not very happy with. This is what the sample_bits field in the DAI structure is for.ya. But still reporting that driver supports 32 bit samples when it does not really support all 32 bits, is kinda misleading to user. Isn't it? And the driver would be end up with hacked up code for each case. --srini ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/bridge: tc358767: do no fail on hi-res displays
On Thu, 2017-07-27 at 15:47 +0300, Andrey Gusakov wrote:
> Do not fail data rates higher than 2.7 and more than 2 lanes.
> Try to fall back to 2.7Gbps and 2 lanes.
>
> Signed-off-by: Andrey Gusakov
> ---
> drivers/gpu/drm/bridge/tc358767.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 5c26488e7a2d..f605bb7d1aa3 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -603,8 +603,15 @@ static int tc_get_display_props(struct tc_data *tc)
> ret = drm_dp_link_probe(&tc->aux, &tc->link.base);
> if (ret < 0)
> goto err_dpcd_read;
> - if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27))
> - goto err_dpcd_inval;
> + if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27)) {
> + dev_dbg(tc->dev, "Falling to 2.7 Gbps rate\n");
> + tc->link.base.rate = 27;
> + }
> +
> + if (tc->link.base.num_lanes > 2) {
> + dev_dbg(tc->dev, "Falling to 2 lanes\n");
> + tc->link.base.num_lanes = 2;
> + }
>
> ret = drm_dp_dpcd_readb(&tc->aux, DP_MAX_DOWNSPREAD, tmp);
> if (ret < 0)
> @@ -637,9 +644,6 @@ static int tc_get_display_props(struct tc_data *tc)
> err_dpcd_read:
> dev_err(tc->dev, "failed to read DPCD: %d\n", ret);
> return ret;
> -err_dpcd_inval:
> - dev_err(tc->dev, "invalid DPCD\n");
> - return -EINVAL;
> }
>
> static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode
> *mode)
Acked-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] ASoC: dwc: Added a quirk DW_I2S_QUIRK_16BIT_IDX_OVERRIDE to dwc driver
On Fri, Jul 28, 2017 at 03:31:26PM -0400, Alex Deucher wrote: > This patch is already applied to the audio tree, I'm just > including it here for completeness since it's not yet in > the drm tree. It's in mainline, please don't resubmit already applied patches. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/bridge: tc358767: fix timing calculations
On Thu, 2017-07-27 at 15:47 +0300, Andrey Gusakov wrote: > Fields in HTIM01 and HTIM02 regs should be even. > Recomended thresh_dly value is max_tu_symbol. What about the VSDELAY change? This should be mentioned in the commit message. > Signed-off-by: Andrey Gusakov > --- > drivers/gpu/drm/bridge/tc358767.c | 34 -- > 1 file changed, 20 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c > b/drivers/gpu/drm/bridge/tc358767.c > index 4aee6178d889..c657a00af508 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -659,6 +659,14 @@ static int tc_set_video_mode(struct tc_data *tc, struct > drm_display_mode *mode) > int lower_margin = mode->vsync_start - mode->vdisplay; > int vsync_len = mode->vsync_end - mode->vsync_start; > > + /* > + * Recommended maximum number of symbols transferred in a transfer unit: > + * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size, > + * (output active video bandwidth in bytes)) > + * Must be less than tu_size. > + */ > + max_tu_symbol = TU_SIZE_RECOMMENDED - 1; > + > dev_dbg(tc->dev, "set mode %dx%d\n", > mode->hdisplay, mode->vdisplay); > dev_dbg(tc->dev, "H margin %d,%d sync %d\n", > @@ -668,13 +676,18 @@ static int tc_set_video_mode(struct tc_data *tc, struct > drm_display_mode *mode) > dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal); > > > - /* LCD Ctl Frame Size */ > - tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ | > + /* > + * LCD Ctl Frame Size > + * datasheet is not clear of vsdelay in case of DPI > + * assume we do not need any delay when DPI is a source of > + * sync signals > + */ > + tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ | VSDELAY is documented as the delay in pixel clocks between the time a VSYNC/HSYNC Start DSI packet is received and the time HSYNC/VSYNC is asserted in the DP output. I assume that this field is just ignored in DPI mode. >OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED); > - tc_write(HTIM01, (left_margin << 16) | /* H back porch */ > - (hsync_len << 0)); /* Hsync */ > - tc_write(HTIM02, (right_margin << 16) | /* H front porch */ > - (mode->hdisplay << 0));/* width */ > + tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */ > + (ALIGN(hsync_len, 2) << 0));/* Hsync */ > + tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) | /* H front porch */ > + (ALIGN(mode->hdisplay, 2) << 0)); /* width */ > tc_write(VTIM01, (upper_margin << 16) | /* V back porch */ >(vsync_len << 0)); /* Vsync */ > tc_write(VTIM02, (lower_margin << 16) | /* V front porch */ > @@ -693,7 +706,7 @@ static int tc_set_video_mode(struct tc_data *tc, struct > drm_display_mode *mode) > /* DP Main Stream Attributes */ > vid_sync_dly = hsync_len + left_margin + mode->hdisplay; > tc_write(DP0_VIDSYNCDELAY, > - (0x003e << 16) | /* thresh_dly */ > + (max_tu_symbol << 16) |/* thresh_dly */ >(vid_sync_dly << 0)); > > tc_write(DP0_TOTALVAL, (mode->vtotal << 16) | (mode->htotal)); > @@ -709,13 +722,6 @@ static int tc_set_video_mode(struct tc_data *tc, struct > drm_display_mode *mode) > tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | >DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); > > - /* > - * Recommended maximum number of symbols transferred in a transfer unit: > - * DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size, > - * (output active video bandwidth in bytes)) > - * Must be less than tu_size. > - */ > - max_tu_symbol = TU_SIZE_RECOMMENDED - 1; > tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) | > BPC_8); > Otherwise, Acked-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm/bridge: tc358767: filter out too high modes
On Thu, 2017-07-27 at 15:47 +0300, Andrey Gusakov wrote:
> Minimum pixel clock period is 6.5 nS for DPI. Do not accept modes
> with lower pixel clock period.
>
> Signed-off-by: Andrey Gusakov
> ---
> drivers/gpu/drm/bridge/tc358767.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index f605bb7d1aa3..e8008e0c2e88 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1103,7 +1103,10 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
> *bridge,
> static int tc_connector_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> {
> - /* Accept any mode */
> + /* PCLK limitation = 6.5 nS */
> + if (mode->clock > 163000)
> + return MODE_CLOCK_HIGH;
The comment doesn't match the code. If the limit is 6.5 nS, shouldn't
that be
if (mode->clock > 153846)
?
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm/bridge: tc358767: fix DP0_MISC register set
On Thu, 2017-07-27 at 15:47 +0300, Andrey Gusakov wrote: > Remove shift from TU_SIZE_RECOMMENDED define as it used to > calculate max_tu_symbols. > > Signed-off-by: Andrey Gusakov > --- > drivers/gpu/drm/bridge/tc358767.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/tc358767.c > b/drivers/gpu/drm/bridge/tc358767.c > index e8008e0c2e88..4aee6178d889 100644 > --- a/drivers/gpu/drm/bridge/tc358767.c > +++ b/drivers/gpu/drm/bridge/tc358767.c > @@ -97,7 +97,7 @@ > #define DP0_ACTIVEVAL0x0650 > #define DP0_SYNCVAL 0x0654 > #define DP0_MISC 0x0658 > -#define TU_SIZE_RECOMMENDED (0x3f << 16) /* LSCLK cycles per TU */ > +#define TU_SIZE_RECOMMENDED (63) /* LSCLK cycles per TU */ > #define BPC_6(0 << 5) > #define BPC_8(1 << 5) > > @@ -716,7 +716,8 @@ static int tc_set_video_mode(struct tc_data *tc, struct > drm_display_mode *mode) >* Must be less than tu_size. >*/ > max_tu_symbol = TU_SIZE_RECOMMENDED - 1; > - tc_write(DP0_MISC, (max_tu_symbol << 23) | TU_SIZE_RECOMMENDED | BPC_8); > + tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) | > +BPC_8); > > return 0; > err: Acked-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/bridge: tc358767: fix 1-lane behavior
On Thu, 2017-07-27 at 15:47 +0300, Andrey Gusakov wrote:
> Use drm_dp_channel_eq_ok helper
>
> Signed-off-by: Andrey Gusakov
> ---
> drivers/gpu/drm/bridge/tc358767.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 84b0b0fff854..24abffae6edb 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -819,8 +819,6 @@ static int tc_main_link_setup(struct tc_data *tc)
> unsigned int rate;
> u32 dp_phy_ctrl;
> int timeout;
> - bool aligned;
> - bool ready;
> u32 value;
> int ret;
> u8 tmp[8];
> @@ -965,16 +963,15 @@ static int tc_main_link_setup(struct tc_data *tc)
> ret = drm_dp_dpcd_read_link_status(aux, tmp + 2);
> if (ret < 0)
> goto err_dpcd_read;
> - ready = (tmp[2] == ((DP_CHANNEL_EQ_BITS << 4) | /* Lane1 */
> - DP_CHANNEL_EQ_BITS)); /* Lane0 */
> - aligned = tmp[4] & DP_INTERLANE_ALIGN_DONE;
> - } while ((--timeout) && !(ready && aligned));
> + } while ((--timeout) &&
> + !(drm_dp_channel_eq_ok(tmp + 2, tc->link.base.num_lanes)));
>
> if (timeout == 0) {
> /* Read DPCD 0x200-0x201 */
> ret = drm_dp_dpcd_read(aux, DP_SINK_COUNT, tmp, 2);
> if (ret < 0)
> goto err_dpcd_read;
> + dev_err(dev, "channel(s) EQ not ok\n");
> dev_info(dev, "0x0200 SINK_COUNT: 0x%02x\n", tmp[0]);
> dev_info(dev, "0x0201 DEVICE_SERVICE_IRQ_VECTOR: 0x%02x\n",
>tmp[1]);
> @@ -985,10 +982,6 @@ static int tc_main_link_setup(struct tc_data *tc)
> dev_info(dev, "0x0206 ADJUST_REQUEST_LANE0_1: 0x%02x\n",
>tmp[6]);
>
> - if (!ready)
> - dev_err(dev, "Lane0/1 not ready\n");
> - if (!aligned)
> - dev_err(dev, "Lane0/1 not aligned\n");
> return -EAGAIN;
> }
Acked-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/bridge: tc358767: fix AUXDATAn registers access
On Thu, 2017-07-27 at 15:47 +0300, Andrey Gusakov wrote:
> First four bytes should go to DP0_AUXWDATA0. Due to bug if
> len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
> data get shifted by 4 bytes. Fix it.
>
> Signed-off-by: Andrey Gusakov
> ---
> drivers/gpu/drm/bridge/tc358767.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index c657a00af508..84b0b0fff854 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -318,7 +318,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
> tmp = (tmp << 8) | buf[i];
> i++;
> if (((i % 4) == 0) || (i == size)) {
> - tc_write(DP0_AUXWDATA(i >> 2), tmp);
> + tc_write(DP0_AUXWDATA((i - 1) >> 2), tmp);
> tmp = 0;
> }
> }
Acked-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [alsa-devel] [PATCH v2 2/2] drm/bridge: adv7511: restrict audio sample sizes
On Tue, Aug 01, 2017 at 01:52:35PM +0100, Srinivas Kandagatla wrote: > On 01/08/17 13:28, Mark Brown wrote: > > > And it's a false indication that we are supporting 32bit samples. > > > Which am not very happy with. > > This is what the sample_bits field in the DAI structure is for.ya. > But still reporting that driver supports 32 bit samples when it does not > really support all 32 bits, is kinda misleading to user. > Isn't it? No. Please read what I wrote and look at what setting sample_bits does. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/bridge/synopsys: dsi: Constify funcs structures
Constify dw_mipi_dsi_bridge_funcs as these functions are not supposed
to change at runtime.
Signed-off-by: Philippe CORNU
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 36f5ccb..63c7a01 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -811,7 +811,7 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
*bridge)
return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge);
}
-static struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
+static const struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
.mode_set = dw_mipi_dsi_bridge_mode_set,
.enable = dw_mipi_dsi_bridge_enable,
.post_disable = dw_mipi_dsi_bridge_post_disable,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/bridge/synopsys: dsi: Register list clean up
This patch cleans up the Synopsys mipi dsi register list: - rename registers according to the Synopsys documentation (1.30 & 1.31) - fix typos - re-order registers for a better coherency Signed-off-by: Philippe CORNU Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 92 --- 1 file changed, 56 insertions(+), 36 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 63c7a01..781340d 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -30,19 +30,20 @@ #include #define DSI_VERSION0x00 + #define DSI_PWR_UP 0x04 #define RESET 0 #define POWERUPBIT(0) #define DSI_CLKMGR_CFG 0x08 -#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) -#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) +#define TO_CLK_DIVISION(div) (((div) & 0xff) << 8) +#define TX_ESC_CLK_DIVISION(div) ((div) & 0xff) #define DSI_DPI_VCID 0x0c -#define DPI_VID(vid) (((vid) & 0x3) << 0) +#define DPI_VCID(vcid) ((vcid) & 0x3) #define DSI_DPI_COLOR_CODING 0x10 -#define EN18_LOOSELY BIT(8) +#define LOOSELY18_EN BIT(8) #define DPI_COLOR_CODING_16BIT_1 0x0 #define DPI_COLOR_CODING_16BIT_2 0x1 #define DPI_COLOR_CODING_16BIT_3 0x2 @@ -61,22 +62,25 @@ #define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) #define INVACT_LPCMD_TIME(p) ((p) & 0xff) +#define DSI_DBI_VCID 0x1c #define DSI_DBI_CFG0x20 +#define DSI_DBI_PARTITIONING_EN0x24 #define DSI_DBI_CMDSIZE0x28 #define DSI_PCKHDL_CFG 0x2c -#define EN_CRC_RX BIT(4) -#define EN_ECC_RX BIT(3) -#define EN_BTA BIT(2) -#define EN_EOTP_RX BIT(1) -#define EN_EOTP_TX BIT(0) +#define CRC_RX_EN BIT(4) +#define ECC_RX_EN BIT(3) +#define BTA_EN BIT(2) +#define EOTP_RX_EN BIT(1) +#define EOTP_TX_EN BIT(0) + +#define DSI_GEN_VCID 0x30 #define DSI_MODE_CFG 0x34 #define ENABLE_VIDEO_MODE 0 #define ENABLE_CMD_MODEBIT(0) #define DSI_VID_MODE_CFG 0x38 -#define FRAME_BTA_ACK BIT(14) #define ENABLE_LOW_POWER (0x3f << 8) #define ENABLE_LOW_POWER_MASK (0x3f << 8) #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0 @@ -85,8 +89,13 @@ #define VID_MODE_TYPE_MASK 0x3 #define DSI_VID_PKT_SIZE 0x3c -#define VID_PKT_SIZE(p)(((p) & 0x3fff) << 0) -#define VID_PKT_MAX_SIZE 0x3fff +#define VID_PKT_SIZE(p)((p) & 0x3fff) + +#define DSI_VID_NUM_CHUNKS 0x40 +#define VID_NUM_CHUNKS(c) ((c) & 0x1fff) + +#define DSI_VID_NULL_SIZE 0x44 +#define VID_NULL_SIZE(b) ((b) & 0x1fff) #define DSI_VID_HSA_TIME 0x48 #define DSI_VID_HBP_TIME 0x4c @@ -95,6 +104,8 @@ #define DSI_VID_VBP_LINES 0x58 #define DSI_VID_VFP_LINES 0x5c #define DSI_VID_VACTIVE_LINES 0x60 +#define DSI_EDPI_CMD_SIZE 0x64 + #define DSI_CMD_MODE_CFG 0x68 #define MAX_RD_PKT_SIZE_LP BIT(24) #define DCS_LW_TX_LP BIT(19) @@ -108,8 +119,8 @@ #define GEN_SW_2P_TX_LPBIT(10) #define GEN_SW_1P_TX_LPBIT(9) #define GEN_SW_0P_TX_LPBIT(8) -#define EN_ACK_RQSTBIT(1) -#define EN_TEAR_FX BIT(0) +#define ACK_RQST_ENBIT(1) +#define TEAR_FX_EN BIT(0) #define CMD_MODE_ALL_LP(MAX_RD_PKT_SIZE_LP | \ DCS_LW_TX_LP | \ @@ -125,27 +136,31 @@ GEN_SW_0P_TX_LP) #define DSI_GEN_HDR0x6c +/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet() */ #define GEN_HDATA(data)(((data) & 0x) << 8) -#define GEN_HDATA_MASK (0x << 8) #define GEN_HTYPE(type)(((type) & 0xff) << 0) -#define GEN_HTYPE_MASK 0xff #define DSI_GEN_PLD_DATA 0x70 #define DSI_CMD_PKT_STATUS 0x74 -#define GEN_CMD_EMPTY BIT(0) -#define GEN_CMD_FULL BIT(1) -#define GEN_PLD_W_EMPTYBIT(
[PATCH v3 0/3] drm/bridge/synopsys: dsi: Various cleanups
Version 3: - Add devm_reset_control_get_optional_exclusive (Philipp Zabel). Version 2: - Put back Synopsys mipi dsi unused registers. - Add devm_reset_control_get_exclusive to follow explicit reset API. - Add a missing commit message & reviewed-by. Version 1: - Initial commit The purpose of this set of patches is to clean up the mipi dsi dw Synopsys drm bridge. Philippe CORNU (3): drm/bridge/synopsys: dsi: Constify funcs structures drm/bridge/synopsys: dsi: Register list clean up drm/bridge/synopsys: dsi: explicitly request exclusive reset control drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 104 +++--- 1 file changed, 60 insertions(+), 44 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/bridge/synopsys: dsi: explicitly request exclusive reset control
Based on patch "Convert drivers to explicit reset API" from Philipp Zabel
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Philipp Zabel
Signed-off-by: Philippe CORNU
Acked-by: Philipp Zabel
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 781340d..4e1f91e 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -885,15 +885,11 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
*bridge)
* Note that the reset was not defined in the initial device tree, so
* we have to be prepared for it not being found.
*/
- apb_rst = devm_reset_control_get(dev, "apb");
+ apb_rst = devm_reset_control_get_optional_exclusive(dev, "apb");
if (IS_ERR(apb_rst)) {
ret = PTR_ERR(apb_rst);
- if (ret == -ENOENT) {
- apb_rst = NULL;
- } else {
- dev_err(dev, "Unable to get reset control: %d\n", ret);
- return ERR_PTR(ret);
- }
+ dev_err(dev, "Unable to get reset control: %d\n", ret);
+ return ERR_PTR(ret);
}
if (apb_rst) {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] drm/bridge/synopsys: dsi: Various cleanups
Hi Archit, The 2 first patches have been reviewed by Laurent. The 3rd one has been "acked" by Philipp. Do not hesitate to send me any comments so I can take them into account before my holidays (end of next week)... Many thanks for your support, Philippe :-) On 08/01/2017 03:23 PM, Philippe CORNU wrote: > Version 3: > - Add devm_reset_control_get_optional_exclusive (Philipp Zabel). > > Version 2: > - Put back Synopsys mipi dsi unused registers. > - Add devm_reset_control_get_exclusive to follow explicit reset API. > - Add a missing commit message & reviewed-by. > > Version 1: > - Initial commit > > The purpose of this set of patches is to clean up the mipi dsi dw > Synopsys drm bridge. > > Philippe CORNU (3): >drm/bridge/synopsys: dsi: Constify funcs structures >drm/bridge/synopsys: dsi: Register list clean up >drm/bridge/synopsys: dsi: explicitly request exclusive reset control > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 104 > +++--- > 1 file changed, 60 insertions(+), 44 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/14] drm: rcar-du: Configure DPAD0 routing through last group on Gen3
Hi Kieran,
On Tuesday 01 Aug 2017 14:46:13 Kieran Bingham wrote:
> On 26/06/17 19:12, Laurent Pinchart wrote:
> > On Gen3 SoCs DPAD0 routing is configured through the last CRTC group,
> > unlike on Gen2 where it is configured through the first CRTC group. Fix
> > the driver accordingly.
> >
> > Fixes: 2427b3037710 ("drm: rcar-du: Add R8A7795 device support")
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_group.c | 21 ++---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_group.c index
> > 64738fca96d0..2abb2fdd143e 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
> > @@ -208,23 +208,30 @@ void rcar_du_group_restart(struct rcar_du_group
> > *rgrp)
> > int rcar_du_set_dpad0_vsp1_routing(struct rcar_du_device *rcdu)
> > {
> > + struct rcar_du_group *rgrp;
> > + struct rcar_du_crtc *crtc;
> > int ret;
> >
> > if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_EXT_CTRL_REGS))
> > return 0;
> >
> > - /* RGB output routing to DPAD0 and VSP1D routing to DU0/1/2 are
> > -* configured in the DEFR8 register of the first group. As this
> > function
> > -* can be called with the DU0 and DU1 CRTCs disabled, we need to
> > enable
> > -* the first group clock before accessing the register.
> > + /*
> > +* RGB output routing to DPAD0 and VSP1D routing to DU0/1/2 are
> > +* configured in the DEFR8 register of the first group on Gen2 and the
> > +* last group on Gen3. As this function can be called with the DU
> > +* channels of the corresponding CRTCs disabled, we need to enable the
> > +* group clock before accessing the register.
> > */
> >
> > - ret = clk_prepare_enable(rcdu->crtcs[0].clock);
> > + rgrp = &rcdu->groups[DIV_ROUND_UP(rcdu->num_crtcs, 2) - 1];
> > + crtc = &rcdu->crtcs[rgrp->index * 2];
>
> I'm not certain I understand how this makes a distinct difference between
> G2, and G3.
That's because, well, it doesn't :-)
> Is rcdu->num_crtcs the distinguishing factor between the SoC's?
I'm not sure what I was thinking when I wrote this. I'll send a v3.
> > +
> > + ret = clk_prepare_enable(crtc->clock);
> > if (ret < 0)
> > return ret;
> >
> > - rcar_du_group_setup_defr8(&rcdu->groups[0]);
> > + rcar_du_group_setup_defr8(rgrp);
> >
> > - clk_disable_unprepare(rcdu->crtcs[0].clock);
> > + clk_disable_unprepare(crtc->clock);
> >
> > return 0;
> > }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #13 from 247 --- tried again and this time the command gave me this result error: XDG_RUNTIME_DIR not set in the environment. No protocol specified No protocol specified error: XDG_RUNTIME_DIR not set in the environment. No protocol specified No protocol specified set pipelines to PAUSED ... No protocol specified ERROR: pipelines don't wan't to pause. ERROR: from the element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: Could not initialise Xv output additional debug informations: xvimagesink.c(1759): gst_xv_image_sink_open (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: Could not open display (null) set pipeline to NULL ... free execution on the pipeline... of course i translated everything into english...anyway i don't think it's a matter of x.org or wayland cause i've tried to set x.org as display driver but had exactly the same error...so don't think comparing gnome or cinnamon will help at this point... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #14 from Julien Isorce --- (In reply to 247 from comment #13) > tried again and this time the command gave me this result > > error: XDG_RUNTIME_DIR not set in the environment. > No protocol specified > No protocol specified > error: XDG_RUNTIME_DIR not set in the environment. > No protocol specified > No protocol specified > set pipelines to PAUSED ... > No protocol specified > ERROR: pipelines don't wan't to pause. > ERROR: from the element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: > Could not initialise Xv output > additional debug informations: > xvimagesink.c(1759): gst_xv_image_sink_open (): > /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: > Could not open display (null) > set pipeline to NULL ... > free execution on the pipeline... > > > of course i translated everything into english...anyway i don't think it's a > matter of x.org or wayland cause i've tried to set x.org as display driver > but had exactly the same error...so don't think comparing gnome or cinnamon > will help at this point... Try installing libxv1 or try to use ximagesink (instead of xvimagesink) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #15 from Julien Isorce --- (In reply to Julien Isorce from comment #14) > (In reply to 247 from comment #13) > > tried again and this time the command gave me this result > > > > error: XDG_RUNTIME_DIR not set in the environment. > > No protocol specified > > No protocol specified > > error: XDG_RUNTIME_DIR not set in the environment. > > No protocol specified > > No protocol specified > > set pipelines to PAUSED ... > > No protocol specified > > ERROR: pipelines don't wan't to pause. > > ERROR: from the element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: > > Could not initialise Xv output > > additional debug informations: > > xvimagesink.c(1759): gst_xv_image_sink_open (): > > /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: > > Could not open display (null) > > set pipeline to NULL ... > > free execution on the pipeline... > > > > > > of course i translated everything into english...anyway i don't think it's a > > matter of x.org or wayland cause i've tried to set x.org as display driver > > but had exactly the same error...so don't think comparing gnome or cinnamon > > will help at this point... > > Try installing libxv1 or try to use ximagesink (instead of xvimagesink) Ah if this is wayland, then try: waylandsink (instead of xvimagesink), or autovideosink -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #21 from Luke A. Guest --- Created attachment 133172 --> https://bugs.freedesktop.org/attachment.cgi?id=133172&action=edit Test of above with R9 380 with Windows 8.1 and latest AMD drivers Hi, After being asked to try this by Alex in IRC, I've added the output of the various logs, there will be overlap in places, dmesg and messages. I'm running 4.13.0-rc2 with drm-next-4.14 branch merged and the set of 3 patches from Alex. Tried with and without the third patch, I still get a black screen on restarting the VM (using virt manager). The first boot from a freshly booted host starts fine. In the log I've put "START" and "RESTART" where the VM is started (then shutdown) and then restarted. There is also extra PCI debugging messages enabled in the kernel. I too, would like an answer re the probing mentioned in 11. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #16 from 247 --- that's the result with waylandsink error: XDG_RUNTIME_DIR not set in the environment. No protocol specified No protocol specified Impostazione della pipeline a PAUSED ... error: XDG_RUNTIME_DIR not set in the environment. ERROR: pipeline don't wan't to pause. WARNING: to the element /GstPipeline:pipeline0/GstWaylandSink:waylandsink0: Could not initialise Wayland output Additional debug informations: gstwaylandsink.c(294): gst_wayland_sink_find_display (): /GstPipeline:pipeline0/GstWaylandSink:waylandsink0: Failed to create GstWlDisplay: 'Failed to connect to the wayland display '(default)'' Set pipeline to NULL ... Free execution on the pipeline... if i ipunt the command a second time i get : set pipeline to PAUSED ... ** (gst-launch-1.0:9446): WARNING **: Wayland compositor is missing the ability to scale, video display may not work properly. ** (gst-launch-1.0:9446): WARNING **: Could not bind to zwp_linux_dmabuf_v1 ERRORE: lpipeline does not wan't to pause. Got context from element 'vaapidecode_h264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayWayland\)\ vaapidisplaywayland1"; ERROR: to the element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Resource not found. Additional debug information: gstfilesrc.c(535): gst_file_src_start (): /GstPipeline:pipeline0/GstFileSrc:filesrc0: No such file "test.mp4" Set pipeline to NULL ... Free execution on the pipeline... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite
Hi Hean Loong,
Thank you for the patch.
On Tuesday 01 Aug 2017 10:31:32 Hean Loong, Ong wrote:
> From: Ong Hean Loong
>
> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height, buts per pixel and memory
> port width. The device tree binding only supports the Intel
> Arria10 devkit and its variants. Vendor name retained as
> altr.
>
> Signed-off-by: Ong, Hean Loong
> ---
> .../devicetree/bindings/display/altr,vip-fb2.txt | 39 ++
> 1 file changed, 39 insertions(+
> create mode 100644
> Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt new file mode
> 100644
> index 000..c4338d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> @@ -0,0 +1,39 @@
> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
> +
> +Supported hardware: Arria 10 and above with display port IP
> +
> +The hardware associated with this device tree is a SoC FPGA. Where there is
> an ARM controller +and a FPGA device. The ARM controller would host the
> Linux OS while the FPGA device runs on its +individual IP firmware.
DT bindings should not be OS-specific, you shouldn't mention Linux here.
> In the
> Intel VIP Frame Buffer II the ARM controller would be +driving data from
> the Linux OS to the FPGA device programmed with the Frame Buffer II IP +to
> render pixels to be streamed to the Display Port connector.
> +
> +The Frame Buffer II device is a simple frame buffer device. The device
> contains the display +properties and the bridge or connector register. The
> output for this device currently +is a dedicated to a single Display Port.
> Currently the max resolution supported is 1280 x 720 at +60Hz.
> +
> +More information the FPGA video IP component can be acquired from
> +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/
> ug/ug_vip.pdf +
> +
> +New bindings:
> +=
> +Required properties:
> +
> +- compatible: "altr,vip-frame-buffer-2.0"
> +- reg: Physical base address and length of the framebuffer controller's
> + registers.
> +- altr,max-width: The width of the framebuffer in pixels.
> +- altr,max-height: The height of the framebuffer in pixels.
The properties hint that those are the maximum values, but the descriptions
don't match. One of the two needs to be fixed.
> +- altr,mem-port-width = the bus width of the avalon master port on the
> frame reader
> +
> +Example:
> +
> + dp_0_frame_buf: display-controller@10280 {
> + compatible = "altr,vip-frame-buffer-2.0";
> + reg = <0x0001 0x0280 0x0040>;
> + altr,max-width = <1280>;
> + altr,max-height = <720>;
> + altr,mem-port-width = <128>;
> + };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition
https://bugs.freedesktop.org/show_bug.cgi?id=101988 --- Comment #3 from Alex Deucher --- Does using this branch help? https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.14-wip -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 3/3] DRM:ivip Intel FPGA Video and Image Processing Suite
Hi Hean Loong,
Thank you for the patch.
On Tuesday 01 Aug 2017 10:31:34 Hean Loong, Ong wrote:
> From: Ong Hean Loong
>
> Driver for Intel FPGA Video and Image Processing
> Suite Frame Buffer II. The driver only supports the Intel
> Arria10 devkit and its variants. This driver can be either
> loaded staticlly or in modules. The OF device tree binding
> is located at:
> Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> Signed-off-by: Ong, Hean Loong
> ---
> V3:
> *Changes to fixing drm_simple_pipe
> *Used drm_fb_cma_get_gem_addr
>
> V2:
> *Adding drm_simple_display_pipe_init
> ---
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/ivip/Kconfig | 13 +++
> drivers/gpu/drm/ivip/Makefile | 9 ++
> drivers/gpu/drm/ivip/intel_vip_conn.c | 96
> drivers/gpu/drm/ivip/intel_vip_core.c | 183 ++
> drivers/gpu/drm/ivip/intel_vip_drv.h | 54 +
> drivers/gpu/drm/ivip/intel_vip_of.c | 204 +++
> 8 files changed, 562 insertions(+)
> create mode 100644 drivers/gpu/drm/ivip/Kconfig
> create mode 100644 drivers/gpu/drm/ivip/Makefile
> create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
> create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
> create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
> create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
[snip]
> diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
> new file mode 100644
> index 000..9a8c5ce
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Kconfig
> @@ -0,0 +1,13 @@
> +config DRM_IVIP
> + tristate "Intel FGPA Video and Image Processing"
> + depends on DRM && OF
> + select DRM_GEM_CMA_HELPER
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select DRM_KMS_CMA_HELPER
> + help
> + Choose this option if you have a Intel FPGA Arria 10 system
> + and above with a Display Port IP. This does not support legacy
> + Intel FPGA Cyclone V display port. Currently only single frame
> + buffer is supported.
I think this should be fixed to upstream this driver.
> Note that ACPI and X_86 architecture is yet
ACPI on FPGA... I wonder if it could get any crazier than that :-)
> + to be supported.If M is selected the module would be called ivip.
s/.If/. If/
[snip]
> diff --git a/drivers/gpu/drm/ivip/intel_vip_core.c
> b/drivers/gpu/drm/ivip/intel_vip_core.c new file mode 100644
> index 000..ea85715
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_core.c
> @@ -0,0 +1,183 @@
> +/*
> + * intel_vip_core.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> for + * more details.
> + *
> + * Authors:
> + * Ong, Hean-Loong
> + *
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "intel_vip_drv.h"
> +
> +static void intelvipfb_enable(struct drm_simple_display_pipe *pipe,
> + struct drm_crtc_state *crtc_state)
> +{
> + /*
> + * The frameinfo variable has to correspond to the size of the VIP
Suite
> + * Frame Reader register 7 which will determine the maximum size used
> + * in this frameinfo
> + */
> +
> + u32 frameinfo;
> + struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
> + void __iomem *base = priv->base;
> + struct drm_plane_state *state = pipe->plane.state;
> + dma_addr_t addr;
> +
> + addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
> +
> + dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
> +
> + frameinfo =
> + readl(base + INTELVIPFB_FRAME_READER) & 0x00ff;
> + writel(frameinfo, base + INTELVIPFB_FRAME_INFO);
> + writel(addr, base + INTELVIPFB_FRAME_START);
> + /* Finally set the control register to 1 to start streaming */
> + writel(1, base + INTELVIPFB_CONTROL);
> +}
> +
> +static void intelvipfb_disable(struct drm_simple_display_pipe *pipe)
> +{
> + struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
> + void __iomem *base = priv->base;
Missing blank line.
> + /* set
[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition
https://bugs.freedesktop.org/show_bug.cgi?id=101988 Alex Deucher changed: What|Removed |Added Resolution|NOTOURBUG |--- Status|RESOLVED|REOPENED --- Comment #4 from Alex Deucher --- Sorry. I didn't realize this worked on radeon. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #22 from Luke A. Guest --- I'd like to report a minor success. I've managed to boot into win8.1 twice in a row. I booted as normal through virt-manager, then shutdown from inside the guest, then called a script: #!/bin/sh echo 1 > /sys/bus/pci/devices/\:03\:00.0/remove echo 1 > /sys/bus/pci/devices/\:03\:00.1/remove echo 1 > /sys/bus/pci/rescan /opt/vfio/rebind_dev_to_vfio.sh :03:00.0 /opt/vfio/rebind_dev_to_vfio.sh :03:00.1 Then restarted the guest from virt-manager, booted fine, again I shutdown from within the guest. On running the above script a second time, the machine hung, hard. I couldn't login through serial, sysrq keys didn't do anything. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #23 from Luke A. Guest --- Created attachment 133173 --> https://bugs.freedesktop.org/attachment.cgi?id=133173&action=edit Script to rebind a device back to the vfio-pci driver forgot to submit this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb-helper: pass physical dimensions to fbdev
The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.
Signed-off-by: David Lechner
---
drivers/gpu/drm/drm_fb_helper.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 574af01..07a6621 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1759,6 +1759,7 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
uint32_t fb_width, uint32_t fb_height)
{
struct drm_framebuffer *fb = fb_helper->fb;
+ int i;
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
@@ -1771,6 +1772,18 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
info->var.height = -1;
info->var.width = -1;
+ drm_fb_helper_for_each_connector(fb_helper, i) {
+ struct drm_connector *connector =
+ fb_helper->connector_info[i]->connector;
+
+ /* use the first connected connector for the physical
dimensions */
+ if (connector->status == connector_status_connected) {
+ info->var.height = connector->display_info.width_mm;
+ info->var.width = connector->display_info.height_mm;
+ break;
+ }
+ }
+
switch (fb->format->depth) {
case 8:
info->var.red.offset = 0;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102004] Graphics renders only random black and white artifacts after boot. GUI mode unusable. Padoka ppa update Aug 1/2017
https://bugs.freedesktop.org/show_bug.cgi?id=102004 Bug ID: 102004 Summary: Graphics renders only random black and white artifacts after boot. GUI mode unusable. Padoka ppa update Aug 1/2017 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: lesserbr...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 133174 --> https://bugs.freedesktop.org/attachment.cgi?id=133174&action=edit Screen photo just after boot. This is a login screen that works but failed to display GUI mode is completely unusable due to massive graphics corruption. Looks like libllvm5.0 -> libllvm6.0 is the point of failure. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102004] Graphics renders only random black and white artifacts after boot. GUI mode unusable. Padoka ppa update Aug 1/2017
https://bugs.freedesktop.org/show_bug.cgi?id=102004 --- Comment #1 from lesserbr...@gmail.com --- Created attachment 133175 --> https://bugs.freedesktop.org/attachment.cgi?id=133175&action=edit System configuration (after mesa downgrade) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102004] Graphics renders only random black and white artifacts after boot. GUI mode unusable. Padoka ppa update Aug 1/2017
https://bugs.freedesktop.org/show_bug.cgi?id=102004 --- Comment #2 from lesserbr...@gmail.com --- Created attachment 133176 --> https://bugs.freedesktop.org/attachment.cgi?id=133176&action=edit apt log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #17 from Julien Isorce --- (In reply to 247 from comment #16) > No such file "test.mp4" Yes you need to point to a valid mp4 file. Also try gst-launch-1.0 playbin uri=file:///home/you/test.mp4 -v -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] fbcon: Make fbcon a built-time depency for fbdev
On Wednesday, July 12, 2017 12:40:45 PM Bartlomiej Zolnierkiewicz wrote: > On Thursday, July 06, 2017 02:57:32 PM Daniel Vetter wrote: > > There's a bunch of folks who're trying to make printk less > > contended and faster, but there's a problem: printk uses the > > console_lock, and the console lock has become the BKL for all things > > fbdev/fbcon, which in turn pulled in half the drm subsystem under that > > lock. That's awkward. > > > > There reasons for that is probably just a historical accident: > > > > - fbcon is a runtime option of fbdev, i.e. at runtime you can pick > > whether your fbdev driver instances are used as kernel consoles. > > Unfortunately this wasn't implemented with some module option, but > > through some module loading magic: As long as you don't load > > fbcon.ko, there's no fbdev console support, but loading it (in any > > order wrt fbdev drivers) will create console instances for all fbdev > > drivers. > > > > - This was implemented through a notifier chain. fbcon.ko enumerates > > all fbdev instances at load time and also registers itself as > > listener in the fbdev notifier. The fbdev core tries to register new > > fbdev instances with fbcon using the notifier. > > > > - On top of that the modifier chain is also used at runtime by the > > fbdev subsystem to e.g. control backlights for panels. > > > > - The problem is that the notifier puts a mutex locking context > > between fbdev and fbcon, which mixes up the locking contexts for > > both the runtime usage and the register time usage to notify fbcon. > > And at runtime fbcon (through the fbdev core) might call into the > > notifier from a printk critical section while console_lock is held. > > > > - This means console_lock must be an outer lock for the entire fbdev > > subsystem, which also means it must be acquired when registering a > > new framebuffer driver as the outermost lock since we might call > > into fbcon (through the notifier) which would result in a locking > > inversion if fbcon would acquire the console_lock from its notifier > > callback (which it needs to register the console). > > > > - console_lock can be held anywhere, since printk can be called > > anywhere, and through the above story, plus drm/kms being an fbdev > > driver, we pull in a shocking amount of locking hiercharchy > > underneath the console_lock. Which makes cleaning up printk really > > hard (not even splitting console_lock into an rwsem is all that > > useful due to this). > > > > There's various ways to address this, but the cleanest would be to > > make fbcon a compile-time option, where fbdev directly calls the fbcon > > register functions from register_framebuffer, or dummy static inline > > versions if fbcon is disabled. Maybe augmented with a runtime knob to > > disable fbcon, if that's needed (for debugging perhaps). > > > > But this could break some users who rely on the magic "loading > > fbcon.ko enables/disables fbdev framebuffers at runtime" thing, even > > if that's unlikely. Hence we must be careful: > > > > 1. Create a compile-time dependency between fbcon and fbdev in the > > least minimal way. This is what this patch does. > > > > 2. Wait at least 1 year to give possible users time to scream about > > how we broke their setup. Unlikely, since all distros make fbcon > > compile-in, and embedded platforms only compile stuff they know they > > need anyway. But still. > > > > 3. Convert the notifier to direct functions calls, with dummy static > > inlines if fbcon is disabled. We'll still need the fb notifier for the > > other uses (like backlights), but we can probably move it into the fb > > core (atm it must be built-into vmlinux). > > > > 4. Push console_lock down the call-chain, until it is down in > > console_register again. > > > > 5. Finally start to clean up and rework the printk/console locking. > > > > For context of this saga see > > > > commit 50e244cc793d511b86adea24972f3a7264cae114 > > Author: Alan Cox > > Date: Fri Jan 25 10:28:15 2013 +1000 > > > > fb: rework locking to fix lock ordering on takeover > > > > plus the pile of commits on top that tried to make this all work > > without terminally upsetting lockdep. We've uncovered all this when > > console_lock lockdep annotations where added in > > > > commit daee779718a319ff9f83e1ba3339334ac650bb22 > > Author: Daniel Vetter > > Date: Sat Sep 22 19:52:11 2012 +0200 > > > > console: implement lockdep support for console_lock > > > > On the patch itself: > > - Switch CONFIG_FRAMEBUFFER_CONSOLE to be a boolean, using the overall > > CONFIG_FB tristate to decided whether it should be a module or > > built-in. > > > > - At first I thought I could force the build depency with just a dummy > > symbol that fbcon.ko exports and fb.ko uses. But that leads to a > > module depency cycle (it works fine when built-in). > > > > Since this tight binding is the entire goal the simple
Re: [PATCH] fbdev: Nuke FBINFO_MODULE
On Thursday, July 13, 2017 04:01:50 PM Bartlomiej Zolnierkiewicz wrote: > On Wednesday, July 12, 2017 05:07:42 PM Daniel Vetter wrote: > > On Wed, Jul 12, 2017 at 2:54 PM, Bartlomiej Zolnierkiewicz > > wrote: > > > On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: > > >> On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz > > >> wrote: > > >> > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote: > > >> > > Instead check info->ops->owner, which amounts to the same. > > >> > > > > >> > > Spotted because I want to remove the pile of broken and cargo-culted > > >> > > fb_info->flags assignments in drm drivers. > > >> > > > > >> > > v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* > > >> > > defines > > >> > > that I've failed to spot. > > >> > > > > >> > > v3: Don't nuke FBINFO_FLAG_DEFAULT, that's used all over the place. > > >> > > > > >> > > Cc: Bartlomiej Zolnierkiewicz > > >> > > Cc: linux-fb...@vger.kernel.org > > >> > > Signed-off-by: Daniel Vetter > > >> > > > >> > Acked-by: Bartlomiej Zolnierkiewicz > > >> > > >> Do you plan to pick these two patches up yourself, or do you expect me to > > >> merge them? > > > > > > Since the original patchset contained DRM changes (two last patches) > > > depending on fbdev changes (two first patches, the patch being discussed > > > was the second one) I assumed that you would like to take them all > > > through DRM tree. If this is not what is preferred, please tell me. > > > > There's no direct depency between 1&2 and 3&4, the only effect of > > merging them through separate trees is that the bootup logo might not > > show up when it's expected, until the trees are merged together. We > > could merge them through separate trees if you prefer that (I forgot > > to mention that in the cover letter), but I'm fine with putting them > > all into drm-misc with your ack for 4.14. > > > > Whatever you prefer, I don't mind either way. > > Then I will merge patches 1&2 for v4.14 through fbdev tree (there are > some other changes pending touching fbdev core and I would like to avoid > conflicts between fbdev & drm-misc trees). Thanks! Patch queued for 4.14, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Add support for CCS modifiers
On 17-07-31 10:29:55, Daniel Vetter wrote:
On Sat, Jul 29, 2017 at 09:25:50AM -0700, Ben Widawsky wrote:
On 17-07-29 13:53:10, Daniel Stone wrote:
> Hi Ben,
>
> On 26 July 2017 at 19:08, Ben Widawsky wrote:
> > + } else if (INTEL_GEN(dev_priv) >= 9) {
> > intel_primary_formats = skl_primary_formats;
> > num_formats = ARRAY_SIZE(skl_primary_formats);
> > - modifiers = skl_format_modifiers;
> > + if (pipe >= PIPE_C)
> > + modifiers = skl_format_modifiers_ccs;
> > + else
> > + modifiers = skl_format_modifiers_noccs;
>
> Shouldn't that be (pipe < PIPE_C)?
>
> Cheers,
> Daniel
Yep. It was wrong in v7 too :/. I have it fixed locally.
Shouldn't the igt catch this, or does it not try to exercise all the
plane/crtc combos there are?
-Daniel
I don't know whether or not IGT should have caught this, but it wouldn't have
because I had been sending these without Ville's patches, so my patches alone
don't even build (since his patches defined the modifiers).
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #24 from Robin --- (In reply to Luke A. Guest from comment #22) > I'd like to report a minor success. I've managed to boot into win8.1 twice > in a row. I booted as normal through virt-manager, then shutdown from inside > the guest, then called a script: Hi Luke, few questions. When booting the host, do you boot with amdgpu or vfio-pci bound to the GPU? After you've started a VM, did you bind back to amdgpu or did you stay on vfio-pci? Is it during vfio or amdgpu control that your system hangs on the second boot? If it's during amdgpu, have you tried my patch from comment 20? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #25 from Luke A. Guest --- > Hi Luke, few questions. When booting the host, do you boot with amdgpu or > vfio-pci bound to the GPU? After you've started a VM, did you bind back to > amdgpu or did you stay on vfio-pci? I have 2 AMD GPU's, R9 390 (host) and R9 380 (guest). I boot with the 380 being passed over to vfio-pci. On exit the VM sets the 380 back to vfio-pci. > Is it during vfio or amdgpu control that your system hangs on the second boot? It was during a boot of the VM, the devices were attached to the vfio-pci driver. > If it's during amdgpu, have you tried my patch from comment 20? I haven't tried it, I don't think it would apply to my card as it's VI not CIK. Although, if I were using the 390 (CIK) it likely would. The issues are similar though and I believe I've just proved that the so called hw reset bug, in may case anyway, is sw not hw. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition
https://bugs.freedesktop.org/show_bug.cgi?id=101988 --- Comment #5 from newin...@gmail.com --- I cloned "~agd5f/linux" on the branch "drm-next-4.14-wip" and copied my .config from the 4.12.4 I was using. `uname -r` give me "4.12.0-rc7+" Now `modprobe amdgpu` is freezing my screen instead of blackscreen. `dmesg | grep amdgpu -i` give this : [ 107.804074] [drm] amdgpu kernel modesetting enabled. [ 107.804109] fb: switching to amdgpudrmfb from EFI VGA [ 107.804672] amdgpu :01:00.0: SI support provided by radeon. [ 107.804674] amdgpu :01:00.0: Use radeon.si_support=0 amdgpu.si_support=1 to override. Using 4.12.4 my second screen was fine, that isn't the case anymore with drm-next-4.14-wip. Using 4.12.4 I could startx (with a second screen obviously, my main screen was remaining black) now startx seems to return "no screen found". Note that radeon is still working perfectly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display
On 07/30/2017 12:14 PM, Noralf Trønnes wrote: Den 29.07.2017 21.40, skrev David Lechner: On 07/29/2017 02:17 PM, David Lechner wrote: The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3 working. But, most of the content here is building up the infrastructure to do that. Some general comments/questions: I have noticed that DRM doesn't really have support for monochrome displays. I'm guessing that is because no one really uses them anymore? The repaper driver was the first monochrome drm driver and I chose to present it to userspace as XRGB and convert it to monochrome. The reason for this is that everything, libraries, apps, plymouth (boot splash, no rgb565) supports it. I didn't see any point in adding a new monochrome drm format that didn't have, or probably wouldn't get userspace support (by libraries at least). The application of course needs to know this to get a good result. tinydrm_xrgb_to_gray8() does the conversion: https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781 The LEGO EV3 display is just an LCD (not the backlit kind). It has two modes of operation. It can to 2bbp grayscale or it can do 1bpp monochrome. The grayscale isn't the best (looks splotchy in places), so it would be nice to be able to choose between these two modes. How would I implement something like that? Do you expect anyone to use grayscale if it doesn't look good? Maybe better to add it later if there's a demand for it. I don't expect many people to use it at all. The people that do will be hackers like me that want to see what it is capable of, so I think I will keep it grayscale by default. Also, how can I indicate to userspace that this display really is monochrome/grayscale since the reported color depth 16bpp? There isn't unless we add formats for it. Since this display is in a Lego piece, doesn't it have custom userspace that already know it's monochrome? The official LEGO software is like this, yes. But I am working on a project that supports other LEGO compatible devices that have color screens, so the same software needs to be able to detect at runtime which type of screen it is using. Currently I have a plain fbdev driver that provides FB_VISUAL_MONO10 for the EV3 display and so the software knows when it has a monochrome screen and when it doesn't. But since plain fbdev drivers can't be accepted into mainline, I need to find a different way to detect what type of screen this is so that my graphics library can treat it differently. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #18 from 247 --- Created attachment 133177 --> https://bugs.freedesktop.org/attachment.cgi?id=133177&action=edit gst launch -v this is the output of the second command you gave me...now i'll output even the other one... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition
https://bugs.freedesktop.org/show_bug.cgi?id=101988 --- Comment #6 from Alex Deucher --- Can you try this patch: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.14-wip&id=e5c8d400da67abc1c033b9a4af1806926b55e5f6 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #26 from Robin --- (In reply to Luke A. Guest from comment #25) > I have 2 AMD GPU's, R9 390 (host) and R9 380 (guest). I boot with the 380 > being passed over to vfio-pci. On exit the VM sets the 380 back to vfio-pci. FWIW I don't think any of these patches are relevant to you then. The reset logic for your 380 would be coming from the guest's driver + vfio-pci. Where vfio in theory should only try to get the 380's state back to how it would be if you actually rebooted and leave the more sophisticated work to the guest driver. Though as mentioned here https://www.spinics.net/lists/kvm/msg116277.html vfio-pci may employ hardware specific solutions if there's no good blanket solution. --- For my scenario I have the Intel iGPU and the R9 290. So I am trying to find a setup where I can use the 290 for gaming on both the host and the guest. Once the 290 is bound to vfio-pci I have no issues with the VM. Reboot, force off, as many times as I like and no problems. It's when I am done with the VMs and try to give the 290 back to amdgpu I had init issues. Which my comment 20 patch does resolve, even if it is a carpet bomb approach to solving it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/i915: Add render decompression support
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.
Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.
Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.
Also not all planes will be capable of scanning out compressed
surfaces,
and eg. 90/270 degree rotation is not supported in combination
with
decompression either.
This patch may contain work from at least the following people:
* Vandana Kannan
* Daniel Vetter
* Ben Widawsky
v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
Put the AUX register defines to the correct place
Fix up the slightly bogus rotation check
v4: Use I915_WRITE_FW() due to plane update locking changes
s/return -EINVAL/goto err/ in intel_framebuffer_init()
Eliminate a bunch hardcoded numbers in CCS code
v5: (By Ben)
conflict resolution +
- res_blocks += fixed_16_16_to_u32_round_up(y_tile_minimum);
+ res_blocks += fixed16_to_u32_round_up(y_tile_minimum);
Cc: Paulo Zanoni
Cc: Daniel Vetter
Cc: Ben Widawsky
Cc: Jason Ekstrand
Signed-off-by: Ville Syrjä
Reviewed-by: Ben Widawsky (v1)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 23
drivers/gpu/drm/i915/intel_display.c | 233 ---
drivers/gpu/drm/i915/intel_pm.c | 29 -
drivers/gpu/drm/i915/intel_sprite.c | 5 +
4 files changed, 272 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01f92ab..cea4f941a56e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6106,6 +6106,10 @@ enum {
#define _PLANE_KEYMSK_2_A 0x70298
#define _PLANE_KEYMAX_1_A 0x701a0
#define _PLANE_KEYMAX_2_A 0x702a0
+#define _PLANE_AUX_DIST_1_A0x701c0
+#define _PLANE_AUX_DIST_2_A0x702c0
+#define _PLANE_AUX_OFFSET_1_A 0x701c4
+#define _PLANE_AUX_OFFSET_2_A 0x702c4
#define _PLANE_COLOR_CTL_1_A 0x701CC /* GLK+ */
#define _PLANE_COLOR_CTL_2_A 0x702CC /* GLK+ */
#define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
@@ -6212,6 +6216,24 @@ enum {
#define PLANE_NV12_BUF_CFG(pipe, plane)\
_MMIO_PLANE(plane, _PLANE_NV12_BUF_CFG_1(pipe),
_PLANE_NV12_BUF_CFG_2(pipe))
+#define _PLANE_AUX_DIST_1_B0x711c0
+#define _PLANE_AUX_DIST_2_B0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+ _PIPE(pipe, _PLANE_AUX_DIST_1_A, _PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+ _PIPE(pipe, _PLANE_AUX_DIST_2_A, _PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define _PLANE_AUX_OFFSET_1_B 0x711c4
+#define _PLANE_AUX_OFFSET_2_B 0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe) \
+ _PIPE(pipe, _PLANE_AUX_OFFSET_1_A, _PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe) \
+ _PIPE(pipe, _PLANE_AUX_OFFSET_2_A, _PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
#define _PLANE_COLOR_CTL_1_B 0x711CC
#define _PLANE_COLOR_CTL_2_B 0x712CC
#define _PLANE_COLOR_CTL_3_B 0x713CC
@@ -6695,6 +6717,7 @@ enum {
# define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
#define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define SKL_RC_HASH_OUTSIDE (1 << 15)
#define DPA_MASK_VBLANK_SRD (1 << 15)
#define FORCE_ARB_IDLE_PLANES (1 << 14)
#define SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6b00689ef6e0..f45f55998a5f 100644
--- a
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #19 from 247 --- the gst command you gave me before, on the same file result in "WARNING : wrong pipeline: no uri property for the element filesrc0" -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/i915: Implement .get_format_info() hook for CCS
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The location
of CCS is provided by userspace as just another plane with its own offset.
By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.
Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.
v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout
v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
Cc: Daniel Vetter
Cc: Ben Widawsky
Cc: Jason Ekstrand
Reviewed-by: Ben Widawsky (v3)
Signed-off-by: Ville Syrjä
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_fourcc.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 37
include/drm/drm_mode_config.h| 3 ++-
include/uapi/drm/drm_fourcc.h| 3 +++
4 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152df45ad..50da6180c495 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -222,7 +222,7 @@ drm_get_format_info(struct drm_device *dev,
const struct drm_format_info *info = NULL;
if (dev->mode_config.funcs->get_format_info)
- info = dev->mode_config.funcs->get_format_info(mode_cmd);
+ info = dev->mode_config.funcs->get_format_info(dev, mode_cmd);
if (!info)
info = drm_format_info(mode_cmd->pixel_format);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e92fd14c06c7..6b00689ef6e0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2433,6 +2433,42 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t
fb_modifier)
}
}
+static const struct drm_format_info ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+ int num_formats, u32 format)
+{
+ int i;
+
+ for (i = 0; i < num_formats; i++) {
+ if (formats[i].format == format)
+ return &formats[i];
+ }
+
+ return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *cmd)
+{
+ switch (cmd->modifier[0]) {
+ case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Yf_TILED_CCS:
+ return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+ default:
+ return NULL;
+ }
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -14630,6 +14666,7 @@ static void intel_atomic_state_free(struct
drm_atomic_state *state)
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+ .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 42981711189b..f0d3d3857ae2 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -81,7 +81,8 @@ struct drm_mode_config_funcs {
* The format information specific to the given fb metadata, or
* NULL if none is found.
*/
- const struct drm_format_info *(*get_format_info)(const struct
drm_mode_fb_cmd2 *mode_cmd);
+ const struct drm_format_info *(*get_format_info)(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd);
/**
* @output_poll_changed:
diff --git a/in
[PATCH 4/6] [v5] drm: Create a format/modifier blob
Updated blob layout (Rob, Daniel, Kristian, xerpi)
v2:
* Removed __packed, and alignment (.+)
* Fix indent in drm_format_modifier fields (Liviu)
* Remove duplicated modifier > 64 check (Liviu)
* Change comment about modifier (Liviu)
* Remove arguments to blob creation, use plane instead (Liviu)
* Fix data types (Ben)
* Make the blob part of uapi (Daniel)
v3:
Remove unused ret field.
Change i, and j to unsigned int (Emil)
v4:
Use plane->modifier_count instead of recounting (Daniel)
v5:
Rename modifiers to modifiers_property (Ville)
Use sizeof(__u32) instead to reflect UAPI nature (Ville)
Make BUILD_BUG_ON for blob header size
Cc: Rob Clark
Cc: Kristian H. Kristensen
Signed-off-by: Ben Widawsky
Reviewed-by: Daniel Stone (v2)
Reviewed-by: Liviu Dudau (v2)
Reviewed-by: Emil Velikov (v3)
---
drivers/gpu/drm/drm_mode_config.c | 7
drivers/gpu/drm/drm_plane.c | 84 +++
include/drm/drm_mode_config.h | 6 +++
include/uapi/drm/drm_mode.h | 50 +++
4 files changed, 147 insertions(+)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..74f6ff5df656 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+ "IN_FORMATS", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.modifiers_property = prop;
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index d3fc561d7b48..5c14beee52ff 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,87 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
}
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+ return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+ return (struct drm_format_modifier *)(((char *)blob) +
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane
*plane)
+{
+ const struct drm_mode_config *config = &dev->mode_config;
+ struct drm_property_blob *blob;
+ struct drm_format_modifier *mod;
+ size_t blob_size, formats_size, modifiers_size;
+ struct drm_format_modifier_blob *blob_data;
+ unsigned int i, j;
+
+ formats_size = sizeof(__u32) * plane->format_count;
+ if (WARN_ON(!formats_size)) {
+ /* 0 formats are never expected */
+ return 0;
+ }
+
+ modifiers_size =
+ sizeof(struct drm_format_modifier) * plane->modifier_count;
+
+ blob_size = sizeof(struct drm_format_modifier_blob);
+ /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+ BUILD_BUG_ON(sizeof(struct drm_format_modifier_blob) % 8);
+ blob_size += ALIGN(formats_size, 8);
+ blob_size += modifiers_size;
+
+ blob = drm_property_create_blob(dev, blob_size, NULL);
+ if (IS_ERR(blob))
+ return -1;
+
+ blob_data = (struct drm_format_modifier_blob *)blob->data;
+ blob_data->version = FORMAT_BLOB_CURRENT;
+ blob_data->count_formats = plane->format_count;
+ blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+ blob_data->count_modifiers = plane->modifier_count;
+
+ blob_data->modifiers_offset =
+ ALIGN(blob_data->formats_offset + formats_size, 8);
+
+ memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
+
+ /* If we can't determine support, just bail */
+ if (!plane->funcs->format_mod_supported)
+ goto done;
+
+ mod = modifiers_ptr(blob_data);
+ for (i = 0; i < plane->modifier_count; i++) {
+ for (j = 0; j < plane->format_count; j++) {
+ if (plane->funcs->format_mod_supported(plane,
+
plane->format_types[j],
+
plane->modifiers[i])) {
+
+ mod->formats |= 1 << j;
+ }
+ }
+
+ mod->modifier = plane->modifiers[i];
+ mod->offset = 0;
+ mod->pad = 0;
+ mod++;
+ }
+
+done:
+ drm_object_attach_property(&plane->base, config->modifiers_property,
+ blob->base.id);
+
+ return 0;
+}
+
/**
* drm_universal_plane_init -
[PATCH 5/6] [v10] drm/i915: Add format modifiers for Intel
This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.
v2:
- Add LINEAR and Yf modifiers to list (Ville)
- Combine i8xx and i965 into one list of formats (Ville)
- Allow 1010102 formats for Y/Yf tiled (Ville)
v3:
- Handle cursor formats (Ville)
- Put handling for LINEAR in the mod_support functions (Ville)
v4:
- List each modifier explicitly in supported modifiers (Ville)
- Handle the CURSOR plane (Ville)
v5:
- Split out cursor and sprite handling (Ville)
v6:
- Actually use the sprite funcs (Emil)
- Use unreachable (Emil)
v7:
- Only allow Intel modifiers and LINEAR (Ben)
v8
- Fix spite assert introduced in v6 (Daniel)
v9
- Change vendor check logic to avoid magic 56 (Emil)
- Reorder skl_mod_support (Ville)
- make intel_plane_funcs static, could be done as of v5 (Ville)
- rename local variable intel_format_modifiers to modifiers (Ville)
- actually use sprite modifiers
- split out modifier/formats by platform (Ville)
v10:
- Undo vendor check from v9
Cc: Ville Syrjälä
Cc: Kristian H. Kristensen
Reviewed-by: Emil Velikov (v8)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c | 127 +--
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_sprite.c | 141 ++-
3 files changed, 259 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b9dda03678c0..ad49b99ef25f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
};
+static const uint64_t i9xx_format_modifiers[] = {
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,11 +93,24 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
+static const uint64_t skl_format_modifiers[] = {
+ I915_FORMAT_MOD_Yf_TILED,
+ I915_FORMAT_MOD_Y_TILED,
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
/* Cursor formats */
static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
};
+static const uint64_t cursor_format_modifiers[] = {
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
static void ironlake_pch_clock_get(struct intel_crtc *crtc,
@@ -13797,7 +13816,98 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
}
-const struct drm_plane_funcs intel_plane_funcs = {
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB1555:
+ case DRM_FORMAT_XRGB:
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ modifier == I915_FORMAT_MOD_X_TILED;
+ default:
+ return false;
+ }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ modifier == I915_FORMAT_MOD_X_TILED;
+ default:
+ return false;
+ }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+ switch (format) {
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_YVYU:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ if (modifier == I915_FORMAT_MOD_Yf_TILED)
+ return true;
+ /* fall through */
+ case DRM_FORMAT_C8:
+ if (modifier == DRM_FORMAT_MOD_LINEAR ||
+ modifier == I915_FORMAT_MOD_X_TILED ||
+ modifier == I915_FORMAT_MOD_Y_TILED)
+ return true;
+ /* fall through */
+ default:
+ return false;
+ }
+}
+
+static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+ struct drm_i915
[PATCH 6/6] [v4] drm/i915: Add support for CCS modifiers
v2:
- Support sprite plane.
- Support pipe C/D limitation on GEN9.
v3:
- Rename structure (Ville)
- Handle GLK (Ville)
v4:
- Fix PIPE_C check, introduced in v2 (Daniel)
- Whitespace fix (Daniel)
Cc: Daniel Stone
Cc: Kristian Høgsberg
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c | 30 +++---
drivers/gpu/drm/i915/intel_sprite.c | 28 +++-
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad49b99ef25f..0dc9f40edc7e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -93,7 +93,17 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
-static const uint64_t skl_format_modifiers[] = {
+static const uint64_t skl_format_modifiers_noccs[] = {
+ I915_FORMAT_MOD_Yf_TILED,
+ I915_FORMAT_MOD_Y_TILED,
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
+static const uint64_t skl_format_modifiers_ccs[] = {
+ I915_FORMAT_MOD_Yf_TILED_CCS,
+ I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
I915_FORMAT_MOD_X_TILED,
@@ -13853,6 +13863,10 @@ static bool skl_mod_supported(uint32_t format,
uint64_t modifier)
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
+ if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_CCS)
+ return true;
+ /* fall through */
case DRM_FORMAT_RGB565:
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
@@ -14099,10 +14113,20 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
primary->check_plane = intel_check_primary_plane;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ intel_primary_formats = skl_primary_formats;
+ num_formats = ARRAY_SIZE(skl_primary_formats);
+ modifiers = skl_format_modifiers_ccs;
+
+ primary->update_plane = skylake_update_primary_plane;
+ primary->disable_plane = skylake_disable_primary_plane;
+ } else if (INTEL_GEN(dev_priv) >= 9) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
- modifiers = skl_format_modifiers;
+ if (pipe < PIPE_C)
+ modifiers = skl_format_modifiers_ccs;
+ else
+ modifiers = skl_format_modifiers_noccs;
primary->update_plane = skylake_update_primary_plane;
primary->disable_plane = skylake_disable_primary_plane;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b1cc4835b963..5a2b3f3693a6 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1085,7 +1085,17 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
};
+static const uint64_t skl_plane_format_modifiers_noccs[] = {
+ I915_FORMAT_MOD_Yf_TILED,
+ I915_FORMAT_MOD_Y_TILED,
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static const uint64_t skl_plane_format_modifiers[] = {
+ I915_FORMAT_MOD_Yf_TILED_CCS,
+ I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
I915_FORMAT_MOD_X_TILED,
@@ -1148,6 +1158,9 @@ static bool skl_sprite_plane_format_mod_supported(struct
drm_plane *plane,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
+ if (modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Yf_TILED_CCS)
+ return true;
case DRM_FORMAT_RGB565:
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
@@ -1230,7 +1243,7 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
}
intel_plane->base.state = &state->base;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (INTEL_GEN(dev_priv) >= 10) {
intel_plane->can_scale = true;
state->scaler_id = -1;
@@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
plane_formats = skl_plane_formats;
num_plane_formats = ARRAY_SIZE(skl_plane_formats);
modifiers = skl_plane_format_modifiers;
+ } else if (INTEL_GEN(dev_priv) >= 9) {
+ intel_plane->can_scale = true;
+ state->scaler_id = -1;
+
+ intel_plane->update_plane = skl_upd
[PATCH 3/6] [v7] drm: Plumb modifiers through plane init
This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.
This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.
v2: A minor addition from Daniel
v3:
* Updated commit message
* s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
* Remove some excess newlines (Liviu)
* Update comment for > 64 modifiers (Liviu)
v4: Minor comment adjustments (Liviu)
v5: Some new platforms added due to rebase
v6: Add some missed plane inits (or maybe they're new - who knows at
this point) (Daniel)
v7: Add sun8i (Daniel)
Signed-off-by: Ben Widawsky
Reviewed-by: Daniel Stone (v2)
Reviewed-by: Liviu Dudau
Acked-by: Philippe Cornu (for stm)
Tested-by: Philippe Cornu (for stm)
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 1 +
drivers/gpu/drm/arm/hdlcd_crtc.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
drivers/gpu/drm/armada/armada_crtc.c| 1 +
drivers/gpu/drm/armada/armada_overlay.c | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ++-
drivers/gpu/drm/drm_modeset_helper.c| 1 +
drivers/gpu/drm/drm_plane.c | 36 -
drivers/gpu/drm/drm_simple_kms_helper.c | 3 +++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 1 +
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 5 +++-
drivers/gpu/drm/i915/intel_sprite.c | 4 +--
drivers/gpu/drm/imx/ipuv3-plane.c | 4 +--
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 2 +-
drivers/gpu/drm/meson/meson_plane.c | 1 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 2 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 4 +--
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
drivers/gpu/drm/nouveau/nv50_display.c | 5 ++--
drivers/gpu/drm/omapdrm/omap_plane.c| 2 +-
drivers/gpu/drm/pl111/pl111_display.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +--
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +--
drivers/gpu/drm/sti/sti_cursor.c| 2 +-
drivers/gpu/drm/sti/sti_gdp.c | 2 +-
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
drivers/gpu/drm/stm/ltdc.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_layer.c | 2 +-
drivers/gpu/drm/sun4i/sun8i_layer.c | 2 +-
drivers/gpu/drm/tegra/dc.c | 12 -
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +-
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 4 +--
drivers/gpu/drm/zte/zx_plane.c | 2 +-
include/drm/drm_plane.h | 22 ++-
include/drm/drm_simple_kms_helper.h | 1 +
include/uapi/drm/drm_fourcc.h | 11
45 files changed, 131 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 1859dd3ad622..799416651f2f 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -217,6 +217,7 @@ static struct drm_plane *arc_pgu_plane_init(struct
drm_device *drm)
ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs,
formats, ARRAY_SIZE(formats),
+ NULL,
DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 16e1e20cf04c..72b22b805412 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -315,6 +315,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device
*drm)
ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs,
formats, ARRAY_SIZE(formats),
+ NULL,
DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 600fa7bd7f52..60402e27882f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
++
Re: [PATCH 11/17] lib/interval_tree: fast overlap detection
On Tue, Jul 18, 2017 at 06:45:57PM -0700, Davidlohr Bueso wrote:
> Allow interval trees to quickly check for overlaps to avoid
> unnecesary tree lookups in interval_tree_iter_first().
>
> As of this patch, all interval tree flavors will require
> using a 'rb_root_cached' such that we can have the leftmost
> node easily available. While most users will make use of this
> feature, those with special functions (in addition to the generic
> insert, delete, search calls) will avoid using the cached
> option as they can do funky things with insertions -- for example,
> vma_interval_tree_insert_after().
>
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Doug Ledford
> Cc: Christian Benvenuti
> Cc: linux-r...@vger.kernel.org
> Acked-by: Christian König
> Acked-by: Peter Zijlstra (Intel)
> Signed-off-by: Davidlohr Bueso
For vhost bits:
Acked-by: Michael S. Tsirkin
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 8 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
> drivers/gpu/drm/drm_mm.c | 19 +
> drivers/gpu/drm/drm_vma_manager.c | 2 +-
> drivers/gpu/drm/i915/i915_gem_userptr.c| 6 +--
> drivers/gpu/drm/radeon/radeon.h| 2 +-
> drivers/gpu/drm/radeon/radeon_mn.c | 8 ++--
> drivers/gpu/drm/radeon/radeon_vm.c | 7 ++--
> drivers/infiniband/core/umem_rbtree.c | 4 +-
> drivers/infiniband/core/uverbs_cmd.c | 2 +-
> drivers/infiniband/hw/hfi1/mmu_rb.c| 10 ++---
> drivers/infiniband/hw/usnic/usnic_uiom.c | 6 +--
> drivers/infiniband/hw/usnic/usnic_uiom.h | 2 +-
> .../infiniband/hw/usnic/usnic_uiom_interval_tree.c | 15 +++
> .../infiniband/hw/usnic/usnic_uiom_interval_tree.h | 12 +++---
> drivers/vhost/vhost.c | 2 +-
> drivers/vhost/vhost.h | 2 +-
> fs/hugetlbfs/inode.c | 6 +--
> fs/inode.c | 2 +-
> include/drm/drm_mm.h | 2 +-
> include/linux/fs.h | 4 +-
> include/linux/interval_tree.h | 8 ++--
> include/linux/interval_tree_generic.h | 46
> +-
> include/linux/mm.h | 17
> include/linux/rmap.h | 4 +-
> include/rdma/ib_umem_odp.h | 11 --
> include/rdma/ib_verbs.h| 2 +-
> lib/interval_tree_test.c | 4 +-
> mm/interval_tree.c | 10 ++---
> mm/memory.c| 4 +-
> mm/mmap.c | 10 ++---
> mm/rmap.c | 4 +-
> 33 files changed, 145 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> index 38f739fb727b..3f8aef21b9a6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> @@ -51,7 +51,7 @@ struct amdgpu_mn {
>
> /* objects protected by lock */
> struct mutexlock;
> - struct rb_root objects;
> + struct rb_root_cached objects;
> };
>
> struct amdgpu_mn_node {
> @@ -76,8 +76,8 @@ static void amdgpu_mn_destroy(struct work_struct *work)
> mutex_lock(&adev->mn_lock);
> mutex_lock(&rmn->lock);
> hash_del(&rmn->node);
> - rbtree_postorder_for_each_entry_safe(node, next_node, &rmn->objects,
> - it.rb) {
> + rbtree_postorder_for_each_entry_safe(node, next_node,
> + &rmn->objects.rb_root, it.rb) {
> list_for_each_entry_safe(bo, next_bo, &node->bos, mn_list) {
> bo->mn = NULL;
> list_del_init(&bo->mn_list);
> @@ -252,7 +252,7 @@ static struct amdgpu_mn *amdgpu_mn_get(struct
> amdgpu_device *adev)
> rmn->mm = mm;
> rmn->mn.ops = &amdgpu_mn_ops;
> mutex_init(&rmn->lock);
> - rmn->objects = RB_ROOT;
> + rmn->objects = RB_ROOT_CACHED;
>
> r = __mmu_notifier_register(&rmn->mn, mm);
> if (r)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index 5795f81369f0..f872e2179bbd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -2405,7 +2405,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct
> amdgpu_vm *vm,
> int r, i;
> u64 flags;
>
> - vm->va = RB_ROOT;
> + vm->va = RB_ROOT_CACHED;
> vm->client_id = atomic64_
[PATCH v2.1 14/14] drm: rcar-du: Configure DPAD0 routing through last group on Gen3
On Gen3 SoCs DPAD0 routing is configured through the last CRTC group,
unlike on Gen2 where it is configured through the first CRTC group. Fix
the driver accordingly.
Fixes: 2427b3037710 ("drm: rcar-du: Add R8A7795 device support")
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Compute the group index correctly on Gen2
---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index a3e29bb420fd..2f37ea901873 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -212,6 +212,9 @@ void rcar_du_group_restart(struct rcar_du_group *rgrp)
int rcar_du_set_dpad0_vsp1_routing(struct rcar_du_device *rcdu)
{
+ struct rcar_du_group *rgrp;
+ struct rcar_du_crtc *crtc;
+ unsigned int index;
int ret;
if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_EXT_CTRL_REGS))
@@ -219,17 +222,22 @@ int rcar_du_set_dpad0_vsp1_routing(struct rcar_du_device
*rcdu)
/*
* RGB output routing to DPAD0 and VSP1D routing to DU0/1/2 are
-* configured in the DEFR8 register of the first group. As this function
-* can be called with the DU0 and DU1 CRTCs disabled, we need to enable
-* the first group clock before accessing the register.
+* configured in the DEFR8 register of the first group on Gen2 and the
+* last group on Gen3. As this function can be called with the DU
+* channels of the corresponding CRTCs disabled, we need to enable the
+* group clock before accessing the register.
*/
- ret = clk_prepare_enable(rcdu->crtcs[0].clock);
+ index = rcdu->info->gen < 3 ? 0 : DIV_ROUND_UP(rcdu->num_crtcs, 2) - 1;
+ rgrp = &rcdu->groups[index];
+ crtc = &rcdu->crtcs[index * 2];
+
+ ret = clk_prepare_enable(crtc->clock);
if (ret < 0)
return ret;
- rcar_du_group_setup_defr8(&rcdu->groups[0]);
+ rcar_du_group_setup_defr8(rgrp);
- clk_disable_unprepare(rcdu->crtcs[0].clock);
+ clk_disable_unprepare(crtc->clock);
return 0;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99316] Radeon crash when laptop on AC power
https://bugs.freedesktop.org/show_bug.cgi?id=99316 --- Comment #11 from Samuel Anderson --- (In reply to Mathias from comment #10) > I have also a Dell notebook with the same dGPU, but cannot reproduce your > error with Ubuntu 16.04 kernel 4.10.0. > > Instead I have the problem, that the dGPU only gets powered at a low > frequency, and becomes slower than the Intel GPU by doing so. > > When I run glmark2, I look at "/sys/kernel/debug/dri/0/radeon_pm_info" and > always see the following output: > > default engine clock: 925000 kHz > current engine clock: 20 kHz > default memory clock: 100 kHz > current memory clock: 148990 kHz > voltage: 1225 mV > PCIE lanes: 16 > > Btw.: This dGPU cannot be connected to a CRT directly, as there seems to be > no connection available at all. Is the GPU at low power while plugged in, or always? glmark2 while plugged in instantly crashes for me, but on battery I get a score of 1395 which is horrible compared to the 3680 from my integrated card. Plus horrible rendering artifacts. But I'm not sure if that is really related to my main problem. This is "/sys/kernel/debug/dri/0/radeon_pm_info" on battery with glmark2 for me: uvdvclk: 0 dclk: 0 power level 2sclk: 4 mclk: 3 vddc: 900 vddci: 0 pcie gen: 3 Oddly enough, a completely different format than yours. This card seems to have a multitude of problems -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99316] Radeon crash when laptop on AC power
https://bugs.freedesktop.org/show_bug.cgi?id=99316 --- Comment #12 from Samuel Anderson --- Created attachment 133178 --> https://bugs.freedesktop.org/attachment.cgi?id=133178&action=edit Rendering artifacts on battery Perhaps not entirely related, but these are rendering artifacts while on battery with glmark2. Note the horizontal lines, this is the main issue, that and major stuttering. glxgears produces similar results. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition
https://bugs.freedesktop.org/show_bug.cgi?id=101988 --- Comment #7 from newin...@gmail.com --- git apply returned me: "error: patch failed: drivers/gpu/drm/amd/amdgpu/si.c:1413 error: drivers/gpu/drm/amd/amdgpu/si.c: patch does not apply" So I checked manually: 1413 amdgpu_program_register_sequence(adev, 1414 pitcairn_mgcg_cgcg_init, 1415 (const u32)ARRAY_SIZE(pitcairn_mgcg_cgcg_init)); 1416 break; 1417 1438 amdgpu_program_register_sequence(adev, 1439 oland_mgcg_cgcg_init, 1440 (const u32)ARRAY_SIZE(oland_mgcg_cgcg_init)); 1441 break; 1442 case CHIP_HAINAN: 1443 The two break are already there. I checked if I cloned what you said: `git branch` return "* drm-next-4.14-wip" I also checked using git log and the patch e5c8d400da67abc1c033b9a4af1806926b55e5f6 is already in the list PS: I'm very far from being a git expert so maybe I got something wrong and not cloned the good one ? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 --- Comment #27 from Luke A. Guest --- > FWIW I don't think any of these patches are relevant to you then. Not strictly true. As I said, Alex pointed me at this page to try his patches. I believe all this is connected. There are issues un/binding from/to the driver. There are reset issues as well. I've put my test branch here https://github.com/Lucretia/linux-amdgpu/tree/amdgpu/v4.13-rc2-amdgpu-reset-test -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition
https://bugs.freedesktop.org/show_bug.cgi?id=101988 --- Comment #8 from Alex Deucher --- (In reply to newincpp from comment #7) > The two break are already there. I checked if I cloned what you said: > `git branch` return > "* drm-next-4.14-wip" > I also checked using git log and the patch > e5c8d400da67abc1c033b9a4af1806926b55e5f6 is already in the list The patch is already there in my 4.14-wip branch, but you seem to be having other problems with that kernel, so I suggested that patch if you want to try the patch on an older kernel that works better. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display
(cc: Daniel Vetter)
Den 01.08.2017 18.51, skrev David Lechner:
On 07/30/2017 12:14 PM, Noralf Trønnes wrote:
Den 29.07.2017 21.40, skrev David Lechner:
On 07/29/2017 02:17 PM, David Lechner wrote:
The goal of this series is to get the built-in LCD of the LEGO
MINDSTORMS EV3
working. But, most of the content here is building up the
infrastructure to do
that.
Some general comments/questions:
I have noticed that DRM doesn't really have support for monochrome
displays. I'm guessing that is because no one really uses them anymore?
The repaper driver was the first monochrome drm driver and I chose to
present it to userspace as XRGB and convert it to monochrome.
The reason for this is that everything, libraries, apps, plymouth (boot
splash, no rgb565) supports it. I didn't see any point in adding a new
monochrome drm format that didn't have, or probably wouldn't get
userspace support (by libraries at least). The application of course
needs to know this to get a good result.
tinydrm_xrgb_to_gray8() does the conversion:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781
The LEGO EV3 display is just an LCD (not the backlit kind). It has
two modes of operation. It can to 2bbp grayscale or it can do 1bpp
monochrome. The grayscale isn't the best (looks splotchy in places),
so it would be nice to be able to choose between these two modes.
How would I implement something like that?
Do you expect anyone to use grayscale if it doesn't look good?
Maybe better to add it later if there's a demand for it.
I don't expect many people to use it at all. The people that do will
be hackers like me that want to see what it is capable of, so I think
I will keep it grayscale by default.
It looks like the best way to satisfy your needs is to add specific formats.
Video for Linux have these:
include/uapi/linux/videodev2.h
/* Grey formats */
#define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8
Greyscale */
#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4
Greyscale */
#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6
Greyscale */
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10
Greyscale */
#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12
Greyscale */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16
Greyscale */
#define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16
Greyscale BE */
Maybe we can add formats like these:
include/uapi/drm/drm_fourcc.h
#define DRM_FORMAT_MONOfourcc_code('Y', '0', '1', ' ') /* [0]
Monochrome */
or
#define DRM_FORMAT_Y1fourcc_code('Y', '0', '1', ' ') /* [0]
Monochrome */
#define DRM_FORMAT_Y2fourcc_code('Y', '0', '2', ' ') /* [1:0]
Greyscale */
Daniel, what do you think?
Also, how can I indicate to userspace that this display really is
monochrome/grayscale since the reported color depth 16bpp?
There isn't unless we add formats for it.
Since this display is in a Lego piece, doesn't it have custom userspace
that already know it's monochrome?
The official LEGO software is like this, yes. But I am working on a
project that supports other LEGO compatible devices that have color
screens, so the same software needs to be able to detect at runtime
which type of screen it is using. Currently I have a plain fbdev
driver that provides FB_VISUAL_MONO10 for the EV3 display and so the
software knows when it has a monochrome screen and when it doesn't.
But since plain fbdev drivers can't be accepted into mainline, I need
to find a different way to detect what type of screen this is so that
my graphics library can treat it differently.
You can tell userspace about the preferred bitdepth:
drm->mode_config.preferred_depth
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101927] American Conquest via Wine cannot start
https://bugs.freedesktop.org/show_bug.cgi?id=101927 --- Comment #2 from almos --- There is nothing wrong with libLLVM-4.0.so.1 as far as I can tell. Only American Conquest throws this error, so there must be something special about this one exe. I compiled Mesa without LLVM, so I could try it with softpipe. I get no dlopen error, but the X error remains. Here is what I have managed to debug so far: - Wine creates a GLX context to query the OpenGL information, destroys it, and creates a permanent one for GDI drawing; the error happens for the second one - In softpipe_create_context() the CALLOC_STRUCT() fails for sp_create_tex_tile_cache() (always at sh=4 and i=28...30), I have no idea why - In CreateContext() (mesa/src/glx/glxcmds.c:278) psc->vtable->create_context() fails because of the previous point, and indirect_create_context() is attempted - The X server rejects indirect contexts (xserver/glx/glxcmds.c:284), hence the X error The hard part is that gdb doesn't work on Wine, and winedbg is mostly useless. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/14] drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x
Hi Kieran,
On Tuesday 01 Aug 2017 15:06:20 Kieran Bingham wrote:
> On 26/06/17 19:12, Laurent Pinchart wrote:
> > The H3 ES1.x exhibits dot clock duty cycle stability issues. We can work
> > around them by configuring the DPLL to twice the desired frequency,
> > coupled with a /2 post-divider. This isn't needed on other SoCs and
> > breaks HDMI output on M3-W for a currently unknown reason, so restrict
> > the workaround to H3 ES1.x.
> >
> > From an implementation point of view, move work around handling outside
> > of the rcar_du_dpll_divider() function by requesting a x2 DPLL output
> > frequency explicitly. The existing post-divider calculation mechanism
> > will then take care of dividing the clock by two automatically.
> >
> > While at it, print a more useful debugging message to ease debugging
> > clock rate issues.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 +---
> > 1 file changed, 27 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 8f942ebdd0c6..6c29981377c0
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -13,6 +13,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -129,10 +130,8 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc
> > *rcrtc,>
> > for (fdpll = 1; fdpll < 32; fdpll++) {
> > unsigned long output;
> >
> > - /* 1/2 (FRQSEL=1) for duty rate 50% */
> > output = input * (n + 1) / (m + 1)
> > - / (fdpll + 1) / 2;
> > -
> > + / (fdpll + 1);
>
> I'm finding this hard to interpret vs the commit-message.
>
> Here we remove the /2 (which affects all targets... is this a problem?)
The purpose of this function is to compute DPLL parameters for given input and
output frequencies. However, the current implementation computes parameters
that result in twice the requested frequency, assuming that the caller will
configure a /2 post-divider.
I found this confusing, so the patch modifies the function to use the
requested output frequency, and updates the caller accordingly. The function
now performs the operation described by its name.
This indeed affects all targets, but there's no DPLL on Gen2, so in practice
only H3 and M3-W are affected.
> > if (output >= 4)
> > continue;
[snip]
> > @@ -185,7 +189,20 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)>
> > extclk = clk_get_rate(rcrtc->extclock);
> > if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> >
> > - rcar_du_dpll_divider(rcrtc, &dpll, extclk,
> > mode_clock);
> > + unsigned long target = mode_clock;
> > +
> > + /*
> > +* The H3 ES1.x exhibits dot clock duty cycle
> > stability
> > +* issues. We can work around them by configuring the
> > +* DPLL to twice the desired frequency, coupled with a
> > +* /2 post-divider. This isn't needed on other SoCs
> > and
>
> But here we discuss 'coupling' it with a /2 post - divider.
>
> My inference here then is that by setting a target that is 'twice' the value
> - code later will provide the /2 post-divide?
Correct. The /2 post-divider is required on H3 ES1.x to obtain a stable output
clock, so the output of the DPLL has to be twice the pixel clock frequency.
Based on my understanding it shouldn't hurt to do the same on H3 ES2.0 and M3-
W, but in practice that doesn't work. I've thus restricted the post-divider to
H3 ES1.x.
> > +* breaks HDMI output on M3-W for a currently unknown
> > +* reason, so restrict the workaround to H3 ES1.x.
> > +*/
> > + if (soc_device_match(rcar_du_r8a7795_es1))
> > + target *= 2;
> > +
> > + rcar_du_dpll_divider(rcrtc, &dpll, extclk, target);
> > extclk = dpll.output;
> > }
> >
> > @@ -197,8 +214,6 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> > if (abs((long)extrate - (long)mode_clock) <
> > abs((long)rate - (long)mode_clock)) {
> > - dev_dbg(rcrtc->group->dev->dev,
> > - "crtc%u: using external clock\n", rcrtc-
>index);
> >
> > if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> > u32 dpllcr = DPLLCR_CODE | DPLLCR_CLKE
> >
> > @@ -215,12 +230,14 @@ static void rcar_du_crtc_set_display_timing(struct
> > rcar_du_crtc *rcrtc)
> >
Re: [PATCH v2 11/14] v4l: vsp1: Add support for header display lists in continuous mode
Hi Kieran, On Tuesday 01 Aug 2017 18:35:48 Kieran Bingham wrote: > On 26/06/17 19:12, Laurent Pinchart wrote: > > The VSP supports both header and headerless display lists. The latter is > > easier to use when the VSP feeds data directly to the DU in continuous > > mode, and the driver thus uses headerless display lists for DU operation > > and header display lists otherwise. > > > > Headerless display lists are only available on WPF.0. This has never > > been an issue so far, as only WPF.0 is connected to the DU. However, on > > H3 ES2.0, the VSP-DL instance has both WPF.0 and WPF.1 connected to the > > DU. We thus can't use headerless display lists unconditionally for DU > > operation. > > Would it be crazy to suggest we drop headerless display lists? > > If we must support header display lists in continuous mode - Rather than > having 2 cases for continuous modes to support (having to support > headerless, on WPF.0, and header on WPF.1) if we just use your header loop > trick - would that simplify our code maintenance? > > (We can always remove headerless support later if you agree, this is more of > an idea at the moment) I had the exact same thought, but I believe we should wait a few kernel releases to see if the next code is stable before removing the old one. I have a debug patch that forces usage of header display lists unconditionally, and I'll try to develop a few additional stress-tests for that. > > Implement support for continuous mode with header display lists, and use > > it for DU operation on WPF outputs that don't support headerless mode. > > > > Signed-off-by: Laurent Pinchart > > > > Except for future discussion points, I can't see anything wrong here so: > > Reviewed-by: Kieran Bingham > > > --- > > > > drivers/media/platform/vsp1/vsp1_dl.c | 195 +- > > drivers/media/platform/vsp1/vsp1_regs.h | 1 + > > 2 files changed, 127 insertions(+), 69 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/14] drm: rcar-du: Support multiple sources from the same VSP
Hi Kieran,
On Tuesday 01 Aug 2017 19:10:20 Kieran Bingham wrote:
> On 26/06/17 19:12, Laurent Pinchart wrote:
> > On R-Car H3 ES2.0, DU channels 0 and 3 are served by two separate
> > pipelines from the same VSP. Support this in the DU driver.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> This looks good to me.
>
> Minor nit / comment can be safely ignored. Mostly just me thinking outload.
>
> Reviewed-by: Kieran Bingham
>
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 3 ++
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 91 +
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 37 +++---
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 10 +++-
> > 5 files changed, 110 insertions(+), 33 deletions(-)
[snip]
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index f4125c8ca902..82b978a5dae6
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -432,6 +432,83 @@ static int rcar_du_properties_init(struct
> > rcar_du_device *rcdu)
> > return 0;
> > }
> >
> > +static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
> > +{
> > + const struct device_node *np = rcdu->dev->of_node;
> > + struct of_phandle_args args;
> > + struct {
> > + struct device_node *np;
> > + unsigned int crtcs_mask;
> > + } vsps[RCAR_DU_MAX_VSPS] = { { 0, }, };
> > + unsigned int vsps_count = 0;
> > + unsigned int cells;
> > + unsigned int i;
> > + int ret;
> > +
> > + /*
> > +* First parse the DT vsps property to populate the list of VSPs. Each
> > +* entry contains a pointer to the VSP DT node and a bitmask of the
> > +* connected DU CRTCs.
> > +*/
> > + cells = of_property_count_u32_elems(np, "vsps") / rcdu->num_crtcs - 1;
> > + if (cells > 1)
> > + return -EINVAL;
> > +
> > + for (i = 0; i < rcdu->num_crtcs; ++i) {
> > + unsigned int j;
> > +
> > + ret = of_parse_phandle_with_fixed_args(np, "vsps", cells, i,
> > + &args);
> > + if (ret < 0)
> > + goto error;
> > +
> > + /*
> > +* Add the VSP to the list or update the corresponding
> > existing
> > +* entry if the VSP has already been added.
> > +*/
> > + for (j = 0; j < vsps_count; ++j) {
> > + if (vsps[j].np == args.np)
> > + break;
> > + }
> > +
> > + if (j < vsps_count)
> > + of_node_put(args.np);
> > + else
> > + vsps[vsps_count++].np = args.np;
> > +
> > + vsps[j].crtcs_mask |= 1 << i;
>
> I do love the BIT(x) macro personally - but it's not important :)
I wonder why I don't like the BIT macro. There's probably no good reason.
> > +
> > + /* Store the VSP pointer and pipe index in the CRTC. */
> > + rcdu->crtcs[i].vsp = &rcdu->vsps[j];
> > + rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0;
> > + }
> > +
> > + /*
> > +* Then initialize all the VSPs from the node pointers and CRTCs
> > bitmask
> > +* computed previously.
> > +*/
> > + for (i = 0; i < vsps_count; ++i) {
> > + struct rcar_du_vsp *vsp = &rcdu->vsps[i];
> > +
> > + vsp->index = i;
> > + vsp->dev = rcdu;
> > +
> > + ret = rcar_du_vsp_init(vsp, vsps[i].np, vsps[i].crtcs_mask);
> > + if (ret < 0)
> > + goto error;
> > + }
> > +
> > + return 0;
> > +
> > +error:
> > + for (i = 0; i < ARRAY_SIZE(vsps); ++i) {
> > + if (vsps[i].np)
>
> Minor nit: of_node_put already has NULL protection so we don't need this
> 'if' but it probably does make it clearer that we are only putting back
> nodes that we collected.
It's a good point, I'll remove the check.
> > + of_node_put(vsps[i].np);
> > + }
> > +
> > + return ret;
> > +}
[snip]
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101969] Massive graphics corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=101969
--- Comment #5 from Chris Rankin ---
Ah, this is now fixed in the latest Mesa-git. I am assuming that this is the
relevant commit:
author Marek Olšák2017-07-30 01:37:21 (GMT)
committer Marek Olšák2017-08-01 15:06:38
(GMT)
commit b9fc9d3f241758ed8a274be7abf68bf448653508 (patch)
tree982cbf445d27083138874d22599c3fbdb11e0a57
parent b99dcbfeb344390fea9919199b34e5504f7c84e3 (diff)
radeonsi: fix various CLEAR_STATE issues
Fixes: 064550238ef0 ("radeonsi: use CLEAR_STATE to initialize some registers")
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102006] gstreamer vaapih264enc segfault
https://bugs.freedesktop.org/show_bug.cgi?id=102006 Bug ID: 102006 Summary: gstreamer vaapih264enc segfault Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: rata...@gmail.com Created attachment 133180 --> https://bugs.freedesktop.org/attachment.cgi?id=133180&action=edit proposed patch by Julien Isorce Based on following bug: https://bugzilla.gnome.org/show_bug.cgi?id=785085 In Mesa the picture_id is a frame number which is in the range 0-31 here: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/picture.c#n430 In gst vaapi it is used as surface handles and that can be larger than 31 thus causing SEGFAULT. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access
If we return here and import_attach is true, then dma_buf_end_cpu_access() will not be called balance dma_buf_begin_cpu_access(). Fix by setting ret instead of returning. Signed-off-by: David Lechner --- drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c b/drivers/gpu/drm/tinydrm/mipi-dbi.c index c83eeb7..e10fa4b 100644 --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c @@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb, dev_err_once(fb->dev->dev, "Format is not supported: %s\n", drm_get_format_name(fb->format->format, &format_name)); - return -EINVAL; + ret = -EINVAL; + break; } if (import_attach) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101988] blackscreen after modprobe amdgpu on R9M370X mac edition
https://bugs.freedesktop.org/show_bug.cgi?id=101988 --- Comment #9 from newin...@gmail.com --- Having this patch or not on 4.12.4 does not change anything (at least on this bug) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add drm ioctl DRM_IOCTL_MODE_GETFB2 & associated helpers.
Hi Joe,
On Tuesday 01 Aug 2017 10:24:25 Joe Kniss wrote:
> On Tue, Aug 1, 2017 at 5:09 AM, Laurent Pinchart wrote:
> > On Monday 31 Jul 2017 11:29:13 Joe Kniss wrote:
> >> New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric
> >> with addfb2.
> >
> > What's the use case for this ? We haven't needed such an ioctl for so long
> > that it seemed to me that userspace doesn't really need it, but I could be
> > wrong.
>
> Sorry, I failed to reference the original email. Here it is:
>
>
> I am a recent addition to Google's ChromeOS gfx team. I am currently
> working on display testing and reporting. An important part of this is
> our screen capture tool, which works by querying drm for crtcs, planes, and
> fbs. Unfortunately, there is only limited information available via
> drmModeGetFB(), which often wrong information when drmModeAddFB2() was used
> to create the fbs. For example, if the pixel format is NV12 or YUV420,
> the fb returned knows nothing about the additional buffer planes required
> by these formats. Ideally, we would like a function (e.g. drmModeGetFB2)
> to return information symmetric with drmModeAddFB2 including the pixel
> format id, buffer plane information etc.
>
>
> ChromeOS has needed this functionality from the start, for both testing and
> error reporting. We got away with guessing the buffer's format (32bit
> xrgb) until now. We are now enabling overlays and more formats including
> multi-planar (e.g. NV12). Current getfb() reports neither the pixel format
> nor planar information. Without this information, going forward, our gfx
> testing is going to break. It would be great if we had access to higher
> level buffer structs (like gbm), but we generally don't since they would be
> created by other apps (chrome browser, android apps, etc...).
How is screen capture implemented ? Do you enumerate the framebuffers being
scanned out, dump their contents and compose them manually based on the active
plane configuration ? If so, isn't this very race-prone ?
> >> Also modifies *_fb_create_handle() calls to accept a
> >> format_plane_index so that handles for each plane can be generated.
> >> Previously, many *_fb_create_handle() calls simply defaulted to plane 0
> >> only.
> >
> > And with this patch the amd/amdgpu, armada, gma500, i915, mediatek, msm,
> > nouveau and radeon drivers still do. Do none of them support multi-planar
> > formats ?
>
> I would imagine that some of these do support multi-planar formats, but
> they don't appear to have them implemented yet (except perhaps as offsets
> into a single buffer). I will certainly be looking into this soon, but any
> changes will come in future patches.
>
> >> Signed-off-by: Joe Kniss
> >> ---
> >>
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +-
> >> drivers/gpu/drm/armada/armada_fb.c | 1 +
> >> drivers/gpu/drm/drm_crtc_internal.h | 2 +
> >> drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++--
> >> drivers/gpu/drm/drm_framebuffer.c | 79 +++-
> >> drivers/gpu/drm/drm_ioctl.c | 1 +
> >> drivers/gpu/drm/exynos/exynos_drm_fb.c | 7 ++-
> >> drivers/gpu/drm/gma500/framebuffer.c| 2 +
> >> drivers/gpu/drm/i915/intel_display.c| 1 +
> >> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 1 +
> >> drivers/gpu/drm/msm/msm_fb.c| 5 +-
> >> drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
> >> drivers/gpu/drm/omapdrm/omap_fb.c | 5 +-
> >> drivers/gpu/drm/radeon/radeon_display.c | 5 +-
> >> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 6 ++-
> >> drivers/gpu/drm/tegra/fb.c | 9 +++-
> >> include/drm/drm_framebuffer.h | 1 +
> >> include/uapi/drm/drm.h | 2 +
> >> 18 files changed, 127 insertions(+), 17 deletions(-)
> >
> > [snip]
> >
> >> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> >> b/drivers/gpu/drm/drm_framebuffer.c index 28a0108a1ab8..67b3be1bedbc
> >> 100644
> >> --- a/drivers/gpu/drm/drm_framebuffer.c
> >> +++ b/drivers/gpu/drm/drm_framebuffer.c
> >> @@ -24,6 +24,7 @@
[snip]
> >> +/**
> >> + * drm_mode_getfb2 - get FB info
> >> + * @dev: drm device for the ioctl
> >> + * @data: data pointer for the ioctl
> >> + * @file_priv: drm file for the ioctl call
> >> + *
> >> + * Lookup the FB given its ID and return info about it.
> >> + *
> >> + * Called by the user via ioctl.
> >> + *
> >> + * Returns:
> >> + * Zero on success, negative errno on failure.
> >> + */
> >> +int drm_mode_getfb2(struct drm_device *dev,
> >> +void *data, struct drm_file *file_priv)
> >> +{
> >> + struct drm_mode_fb_cmd2 *r = data;
> >> + struct drm_framebuffer *fb;
> >> + int ret, i;
> >> +
> >> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> >> + return -EINVAL;
> >> +
> >> + fb = drm_framebuffer_lookup(dev, r->fb_id);
> >> + if (!fb)
> >> + return -ENOENT;
Re: [PATCH 00/14] mgag200 fixes
On Tue, 01 Aug 2017 21:25:11 +0200, Mathieu Larouche wrote: > > On 18/07/2017 10:43 AM, Takashi Iwai wrote: > > Hi, > > > > this is a summer cleanup sale, a patchset containing various fixes for > > mgag200 driver taken from openSUSE / SUSE kernels. They have been in > > our kernels for ages, so at least they are supposed to be stable. > > > > Most of patches came from Egbert, and one PM patch from me that is a > > resubmission of the once-post-and-lost patch. > > > > > > thanks, > > > > Takashi > > > > === > > > > Egbert Eich (13): > >drm/mgag200: Add doublescan and interlace support > >drm/mgag200: Add additional limits for certain G200 variants > >drm/mgag200: Fix memleak in error path in mgag200_bo_create() > >drm/mgag200: Free container instead of member in > > mga_user_framebuffer_destroy() > >drm/mgag200: Initialize data needed to map fbdev memory > >drm/mgag200: Simplify function mgag200_ttm_placement() > >drm/mgag200: Add support for MATROX PCI device IDs 0x520 and 0x521 > >drm/mgag200: Cleanup cursor BOs properly > >drm/mgag200: Add missing drm_connector_unregister() > >drm/mgag200: Don't use crtc_* parameters for validation > >drm/mgag200: Consolidate depth/bpp handling > >drm/mgag200: Add command line option to specify preferred depth > >drm/mgag200: Add mode validation debugging code > > > > Takashi Iwai (1): > >drm/mgag200: Implement basic PM support > > > > drivers/gpu/drm/mgag200/mgag200_drv.c | 54 +++ > > drivers/gpu/drm/mgag200/mgag200_drv.h | 22 +++-- > > drivers/gpu/drm/mgag200/mgag200_fb.c | 14 +-- > > drivers/gpu/drm/mgag200/mgag200_main.c | 146 +++-- > > drivers/gpu/drm/mgag200/mgag200_mode.c | 166 > > ++--- > > drivers/gpu/drm/mgag200/mgag200_ttm.c | 11 ++- > > 6 files changed, 357 insertions(+), 56 deletions(-) > > > > Patches were tested against G200eW3, G200e4 & G200eH3 and it's working > fine and we haven't seen any issues. Thanks for testing! > There's one thing though, the patch "[PATCH 01/14] drm/mgag200: Add > doublescan and interlace support" may cause problems as doublescan and > interlace aren't tested and aren't officially supported on the G200 > server line products. So, I'm wondering if it shouldn't be kept > disabled for them. OK, that's good to know. My understanding is that the patch was brought only for adapting the UMS X driver quality, but not for actually fixing the real bugs. Let's drop that patch, then. Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
On Tue, 25 Jul 2017 17:28:18 +0800
Tina Zhang wrote:
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
> get the plan and its related information.
>
> The dma-buf's life cycle is handled by user mode and tracked by kernel.
> The returned fd in struct vfio_device_query_gfx_plane can be a new
> fd or an old fd of a re-exported dma-buf. Host User mode can check the
> value of fd and to see if it needs to create new resource according to
> the new fd or just use the existed resource related to the old fd.
>
> Signed-off-by: Tina Zhang
> ---
> include/uapi/linux/vfio.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index ae46105..827a230 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,6 +502,34 @@ struct vfio_pci_hot_reset {
>
> #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE + 13)
>
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14, struct
> vfio_device_query_gfx_plane)
> + *
> + * Set the drm_plane_type and retrieve information about the gfx plane.
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +struct vfio_device_gfx_plane_info {
> + __u32 argsz;
> + __u32 flags;
> + /* in */
> + __u32 drm_plane_type; /* type of plane: DRM_PLANE_TYPE_* */
> + /* out */
> + __u32 drm_format; /* drm format of plane */
> + __u64 drm_format_mod; /* tiled mode */
> + __u32 width;/* width of plane */
> + __u32 height; /* height of plane */
> + __u32 stride; /* stride of plane */
> + __u32 size; /* size of plane in bytes, align on page*/
> + __u32 x_pos;/* horizontal position of cursor plane, upper left
> corner in pixels */
> + __u32 y_pos;/* vertical position of cursor plane, upper left corner
> in lines*/
> + __u32 region_index;
> + __s32 fd; /* dma-buf fd */
How do I know which of these is valid, region_index or fd? Can I ask
for one vs the other? What are the errno values to differentiate
unsupported vs not initialized? Is there a "probe" flag that I can use
to determine what the device supports without allocating those
resources yet?
Kirti, does this otherwise meet your needs?
Thanks,
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102008] DRI_PRIME causes X Error of failed request: BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=102008 Bug ID: 102008 Summary: DRI_PRIME causes X Error of failed request: BadAlloc (insufficient resources for operation) Product: Mesa Version: 17.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: bartos.p...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Hi, I'm on Fedora using git mesa from che/mesa Copr repository. From build based on commit 5ffe0c9 I am encountering problem with using discrete Radeon R5 M240 via DRI_PRIME. When using wine, it crashes with message: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 148 () Minor opcode of failed request: 2 Serial number of failed request: 4615 Current serial number in output stream: 4616 Steam via wine with DRI_PRIME starts, but crashes whenever any game is started or when system information dialog is invoked (with above message). Native Steam with DRI_PRIME does not start at all, some native games work (Amnesia), some not (Serious Sam Fusion), however message printed when using wine does not appear. Last mesa built which works for me is based on commit 7250cba. I'm using modesetting driver for both GPUs. Programs with DRI_PRIME starts when DRI3 is disabled via LIBGL_DRI3_DISABLE, however in that case image is distorted and thus unusable. I thought it might be some problem related to 101867 or 101876, however these should be fixed and latest mesa build based on commit b8bea9a still does not work for me. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] Support for LEGO MINDSTORMS EV3 LCD display
The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3 working. v2 changes: * Wrote a new driver for ST7586 instead of combining it with existing drivers * Don't touch MIPI DBI code (other than the patch suggested by Noralf) * New defconfig patch David Lechner (4): drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init() drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD ARM: dts: da850-lego-ev3: Add node for LCD display ARM: davinci_all_defconfig: enable tinydrm and ST7586 .../devicetree/bindings/display/st7586.txt | 26 + arch/arm/boot/dts/da850-lego-ev3.dts | 24 + arch/arm/configs/davinci_all_defconfig | 2 + drivers/gpu/drm/tinydrm/Kconfig| 10 + drivers/gpu/drm/tinydrm/Makefile | 1 + drivers/gpu/drm/tinydrm/mi0283qt.c | 8 +- drivers/gpu/drm/tinydrm/mipi-dbi.c | 17 +- drivers/gpu/drm/tinydrm/st7586.c | 579 + include/drm/tinydrm/mipi-dbi.h | 6 +- include/drm/tinydrm/st7586.h | 34 ++ 10 files changed, 688 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/st7586.txt create mode 100644 drivers/gpu/drm/tinydrm/st7586.c create mode 100644 include/drm/tinydrm/st7586.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] ARM: davinci_all_defconfig: enable tinydrm and ST7586
This enables the tinydrm and ST7586 panel modules used by the display on LEGO MINDSTORMS EV3. Signed-off-by: David Lechner --- arch/arm/configs/davinci_all_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index 06e2e2a..27d9720 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -143,6 +143,8 @@ CONFIG_VIDEO_ADV7343=m CONFIG_DRM=m CONFIG_DRM_TILCDC=m CONFIG_DRM_DUMB_VGA_DAC=m +CONFIG_DRM_TINYDRM=m +CONFIG_TINYDRM_ST7586=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DA8XX=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()
This removes the call to mipi_dbi_init() from mipi_dbi_spi_init() so that
drivers can have a driver-specific implementation if needed.
Also fixed order of @dc parameter in the doc comment.
Suggested-by: Noralf Trønnes
Signed-off-by: David Lechner
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 8 ++--
drivers/gpu/drm/tinydrm/mipi-dbi.c | 17 +
include/drm/tinydrm/mipi-dbi.h | 6 +-
3 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 482ff1c3..7e5bb7d 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -195,8 +195,12 @@ static int mi0283qt_probe(struct spi_device *spi)
device_property_read_u32(dev, "rotation", &rotation);
- ret = mipi_dbi_spi_init(spi, mipi, dc, &mi0283qt_pipe_funcs,
- &mi0283qt_driver, &mi0283qt_mode, rotation);
+ ret = mipi_dbi_spi_init(spi, mipi, dc);
+ if (ret)
+ return ret;
+
+ ret = mipi_dbi_init(&spi->dev, mipi, &mi0283qt_pipe_funcs,
+ &mi0283qt_driver, &mi0283qt_mode, rotation);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index e10fa4b..cba9784 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -777,15 +777,12 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi,
u8 cmd,
/**
* mipi_dbi_spi_init - Initialize MIPI DBI SPI interfaced controller
* @spi: SPI device
- * @dc: D/C gpio (optional)
* @mipi: &mipi_dbi structure to initialize
- * @pipe_funcs: Display pipe functions
- * @driver: DRM driver
- * @mode: Display mode
- * @rotation: Initial rotation in degrees Counter Clock Wise
+ * @dc: D/C gpio (optional)
*
* This function sets &mipi_dbi->command, enables &mipi->read_commands for the
- * usual read commands and initializes @mipi using mipi_dbi_init().
+ * usual read commands. It should be followed by a call to mipi_dbi_init() or
+ * a driver-specific init.
*
* If @dc is set, a Type C Option 3 interface is assumed, if not
* Type C Option 1.
@@ -800,11 +797,7 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi,
u8 cmd,
* Zero on success, negative error code on failure.
*/
int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation)
+ struct gpio_desc *dc)
{
size_t tx_size = tinydrm_spi_max_transfer_size(spi, 0);
struct device *dev = &spi->dev;
@@ -850,7 +843,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *mipi,
return -ENOMEM;
}
- return mipi_dbi_init(dev, mipi, pipe_funcs, driver, mode, rotation);
+ return 0;
}
EXPORT_SYMBOL(mipi_dbi_spi_init);
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index d137b16..83346dd 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -62,11 +62,7 @@ mipi_dbi_from_tinydrm(struct tinydrm_device *tdev)
}
int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation);
+ struct gpio_desc *dc);
int mipi_dbi_init(struct device *dev, struct mipi_dbi *mipi,
const struct drm_simple_display_pipe_funcs *pipe_funcs,
struct drm_driver *driver,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] ARM: dts: da850-lego-ev3: Add node for LCD display
This adds a new node for the LEGO MINDSTORMS EV3 LCD display.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/da850-lego-ev3.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 45983c0..249b317 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -249,6 +249,15 @@
0x4c 0x0080 0x00f0
>;
};
+
+ ev3_lcd_pins: pinmux_lcd {
+ pinctrl-single,bits = <
+ /* SIMO, GP2[11], GP2[12], CLK */
+ 0x14 0x00188100 0x0000
+ /* GP5[0] */
+ 0x30 0x8000 0xf000
+ >;
+ };
};
&pinconf {
@@ -357,6 +366,21 @@
};
};
+&spi1 {
+ status = "okay";
+ pinctrl-0 = <&ev3_lcd_pins>;
+ pinctrl-names = "default";
+ cs-gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
+
+ display@0{
+ compatible = "lego,ev3-lcd";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&ehrpwm0 {
status = "okay";
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
}
+
+ /* Avoid flicker by skipping setup if the bootloader has done it */
+ if (mipi_dbi_display_is_on(mipi))
+ return 0;
+
+ mipi_dbi_hw_reset(mipi);
+ ret = mipi_dbi_command(mipi, ST7586_AUTO_READ_CTRL, 0x9f);
+ if (ret) {
+ dev_err(dev, "Error sending command %d\n", ret);
+ regulator_disable(mipi->regulator);
+ return ret;
+ }
+
+ mipi_dbi_command(mipi, ST7586_OTP_RW_CTRL, 0x00);
+
+ msleep(10);
+
+ mipi_dbi_command(mipi, ST7586_OTP_READ);
+
+ msleep(20);
+
+ mipi_dbi_command(mipi, ST7586_OTP_CTRL_OUT);
+ mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
+
+ msleep(50);
+
+ mipi_dbi_command(mipi, ST7586_SET_VOP_OFFSET, 0x00);
+ mipi_dbi_command(mipi, ST7586_SET_VOP, 0xe3, 0x00);
+ mipi_dbi_command(mipi, ST7586_SET_BIAS_SYSTEM, 0x02);
+ mipi_dbi_command(mipi, ST7586_SET_BOOST_LEVEL, 0x04);
+ mipi_dbi_command(mipi, ST7586_ENABLE_ANALOG, 0x1d);
+ mipi_dbi_command(mipi, ST7586_SET_NLINE_INV, 0x00);
+ mipi_dbi_command(mipi, ST7586_DISP_MODE_GRAY);
+ mipi_dbi_command(mipi, ST7586_ENABLE_DDRAM, 0x02);
+
+ switch (mipi->rotation) {
+ default:
+ addr_mode = 0x00;
+ break;
+ case 90:
+ addr_mode = ST7586_DISP_CTRL_MY;
+ break;
+ case 180:
+ addr_mode = ST7586_DISP_CTRL_MX | ST7586_DISP_CTRL_MY;
+ break;
+ case 270:
+ addr_mode = ST7586_DISP_CTRL_MX;
+ break;
+ }
+ mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+
+ mipi_dbi_command(mipi, ST7586_SET_DISP_DUTY, 0x7f);
+ mipi_dbi_command(mipi, ST7586_SET_PART_DISP, 0xa0);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_PARTIAL_AREA, 0x00, 0x00, 0x00,
0x77);
+ mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+
+ msleep(100);
+
+ mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+ return 0;
+}
+
+static void st7586_fini(void *data)
+{
+ struct mipi_dbi *mipi = data;
+
+ DRM_DEBUG_KMS("\n");
+ regulator_disable(mipi->regulator);
+}
+
+static const struct drm_simple_display_pipe_funcs st7586_pipe_funcs = {
+ .enable = st7586_mipi_dbi_pipe_enable,
+ .disable = st7586_mipi_dbi_pipe_disable,
+ .update = tinydrm_display_pipe_update,
+ .prepare_fb = tinydrm_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode st7586_mode = {
+ TINYDRM_MODE(178, 128, 37, 27),
+};
+
+DEFINE_DRM_GEM_CMA_FOPS(st7586_fops);
+
+static struct drm_driver st7586_driver = {
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+ .fops = &st7586_fops,
+ TINYDRM_GEM_DRIVER_OPS,
+ .lastclose = tinydrm_lastclose,
+ .debugfs_init = mipi_dbi_debugfs_init,
+ .name = "st7586",
+ .desc = "Sitronix ST7586",
+ .date = "20170801",
+ .major = 1,
+ .minor = 0,
+};
+
+static const struct of_device_id st7586_of_match[] = {
+ { .compatible = "lego,ev3-lcd" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, st7586_of_match);
+
+static const struct spi_device_id st7586_id[] = {
+ { "ev3-lcd", 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(spi, st7586_id);
+
+static int st7586_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct tinydrm_device *tdev;
+ struct mipi_dbi *mipi;
+ struct gpio_desc *dc;
+ u32 rotation = 0;
+ int ret;
+
+ mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
+ if (!mipi)
+ return -ENOMEM;
+
+ mipi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(mipi->reset)) {
+ dev_err(dev, "Failed to get gpio 'reset'\n");
+ return PTR_ERR(mipi->reset);
+ }
+
+ dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
+ if (IS_ERR(dc)) {
+ dev_err(dev, "Failed to get gpio 'dc'\n");
+ return PTR_ERR(dc);
+ }
+
+ mipi->regulator = devm_regulator_get(dev, "power");
+ if (IS_ERR(mipi->regulator))
+ return PTR_ERR(mipi->regulator);
+
+ mipi->backlight = tinydrm_of_find_backlight(dev);
+ if (IS_ERR(mipi->backlight))
+ return PTR_ERR(mipi->backlight);
+
+ device_property_read_u32(dev, "rotation", &rotation);
+
+ ret = mipi_dbi_spi_init(spi, mipi, dc);
+ if (ret)
+ return ret;
+
+ /*
+*
[Bug 102009] Blender crashes when compiling OpenCL kernel
https://bugs.freedesktop.org/show_bug.cgi?id=102009 Bug ID: 102009 Summary: Blender crashes when compiling OpenCL kernel Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: m...@graph-ix.net QA Contact: dri-devel@lists.freedesktop.org Created attachment 133182 --> https://bugs.freedesktop.org/attachment.cgi?id=133182&action=edit Blender crash dump On Ubuntu 17.04 with a AMD Radeon R9 380 (Tonga Pro chipset), daily Mesa from Padoka PPA (version 1:17.3~git170731230100.df61a05~z~padoka0), both Blender 2.78 and 2.79 daily build (09eac0159db) crash when the OpenCL kernel is compiled for GPU rendering. Steps to reproduce: 1. Start Blender with `CYCLES_OPENCL_SPLIT_KERNEL_TEST=1 ./blender` due to missing detection of OpenCL support (probably due to #101594). 2. Under Render settings, switch `Device` to `GPU Compute` and assert this setting is actually used. 3. Start a render and assert the OpenCL kernel is compiled. Actual behavior: * Blender crashes during kernel compilation (crash dump of 2.79 build is attached). Expected behavior: * Blender renders with OpenCL. Addtional info: * `clinfo` and `glxinfo` output is attached as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102009] Blender crashes when compiling OpenCL kernel
https://bugs.freedesktop.org/show_bug.cgi?id=102009 --- Comment #1 from Markus --- Created attachment 133183 --> https://bugs.freedesktop.org/attachment.cgi?id=133183&action=edit glxinfo -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102009] Blender crashes when compiling OpenCL kernel
https://bugs.freedesktop.org/show_bug.cgi?id=102009 --- Comment #2 from Markus --- Created attachment 133184 --> https://bugs.freedesktop.org/attachment.cgi?id=133184&action=edit clinfo -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display
On 08/01/2017 01:08 PM, Noralf Trønnes wrote:
(cc: Daniel Vetter)
Den 01.08.2017 18.51, skrev David Lechner:
On 07/30/2017 12:14 PM, Noralf Trønnes wrote:
Den 29.07.2017 21.40, skrev David Lechner:
On 07/29/2017 02:17 PM, David Lechner wrote:
The goal of this series is to get the built-in LCD of the LEGO
MINDSTORMS EV3
working. But, most of the content here is building up the
infrastructure to do
that.
Some general comments/questions:
I have noticed that DRM doesn't really have support for monochrome
displays. I'm guessing that is because no one really uses them anymore?
The repaper driver was the first monochrome drm driver and I chose to
present it to userspace as XRGB and convert it to monochrome.
The reason for this is that everything, libraries, apps, plymouth (boot
splash, no rgb565) supports it. I didn't see any point in adding a new
monochrome drm format that didn't have, or probably wouldn't get
userspace support (by libraries at least). The application of course
needs to know this to get a good result.
tinydrm_xrgb_to_gray8() does the conversion:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781
The LEGO EV3 display is just an LCD (not the backlit kind). It has
two modes of operation. It can to 2bbp grayscale or it can do 1bpp
monochrome. The grayscale isn't the best (looks splotchy in places),
so it would be nice to be able to choose between these two modes.
How would I implement something like that?
Do you expect anyone to use grayscale if it doesn't look good?
Maybe better to add it later if there's a demand for it.
I don't expect many people to use it at all. The people that do will
be hackers like me that want to see what it is capable of, so I think
I will keep it grayscale by default.
It looks like the best way to satisfy your needs is to add specific
formats.
Video for Linux have these:
include/uapi/linux/videodev2.h
/* Grey formats */
#define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8
Greyscale */
#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4
Greyscale */
#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6
Greyscale */
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10
Greyscale */
#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12
Greyscale */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16
Greyscale */
#define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16
Greyscale BE */
Maybe we can add formats like these:
include/uapi/drm/drm_fourcc.h
#define DRM_FORMAT_MONOfourcc_code('Y', '0', '1', ' ') /* [0]
Monochrome */
or
#define DRM_FORMAT_Y1fourcc_code('Y', '0', '1', ' ') /* [0]
Monochrome */
#define DRM_FORMAT_Y2fourcc_code('Y', '0', '2', ' ') /* [1:0]
Greyscale */
Daniel, what do you think?
2 of the first 3 tinydrm drivers are monochrome (and I would like to
write a driver for the Seeed/Grove I2C OLED displays which are also
monochrome), so I think the 1bpp modes would definitely be useful. I
think there is enough userspace code still around that knows about
FB_VISUAL_MONO01 and FB_VISUAL_MONO10 that could use these.
I don't think a Y02 mode would be useful though. There is pretty much
nothing out there (that I could find) that uses such a mode.
A Y08 mode for 8bpp grayscale would be useful though. This is another
more commonly used format.
Also, how can I indicate to userspace that this display really is
monochrome/grayscale since the reported color depth 16bpp?
There isn't unless we add formats for it.
Since this display is in a Lego piece, doesn't it have custom userspace
that already know it's monochrome?
The official LEGO software is like this, yes. But I am working on a
project that supports other LEGO compatible devices that have color
screens, so the same software needs to be able to detect at runtime
which type of screen it is using. Currently I have a plain fbdev
driver that provides FB_VISUAL_MONO10 for the EV3 display and so the
software knows when it has a monochrome screen and when it doesn't.
But since plain fbdev drivers can't be accepted into mainline, I need
to find a different way to detect what type of screen this is so that
my graphics library can treat it differently.
You can tell userspace about the preferred bitdepth:
drm->mode_config.preferred_depth
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] dw-hdmi CEC support
Hi Russell, Thank you for the patches. On Monday 31 Jul 2017 15:29:06 Russell King - ARM Linux wrote: > Hi, > > This series adds dw-hdmi CEC support. This is done in four stages: > > 1. Add cec-notifier support > 2. Fix up the clkdis register support, as this register contains a >clock disable bit for the CEC module. > 3. Add the driver. > 4. Remove definitions that are not required from dw-hdmi.h > > The CEC driver has been updated to use the register accessors in the > main driver - it would be nice if it was possible to use the regmap > support directly, but there's some knowledge private to the main > driver that's required to correctly access the registers. (I don't > understand why the register stride isn't part of regmap.) > > drivers/gpu/drm/bridge/synopsys/Kconfig | 10 + > drivers/gpu/drm/bridge/synopsys/Makefile | 1 + > drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 326 +++ > drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++ > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 93 +++- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 46 +--- > 6 files changed, 437 insertions(+), 58 deletions(-) > > v2 - fix selection of CEC_NOTIFIER in Kconfig For the whole series, Tested-by: Laurent Pinchart on R-Car H3. The DWC HDMI controller in this SoC supports CEC, but I have no CEC-enabled sink, so tests were limited to regression checks. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver
Hi Russell,
Thank you for the patch.
On Monday 31 Jul 2017 15:29:51 Russell King wrote:
> Add a CEC driver for the dw-hdmi hardware.
>
> Reviewed-by: Neil Armstrong
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/bridge/synopsys/Kconfig | 9 +
> drivers/gpu/drm/bridge/synopsys/Makefile | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 326 +++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 42 +++-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
> 6 files changed, 397 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h
[snip]
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c new file mode 100644
> index ..52c9d93b9602
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
[snip]
> +static int dw_hdmi_cec_probe(struct platform_device *pdev)
> +{
> + struct dw_hdmi_cec_data *data = dev_get_platdata(&pdev->dev);
> + struct dw_hdmi_cec *cec;
> + int ret;
> +
> + if (!data)
> + return -ENXIO;
> +
> + /*
> + * Our device is just a convenience - we want to link to the real
> + * hardware device here, so that userspace can see the association
> + * between the HDMI hardware and its associated CEC chardev.
> + */
> + cec = devm_kzalloc(&pdev->dev, sizeof(*cec), GFP_KERNEL);
> + if (!cec)
> + return -ENOMEM;
> +
> + cec->irq = data->irq;
> + cec->ops = data->ops;
> + cec->hdmi = data->hdmi;
> +
> + platform_set_drvdata(pdev, cec);
> +
> + dw_hdmi_write(cec, 0, HDMI_CEC_TX_CNT);
> + dw_hdmi_write(cec, ~0, HDMI_CEC_MASK);
> + dw_hdmi_write(cec, ~0, HDMI_IH_MUTE_CEC_STAT0);
> + dw_hdmi_write(cec, 0, HDMI_CEC_POLARITY);
> +
> + cec->adap = cec_allocate_adapter(&dw_hdmi_cec_ops, cec, "dw_hdmi",
> + CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT
|
> + CEC_CAP_RC, CEC_MAX_LOG_ADDRS);
> + if (IS_ERR(cec->adap))
> + return PTR_ERR(cec->adap);
> +
> + /* override the module pointer */
> + cec->adap->owner = THIS_MODULE;
> +
> + ret = devm_add_action(&pdev->dev, dw_hdmi_cec_del, cec);
> + if (ret) {
> + cec_delete_adapter(cec->adap);
> + return ret;
> + }
> +
> + ret = devm_request_threaded_irq(&pdev->dev, cec->irq,
> + dw_hdmi_cec_hardirq,
> + dw_hdmi_cec_thread, IRQF_SHARED,
> + "dw-hdmi-cec", cec->adap);
> + if (ret < 0)
> + return ret;
> +
> + cec->notify = cec_notifier_get(pdev->dev.parent);
> + if (!cec->notify)
> + return -ENOMEM;
> +
> + ret = cec_register_adapter(cec->adap, pdev->dev.parent);
> + if (ret < 0) {
> + cec_notifier_put(cec->notify);
> + return ret;
> + }
> +
> + /*
> + * CEC documentation says we must not call cec_delete_adapter
> + * after a successful call to cec_register_adapter().
> + */
> + devm_remove_action(&pdev->dev, dw_hdmi_cec_del, cec);
dw_hdmi_cec_del() is only used to clean up in the error path of the probe
function. It would be simpler and less resource-consuming to add an error
label to this function instead of using devm.
> +
> + cec_register_cec_notifier(cec->adap, cec->notify);
> +
> + return 0;
> +}
> +
> +static int dw_hdmi_cec_remove(struct platform_device *pdev)
> +{
> + struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
> +
> + cec_unregister_adapter(cec->adap);
> + cec_notifier_put(cec->notify);
> +
> + return 0;
> +}
> +
> +static struct platform_driver dw_hdmi_cec_driver = {
> + .probe = dw_hdmi_cec_probe,
> + .remove = dw_hdmi_cec_remove,
> + .driver = {
> + .name = "dw-hdmi-cec",
> + },
> +};
> +module_platform_driver(dw_hdmi_cec_driver);
Is there a particular reason why this has to be a separate module instead of
simply calling the CEC init/cleanup functions directly from the main dw-hdmi
driver ?
> +MODULE_AUTHOR("Russell King ");
> +MODULE_DESCRIPTION("Synopsys Designware HDMI CEC driver for i.MX");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS(PLATFORM_MODULE_PREFIX "dw-hdmi-cec");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102009] Blender crashes when compiling OpenCL kernel
https://bugs.freedesktop.org/show_bug.cgi?id=102009 Jan Vesely changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||102009 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=102009 [Bug 102009] Blender crashes when compiling OpenCL kernel -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/6] [v4] drm/i915: Add support for CCS modifiers
On 17-08-01 15:43:50, Kenneth Graunke wrote:
On Tuesday, August 1, 2017 9:58:17 AM PDT Ben Widawsky wrote:
v2:
- Support sprite plane.
- Support pipe C/D limitation on GEN9.
v3:
- Rename structure (Ville)
- Handle GLK (Ville)
v4:
- Fix PIPE_C check, introduced in v2 (Daniel)
- Whitespace fix (Daniel)
Cc: Daniel Stone
Cc: Kristian Høgsberg
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c | 30 +++---
drivers/gpu/drm/i915/intel_sprite.c | 28 +++-
2 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad49b99ef25f..0dc9f40edc7e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -93,7 +93,17 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
};
-static const uint64_t skl_format_modifiers[] = {
+static const uint64_t skl_format_modifiers_noccs[] = {
+ I915_FORMAT_MOD_Yf_TILED,
+ I915_FORMAT_MOD_Y_TILED,
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
+static const uint64_t skl_format_modifiers_ccs[] = {
+ I915_FORMAT_MOD_Yf_TILED_CCS,
+ I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
I915_FORMAT_MOD_X_TILED,
@@ -13853,6 +13863,10 @@ static bool skl_mod_supported(uint32_t format,
uint64_t modifier)
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
+ if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_CCS)
+ return true;
+ /* fall through */
case DRM_FORMAT_RGB565:
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
@@ -14099,10 +14113,20 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
primary->check_plane = intel_check_primary_plane;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ intel_primary_formats = skl_primary_formats;
+ num_formats = ARRAY_SIZE(skl_primary_formats);
+ modifiers = skl_format_modifiers_ccs;
+
+ primary->update_plane = skylake_update_primary_plane;
+ primary->disable_plane = skylake_disable_primary_plane;
+ } else if (INTEL_GEN(dev_priv) >= 9) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
- modifiers = skl_format_modifiers;
+ if (pipe < PIPE_C)
+ modifiers = skl_format_modifiers_ccs;
+ else
+ modifiers = skl_format_modifiers_noccs;
primary->update_plane = skylake_update_primary_plane;
primary->disable_plane = skylake_disable_primary_plane;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b1cc4835b963..5a2b3f3693a6 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1085,7 +1085,17 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_VYUY,
};
+static const uint64_t skl_plane_format_modifiers_noccs[] = {
+ I915_FORMAT_MOD_Yf_TILED,
+ I915_FORMAT_MOD_Y_TILED,
+ I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_LINEAR,
+ DRM_FORMAT_MOD_INVALID
+};
+
static const uint64_t skl_plane_format_modifiers[] = {
+ I915_FORMAT_MOD_Yf_TILED_CCS,
+ I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
I915_FORMAT_MOD_X_TILED,
@@ -1148,6 +1158,9 @@ static bool skl_sprite_plane_format_mod_supported(struct
drm_plane *plane,
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
+ if (modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Yf_TILED_CCS)
+ return true;
case DRM_FORMAT_RGB565:
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
@@ -1230,7 +1243,7 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
}
intel_plane->base.state = &state->base;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (INTEL_GEN(dev_priv) >= 10) {
I think this should be INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv).
With that fixed, this patch would be:
Reviewed-by: Kenneth Graunke
for what it's worth (I'm not that familiar with display).
Thanks. Here is what I've changed locally which didn't match the primary
support:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 5a2b3f3693a6..1c484195fd0f 100644
--- a/d
[Bug 101927] American Conquest via Wine cannot start
https://bugs.freedesktop.org/show_bug.cgi?id=101927 --- Comment #3 from Roland Scheidegger --- Sounds to me like you're simply running out of (virtual) memory. Those allocations in softpipe are quite a waste of memory, albeit not THAT big (each tile is 32x32 pixels, at 16 bytes, so 16kB, and there's 16 tiles per shader type and per sampler view - with 6 shader types and 32 sampler views that adds up to (typically mostly never used...) 48MB. That's probably also the reason why the map fails with radeonsi. I have no idea though where all your virtual memory address space went, but I don't see any evidence it's really related to mesa, albeit there recently was a new and already fixed memory leak. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/3] freedreno/msm: remove dead error path
On Sun, Jul 30, 2017 at 4:27 PM, Eric Engestrom wrote:
> `ring` cannot be non-null, so the label reduces to a simple return.
> Then, there is no point initialising `ring` just to overwrite it before
> anyone reads it.
>
> Signed-off-by: Eric Engestrom
Reviewed-by: Rob Clark
if you have push access, go ahead and push it yourself, otherwise let me know
BR,
-R
> ---
> freedreno/msm/msm_ringbuffer.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/freedreno/msm/msm_ringbuffer.c b/freedreno/msm/msm_ringbuffer.c
> index c3b2eded..5b28feaa 100644
> --- a/freedreno/msm/msm_ringbuffer.c
> +++ b/freedreno/msm/msm_ringbuffer.c
> @@ -589,12 +589,12 @@ drm_private struct fd_ringbuffer *
> msm_ringbuffer_new(struct fd_pipe *pipe,
> uint32_t size)
> {
> struct msm_ringbuffer *msm_ring;
> - struct fd_ringbuffer *ring = NULL;
> + struct fd_ringbuffer *ring;
>
> msm_ring = calloc(1, sizeof(*msm_ring));
> if (!msm_ring) {
> ERROR_MSG("allocation failed");
> - goto fail;
> + return NULL;
> }
>
> if (size == 0) {
> @@ -614,8 +614,4 @@ drm_private struct fd_ringbuffer *
> msm_ringbuffer_new(struct fd_pipe *pipe,
> ring_cmd_new(ring, size);
>
> return ring;
> -fail:
> - if (ring)
> - fd_ringbuffer_del(ring);
> - return NULL;
> }
> --
> Cheers,
> Eric
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101969] Massive graphics corruption with World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=101969 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Marek Olšák --- Yes. Thanks for the bug report. Closing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
