Re: [PATCH v2 12/15] drm: omapdrm: dss: Move initialization code from component bind to probe

[Sebastian Reichel]

Hi,

On Sun, Feb 11, 2018 at 03:07:44PM +0200, Laurent Pinchart wrote:
> There's no reason to delay initialization of most of the driver (such as
> mapping memory I/O, getting clocks or enabling runtime PM) to the
> component master bind handler.
> 
> This additionally fixes a real PM issue caused enabling runtime PM in
> the bind handler.
> 
> The bind handler performs the following sequence of PM operations:
> 
>   pm_runtime_enable(dev);
>   pm_runtime_get_sync(dev);
> 
>   ... (access the hardware to read the device revision) ...
> 
>   pm_runtime_put_sync(dev);
> 
> If a failure occurs at this point, the error path calls
> pm_runtime_disable() to balance the pm_runtime_enable() call.
> 
> To understand the problem, it should be noted that the bind handler is
> called when one of the component registers itself, which happens in the
> component's probe handler. Furthermore, as the components are children
> of the DSS, the device core calls pm_runtime_get_sync() on the DSS
> platform device before calling the component's probe handler. This
> increases the DSS power usage count but doesn't runtime resume the
> device, as runtime PM is disabled at that point.
> 
> The bind handler is thus called with runtime PM disabled, with the
> device runtime suspended, but with the power usage count larger than 0.
> The pm_runtime_get_sync() call will thus further increase the power
> usage count and runtime resume the device. The pm_runtime_put_sync()
> handler will decrease the power usage count to a non-zero value and will
> thus not suspend the device. Finally, the pm_runtime_disable() call will
> disable runtime PM, preventing the pm_runtime_put() call in the device
> core from runtime suspending the device. The DSS device is thus left
> powered on.
> 
> To fix this, move the initialization code from the bind handler to the
> probe handler.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dss.c | 193 
> --
>  1 file changed, 104 insertions(+), 89 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
> b/drivers/gpu/drm/omapdrm/dss/dss.c
> index f1c7ef3a2ec3..d086189263ef 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
> @@ -1300,88 +1300,18 @@ static const struct soc_device_attribute 
> dss_soc_devices[] = {
>  
>  static int dss_bind(struct device *dev)
>  {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct resource *dss_mem;
> - u32 rev;
>   int r;
>  
> - dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
> - dss.base = devm_ioremap_resource(&pdev->dev, dss_mem);
> - if (IS_ERR(dss.base))
> - return PTR_ERR(dss.base);
> -
> - r = dss_get_clocks();
> + r = component_bind_all(dev, NULL);
>   if (r)
>   return r;
>  
> - r = dss_setup_default_clock();
> - if (r)
> - goto err_setup_clocks;
> -
> - r = dss_video_pll_probe(pdev);
> - if (r)
> - goto err_pll_init;
> -
> - r = dss_init_ports(pdev);
> - if (r)
> - goto err_init_ports;
> -
> - pm_runtime_enable(&pdev->dev);
> -
> - r = dss_runtime_get();
> - if (r)
> - goto err_runtime_get;
> -
> - dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
> -
> - /* Select DPLL */
> - REG_FLD_MOD(DSS_CONTROL, 0, 0, 0);
> -
> - dss_select_dispc_clk_source(DSS_CLK_SRC_FCK);
> -
> -#ifdef CONFIG_OMAP2_DSS_VENC
> - REG_FLD_MOD(DSS_CONTROL, 1, 4, 4);  /* venc dac demen */
> - REG_FLD_MOD(DSS_CONTROL, 1, 3, 3);  /* venc clock 4x enable */
> - REG_FLD_MOD(DSS_CONTROL, 0, 2, 2);  /* venc clock mode = normal */
> -#endif
> - dss.dsi_clk_source[0] = DSS_CLK_SRC_FCK;
> - dss.dsi_clk_source[1] = DSS_CLK_SRC_FCK;
> - dss.dispc_clk_source = DSS_CLK_SRC_FCK;
> - dss.lcd_clk_source[0] = DSS_CLK_SRC_FCK;
> - dss.lcd_clk_source[1] = DSS_CLK_SRC_FCK;
> -
> - rev = dss_read_reg(DSS_REVISION);
> - pr_info("OMAP DSS rev %d.%d\n", FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
> -
> - dss_runtime_put();
> -
> - r = component_bind_all(&pdev->dev, NULL);
> - if (r)
> - goto err_component;
> -
> - dss_debugfs_create_file("dss", dss_dump_regs);
> -
>   pm_set_vt_switch(0);
>  
>   omapdss_gather_components(dev);
>   omapdss_set_is_initialized(true);
>  
>   return 0;
> -
> -err_component:
> -err_runtime_get:
> - pm_runtime_disable(&pdev->dev);
> - dss_uninit_ports(pdev);
> -err_init_ports:
> - if (dss.video1_pll)
> - dss_video_pll_uninit(dss.video1_pll);
> -
> - if (dss.video2_pll)
> - dss_video_pll_uninit(dss.video2_pll);
> -err_pll_init:
> -err_setup_clocks:
> - dss_put_clocks();
> - return r;
>  }
>  
>  static void dss_unbind(struct device *dev)
> @@ -1391,18 +1321,6 @@ static void dss_unbind(struc

Re: [PATCH] gpu/drm/udl: Replace struct_mutex with driver private lock

[Shreeya Patel]

On Fri, 2018-02-09 at 12:18 +, Chris Wilson wrote:
> Quoting Shreeya Patel (2018-02-09 12:10:56)
> > 
> > dev->struct_mutex is the Big DRM Lock and the only bit where
> > it’s mandatory is serializing GEM buffer object destruction.
> > Which unfortunately means drivers have to keep track of that
> > lock and either call unreference or unreference_locked
> > depending upon context. Core GEM doesn’t have a need for
> > struct_mutex any more since kernel 4.8.
> > 
> > For drivers that need struct_mutex it should be replaced by a
> > driver
> > private lock.
> In that regard, dev->struct_mutex is already a driver private lock.
> The
> impetus is to reduce a big lock into lots of little locks where
> contention deems prudent.

Ok. I'll make the changes in the commit message.
> 
> > 
> > Signed-off-by: Shreeya Patel 
> > ---
> >  drivers/gpu/drm/udl/udl_dmabuf.c | 5 +++--
> >  drivers/gpu/drm/udl/udl_drv.h| 1 +
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c
> > b/drivers/gpu/drm/udl/udl_dmabuf.c
> > index 2867ed1..120d2d9 100644
> > --- a/drivers/gpu/drm/udl/udl_dmabuf.c
> > +++ b/drivers/gpu/drm/udl/udl_dmabuf.c
> > @@ -76,6 +76,7 @@ static struct sg_table *udl_map_dma_buf(struct
> > dma_buf_attachment *attach,
> > struct udl_drm_dmabuf_attachment *udl_attach = attach-
> > >priv;
> > struct udl_gem_object *obj = to_udl_bo(attach->dmabuf-
> > >priv);
> > struct drm_device *dev = obj->base.dev;
> > +   struct udl_device *udl = dev->dev_private;
> > struct scatterlist *rd, *wr;
> > struct sg_table *sgt = NULL;
> > unsigned int i;
> > @@ -112,7 +113,7 @@ static struct sg_table *udl_map_dma_buf(struct
> > dma_buf_attachment *attach,
> > return ERR_PTR(-ENOMEM);
> > }
> >  
> > -   mutex_lock(&dev->struct_mutex);
> > +   mutex_lock(&udl->urbs.plock);
> >  
> > rd = obj->sg->sgl;
> > wr = sgt->sgl;
> > @@ -137,7 +138,7 @@ static struct sg_table *udl_map_dma_buf(struct
> > dma_buf_attachment *attach,
> > attach->priv = udl_attach;
> >  
> >  err_unlock:
> > -   mutex_unlock(&dev->struct_mutex);
> > +   mutex_unlock(&udl->urbs.plock);
> > return sgt;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/udl/udl_drv.h
> > b/drivers/gpu/drm/udl/udl_drv.h
> > index 2a75ab8..24cca17 100644
> > --- a/drivers/gpu/drm/udl/udl_drv.h
> > +++ b/drivers/gpu/drm/udl/udl_drv.h
> > @@ -39,6 +39,7 @@ struct urb_node {
> >  
> >  struct urb_list {
> > struct list_head list;
> > +   struct mutex plock;
> > spinlock_t lock;
> > struct semaphore limit_sem;
> > int available;
> This hasn't seen much testing as it lacks a mutex_init, and one would
> wish for a description of what it is guarding.

Yes, I'll add mutex_init but I am not sure that in which function I
should add it as there is no probe or init function.

Also I will add the description for the lock.

Thanks 
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: drop the dcc probe before drm_do_get_edid

[Lubomir Rintel]

On Sat, 2018-02-10 at 19:03 +0100, Lubomir Rintel wrote:
> Now that drm_do_get_edid() handles override and firmware EDIDs it makes
> no sense to conditionalize it with a DCC probe. On the contrary -- the
> overrides are useful specifically when DCC is not functioning.
> 
> drm_do_get_edid() already bails out when DCC fails, there's no need for
> an extra check. It seems entirely safe to just drop this.
> 
> Working around the issue by forcing the connector on is not a good
> solution because that way the desktop shell can't tell when a monitor is
> plugged in or removed.
> 
> Cc: Jani Nikula 
> Fixes: 53fd40a ("drm: handle override and firmware EDID at drm_do_get_edid() 
> level")

Please disregard this, should have given it more thought. Sorry.

It removes a symbol other modules use, and typoes DDC/DCC in the commit
message. Moreover it doesn't actually seem to solve my problem -- will
try to follow up with a better fix.

Lubo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: drop the dcc probe before drm_do_get_edid

[Lubomir Rintel]

Now that drm_do_get_edid() handles override and firmware EDIDs it makes
no sense to conditionalize it with a DCC probe. On the contrary -- the
overrides are useful specifically when DCC is not functioning.

drm_do_get_edid() already bails out when DCC fails, there's no need for
an extra check. It seems entirely safe to just drop this.

Working around the issue by forcing the connector on is not a good
solution because that way the desktop shell can't tell when a monitor is
plugged in or removed.

Cc: Jani Nikula 
Fixes: 53fd40a ("drm: handle override and firmware EDID at drm_do_get_edid() 
level")
---
 drivers/gpu/drm/drm_edid.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cb487148359a..72169d84256d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1642,21 +1642,6 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 }
 EXPORT_SYMBOL_GPL(drm_do_get_edid);
 
-/**
- * drm_probe_ddc() - probe DDC presence
- * @adapter: I2C adapter to probe
- *
- * Return: True on success, false on failure.
- */
-bool
-drm_probe_ddc(struct i2c_adapter *adapter)
-{
-   unsigned char out;
-
-   return (drm_do_probe_ddc_edid(adapter, &out, 0, 1) == 0);
-}
-EXPORT_SYMBOL(drm_probe_ddc);
-
 /**
  * drm_get_edid - get EDID data, if available
  * @connector: connector we're probing
@@ -1675,9 +1660,6 @@ struct edid *drm_get_edid(struct drm_connector *connector,
if (connector->force == DRM_FORCE_OFF)
return NULL;
 
-   if (connector->force == DRM_FORCE_UNSPECIFIED && 
!drm_probe_ddc(adapter))
-   return NULL;
-
edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
if (edid)
drm_get_displayid(connector, edid);
-- 
2.14.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: Don't use spin_lock_irqsave in interrupt context

[Marc Zyngier]

The rockchip DRM driver is quite careful to disable interrupts
when taking a lock that is also taken in interrupt context,
which is a good thing.

What is a bit over the top is to use spin_lock_irqsave when
already in interrupt context, as you cannot take another
interrupt again, and disabling interrupt is just pure
overhead.

Switching to the non _irqsave version in interrupt context is
more logical, and less heavy handed.

Signed-off-by: Marc Zyngier 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 72554f404b7e..e23877e72c43 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1159,15 +1159,14 @@ static void vop_handle_vblank(struct vop *vop)
 {
struct drm_device *drm = vop->drm_dev;
struct drm_crtc *crtc = &vop->crtc;
-   unsigned long flags;
 
-   spin_lock_irqsave(&drm->event_lock, flags);
+   spin_lock(&drm->event_lock);
if (vop->event) {
drm_crtc_send_vblank_event(crtc, vop->event);
drm_crtc_vblank_put(crtc);
vop->event = NULL;
}
-   spin_unlock_irqrestore(&drm->event_lock, flags);
+   spin_unlock(&drm->event_lock);
 
if (test_and_clear_bit(VOP_PENDING_FB_UNREF, &vop->pending))
drm_flip_work_commit(&vop->fb_unref_work, system_unbound_wq);
@@ -1178,21 +1177,20 @@ static irqreturn_t vop_isr(int irq, void *data)
struct vop *vop = data;
struct drm_crtc *crtc = &vop->crtc;
uint32_t active_irqs;
-   unsigned long flags;
int ret = IRQ_NONE;
 
/*
 * interrupt register has interrupt status, enable and clear bits, we
 * must hold irq_lock to avoid a race with enable/disable_vblank().
*/
-   spin_lock_irqsave(&vop->irq_lock, flags);
+   spin_lock(&vop->irq_lock);
 
active_irqs = VOP_INTR_GET_TYPE(vop, status, INTR_MASK);
/* Clear all active interrupt sources */
if (active_irqs)
VOP_INTR_SET_TYPE(vop, clear, active_irqs, 1);
 
-   spin_unlock_irqrestore(&vop->irq_lock, flags);
+   spin_unlock(&vop->irq_lock);
 
/* This is expected for vop iommu irqs, since the irq is shared */
if (!active_irqs)
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/15] drm: omapdrm: dss: Don't export functions internal to omapdss-base

[Sebastian Reichel]

Hi,

On Sun, Feb 11, 2018 at 03:07:43PM +0200, Laurent Pinchart wrote:
> A few functions defined in omapdss-base are internal to the module.
> Don't export them.
> 
> Signed-off-by: Laurent Pinchart 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 2 --
>  drivers/gpu/drm/omapdrm/dss/output.c | 1 -
>  2 files changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> index 967d9e1b34e5..4602a79c6c44 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
> @@ -44,7 +44,6 @@ struct device_node *dss_of_port_get_parent_device(struct 
> device_node *port)
>  
>   return NULL;
>  }
> -EXPORT_SYMBOL_GPL(dss_of_port_get_parent_device);
>  
>  u32 dss_of_port_get_port_number(struct device_node *port)
>  {
> @@ -57,7 +56,6 @@ u32 dss_of_port_get_port_number(struct device_node *port)
>  
>   return reg;
>  }
> -EXPORT_SYMBOL_GPL(dss_of_port_get_port_number);
>  
>  struct omap_dss_device *
>  omapdss_of_find_source_for_first_ep(struct device_node *node)
> diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
> b/drivers/gpu/drm/omapdrm/dss/output.c
> index b9afd80ae385..a28e00c94c05 100644
> --- a/drivers/gpu/drm/omapdrm/dss/output.c
> +++ b/drivers/gpu/drm/omapdrm/dss/output.c
> @@ -156,7 +156,6 @@ struct omap_dss_device 
> *omap_dss_find_output_by_port_node(struct device_node *po
>  
>   return NULL;
>  }
> -EXPORT_SYMBOL(omap_dss_find_output_by_port_node);
>  
>  struct omap_dss_device *omapdss_find_output_from_display(struct 
> omap_dss_device *dssdev)
>  {
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] drm/vc4: *ERROR* [PLANE:67:plane-20] flip_done timed out

[Stefan Wahren]

Hi Boris,

> Boris Brezillon  hat am 10. Februar 2018 um 
> 17:40 geschrieben:
> 
> 
> Hi Stefan,
> 
> On Sat, 10 Feb 2018 16:57:23 +0100 (CET)
> Stefan Wahren  wrote:
> 
> > Hi,
> > i'm having problems while booting Raspberry Pi 1 B (Linux 4.15, 
> > bcm2835_defconfig) on my display, which is connected via HDMI. Mostly the 
> > screen stays black and i'm getting the following warnings via debug UART. 
> > Sometimes after disconnecting HDMI, i'm getting the expected screen.
> 
> Was it working with 4.14?

These "vblank wait timed out" weren't new, but with older versions i always got 
a screen after some time.

> Could you try after applying this patch
> series [1]?

Great, this series fixed the issue incl the annoying vblank timeouts.

Btw Stephen isn't bcm2835 maintainer anymore, because you add him to CC instead 
of me for this series.

Thanks
Stefan

> 
> Regards,
> 
> Boris
> 
> [1]https://www.spinics.net/lists/stable/msg214527.html
> 
> -- 
> Boris Brezillon, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> http://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] drm/vc4: *ERROR* [PLANE:67:plane-20] flip_done timed out

[Stefan Wahren]

Hi,
i'm having problems while booting Raspberry Pi 1 B (Linux 4.15, 
bcm2835_defconfig) on my display, which is connected via HDMI. Mostly the 
screen stays black and i'm getting the following warnings via debug UART. 
Sometimes after disconnecting HDMI, i'm getting the expected screen.

[3.253930] vc4-drm soc:gpu: bound 20902000.hdmi (ops vc4_hdmi_ops)
[3.283413] vc4-drm soc:gpu: bound 20806000.vec (ops vc4_vec_ops)
[3.310306] vc4-drm soc:gpu: bound 2040.hvs (ops vc4_hvs_ops)
[3.339131] vc4-drm soc:gpu: bound 20206000.pixelvalve (ops vc4_crtc_ops)
[3.368727] vc4-drm soc:gpu: bound 20207000.pixelvalve (ops vc4_crtc_ops)
[3.397935] vc4-drm soc:gpu: bound 20807000.pixelvalve (ops vc4_crtc_ops)
[3.450306] vc4-drm soc:gpu: bound 20c0.v3d (ops vc4_v3d_ops)
[3.475686] checking generic (e33 8ca000) vs hw (0 )
[3.475700] fb: switching to vc4drmfb from simple
[3.499714] Console: switching to colour dummy device 80x30
[3.520255] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[3.527030] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.533779] [drm] Driver supports precise vblank timestamp query.
[3.647269] [ cut here ]
[3.647320] WARNING: CPU: 0 PID: 10 at 
drivers/gpu/drm/drm_atomic_helper.c:1349 
drm_atomic_helper_wait_for_vblanks+0x1fc/0x21c
[3.647328] [CRTC:68:crtc-2] vblank wait timed out
[3.647333] Modules linked in:
[3.647354] CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 4.15.0+ #2
[3.647358] Hardware name: BCM2835
[3.647383] Workqueue: events deferred_probe_work_func
[3.647429] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[3.647459] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[3.647488] [] (dump_stack) from [] (__warn+0xec/0x104)
[3.647509] [] (__warn) from [] 
(warn_slowpath_fmt+0x48/0x50)
[3.647532] [] (warn_slowpath_fmt) from [] 
(drm_atomic_helper_wait_for_vblanks+0x1fc/0x21c)
[3.647556] [] (drm_atomic_helper_wait_for_vblanks) from 
[] (vc4_atomic_complete_commit+0x80/0xb8)
[3.647575] [] (vc4_atomic_complete_commit) from [] 
(vc4_atomic_commit+0x110/0x11c)
[3.647600] [] (vc4_atomic_commit) from [] 
(drm_atomic_commit+0x54/0x68)
[3.647628] [] (drm_atomic_commit) from [] 
(restore_fbdev_mode_atomic+0x84/0x1bc)
[3.647653] [] (restore_fbdev_mode_atomic) from [] 
(restore_fbdev_mode+0x38/0x144)
[3.647675] [] (restore_fbdev_mode) from [] 
(drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c)
[3.647698] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from 
[] (drm_fb_helper_set_par+0x5c/0x6c)
[3.647718] [] (drm_fb_helper_set_par) from [] 
(fbcon_init+0x2f4/0x488)
[3.647747] [] (fbcon_init) from [] 
(visual_init+0xc8/0x114)
[3.647771] [] (visual_init) from [] 
(do_bind_con_driver+0x280/0x2f4)
[3.647792] [] (do_bind_con_driver) from [] 
(do_take_over_console+0x180/0x1b8)
[3.647813] [] (do_take_over_console) from [] 
(do_fbcon_takeover+0x60/0xc8)
[3.647832] [] (do_fbcon_takeover) from [] 
(fbcon_event_notify+0x40c/0x7a0)
[3.647858] [] (fbcon_event_notify) from [] 
(notifier_call_chain+0x50/0x74)
[3.647881] [] (notifier_call_chain) from [] 
(__blocking_notifier_call_chain+0x54/0x6c)
[3.647902] [] (__blocking_notifier_call_chain) from [] 
(blocking_notifier_call_chain+0x28/0x30)
[3.647931] [] (blocking_notifier_call_chain) from [] 
(fb_notifier_call_chain+0x24/0x2c)
[3.647953] [] (fb_notifier_call_chain) from [] 
(register_framebuffer+0x220/0x264)
[3.647979] [] (register_framebuffer) from [] 
(__drm_fb_helper_initial_config_and_unlock+0x2b8/0x354)
[3.648003] [] (__drm_fb_helper_initial_config_and_unlock) from 
[] (drm_fb_helper_initial_config+0x40/0x48)
[3.648025] [] (drm_fb_helper_initial_config) from [] 
(drm_fb_cma_fbdev_init_with_funcs+0xe4/0x144)
[3.648046] [] (drm_fb_cma_fbdev_init_with_funcs) from 
[] (drm_fb_cma_fbdev_init+0x1c/0x20)
[3.648066] [] (drm_fb_cma_fbdev_init) from [] 
(vc4_kms_load+0x9c/0xb4)
[3.648104] [] (vc4_kms_load) from [] 
(vc4_drm_bind+0xf0/0x134)
[3.648139] [] (vc4_drm_bind) from [] 
(try_to_bring_up_master+0x1e8/0x24c)
[3.648161] [] (try_to_bring_up_master) from [] 
(component_add+0xc0/0x120)
[3.648180] [] (component_add) from [] 
(vc4_v3d_dev_probe+0x20/0x28)
[3.648208] [] (vc4_v3d_dev_probe) from [] 
(platform_drv_probe+0x60/0xac)
[3.648230] [] (platform_drv_probe) from [] 
(driver_probe_device+0x2d4/0x46c)
[3.648250] [] (driver_probe_device) from [] 
(__device_attach_driver+0xb0/0x104)
[3.648269] [] (__device_attach_driver) from [] 
(bus_for_each_drv+0x98/0xa0)
[3.648287] [] (bus_for_each_drv) from [] 
(__device_attach+0xac/0x138)
[3.648305] [] (__device_attach) from [] 
(device_initial_probe+0x1c/0x20)
[3.648323] [] (device_initial_probe) from [] 
(bus_probe_device+0x38/0x90)
[3.648342] [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x124/0x144)
[3.6483

Re: [BUG] drm/vc4: *ERROR* [PLANE:67:plane-20] flip_done timed out

[Stefan Wahren]

Hi Eric,

> Eric Anholt  hat am 10. Februar 2018 um 18:24 geschrieben:
> 
> 
> Stefan Wahren  writes:
> 
> > Hi, i'm having problems while booting Raspberry Pi 1 B (Linux 4.15,
> > bcm2835_defconfig) on my display, which is connected via HDMI. Mostly
> > the screen stays black and i'm getting the following warnings via
> > debug UART. Sometimes after disconnecting HDMI, i'm getting the
> > expected screen.
> >
> > [3.253930] vc4-drm soc:gpu: bound 20902000.hdmi (ops vc4_hdmi_ops)
> > [3.283413] vc4-drm soc:gpu: bound 20806000.vec (ops vc4_vec_ops)
> > [3.310306] vc4-drm soc:gpu: bound 2040.hvs (ops vc4_hvs_ops)
> > [3.339131] vc4-drm soc:gpu: bound 20206000.pixelvalve (ops vc4_crtc_ops)
> > [3.368727] vc4-drm soc:gpu: bound 20207000.pixelvalve (ops vc4_crtc_ops)
> > [3.397935] vc4-drm soc:gpu: bound 20807000.pixelvalve (ops vc4_crtc_ops)
> > [3.450306] vc4-drm soc:gpu: bound 20c0.v3d (ops vc4_v3d_ops)
> > [3.475686] checking generic (e33 8ca000) vs hw (0 )
> > [3.475700] fb: switching to vc4drmfb from simple
> > [3.499714] Console: switching to colour dummy device 80x30
> > [3.520255] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
> > [3.527030] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > [3.533779] [drm] Driver supports precise vblank timestamp query.
> > [3.647269] [ cut here ]
> > [3.647320] WARNING: CPU: 0 PID: 10 at 
> > drivers/gpu/drm/drm_atomic_helper.c:1349 
> > drm_atomic_helper_wait_for_vblanks+0x1fc/0x21c
> > [3.647328] [CRTC:68:crtc-2] vblank wait timed out
> > [3.647333] Modules linked in:
> > [3.647354] CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 4.15.0+ #2
> > [3.647358] Hardware name: BCM2835
> > [3.647383] Workqueue: events deferred_probe_work_func
> > [3.647429] [] (unwind_backtrace) from [] 
> > (show_stack+0x20/0x24)
> > [3.647459] [] (show_stack) from [] 
> > (dump_stack+0x20/0x28)
> > [3.647488] [] (dump_stack) from [] 
> > (__warn+0xec/0x104)
> > [3.647509] [] (__warn) from [] 
> > (warn_slowpath_fmt+0x48/0x50)
> > [3.647532] [] (warn_slowpath_fmt) from [] 
> > (drm_atomic_helper_wait_for_vblanks+0x1fc/0x21c)
> > [3.647556] [] (drm_atomic_helper_wait_for_vblanks) from 
> > [] (vc4_atomic_complete_commit+0x80/0xb8)
> 
> Boris's clk series (https://patchwork.kernel.org/patch/10207161/) from
> Thursday was trying to fix some of this type of failure.
> 
> > Additionally after 10 minutes there are memleaks like this:
> >
> > unreferenced object 0xc8cb5c00 (size 64):
> >   comm "kworker/0:1", pid 10, jiffies 4294937654 (age 881.050s)
> >   hex dump (first 32 bytes):
> > 10 e0 ca c8 01 00 00 00 00 00 00 00 0c 5c cb c8  .\..
> > 0c 5c cb c8 ff ff ff ff 18 5c cb c8 18 5c cb c8  .\...\...\..
> >   backtrace:
> > [<7c3bc269>] kmemleak_alloc+0x78/0xc0
> > [] kmem_cache_alloc_trace+0xfc/0x1e4
> > [<6ecb9de5>] drm_atomic_helper_setup_commit+0xa4/0x3b8
> > [] vc4_atomic_commit+0x30/0x11c
> > [] drm_atomic_commit+0x54/0x68
> 
> I expect this is just waiting for this commit to trickle in:
> 
> commit 1c6c6ebbcdf9839dbce00719162591180524
> Author: Leo (Sunpeng) Li 
> Date:   Wed Jan 17 12:51:08 2018 +0100
> 
> drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

i reverted Boris' patches and applied this one [1], but the leaks still 
persists.

Stefan

[1] - https://patchwork.kernel.org/patch/10169179/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

 Hi,

On Thu, Feb 8, 2018 at 2:28 PM, Bartlomiej Zolnierkiewicz
 wrote:
> On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
>> Bartlomiej,
>>
>> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
>>  wrote:
>> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre wrote:
>> >> Bartlomiej,
>> >>
>> >> On Wed, Jan 3, 2018 at 3:47 PM, Bartlomiej Zolnierkiewicz
>> >>  wrote:
>> >> >
>> >> > On Thursday, December 21, 2017 11:07:56 PM Mathieu Malaterre wrote:
>> >> >> When the linux kernel is build with (typical kernel ship with Debian
>> >> >> installer):
>> >> >>
>> >> >> CONFIG_FB_OF=y
>> >> >> CONFIG_VT_HW_CONSOLE_BINDING=y
>> >> >> CONFIG_FB_RADEON=m
>> >> >>
>> >> >> The offb driver takes precedence over module radeonfb. It is then
>> >> >> impossible to load the module, error reported is:
>> >> >>
>> >> >> [   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> >> [   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
>> >> >> 0x9800-0x9fff pref]
>> >> >> [   96.551531] radeonfb (:00:10.0): cannot request region 0.
>> >> >> [   96.551545] radeonfb: probe of :00:10.0 failed with error -16
>> >> >>
>> >> >> This patch reproduce the behavior of the module radeon, so as to make 
>> >> >> it
>> >> >> possible to load radeonfb when offb is first loaded.
>> >> >>
>> >> >> It should be noticed that `offb_destroy` is never called which explain 
>> >> >> the
>> >> >> need to skip error detection on the radeon side.
>> >> >
>> >> > This still needs to be explained more, from my last mail:
>> >> >
>> >> > "The last put_fb_info() on fb_info should call ->fb_destroy
>> >> > (offb_destroy in our case) and remove_conflicting_framebuffers()
>> >> > is calling put_fb_info() so there is some extra reference on
>> >> > fb_info somewhere preventing it from going away.
>> >> >
>> >> > Please look into fixing this."
>> >>
>> >> I am not familiar with the fb stuff internals but here is what I see:
>> >>
>> >> # modprobe radeonfb
>> >>
>> >> leads to:
>> >>
>> >> [   52.058546] bus: 'pci': add driver radeonfb
>> >> [   52.058588] bus: 'pci': driver_probe_device: matched device
>> >> :00:10.0 with driver radeonfb
>> >> [   52.058595] bus: 'pci': really_probe: probing driver radeonfb with
>> >> device :00:10.0
>> >> [   52.058608] devices_kset: Moving :00:10.0 to end of list
>> >> [   52.058613] radeonfb_pci_register BEGIN
>> >> [   52.058634] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> >> 
>> >> [   52.058666] checking generic (9c008000 96000) vs hw (9800 800)
>> >> [   52.058667] fb: switching to radeonfb from OFfb ATY,RockHo
>> >> [   52.058844] Console: switching to colour dummy device 80x25
>> >> [   52.058860] device: 'fb0': device_unregister
>> >> [   52.058956] PM: Removing info for No Bus:fb0
>> >> [   52.059014] device: 'fb0': device_create_release
>> >> 
>> >> 
>> >> [   52.059048] device: 'vtcon1': device_unregister
>> >> [   52.059076] PM: Removing info for No Bus:vtcon1
>> >> [   52.059091] device: 'vtcon1': device_create_release
>> >> [   52.059107] radeonfb :00:10.0: BAR 0: can't reserve [mem
>> >> 0x9800-0x9fff pref]
>> >> [   52.256151] aper_base: 9800 MC_FB_LOC to: 9bff9800, MC_AGP_LOC
>> >> to: a000
>> >> [   52.256157] radeonfb (:00:10.0): Found 32768k of DDR 64 bits
>> >> wide videoram
>> >>
>> >> I can confirm that offb_destroy is never called (not sure exactly
>> >> why), but in any case the call to radeon_kick_out_firmware_fb happen
>> >> much earlier, at least before the put_fb_info.
>> >
>> > It is okay, put_fb_info() is called indirectly by 
>> > radeon_kick_out_firmware_fb()
>> >
>> > radeon_kick_out_firmware_fb()
>> > remove_conflicting_framebuffers()
>> > do_remove_conflicting_framebuffers()
>> > do_unregister_framebuffer()
>> > put_fb_info()
>> >
>> > offb_destroy() is not called because there is an extra reference on old
>> > fb_info (->count == 2):
>> >
>> > static void put_fb_info(struct fb_info *fb_info)
>> > {
>> > if (!atomic_dec_and_test(&fb_info->count))
>> > return;
>> > if (fb_info->fbops->fb_destroy)
>> > fb_info->fbops->fb_destroy(fb_info);
>> > }
>> >
>> > The question is why there is an extra reference, probably user-space
>> > is still holding the fb_info reference obtained in fb_open() call and
>> > fb_release() is never called. Besides not calling fbops->fb_destroy()
>> > this also causes missing call of fbops->fb_release() (in fb_release())
>> > which some fb drivers are implementing (but not offb.c).
>> >
>> >> Could you describe a bit more the chain of calls you were thinking of ?
>> >
>> > Please add WARN_ON(1) to get_fb_info() and put_fb_info() so we can check
>> > from the stacktrace if it is actually fb_open() that holds the extra
>> > old fb_info reference.
>> >
>> > drivers/video/fbdev/core/fbmem.c:
>> >
>> > static 

[PATCH] drm/rockchip: Set IRQ_NOAUTOEN flag before requesting the interrupt

[Marc Zyngier]

Calling request_irq() followed by disable_irq() is usually a bad idea,
specially if the interrupt can be pending, and you're not yet in a
position to handle it.

This is exactly what happens on my kevin system when rebooting in a
second kernel using kexec: Some interrupt is left pending from
the previous kernel, and we take it too early, before disable_irq()
could do anything.

A better way of ensuring safety is to set the IRQ_NOAUTOEN flag
on the irq before requesting it.

Cc: sta...@vger.kernel.org
Signed-off-by: Marc Zyngier 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 19128b4dea54..72554f404b7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1569,14 +1570,12 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
 
mutex_init(&vop->vsync_mutex);
 
+   irq_set_status_flags(vop->irq, IRQ_NOAUTOEN);
ret = devm_request_irq(dev, vop->irq, vop_isr,
   IRQF_SHARED, dev_name(dev), vop);
if (ret)
return ret;
 
-   /* IRQ is initially disabled; it gets enabled in power_on */
-   disable_irq(vop->irq);
-
ret = vop_create_crtc(vop);
if (ret)
goto err_enable_irq;
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 10/15] drm: omapdrm: dss: Make omapdss_default_get_timings static

[Sebastian Reichel]

Hi,

On Sun, Feb 11, 2018 at 03:07:42PM +0200, Laurent Pinchart wrote:
> The function isn't used outside of its compilation unit, make it static.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Sebastian Reichel 

-- Sebastian

> ---
>  drivers/gpu/drm/omapdrm/dss/display.c | 5 ++---
>  drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
> b/drivers/gpu/drm/omapdrm/dss/display.c
> index 0c9480ba85c0..424143128cd4 100644
> --- a/drivers/gpu/drm/omapdrm/dss/display.c
> +++ b/drivers/gpu/drm/omapdrm/dss/display.c
> @@ -28,12 +28,11 @@
>  
>  #include "omapdss.h"
>  
> -void omapdss_default_get_timings(struct omap_dss_device *dssdev,
> -  struct videomode *vm)
> +static void omapdss_default_get_timings(struct omap_dss_device *dssdev,
> + struct videomode *vm)
>  {
>   *vm = dssdev->panel.vm;
>  }
> -EXPORT_SYMBOL(omapdss_default_get_timings);
>  
>  static LIST_HEAD(panel_list);
>  static DEFINE_MUTEX(panel_list_mutex);
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index ca769466c4dc..4222661d4c88 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -609,9 +609,6 @@ int omapdss_output_unset_device(struct omap_dss_device 
> *out);
>  
>  struct omap_dss_device *omapdss_find_output_from_display(struct 
> omap_dss_device *dssdev);
>  
> -void omapdss_default_get_timings(struct omap_dss_device *dssdev,
> -  struct videomode *vm);
> -
>  typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
>  int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
>  int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/15] omapdrm: Miscellaneous fixes and cleanups

[Tomi Valkeinen]

On 11/02/18 15:07, Laurent Pinchart wrote:
> Hello,
> 
> Most of this series has previously been posted as part of "[PATCH 00/48]
> omapdrm: Merge omapdrm and omapdss". I've decided to split out the
> miscellaneous fixes and cleanups as they are (in my opinion) ready for
> upstream.
> 
> Patch 10/15 and 11/15 are new and trivial. Patch 12/15 is new as well
> and worth being noted as it's more complex. Please see its commit
> message for more details.
> 
> Tomi, I have a large number of other patches that have been developed on
> top of this series. As I think this is ready for upstream I would rather
> avoid rebasing them (there are multiple conflicts that, albeit minor,
> are always annoying). Could you consider taking this in your tree ?

Thanks, I think these look good. I've applied them to my tree.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105051] circular locking, switcheroo-cont/889 is trying to acquire lock vga_switchto_stage2, but vga_switcheroo_debugfs_write already has lock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105051

--- Comment #4 from bugzi...@colorremedies.com ---
Created attachment 137289
  --> https://bugs.freedesktop.org/attachment.cgi?id=137289&action=edit
dmidecode

-- 
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 105051] circular locking, switcheroo-cont/889 is trying to acquire lock vga_switchto_stage2, but vga_switcheroo_debugfs_write already has lock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105051

--- Comment #3 from bugzi...@colorremedies.com ---
Created attachment 137288
  --> https://bugs.freedesktop.org/attachment.cgi?id=137288&action=edit
lspci -vvnn

-- 
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 105051] circular locking, switcheroo-cont/889 is trying to acquire lock vga_switchto_stage2, but vga_switcheroo_debugfs_write already has lock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105051

--- Comment #2 from bugzi...@colorremedies.com ---
Created attachment 137287
  --> https://bugs.freedesktop.org/attachment.cgi?id=137287&action=edit
journalctl -b -o short-monotonic

-- 
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 105051] circular locking, switcheroo-cont/889 is trying to acquire lock vga_switchto_stage2, but vga_switcheroo_debugfs_write already has lock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105051

--- Comment #1 from bugzi...@colorremedies.com ---
Created attachment 137286
  --> https://bugs.freedesktop.org/attachment.cgi?id=137286&action=edit
dmesg.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 105051] circular locking, switcheroo-cont/889 is trying to acquire lock vga_switchto_stage2, but vga_switcheroo_debugfs_write already has lock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105051

bugzi...@colorremedies.com changed:

   What|Removed |Added

Summary|circular locking,   |circular locking,
   ||switcheroo-cont/889 is
   ||trying to acquire lock
   ||vga_switchto_stage2, but
   ||vga_switcheroo_debugfs_writ
   ||e already has lock

-- 
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 105051] circular locking,

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105051

Bug ID: 105051
   Summary: circular locking,
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bugzi...@colorremedies.com

4.16.0-0.rc0.git9.1.fc28.x86_64 which is "linux-next" git f9f1e414128e

[9.523799] switcheroo-cont/889 is trying to acquire lock:
[9.523799]  (console_lock){+.+.}, at: [<2c1cc7fb>]
vga_switchto_stage2+0x93/0x130
[9.523806] 
   but task is already holding lock:
[9.523807]  (vgasr_mutex){+.+.}, at: [<7e504e29>]
vga_switcheroo_debugfs_write+0x6b/0x360
[9.523810] 
   which lock already depends on the new lock.

[9.523810] 
   the existing dependency chain (in reverse order) is:
[9.523810] 
   -> #3 (vgasr_mutex){+.+.}:
[9.523812] 
   -> #2 (&helper->lock){+.+.}:
[9.523814] 
   -> #1 ((fb_notifier_list).rwsem){}:
[9.523816] 
   -> #0 (console_lock){+.+.}:
[9.523818] 
   other info that might help us debug this:

[9.523818] Chain exists of:
 console_lock --> &helper->lock --> vgasr_mutex

-- 
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 01/15] drm: omapdrm: Use kernel integer types

[Laurent Pinchart]

Hi Tomi,

On Monday, 12 February 2018 08:46:22 EET Tomi Valkeinen wrote:
> On 11/02/18 15:07, Laurent Pinchart wrote:
> > The standard kernel integer types are [us]{8,16,32}. Use them instead of
> > the u?int{8,16,32}_t types.
> 
> I presume you used a script to do the conversion? I think I need to do
> the same for TI's kernel, which has some non-mainline patches.

It was actually a simple sed conversion coupled with a manual review to make 
sure there were no false positives.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/15] drm: omapdrm: Use kernel integer types

[Tomi Valkeinen]

On 11/02/18 15:07, Laurent Pinchart wrote:
> The standard kernel integer types are [us]{8,16,32}. Use them instead of
> the u?int{8,16,32}_t types.

I presume you used a script to do the conversion? I think I need to do
the same for TI's kernel, which has some non-mainline patches.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dsi: Get byte_intf_clk only for versions that need it

[architt]

From: Archit Taneja 

Newer DSI host controllers (SDM845 in particular) require a new clock
called byte_intf_clk. A recent patch tried to add this as an optional
clock, but it still set 'ret' to an error number if it didn't find it.
This breaks the host's probe for all previous DSI host versions.

Instead of setting this up as an optional clock, try to get the clock
only for the DSI version that supports it.

Fixes: 56558fb ("drm/msm/dsi: Add byte_intf_clk")
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index f675975..62ac614 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -378,11 +378,16 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
 
-   msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
-   if (IS_ERR(msm_host->byte_intf_clk)) {
-   ret = PTR_ERR(msm_host->byte_intf_clk);
-   pr_debug("%s: can't find byte_intf clock. ret=%d\n",
-__func__, ret);
+   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G &&
+   cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V2_2_1) {
+   msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
+   if (IS_ERR(msm_host->byte_intf_clk)) {
+   ret = PTR_ERR(msm_host->byte_intf_clk);
+   pr_err("%s: can't find byte_intf clock. ret=%d\n",
+   __func__, ret);
+   goto exit;
+   }
+   } else {
msm_host->byte_intf_clk = NULL;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105021

--- Comment #5 from arne_woer...@yahoo.com ---
the new kernel 4.15.2-2-MANJARO still says during the second resume:
Feb 11 14:07:21 vaako.intern.wgboome.org kernel: [drm:uvd_v6_0_ring_test_ring
[amdgpu]] *ERROR* amdgpu: ring 12 test failed (0xCAFEDEAD)

it cannot even "halt -p" after the first thaw (it just reboots, instead of
turning off the power)...

and the command
> echo schedutil > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
fails after the second resume ("no such file" IIRC)...
is it possibly not just related to amdgpu?

-arne

-- 
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/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
> I've not been able to reproduce the original problem you're trying to
> solve on amdgpu thats with or without your patch set and the above
> "trigger" too
> 
> Is anything else required to trigger it, I started multiple DRI_PRIME
> glxgears, in parallel, serial waiting the 12 seconds and serial within
> the 12 seconds and I couldn't reproduce it

The discrete GPU needs to runtime suspend, that's the trigger,
so no DRI_PRIME executables should be running.  Just let it
autosuspend after boot.  Do you see "waiting 12 sec" messages
in dmesg?  If not it's not autosuspending.

Thanks,

Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104082

--- Comment #33 from mikhail.v.gavri...@gmail.com ---
Why are you sure what this totally harmless?
I have proof this this isn't it.
Look at my system log:
- I got message "amdgpu :07:00.0: swiotlb buffer is full (sz: 2097152
bytes)" at Feb 10 18:46:00
- And then happened that gnome-shell crashed  2 seconds later at "Feb 10
18:48:53"

Today gnome-shell not crashed but I noted that gnome-terminal was closed after
this.
Feb 12 02:30:58 localhost.localdomain gnome-terminal-[2799]: Error flushing
display: Resource temporarily unavailable
Feb 12 02:30:58 localhost.localdomain systemd[1872]:
gnome-terminal-server.service: Main process exited, code=exited,
status=1/FAILURE
Feb 12 02:30:58 localhost.localdomain systemd[1872]:
gnome-terminal-server.service: Unit entered failed state.
Feb 12 02:30:58 localhost.localdomain systemd[1872]:
gnome-terminal-server.service: Failed with result 'exit-code'.

Of course, this may just be a coincidence, but the unpleasant residue remains.

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104082

--- Comment #32 from mikhail.v.gavri...@gmail.com ---
Created attachment 137285
  --> https://bugs.freedesktop.org/attachment.cgi?id=137285&action=edit
system 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

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

Hi

I've not been able to reproduce the original problem you're trying to
solve on amdgpu thats with or without your patch set and the above
"trigger" too

Is anything else required to trigger it, I started multiple DRI_PRIME
glxgears, in parallel, serial waiting the 12 seconds and serial within
the 12 seconds and I couldn't reproduce it

Regards

Mike
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104932

--- Comment #7 from Robin Kauffman  ---
(In reply to Michel Dänzer from comment #4)
> Which versions of Mesa & LLVM are you using?

I should also add that LLVM & Clang were compiled/installed *prior* to merging
libclc & Mesa (probably prior to libdrm as well, but in full honesty I can't
remember), and that libdrm, libclc & Mesa were merged in that order.

-- 
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 198551] amdgpu error on shutdown or gpu intense game

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198551

illuslion1...@gmail.com changed:

   What|Removed |Added

 Kernel Version|4.14.14-1   |4.15.1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198551] amdgpu error on shutdown or gpu intense game

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198551

illuslion1...@gmail.com changed:

   What|Removed |Added

 Attachment #273797|0   |1
is obsolete||

--- Comment #2 from illuslion1...@gmail.com ---
Created attachment 274119
  --> https://bugzilla.kernel.org/attachment.cgi?id=274119&action=edit
AMDGPU Error in-game

Now I get this error on Linux 4.15. It should have a newer amdgpu version.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105039] No 120hz with 4.15 kernel and DC enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105039

--- Comment #1 from Matthew Scheirer  ---
Same issue with 4.15 / Mesa 17.3 / Xorg 1.19.6 on a 290 + Acer GN246HL. No DC
the 144 / 120 / etc modes show up, DC only 60hz does.

-- 
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/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 08:23:14PM +0100, Lukas Wunner wrote:
> On Sun, Feb 11, 2018 at 06:58:11PM +, Mike Lothian wrote:
> > On 11 February 2018 at 09:38, Lukas Wunner  wrote:
> > > The patches for radeon and amdgpu are compile-tested only, I only have a
> > > MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> > > "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> > > This ensures that the poll worker runs after ->runtime_suspend has begun.
> > > Wait 12 sec after the GPU has begun runtime suspend, then check
> > > /sys/bus/pci/devices/:01:00.0/power/runtime_status.  Without this
> > > series, the status will be stuck at "suspending" and you'll get hung task
> > > errors in dmesg after a few minutes.
> > 
> > I wasn't quite sure where to add that msleep. I've tested the patches
> > as is on top of agd5f's wip branch without ill effects
> > 
> > I've had a radeon and now a amdgpu PRIME setup and don't believe I've
> > ever seen this issue
> > 
> > If you could pop a patch together for the msleep I'll give it a test on
> > amdgpu
> 
> Here you go, this is for all 3 drivers.
> Should deadlock without the series.
> Thanks!

Sorry, I missed that amdgpu_drv.c and radeon_drv.c don't include delay.h,
rectified testing patch below:


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 50afcf6..beaaf2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -36,6 +36,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -718,6 +719,9 @@ static int amdgpu_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
 
+   printk("waiting 12 sec\n");
+   msleep(12*1000);
+   printk("done waiting 12 sec\n");
drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
drm_kms_helper_poll_disable(drm_dev);
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe5..ee7cf0d 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -586,6 +586,7 @@ static void output_poll_execute(struct work_struct *work)
repoll = true;
goto out;
}
+   dev_info(&dev->pdev->dev, "begin poll\n");
 
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
@@ -651,6 +652,7 @@ static void output_poll_execute(struct work_struct *work)
 
if (repoll)
schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
+   dev_info(&dev->pdev->dev, "end poll\n");
 }
 
 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3e29302..f9da5bc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -855,6 +855,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
return -EBUSY;
}
 
+   printk("waiting 12 sec\n");
+   msleep(12*1000);
+   printk("done waiting 12 sec\n");
drm_kms_helper_poll_disable(drm_dev);
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
nouveau_switcheroo_optimus_dsm();
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 31dd04f..2b4e7e0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -413,6 +414,9 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
 
+   printk("waiting 12 sec\n");
+   msleep(12*1000);
+   printk("done waiting 12 sec\n");
drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
drm_kms_helper_poll_disable(drm_dev);
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 06:58:11PM +, Mike Lothian wrote:
> On 11 February 2018 at 09:38, Lukas Wunner  wrote:
> > The patches for radeon and amdgpu are compile-tested only, I only have a
> > MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> > "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> > This ensures that the poll worker runs after ->runtime_suspend has begun.
> > Wait 12 sec after the GPU has begun runtime suspend, then check
> > /sys/bus/pci/devices/:01:00.0/power/runtime_status.  Without this
> > series, the status will be stuck at "suspending" and you'll get hung task
> > errors in dmesg after a few minutes.
> 
> I wasn't quite sure where to add that msleep. I've tested the patches
> as is on top of agd5f's wip branch without ill effects
> 
> I've had a radeon and now a amdgpu PRIME setup and don't believe I've
> ever seen this issue
> 
> If you could pop a patch together for the msleep I'll give it a test on
> amdgpu

Here you go, this is for all 3 drivers.
Should deadlock without the series.
Thanks!


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 50afcf6..eefa0d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -718,6 +718,9 @@ static int amdgpu_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
 
+   printk("waiting 12 sec\n");
+   msleep(12*1000);
+   printk("done waiting 12 sec\n");
drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
drm_kms_helper_poll_disable(drm_dev);
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe5..ee7cf0d 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -586,6 +586,7 @@ static void output_poll_execute(struct work_struct *work)
repoll = true;
goto out;
}
+   dev_info(&dev->pdev->dev, "begin poll\n");
 
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
@@ -651,6 +652,7 @@ static void output_poll_execute(struct work_struct *work)
 
if (repoll)
schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
+   dev_info(&dev->pdev->dev, "end poll\n");
 }
 
 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3e29302..f9da5bc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -855,6 +855,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
return -EBUSY;
}
 
+   printk("waiting 12 sec\n");
+   msleep(12*1000);
+   printk("done waiting 12 sec\n");
drm_kms_helper_poll_disable(drm_dev);
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
nouveau_switcheroo_optimus_dsm();
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 31dd04f..707b8aa 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -413,6 +413,9 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
return -EBUSY;
}
 
+   printk("waiting 12 sec\n");
+   msleep(12*1000);
+   printk("done waiting 12 sec\n");
drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
drm_kms_helper_poll_disable(drm_dev);
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105042] [LLVM Regression] Shadow of Mordor stucks at intro video

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105042

--- Comment #1 from Bas Nieuwenhuizen  ---
What happens with the range in between? There are quite a few commits ot the
AMDGPU backend in there so would be good if we can reduce that range and
pinpoint the exact revision that is causing 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

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

On 11 February 2018 at 09:38, Lukas Wunner  wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
>
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
>
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
>
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
>
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
>
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
>
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
>
> Please review.  Thanks,
>
> Lukas
>
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +---
>  drivers/gpu/drm/drm_probe_helper.c | 14 +
>  drivers/gpu/drm/nouveau/nouveau_connector.c| 18 +--
>  drivers/gpu/drm/radeon/radeon_connectors.c | 74 
> +-
>  include/drm/drm_crtc_helper.h  |  1 +
>  include/linux/workqueue.h  |  1 +
>  kernel/workqueue.c | 16 ++
>  7 files changed, 132 insertions(+), 50 deletions(-)
>
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


I wasn't quite sure where to add that msleep. I've tested the patches
as is on top of agd5f's wip branch without ill effects

I've had a radeon and now a amdgpu PRIME setup and don't believe I've
ever seen this issue

If you could pop a patch together for the msleep I'll give it a test on amdgpu

Cheers

Mike
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198745

--- Comment #6 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Created attachment 274117
  --> https://bugzilla.kernel.org/attachment.cgi?id=274117&action=edit
xorg log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198745

--- Comment #5 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Created attachment 274115
  --> https://bugzilla.kernel.org/attachment.cgi?id=274115&action=edit
dmesg log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104082

--- Comment #31 from Christian König  ---
(In reply to mikhail.v.gavrilov from comment #30)
> I didn't understand It's already fixed in which commit?
> If yes why I see this issue with latest build amd-staging-drm-next?

See here https://lkml.org/lkml/2018/1/16/106. I've already pinged Konrad
multiple times as well, but I'm still not sure if and when he send that patch
to Linus.

The real point is that those messages are just false positives, e.g. they are
completely harmless and we haven't rebased amd-staging-drm-next in a while
which is most likely the reason why it isn't in there.

-- 
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 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105046

Bug ID: 105046
   Summary: Screen resolution reset to 1368x768 when turning
monitor off
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: forum...@mizapf.de

With amdgpu.dc=1, when I turn off the monitor or the monitor enters power-save
state, the screen resolution changes to 1368x768, which messes up the desktop
elements arrangement. Opening the settings, it is the highest offered
resolution, and the original resolution can only be restored by killing X or
rebooting.

This effectively means that I have to keep my monitor running till logout.

It happens on three different systems, all using amdgpu (RX480, RX580, RX460).

Does not happen with amdgpu.dc=0.

-- 
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 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198745

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your full dmesg output and xorg log if you are using X.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/i915: Add intel_bios_cleanup() function

[Hans de Goede]

Hi,

On 06-02-18 15:12, Hans de Goede wrote:

Add an intel_bios_cleanup() function to act as counterpart of
intel_bios_init() and move the cleanup of vbt related resources there,
putting it in the same file as the allocation.

Signed-off-by: Hans de Goede 


Can I get an Acked-by for this patch and 2/3 please? Then I can
push this series.

Regards,

Hans


---
  drivers/gpu/drm/i915/i915_drv.c   | 14 +-
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_bios.c | 21 +
  3 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9f1daf258fe..7f094bbc2a7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1446,19 +1446,7 @@ void i915_driver_unload(struct drm_device *dev)
  
  	intel_modeset_cleanup(dev);
  
-	/*

-* free the memory space allocated for the child device
-* config parsed from VBT
-*/
-   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
-   kfree(dev_priv->vbt.child_dev);
-   dev_priv->vbt.child_dev = NULL;
-   dev_priv->vbt.child_dev_num = 0;
-   }
-   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
-   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
-   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
-   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+   intel_bios_cleanup(dev_priv);
  
  	vga_switcheroo_unregister_client(pdev);

vga_client_register(pdev, NULL, NULL, NULL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6b5ac2a563d..1cccea1b87bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3675,6 +3675,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
*dev_priv);
  
  /* intel_bios.c */

  void intel_bios_init(struct drm_i915_private *dev_priv);
+void intel_bios_cleanup(struct drm_i915_private *dev_priv);
  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
  bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 4e74aa2f16bc..f9550507bb9f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1610,6 +1610,27 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
pci_unmap_rom(pdev, bios);
  }
  
+/**

+ * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
+ * @dev_priv: i915 device instance
+ */
+void intel_bios_cleanup(struct drm_i915_private *dev_priv)
+{
+   /*
+* free the memory space allocated for the child device
+* config parsed from VBT
+*/
+   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
+   kfree(dev_priv->vbt.child_dev);
+   dev_priv->vbt.child_dev = NULL;
+   dev_priv->vbt.child_dev_num = 0;
+   }
+   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
+   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
+   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
+   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+}
+
  /**
   * intel_bios_is_tv_present - is integrated TV present in VBT
   * @dev_priv: i915 device instance


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104082

--- Comment #30 from mikhail.v.gavri...@gmail.com ---
(In reply to Christian König from comment #28)
> Ok setting this as fixed which hopefully makes people stop adding new
> comments to this bug report.

I didn't understand It's already fixed in which commit?
If yes why I see this issue with latest build amd-staging-drm-next?

-- 
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 10/15] drm: omapdrm: dss: Make omapdss_default_get_timings static

[Laurent Pinchart]

The function isn't used outside of its compilation unit, make it static.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/display.c | 5 ++---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
b/drivers/gpu/drm/omapdrm/dss/display.c
index 0c9480ba85c0..424143128cd4 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -28,12 +28,11 @@
 
 #include "omapdss.h"
 
-void omapdss_default_get_timings(struct omap_dss_device *dssdev,
-struct videomode *vm)
+static void omapdss_default_get_timings(struct omap_dss_device *dssdev,
+   struct videomode *vm)
 {
*vm = dssdev->panel.vm;
 }
-EXPORT_SYMBOL(omapdss_default_get_timings);
 
 static LIST_HEAD(panel_list);
 static DEFINE_MUTEX(panel_list_mutex);
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index ca769466c4dc..4222661d4c88 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -609,9 +609,6 @@ int omapdss_output_unset_device(struct omap_dss_device 
*out);
 
 struct omap_dss_device *omapdss_find_output_from_display(struct 
omap_dss_device *dssdev);
 
-void omapdss_default_get_timings(struct omap_dss_device *dssdev,
-struct videomode *vm);
-
 typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 08/15] drm: omapdrm: displays: Get panel source at connect time

[Laurent Pinchart]

The connector drivers need a handle to the source they are connected to
in order to control the source.

All drivers get that handle at probe time, resulting in probe deferral
when the source hasn't been probed yet. However they don't need the
handle until their connect handler is called.

Move retrieval of the source handle to the connect handler to avoid
probe deferrals.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   | 35 +++-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 27 +++--
 .../omapdrm/displays/panel-lgphilips-lb035q02.c| 35 +++-
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 39 --
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 35 +++-
 .../drm/omapdrm/displays/panel-sony-acx565akm.c| 26 ++--
 .../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 46 +++---
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 29 +++---
 8 files changed, 119 insertions(+), 153 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index 6cb381a452ce..e1320b145692 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -38,16 +38,25 @@ struct panel_drv_data {
 static int panel_dpi_connect(struct omap_dss_device *dssdev)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata->in;
+   struct omap_dss_device *in;
int r;
 
if (omapdss_device_is_connected(dssdev))
return 0;
 
+   in = omapdss_of_find_source_for_first_ep(dssdev->dev->of_node);
+   if (IS_ERR(in)) {
+   dev_err(dssdev->dev, "failed to find video source\n");
+   return PTR_ERR(in);
+   }
+
r = in->ops.dpi->connect(in, dssdev);
-   if (r)
+   if (r) {
+   omap_dss_put_device(in);
return r;
+   }
 
+   ddata->in = in;
return 0;
 }
 
@@ -60,6 +69,9 @@ static void panel_dpi_disconnect(struct omap_dss_device 
*dssdev)
return;
 
in->ops.dpi->disconnect(in, dssdev);
+
+   omap_dss_put_device(in);
+   ddata->in = NULL;
 }
 
 static int panel_dpi_enable(struct omap_dss_device *dssdev)
@@ -165,7 +177,6 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev->dev.of_node;
struct device_node *bl_node;
-   struct omap_dss_device *in;
int r;
struct display_timing timing;
struct gpio_desc *gpio;
@@ -207,15 +218,6 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
 
videomode_from_timing(&timing, &ddata->vm);
 
-   in = omapdss_of_find_source_for_first_ep(node);
-   if (IS_ERR(in)) {
-   dev_err(&pdev->dev, "failed to find video source\n");
-   r = PTR_ERR(in);
-   goto error_free_backlight;
-   }
-
-   ddata->in = in;
-
return 0;
 
 error_free_backlight:
@@ -251,29 +253,22 @@ static int panel_dpi_probe(struct platform_device *pdev)
r = omapdss_register_display(dssdev);
if (r) {
dev_err(&pdev->dev, "Failed to register panel\n");
-   goto err_reg;
+   return r;
}
 
return 0;
-
-err_reg:
-   omap_dss_put_device(ddata->in);
-   return r;
 }
 
 static int __exit panel_dpi_remove(struct platform_device *pdev)
 {
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *dssdev = &ddata->dssdev;
-   struct omap_dss_device *in = ddata->in;
 
omapdss_unregister_display(dssdev);
 
panel_dpi_disable(dssdev);
panel_dpi_disconnect(dssdev);
 
-   omap_dss_put_device(in);
-
if (ddata->backlight)
put_device(&ddata->backlight->dev);
 
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 002082ecbbbc..f960e55d64ea 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -759,17 +759,23 @@ static int dsicm_panel_reset(struct panel_drv_data *ddata)
 static int dsicm_connect(struct omap_dss_device *dssdev)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata->in;
struct device *dev = &ddata->pdev->dev;
+   struct omap_dss_device *in;
int r;
 
if (omapdss_device_is_connected(dssdev))
return 0;
 
+   in = omapdss_of_find_source_for_first_ep(dssdev->dev->of_node);
+   if (IS_ERR(in)) {
+   dev_err(dssdev->dev, "failed to find video source\n");
+   return PTR_ERR(in);
+   }
+
r = in->ops.dsi->connect(in, dssde

[PATCH v2 11/15] drm: omapdrm: dss: Don't export functions internal to omapdss-base

[Laurent Pinchart]

A few functions defined in omapdss-base are internal to the module.
Don't export them.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 2 --
 drivers/gpu/drm/omapdrm/dss/output.c | 1 -
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index 967d9e1b34e5..4602a79c6c44 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -44,7 +44,6 @@ struct device_node *dss_of_port_get_parent_device(struct 
device_node *port)
 
return NULL;
 }
-EXPORT_SYMBOL_GPL(dss_of_port_get_parent_device);
 
 u32 dss_of_port_get_port_number(struct device_node *port)
 {
@@ -57,7 +56,6 @@ u32 dss_of_port_get_port_number(struct device_node *port)
 
return reg;
 }
-EXPORT_SYMBOL_GPL(dss_of_port_get_port_number);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node)
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
b/drivers/gpu/drm/omapdrm/dss/output.c
index b9afd80ae385..a28e00c94c05 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -156,7 +156,6 @@ struct omap_dss_device 
*omap_dss_find_output_by_port_node(struct device_node *po
 
return NULL;
 }
-EXPORT_SYMBOL(omap_dss_find_output_by_port_node);
 
 struct omap_dss_device *omapdss_find_output_from_display(struct 
omap_dss_device *dssdev)
 {
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 12/15] drm: omapdrm: dss: Move initialization code from component bind to probe

[Laurent Pinchart]

There's no reason to delay initialization of most of the driver (such as
mapping memory I/O, getting clocks or enabling runtime PM) to the
component master bind handler.

This additionally fixes a real PM issue caused enabling runtime PM in
the bind handler.

The bind handler performs the following sequence of PM operations:

pm_runtime_enable(dev);
pm_runtime_get_sync(dev);

... (access the hardware to read the device revision) ...

pm_runtime_put_sync(dev);

If a failure occurs at this point, the error path calls
pm_runtime_disable() to balance the pm_runtime_enable() call.

To understand the problem, it should be noted that the bind handler is
called when one of the component registers itself, which happens in the
component's probe handler. Furthermore, as the components are children
of the DSS, the device core calls pm_runtime_get_sync() on the DSS
platform device before calling the component's probe handler. This
increases the DSS power usage count but doesn't runtime resume the
device, as runtime PM is disabled at that point.

The bind handler is thus called with runtime PM disabled, with the
device runtime suspended, but with the power usage count larger than 0.
The pm_runtime_get_sync() call will thus further increase the power
usage count and runtime resume the device. The pm_runtime_put_sync()
handler will decrease the power usage count to a non-zero value and will
thus not suspend the device. Finally, the pm_runtime_disable() call will
disable runtime PM, preventing the pm_runtime_put() call in the device
core from runtime suspending the device. The DSS device is thus left
powered on.

To fix this, move the initialization code from the bind handler to the
probe handler.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 193 --
 1 file changed, 104 insertions(+), 89 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index f1c7ef3a2ec3..d086189263ef 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1300,88 +1300,18 @@ static const struct soc_device_attribute 
dss_soc_devices[] = {
 
 static int dss_bind(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct resource *dss_mem;
-   u32 rev;
int r;
 
-   dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
-   dss.base = devm_ioremap_resource(&pdev->dev, dss_mem);
-   if (IS_ERR(dss.base))
-   return PTR_ERR(dss.base);
-
-   r = dss_get_clocks();
+   r = component_bind_all(dev, NULL);
if (r)
return r;
 
-   r = dss_setup_default_clock();
-   if (r)
-   goto err_setup_clocks;
-
-   r = dss_video_pll_probe(pdev);
-   if (r)
-   goto err_pll_init;
-
-   r = dss_init_ports(pdev);
-   if (r)
-   goto err_init_ports;
-
-   pm_runtime_enable(&pdev->dev);
-
-   r = dss_runtime_get();
-   if (r)
-   goto err_runtime_get;
-
-   dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
-
-   /* Select DPLL */
-   REG_FLD_MOD(DSS_CONTROL, 0, 0, 0);
-
-   dss_select_dispc_clk_source(DSS_CLK_SRC_FCK);
-
-#ifdef CONFIG_OMAP2_DSS_VENC
-   REG_FLD_MOD(DSS_CONTROL, 1, 4, 4);  /* venc dac demen */
-   REG_FLD_MOD(DSS_CONTROL, 1, 3, 3);  /* venc clock 4x enable */
-   REG_FLD_MOD(DSS_CONTROL, 0, 2, 2);  /* venc clock mode = normal */
-#endif
-   dss.dsi_clk_source[0] = DSS_CLK_SRC_FCK;
-   dss.dsi_clk_source[1] = DSS_CLK_SRC_FCK;
-   dss.dispc_clk_source = DSS_CLK_SRC_FCK;
-   dss.lcd_clk_source[0] = DSS_CLK_SRC_FCK;
-   dss.lcd_clk_source[1] = DSS_CLK_SRC_FCK;
-
-   rev = dss_read_reg(DSS_REVISION);
-   pr_info("OMAP DSS rev %d.%d\n", FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
-   dss_runtime_put();
-
-   r = component_bind_all(&pdev->dev, NULL);
-   if (r)
-   goto err_component;
-
-   dss_debugfs_create_file("dss", dss_dump_regs);
-
pm_set_vt_switch(0);
 
omapdss_gather_components(dev);
omapdss_set_is_initialized(true);
 
return 0;
-
-err_component:
-err_runtime_get:
-   pm_runtime_disable(&pdev->dev);
-   dss_uninit_ports(pdev);
-err_init_ports:
-   if (dss.video1_pll)
-   dss_video_pll_uninit(dss.video1_pll);
-
-   if (dss.video2_pll)
-   dss_video_pll_uninit(dss.video2_pll);
-err_pll_init:
-err_setup_clocks:
-   dss_put_clocks();
-   return r;
 }
 
 static void dss_unbind(struct device *dev)
@@ -1391,18 +1321,6 @@ static void dss_unbind(struct device *dev)
omapdss_set_is_initialized(false);
 
component_unbind_all(&pdev->dev, NULL);
-
-   if (dss.video1_pll)
-   dss_video_pll_uninit(dss.video1_pll);
-
-   if (dss.video2_pll)
-   dss_video_pll_uninit(dss.video2_pll);
-
-   

[PATCH v2 14/15] drm: omapdrm: dss: Remove unused functions prototypes

[Laurent Pinchart]

The omap_dss_register_driver(), omap_dss_unregister_driver() and
dispc_enable_gamma_table() functions don't exist anymore, remove their
prototypes.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/dss.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 287c90608557..7f3fa5330408 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -356,7 +356,6 @@ void dispc_disable_sidle(void);
 void dispc_lcd_enable_signal(bool enable);
 void dispc_pck_free_enable(bool enable);
 void dispc_enable_fifomerge(bool enable);
-void dispc_enable_gamma_table(bool enable);
 
 typedef bool (*dispc_div_calc_func)(int lckd, int pckd, unsigned long lck,
unsigned long pck, void *data);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 09/15] drm: omapdrm: displays: Get encoder source at connect time

[Laurent Pinchart]

The encoder drivers need a handle to the source they are connected to in
order to control the source.

All drivers get that handle at probe time, resulting in probe deferral
when the source hasn't been probed yet. However they don't need the
handle until their connect handler is called.

Move retrieval of the source handle to the connect handler to avoid
probe deferrals.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  | 35 ++--
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  | 36 ++--
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   | 66 --
 3 files changed, 54 insertions(+), 83 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index b424db11c6d5..afee1b8b457a 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -36,7 +36,7 @@ static int opa362_connect(struct omap_dss_device *dssdev,
struct omap_dss_device *dst)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata->in;
+   struct omap_dss_device *in;
int r;
 
dev_dbg(dssdev->dev, "connect\n");
@@ -44,13 +44,22 @@ static int opa362_connect(struct omap_dss_device *dssdev,
if (omapdss_device_is_connected(dssdev))
return -EBUSY;
 
+   in = omapdss_of_find_source_for_first_ep(dssdev->dev->of_node);
+   if (IS_ERR(in)) {
+   dev_err(dssdev->dev, "failed to find video source\n");
+   return PTR_ERR(in);
+   }
+
r = in->ops.atv->connect(in, dssdev);
-   if (r)
+   if (r) {
+   omap_dss_put_device(in);
return r;
+   }
 
dst->src = dssdev;
dssdev->dst = dst;
 
+   ddata->in = in;
return 0;
 }
 
@@ -74,6 +83,9 @@ static void opa362_disconnect(struct omap_dss_device *dssdev,
dssdev->dst = NULL;
 
in->ops.atv->disconnect(in, &ddata->dssdev);
+
+   omap_dss_put_device(in);
+   ddata->in = NULL;
 }
 
 static int opa362_enable(struct omap_dss_device *dssdev)
@@ -171,9 +183,8 @@ static const struct omapdss_atv_ops opa362_atv_ops = {
 
 static int opa362_probe(struct platform_device *pdev)
 {
-   struct device_node *node = pdev->dev.of_node;
struct panel_drv_data *ddata;
-   struct omap_dss_device *dssdev, *in;
+   struct omap_dss_device *dssdev;
struct gpio_desc *gpio;
int r;
 
@@ -191,14 +202,6 @@ static int opa362_probe(struct platform_device *pdev)
 
ddata->enable_gpio = gpio;
 
-   in = omapdss_of_find_source_for_first_ep(node);
-   if (IS_ERR(in)) {
-   dev_err(&pdev->dev, "failed to find video source\n");
-   return PTR_ERR(in);
-   }
-
-   ddata->in = in;
-
dssdev = &ddata->dssdev;
dssdev->ops.atv = &opa362_atv_ops;
dssdev->dev = &pdev->dev;
@@ -209,20 +212,16 @@ static int opa362_probe(struct platform_device *pdev)
r = omapdss_register_output(dssdev);
if (r) {
dev_err(&pdev->dev, "Failed to register output\n");
-   goto err_reg;
+   return r;
}
 
return 0;
-err_reg:
-   omap_dss_put_device(ddata->in);
-   return r;
 }
 
 static int __exit opa362_remove(struct platform_device *pdev)
 {
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *dssdev = &ddata->dssdev;
-   struct omap_dss_device *in = ddata->in;
 
omapdss_unregister_output(&ddata->dssdev);
 
@@ -234,8 +233,6 @@ static int __exit opa362_remove(struct platform_device 
*pdev)
if (omapdss_device_is_connected(dssdev))
opa362_disconnect(dssdev, dssdev->dst);
 
-   omap_dss_put_device(in);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index e0bc625a5f3a..ed7ae384c3ed 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -32,19 +32,28 @@ static int tfp410_connect(struct omap_dss_device *dssdev,
struct omap_dss_device *dst)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata->in;
+   struct omap_dss_device *in;
int r;
 
if (omapdss_device_is_connected(dssdev))
return -EBUSY;
 
+   in = omapdss_of_find_source_for_first_ep(dssdev->dev->of_node);
+   if (IS_ERR(in)) {
+   dev_err(dssdev->dev, "failed to find video source\n");
+   return PTR_ERR(in);
+   }
+
r = in->ops.dpi->connect(in, dssdev);
-   if (r)
+   if (r) {
+   omap_dss_put_device(in);
return r;
+   }
 
dst->src = dssdev;
   

[PATCH v2 15/15] drm: omapdrm: dsi: Make wait_for_bit_change() return a status

[Laurent Pinchart]

The wait_for_bit_change() function returns the value of the bit it
polls. This requires the caller to compare the return value to the
expected bit value. As all the existing callers need is to check whether
the bit has reached the expected value, it's easier to return a boolean
status from the function.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 86bd47f23424..41d500eea843 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -524,7 +524,7 @@ static void dsi_completion_handler(void *data, u32 mask)
complete((struct completion *)data);
 }
 
-static inline int wait_for_bit_change(struct platform_device *dsidev,
+static inline bool wait_for_bit_change(struct platform_device *dsidev,
const struct dsi_reg idx, int bitnum, int value)
 {
unsigned long timeout;
@@ -535,21 +535,21 @@ static inline int wait_for_bit_change(struct 
platform_device *dsidev,
t = 100;
while (t-- > 0) {
if (REG_GET(dsidev, idx, bitnum, bitnum) == value)
-   return value;
+   return true;
}
 
/* then loop for 500ms, sleeping for 1ms in between */
timeout = jiffies + msecs_to_jiffies(500);
while (time_before(jiffies, timeout)) {
if (REG_GET(dsidev, idx, bitnum, bitnum) == value)
-   return value;
+   return true;
 
wait = ns_to_ktime(1000 * 1000);
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_hrtimeout(&wait, HRTIMER_MODE_REL);
}
 
-   return !value;
+   return false;
 }
 
 static u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
@@ -1252,9 +1252,9 @@ static inline int dsi_if_enable(struct platform_device 
*dsidev, bool enable)
enable = enable ? 1 : 0;
REG_FLD_MOD(dsidev, DSI_CTRL, enable, 0, 0); /* IF_EN */
 
-   if (wait_for_bit_change(dsidev, DSI_CTRL, 0, enable) != enable) {
-   DSSERR("Failed to set dsi_if_enable to %d\n", enable);
-   return -EIO;
+   if (!wait_for_bit_change(dsidev, DSI_CTRL, 0, enable)) {
+   DSSERR("Failed to set dsi_if_enable to %d\n", enable);
+   return -EIO;
}
 
return 0;
@@ -1441,7 +1441,7 @@ static int dsi_pll_enable(struct dss_pll *pll)
/* XXX PLL does not come out of reset without this... */
dispc_pck_free_enable(1);
 
-   if (wait_for_bit_change(dsidev, DSI_PLL_STATUS, 0, 1) != 1) {
+   if (!wait_for_bit_change(dsidev, DSI_PLL_STATUS, 0, 1)) {
DSSERR("PLL not coming out of reset.\n");
r = -ENODEV;
dispc_pck_free_enable(0);
@@ -2187,7 +2187,7 @@ static int dsi_cio_init(struct platform_device *dsidev)
 * I/O. */
dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
 
-   if (wait_for_bit_change(dsidev, DSI_DSIPHY_CFG5, 30, 1) != 1) {
+   if (!wait_for_bit_change(dsidev, DSI_DSIPHY_CFG5, 30, 1)) {
DSSERR("CIO SCP Clock domain not coming out of reset.\n");
r = -EIO;
goto err_scp_clk_dom;
@@ -2235,7 +2235,7 @@ static int dsi_cio_init(struct platform_device *dsidev)
if (r)
goto err_cio_pwr;
 
-   if (wait_for_bit_change(dsidev, DSI_COMPLEXIO_CFG1, 29, 1) != 1) {
+   if (!wait_for_bit_change(dsidev, DSI_COMPLEXIO_CFG1, 29, 1)) {
DSSERR("CIO PWR clock domain not coming out of reset.\n");
r = -ENODEV;
goto err_cio_pwr_dom;
@@ -2376,7 +2376,7 @@ static int dsi_force_tx_stop_mode_io(struct 
platform_device *dsidev)
r = FLD_MOD(r, 1, 15, 15);  /* FORCE_TX_STOP_MODE_IO */
dsi_write_reg(dsidev, DSI_TIMING1, r);
 
-   if (wait_for_bit_change(dsidev, DSI_TIMING1, 15, 0) != 0) {
+   if (!wait_for_bit_change(dsidev, DSI_TIMING1, 15, 0)) {
DSSERR("TX_STOP bit not going down\n");
return -EIO;
}
@@ -2518,10 +2518,9 @@ static int dsi_vc_enable(struct platform_device *dsidev, 
int channel,
 
REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), enable, 0, 0);
 
-   if (wait_for_bit_change(dsidev, DSI_VC_CTRL(channel),
-   0, enable) != enable) {
-   DSSERR("Failed to set dsi_vc_enable to %d\n", enable);
-   return -EIO;
+   if (!wait_for_bit_change(dsidev, DSI_VC_CTRL(channel), 0, enable)) {
+   DSSERR("Failed to set dsi_vc_enable to %d\n", enable);
+   return -EIO;
}
 
return 0;
@@ -2573,7 +2572,7 @@ static int dsi_vc_config_source(struct platform_device 
*dsidev, int channel,
dsi_vc_enable(dsidev, channel, 0);
 
 

[PATCH v2 03/15] drm: omapdrm: connector-analog-tv: Remove tvc_of_match forward declaration

[Laurent Pinchart]

The tvc_of_match variable is never referenced before its definition.
Remove the forward declaration.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index 95ea6abae914..d3a79d508855 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -40,8 +40,6 @@ static const struct videomode tvc_pal_vm = {
  DISPLAY_FLAGS_VSYNC_LOW,
 };
 
-static const struct of_device_id tvc_of_match[];
-
 #define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
 
 static int tvc_connect(struct omap_dss_device *dssdev)
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 06/15] drm: omapdrm: displays: Remove OF node check in panel drivers

[Laurent Pinchart]

No panel is instantiated through platform data anymore, there is no
need to check for OF node presence.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 3 ---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 3 ---
 drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c | 3 ---
 drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c | 3 ---
 drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c  | 3 ---
 drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 3 ---
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 3 ---
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c | 3 ---
 8 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index efff6dbbb86f..6cb381a452ce 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -231,9 +231,6 @@ static int panel_dpi_probe(struct platform_device *pdev)
struct omap_dss_device *dssdev;
int r;
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
if (ddata == NULL)
return -ENOMEM;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index fb83f757b113..002082ecbbbc 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -1317,9 +1317,6 @@ static int dsicm_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->pdev = pdev;
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
ddata->vm.hactive = 864;
ddata->vm.vactive = 480;
ddata->vm.pixelclock = 864 * 480 * 60;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index 57af22ce87c5..8cb958c0c39d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -268,9 +268,6 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
 
ddata->spi = spi;
 
-   if (!spi->dev.of_node)
-   return -ENODEV;
-
r = lb035q02_probe_of(spi);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c 
b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
index bf53676263ad..3ab4b249e74b 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c
@@ -277,9 +277,6 @@ static int nec_8048_probe(struct spi_device *spi)
 
ddata->spi = spi;
 
-   if (!spi->dev.of_node)
-   return -ENODEV;
-
r = nec_8048_probe_of(spi);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
index 34555801fa4c..124867e35e4b 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c
@@ -268,9 +268,6 @@ static int sharp_ls_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, ddata);
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
r = sharp_ls_probe_of(pdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
index 06d7d8362a73..cc5e9a68726a 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
@@ -720,9 +720,6 @@ static int acx565akm_probe(struct spi_device *spi)
 
dev_dbg(&spi->dev, "%s\n", __func__);
 
-   if (!spi->dev.of_node)
-   return -ENODEV;
-
spi->mode = SPI_MODE_3;
 
ddata = devm_kzalloc(&spi->dev, sizeof(*ddata), GFP_KERNEL);
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index 2721a86ac5e7..3f6c90db35c4 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -404,9 +404,6 @@ static int td028ttec1_panel_probe(struct spi_device *spi)
 
ddata->spi_dev = spi;
 
-   if (!spi->dev.of_node)
-   return -ENODEV;
-
r = td028ttec1_probe_of(spi);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
index ac4a6d4d134c..06fb5a995002 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-t

[PATCH v2 04/15] drm: omapdrm: displays: Remove OF node check in connector drivers

[Laurent Pinchart]

No connector is instantiated through platform data anymore, there is no
need to check for OF node presence.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 ---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   | 3 ---
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  | 3 ---
 3 files changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index d3a79d508855..e6b87adea933 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -196,9 +196,6 @@ static int tvc_probe(struct platform_device *pdev)
struct omap_dss_device *dssdev;
int r;
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 10b4b97d3595..6716aef41c7e 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -275,9 +275,6 @@ static int dvic_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, ddata);
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
r = dvic_probe_of(pdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
index 2867476419dc..c152c5dfb4a0 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-hdmi.c
@@ -336,9 +336,6 @@ static int hdmic_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = &pdev->dev;
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
r = hdmic_probe_of(pdev);
if (r)
return r;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 13/15] drm: omapdrm: dss: Remove dss_get_hdmi_venc_clk_source() function

[Laurent Pinchart]

The function is unused, remove it.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 14 --
 drivers/gpu/drm/omapdrm/dss/dss.h |  1 -
 2 files changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index d086189263ef..d5490336e7c7 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -752,20 +752,6 @@ void dss_select_hdmi_venc_clk_source(enum 
dss_hdmi_venc_clk_source_select src)
REG_FLD_MOD(DSS_CONTROL, src, 15, 15);  /* VENC_HDMI_SWITCH */
 }
 
-enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void)
-{
-   enum omap_dss_output_id outputs;
-
-   outputs = dss.feat->outputs[OMAP_DSS_CHANNEL_DIGIT];
-   if ((outputs & OMAP_DSS_OUTPUT_HDMI) == 0)
-   return DSS_VENC_TV_CLK;
-
-   if ((outputs & OMAP_DSS_OUTPUT_VENC) == 0)
-   return DSS_HDMI_M_PCLK;
-
-   return REG_GET(DSS_CONTROL, 15, 15);
-}
-
 static int dss_dpi_select_source_omap2_omap3(int port, enum omap_channel 
channel)
 {
if (channel != OMAP_DSS_CHANNEL_LCD)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 196f6ddba598..287c90608557 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -270,7 +270,6 @@ unsigned long dss_get_max_fck_rate(void);
 enum omap_dss_output_id dss_get_supported_outputs(enum omap_channel channel);
 int dss_dpi_select_source(int port, enum omap_channel channel);
 void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
-enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
 const char *dss_get_clk_source_name(enum dss_clk_source clk_src);
 
 /* DSS VIDEO PLL */
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 07/15] drm: omapdrm: displays: Get connector source at connect time

[Laurent Pinchart]

The connector drivers need a handle to the source they are connected to
in order to control the source.

All drivers get that handle at probe time, resulting in probe deferral
when the source hasn't been probed yet. However they don't need the
handle until their connect handler is called.

Move retrieval of the source handle to the connect handler to avoid
probe deferrals.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 45 --
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   | 31 +++
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  | 37 --
 3 files changed, 46 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c 
b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
index e6b87adea933..9eabd7201a12 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c
@@ -45,7 +45,7 @@ static const struct videomode tvc_pal_vm = {
 static int tvc_connect(struct omap_dss_device *dssdev)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata->in;
+   struct omap_dss_device *in;
int r;
 
dev_dbg(ddata->dev, "connect\n");
@@ -53,10 +53,19 @@ static int tvc_connect(struct omap_dss_device *dssdev)
if (omapdss_device_is_connected(dssdev))
return 0;
 
+   in = omapdss_of_find_source_for_first_ep(ddata->dev->of_node);
+   if (IS_ERR(in)) {
+   dev_err(ddata->dev, "failed to find video source\n");
+   return PTR_ERR(in);
+   }
+
r = in->ops.atv->connect(in, dssdev);
-   if (r)
+   if (r) {
+   omap_dss_put_device(in);
return r;
+   }
 
+   ddata->in = in;
return 0;
 }
 
@@ -71,6 +80,9 @@ static void tvc_disconnect(struct omap_dss_device *dssdev)
return;
 
in->ops.atv->disconnect(in, dssdev);
+
+   omap_dss_put_device(in);
+   ddata->in = NULL;
 }
 
 static int tvc_enable(struct omap_dss_device *dssdev)
@@ -173,23 +185,6 @@ static struct omap_dss_driver tvc_driver = {
.set_wss= tvc_set_wss,
 };
 
-static int tvc_probe_of(struct platform_device *pdev)
-{
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
-   struct device_node *node = pdev->dev.of_node;
-   struct omap_dss_device *in;
-
-   in = omapdss_of_find_source_for_first_ep(node);
-   if (IS_ERR(in)) {
-   dev_err(&pdev->dev, "failed to find video source\n");
-   return PTR_ERR(in);
-   }
-
-   ddata->in = in;
-
-   return 0;
-}
-
 static int tvc_probe(struct platform_device *pdev)
 {
struct panel_drv_data *ddata;
@@ -203,10 +198,6 @@ static int tvc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = &pdev->dev;
 
-   r = tvc_probe_of(pdev);
-   if (r)
-   return r;
-
ddata->vm = tvc_pal_vm;
 
dssdev = &ddata->dssdev;
@@ -219,28 +210,22 @@ static int tvc_probe(struct platform_device *pdev)
r = omapdss_register_display(dssdev);
if (r) {
dev_err(&pdev->dev, "Failed to register panel\n");
-   goto err_reg;
+   return r;
}
 
return 0;
-err_reg:
-   omap_dss_put_device(ddata->in);
-   return r;
 }
 
 static int __exit tvc_remove(struct platform_device *pdev)
 {
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *dssdev = &ddata->dssdev;
-   struct omap_dss_device *in = ddata->in;
 
omapdss_unregister_display(&ddata->dssdev);
 
tvc_disable(dssdev);
tvc_disconnect(dssdev);
 
-   omap_dss_put_device(in);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 6716aef41c7e..391d80364346 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -51,16 +51,25 @@ struct panel_drv_data {
 static int dvic_connect(struct omap_dss_device *dssdev)
 {
struct panel_drv_data *ddata = to_panel_data(dssdev);
-   struct omap_dss_device *in = ddata->in;
+   struct omap_dss_device *in;
int r;
 
if (omapdss_device_is_connected(dssdev))
return 0;
 
+   in = omapdss_of_find_source_for_first_ep(dssdev->dev->of_node);
+   if (IS_ERR(in)) {
+   dev_err(dssdev->dev, "failed to find video source\n");
+   return PTR_ERR(in);
+   }
+
r = in->ops.dvi->connect(in, dssdev);
-   if (r)
+   if (r) {
+   omap_dss_put_device(in);
return r;
+   }
 
+   ddata->in = in;
return 0;
 }
 
@@ -73,6 +82,9 @@ static void dvic_disconne

[PATCH v2 02/15] drm: omapdrm: Use unsigned int type

[Laurent Pinchart]

The kernel favours 'unsigned int' over plain 'unsigned'. Replace all
occurences of the latter by the former. This avoid lots of checkpatch
complaints in patches that touch lines where a plain 'unsigned' is used.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|  8 +-
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|  6 +-
 drivers/gpu/drm/omapdrm/dss/dispc.c| 25 +++---
 drivers/gpu/drm/omapdrm/dss/dpi.c  |  2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 98 +++---
 drivers/gpu/drm/omapdrm/dss/dss.c  | 12 +--
 drivers/gpu/drm/omapdrm/dss/dss.h  | 12 +--
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|  2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   | 24 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c |  2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |  2 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  4 +-
 drivers/gpu/drm/omapdrm/dss/pll.c  |  4 +-
 14 files changed, 102 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 15399a1a666b..fb83f757b113 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -86,7 +86,7 @@ struct panel_drv_data {
struct workqueue_struct *workqueue;
 
bool ulps_enabled;
-   unsigned ulps_timeout;
+   unsigned int ulps_timeout;
struct delayed_work ulps_work;
 };
 
@@ -513,7 +513,7 @@ static ssize_t dsicm_show_ulps(struct device *dev,
 {
struct platform_device *pdev = to_platform_device(dev);
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
-   unsigned t;
+   unsigned int t;
 
mutex_lock(&ddata->lock);
t = ddata->ulps_enabled;
@@ -560,7 +560,7 @@ static ssize_t dsicm_show_ulps_timeout(struct device *dev,
 {
struct platform_device *pdev = to_platform_device(dev);
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
-   unsigned t;
+   unsigned int t;
 
mutex_lock(&ddata->lock);
t = ddata->ulps_timeout;
@@ -1064,7 +1064,7 @@ static int dsicm_memory_read(struct omap_dss_device 
*dssdev,
int r;
int first = 1;
int plen;
-   unsigned buf_used = 0;
+   unsigned int buf_used = 0;
 
if (size < w * h * 3)
return -ENOMEM;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
index 8e5bff4e5226..06d7d8362a73 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
@@ -289,7 +289,7 @@ static void enable_backlight_ctrl(struct panel_drv_data 
*ddata, int enable)
acx565akm_write(ddata, MIPID_CMD_WRITE_CTRL_DISP, (u8 *)&ctrl, 2);
 }
 
-static void set_cabc_mode(struct panel_drv_data *ddata, unsigned mode)
+static void set_cabc_mode(struct panel_drv_data *ddata, unsigned int mode)
 {
u16 cabc_ctrl;
 
@@ -303,12 +303,12 @@ static void set_cabc_mode(struct panel_drv_data *ddata, 
unsigned mode)
acx565akm_write(ddata, MIPID_CMD_WRITE_CABC, (u8 *)&cabc_ctrl, 2);
 }
 
-static unsigned get_cabc_mode(struct panel_drv_data *ddata)
+static unsigned int get_cabc_mode(struct panel_drv_data *ddata)
 {
return ddata->cabc_mode;
 }
 
-static unsigned get_hw_cabc_mode(struct panel_drv_data *ddata)
+static unsigned int get_hw_cabc_mode(struct panel_drv_data *ddata)
 {
u8 cabc_ctrl;
 
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 4e8f68efd169..86d18f2d48ba 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -969,7 +969,7 @@ static void dispc_ovl_set_pre_mult_alpha(enum omap_plane_id 
plane,
 static void dispc_ovl_setup_global_alpha(enum omap_plane_id plane,
enum omap_overlay_caps caps, u8 global_alpha)
 {
-   static const unsigned shifts[] = { 0, 8, 16, 24, };
+   static const unsigned int shifts[] = { 0, 8, 16, 24, };
int shift;
 
if ((caps & OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
@@ -1197,7 +1197,7 @@ void dispc_wb_set_channel_in(enum dss_writeback_channel 
channel)
 static void dispc_ovl_set_burst_size(enum omap_plane_id plane,
enum omap_burst_size burst_size)
 {
-   static const unsigned shifts[] = { 6, 14, 14, 14, 14, };
+   static const unsigned int shifts[] = { 6, 14, 14, 14, 14, };
int shift;
 
shift = shifts[plane];
@@ -1285,7 +1285,7 @@ static void dispc_ovl_set_vid_color_conv(enum 
omap_plane_id plane,
 static void dispc_ovl_enable_replication(enum omap_plane_id plane,
enum omap_overlay_caps caps, bool enable)
 {
- 

[PATCH v2 05/15] drm: omapdrm: displays: Remove OF node check in encoder drivers

[Laurent Pinchart]

No encoder is instantiated through platform data anymore, there is no
need to check for OF node presence.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c| 5 -
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c| 3 ---
 drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 3 ---
 3 files changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
index d523c67a3ae3..b424db11c6d5 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-opa362.c
@@ -179,11 +179,6 @@ static int opa362_probe(struct platform_device *pdev)
 
dev_dbg(&pdev->dev, "probe\n");
 
-   if (node == NULL) {
-   dev_err(&pdev->dev, "Unable to find device tree\n");
-   return -EINVAL;
-   }
-
ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
index e01ab3db6d86..e0bc625a5f3a 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c
@@ -201,9 +201,6 @@ static int tfp410_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, ddata);
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
r = tfp410_probe_of(pdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 1fd493e5fa3d..fb8f9ce7e5c2 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -299,9 +299,6 @@ static int tpd_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, ddata);
 
-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
r = tpd_probe_of(pdev);
if (r)
return r;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 00/15] omapdrm: Miscellaneous fixes and cleanups

[Laurent Pinchart]

Hello,

Most of this series has previously been posted as part of "[PATCH 00/48]
omapdrm: Merge omapdrm and omapdss". I've decided to split out the
miscellaneous fixes and cleanups as they are (in my opinion) ready for
upstream.

Patch 10/15 and 11/15 are new and trivial. Patch 12/15 is new as well
and worth being noted as it's more complex. Please see its commit
message for more details.

Tomi, I have a large number of other patches that have been developed on
top of this series. As I think this is ready for upstream I would rather
avoid rebasing them (there are multiple conflicts that, albeit minor,
are always annoying). Could you consider taking this in your tree ?

Laurent Pinchart (15):
  drm: omapdrm: Use kernel integer types
  drm: omapdrm: Use unsigned int type
  drm: omapdrm: connector-analog-tv: Remove tvc_of_match forward
declaration
  drm: omapdrm: displays: Remove OF node check in connector drivers
  drm: omapdrm: displays: Remove OF node check in encoder drivers
  drm: omapdrm: displays: Remove OF node check in panel drivers
  drm: omapdrm: displays: Get connector source at connect time
  drm: omapdrm: displays: Get panel source at connect time
  drm: omapdrm: displays: Get encoder source at connect time
  drm: omapdrm: dss: Make omapdss_default_get_timings static
  drm: omapdrm: dss: Don't export functions internal to omapdss-base
  drm: omapdrm: dss: Move initialization code from component bind to
probe
  drm: omapdrm: dss: Remove dss_get_hdmi_venc_clk_source() function
  drm: omapdrm: dss: Remove unused functions prototypes
  drm: omapdrm: dsi: Make wait_for_bit_change() return a status

 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |  50 ++---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |  34 ++--
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  |  40 ++--
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  |  40 ++--
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  |  39 ++--
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   |  69 +++
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   |  38 ++--
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|  38 ++--
 .../omapdrm/displays/panel-lgphilips-lb035q02.c|  38 ++--
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c|  42 ++--
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |  38 ++--
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|  35 ++--
 .../drm/omapdrm/displays/panel-tpo-td028ttec1.c|  49 ++---
 .../drm/omapdrm/displays/panel-tpo-td043mtea1.c|  32 ++-
 drivers/gpu/drm/omapdrm/dss/dispc.c|  25 ++-
 drivers/gpu/drm/omapdrm/dss/display.c  |   5 +-
 drivers/gpu/drm/omapdrm/dss/dpi.c  |   2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 129 ++--
 drivers/gpu/drm/omapdrm/dss/dss-of.c   |   2 -
 drivers/gpu/drm/omapdrm/dss/dss.c  | 219 +++--
 drivers/gpu/drm/omapdrm/dss/dss.h  |  14 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c   |  24 +--
 drivers/gpu/drm/omapdrm/dss/hdmi_phy.c |   2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c  |   2 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |   7 +-
 drivers/gpu/drm/omapdrm/dss/output.c   |   1 -
 drivers/gpu/drm/omapdrm/dss/pll.c  |   4 +-
 drivers/gpu/drm/omapdrm/omap_crtc.c|  12 +-
 drivers/gpu/drm/omapdrm/omap_crtc.h|   2 +-
 drivers/gpu/drm/omapdrm/omap_dmm_priv.h|  10 +-
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |  46 ++---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.h   |  22 +--
 drivers/gpu/drm/omapdrm/omap_drv.h |   4 +-
 drivers/gpu/drm/omapdrm/omap_fb.c  |  18 +-
 drivers/gpu/drm/omapdrm/omap_gem.c |  41 ++--
 drivers/gpu/drm/omapdrm/omap_gem.h |  16 +-
 drivers/gpu/drm/omapdrm/omap_irq.c |   6 +-
 drivers/gpu/drm/omapdrm/omap_irq.h |   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c   |   4 +-
 drivers/gpu/drm/omapdrm/tcm-sita.c |  12 +-
 drivers/gpu/drm/omapdrm/tcm.h  |   4 +-
 43 files changed, 543 insertions(+), 678 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 01/15] drm: omapdrm: Use kernel integer types

[Laurent Pinchart]

The standard kernel integer types are [us]{8,16,32}. Use them instead of
the u?int{8,16,32}_t types.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 12 -
 drivers/gpu/drm/omapdrm/omap_crtc.h  |  2 +-
 drivers/gpu/drm/omapdrm/omap_dmm_priv.h  | 10 +++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 46 
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.h | 22 +++
 drivers/gpu/drm/omapdrm/omap_drv.h   |  4 +--
 drivers/gpu/drm/omapdrm/omap_fb.c| 18 ++---
 drivers/gpu/drm/omapdrm/omap_gem.c   | 41 +++-
 drivers/gpu/drm/omapdrm/omap_gem.h   | 16 +--
 drivers/gpu/drm/omapdrm/omap_irq.c   |  6 ++---
 drivers/gpu/drm/omapdrm/omap_irq.h   |  2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c |  4 +--
 drivers/gpu/drm/omapdrm/tcm-sita.c   | 12 -
 drivers/gpu/drm/omapdrm/tcm.h|  4 +--
 14 files changed, 101 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 1b8154e58d18..95615a86e9f7 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -272,7 +272,7 @@ static const struct dss_mgr_ops mgr_ops = {
  * Setup, Flush and Page Flip
  */
 
-void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+void omap_crtc_error_irq(struct drm_crtc *crtc, u32 irqstatus)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
 
@@ -492,7 +492,7 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_plane_state *pri_state;
 
if (state->color_mgmt_changed && state->gamma_lut) {
-   uint length = state->gamma_lut->length /
+   unsigned int length = state->gamma_lut->length /
sizeof(struct drm_color_lut);
 
if (length < 2)
@@ -526,7 +526,7 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
 
if (crtc->state->color_mgmt_changed) {
struct drm_color_lut *lut = NULL;
-   uint length = 0;
+   unsigned int length = 0;
 
if (crtc->state->gamma_lut) {
lut = (struct drm_color_lut *)
@@ -557,7 +557,7 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
 static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
 struct drm_crtc_state *state,
 struct drm_property *property,
-uint64_t val)
+u64 val)
 {
struct omap_drm_private *priv = crtc->dev->dev_private;
struct drm_plane_state *plane_state;
@@ -585,7 +585,7 @@ static int omap_crtc_atomic_set_property(struct drm_crtc 
*crtc,
 static int omap_crtc_atomic_get_property(struct drm_crtc *crtc,
 const struct drm_crtc_state *state,
 struct drm_property *property,
-uint64_t *val)
+u64 *val)
 {
struct omap_drm_private *priv = crtc->dev->dev_private;
struct omap_crtc_state *omap_state = to_omap_crtc_state(state);
@@ -732,7 +732,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
 * gamma table is not supprted.
 */
if (priv->dispc_ops->mgr_gamma_size(channel)) {
-   uint gamma_lut_size = 256;
+   unsigned int gamma_lut_size = 256;
 
drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h 
b/drivers/gpu/drm/omapdrm/omap_crtc.h
index ad7b007c6174..7f01e730a050 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.h
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
@@ -37,7 +37,7 @@ void omap_crtc_pre_uninit(void);
 struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, struct omap_dss_device *dssdev);
 int omap_crtc_wait_pending(struct drm_crtc *crtc);
-void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus);
+void omap_crtc_error_irq(struct drm_crtc *crtc, u32 irqstatus);
 void omap_crtc_vblank_irq(struct drm_crtc *crtc);
 
 #endif /* __OMAPDRM_CRTC_H__ */
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h 
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index 600064d5c25b..c2785cc98dc9 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -102,10 +102,10 @@ struct pat_ctrl {
 };
 
 struct pat {
-   uint32_t next_pa;
+   u32 next_pa;
struct pat_area area;
struct pat_ctrl ctrl;
-   uint32_t data_pa;
+   u32 data_pa;
 };
 
 #define DMM_FIXED_RETRY_COUNT 1000
@@ -129,7 +129,7 @@ struct dmm_txn {
void *engine_handle;
struc

Re: [PATCH 3/3] drm/pl111: Use max memory bandwidth for resolution

[Linus Walleij]

On Sat, Feb 10, 2018 at 6:14 PM, Eric Anholt  wrote:
> Linus Walleij  writes:

>> +static enum drm_mode_status
>> +pl111_mode_valid(struct drm_crtc *crtc,
>> +  const struct drm_display_mode *mode)
>> +{
>> + struct drm_device *drm = crtc->dev;
>> + struct pl111_drm_dev_private *priv = drm->dev_private;
>> + u32 cpp = priv->variant->fb_bpp / 8;
>> + u64 bw;
>
> Using the variant->fb_bpp for mode_valid checks here feels wrong to me
> -- it means a larger mode wouldn't be considered valid on a
> 32bpp-preferred platform when 16bpp would make it work, and a 16bpp
> platform will happily try to set a 32bpp mode that exceeds the
> bandwidth.

Yeah. So I have an additional patch (that I will send out with the
rest of the v2 patches) that actually go in and set ->fb_bpp to
16 on the RealViews to get some nice 1024x768 on these.

The other mode_valid() checks I've seen (well, OMAPDRM)
just assume 32bpp and goes on. I guess it is saved by not
supporting anything else.

> On the other hand, if it makes things work most of the time I'm also
> kind of OK with it.  Anyone else want to chime in here?

This makes things work but can be improved upon.

The core of the problem is that resolution is CRTC business
and seen as something limited by the monitor or
bridge/connector or so, then it calls this hook into the driver to
check that it can provide what the monitor/bridge/connector
suggests.

And then we have the opportunity to say we can't do such or
such resolution.

The pixel format on the other hand is seen as a display hardware
thing, so if I had an API here to call back into the driver and
restrict the formats to say 16bpp, I could confirm better
resolutions.

We can put that in place later and remove the ->fb_bpp if we
can chisel out the right API to set the pixel format.

I am working on another patch to set the preferred pixel format
instead of BPP when intiializing the framebuffer, so I will
investigate this at the same time, but I'd really like to build
on top of this code to avoid too many variables.

> Maybe DRM_DEBUG_KMS for these?

OK I fix :)

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105042] [LLVM Regression] Shadow of Mordor stucks at intro video

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105042

Bug ID: 105042
   Summary: [LLVM Regression] Shadow of Mordor stucks at intro
video
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gr.mue...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137268
  --> https://bugs.freedesktop.org/attachment.cgi?id=137268&action=edit
game crash dump

The last thing you see is the WB Games logo. The music still plays but it
doesnt get any further, so you cant see the main menu. The CPU is getting 100%
load, seems to be stuck in an endless loop. 
In the console you only see this:
Game crashed, if possible email [supp...@feralinteractive.com] with the crash
file.
A dmp file is created and attached here.

The problem seems to be with LLVM, last good for me is 324167 first bad 324807.

-- 
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] drm/panel: Fix ARM Versatile panel clocks

[Linus Walleij]

On Thu, Feb 8, 2018 at 11:50 AM, Eric Anholt  wrote:

>> - .clock = 62500,
>> + .clock = 625000,
>
> 625000kHz still seems really suspicious.

Right, an order of magnitude typo on my part :(
It is even correct in the fbdev driver.

I sent a v2 fixing it.

>  The fbdev driver does:
>
> clk_set_rate(fb->clk, (10 / regs.pixclock) * 1000);
>
> which seems really strange to me -- set the clock rate lower as pixclock
> increases?  What's going on here?

That is regs.pixclock from struct clcd_regs in ,
i.e. the register value of the pixel clock, not the mode info.
So it makes sense: calculates the frequency in Hz and set that
to the clock (the AUX oscillator, as this driver is not even making
use of the clock divider).

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/panel: Fix ARM Versatile panel clocks

[Linus Walleij]

These clocks are in kHz not in Hz, oops. Fix it so my
new bandwidth calculations patch starts working with these
panels.

Cc: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- The Epson clock was still wrong, off by one order of
  magnitude. It is now fixed. The only source of the actual
  frequency to use is the old fbdev driver, as there is no
  datasheet for this Epson panel that I can find, and it is
  set to 62500 kHz.
---
 drivers/gpu/drm/panel/panel-arm-versatile.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c 
b/drivers/gpu/drm/panel/panel-arm-versatile.c
index 3930b4925b15..b428c4678106 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -132,7 +132,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 79,
.height_mm = 54,
.mode = {
-   .clock = 1000,
+   .clock = 1,
.hdisplay = 320,
.hsync_start = 320 + 6,
.hsync_end = 320 + 6 + 6,
@@ -156,7 +156,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 171,
.height_mm = 130,
.mode = {
-   .clock = 2500,
+   .clock = 25000,
.hdisplay = 640,
.hsync_start = 640 + 24,
.hsync_end = 640 + 24 + 96,
@@ -179,7 +179,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 34,
.height_mm = 45,
.mode = {
-   .clock = 62500,
+   .clock = 62500,
.hdisplay = 176,
.hsync_start = 176 + 2,
.hsync_end = 176 + 2 + 3,
@@ -203,7 +203,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 37,
.height_mm = 50,
.mode = {
-   .clock = 540,
+   .clock = 5400,
.hdisplay = 240,
.hsync_start = 240 + 10,
.hsync_end = 240 + 10 + 10,
-- 
2.14.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103736] Sudden system freezes, GPU fault detected

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103736

--- Comment #8 from Lennart Sauerbeck  ---
I was able to record an ApiTrace which shows the problem consistently. However,
it's 2.5 gigabytes and contains personal information I'd rather not share on a
public bugtracker -- I think a trace can only be truncated, removing stuff from
the beginning messes up the OpenGL context?

I cannot switch to the virtual console when the freeze is triggered.

I also built radeonsi from current Mesa git
(9b9a89cd795fda462a6ee898ef6e5135ca79d94e) but the problem persisted.

-- 
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 v3] drm/vc4: Expose performance counters to userspace

[Eric Anholt]

Boris Brezillon  writes:

> The V3D engine has various hardware counters which might be interesting
> to userspace performance analysis tools.
>
> Expose new ioctls to create/destroy a performance monitor object and
> query the counter values of this perfmance monitor.
>
> Note that a perfomance monitor is given an ID that is only valid on the
> file descriptor it has been allocated from. A performance monitor can be
> attached to a CL submission and the driver will enable HW counters for
> this request and update the performance monitor values at the end of the
> job.
>
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Eric Anholt 

Pushed.  Thanks!


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Print the pid when debug logging an ioctl error.

[Eric Anholt]

Daniel Vetter  writes:

> On Tue, Jan 30, 2018 at 01:56:43PM -0800, Eric Anholt wrote:
>> When we debug print what ioctl we're calling into, we include the pid.
>> If you have multiple processes rendering simulataneously, the error
>> return also needs the pid so you can see which of the ioctl calls was
>> the one to fail.
>> 
>> Signed-off-by: Eric Anholt 
>
> Reviewed-by: Daniel Vetter 

Pushed.  Thanks!


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104082

--- Comment #29 from Christian König  ---
(In reply to Matthew Scheirer from comment #27)
> I do still get the swiotlib OOM errors without DC enabled, but they are
> fairly infrequent and don't panic crash the kernel. With DC enabled,
> swiotlib OOM messages happen much more often coinciding with crashes.

Thanks and yeah that only means that DC releases the memory later than the
classic code path.

So actually not DC related.

-- 
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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104082

Christian König  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #28 from Christian König  ---
Ok setting this as fixed which hopefully makes people stop adding new comments
to this bug report.

-- 
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 105030] `radeon_ib_ring_tests()` takes 1.5 s during resume

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105030

Christian König  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #1 from Christian König  ---
You could bisect, but I would say in general that is desired behavior.

We must make sure that the hardware is correctly powered up before continuing
here.

-- 
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 5/5] drm/amdgpu: Fix deadlock on runtime suspend

[Lukas Wunner]

amdgpu's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.

The output poll worker meanwhile calls pm_runtime_get_sync() in
amdgpu's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.

Fix by not acquiring a runtime PM ref if the ->detect hooks are called
in the output poll worker's context.  This is safe because the poll
worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.

Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Cc: sta...@vger.kernel.org # v4.2+: 1234567890ab: workqueue: Allow retrieval of 
current task's work struct
Cc: sta...@vger.kernel.org # v4.2+: 1234567890ab: drm: Allow determining if 
current task is output poll worker
Cc: Alex Deucher 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +-
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 8ca3783f2deb..74d2efaec52f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -736,9 +736,11 @@ amdgpu_connector_lvds_detect(struct drm_connector 
*connector, bool force)
enum drm_connector_status ret = connector_status_disconnected;
int r;
 
-   r = pm_runtime_get_sync(connector->dev->dev);
-   if (r < 0)
-   return connector_status_disconnected;
+   if (!drm_kms_helper_is_poll_worker()) {
+   r = pm_runtime_get_sync(connector->dev->dev);
+   if (r < 0)
+   return connector_status_disconnected;
+   }
 
if (encoder) {
struct amdgpu_encoder *amdgpu_encoder = 
to_amdgpu_encoder(encoder);
@@ -757,8 +759,12 @@ amdgpu_connector_lvds_detect(struct drm_connector 
*connector, bool force)
/* check acpi lid status ??? */
 
amdgpu_connector_update_scratch_regs(connector, ret);
-   pm_runtime_mark_last_busy(connector->dev->dev);
-   pm_runtime_put_autosuspend(connector->dev->dev);
+
+   if (!drm_kms_helper_is_poll_worker()) {
+   pm_runtime_mark_last_busy(connector->dev->dev);
+   pm_runtime_put_autosuspend(connector->dev->dev);
+   }
+
return ret;
 }
 
@@ -868,9 +874,11 @@ amdgpu_connector_vga_detect(struct drm_connector 
*connector, bool force)
enum drm_connector_status ret = connector_status_disconnected;
int r;
 
-   r = pm_runtime_get_sync(connector->dev->dev);
-   if (r < 0)
-   return connector_status_disconnected;
+   if (!drm_kms_helper_is_poll_worker()) {
+   r = pm_runtime_get_sync(connector->dev->dev);
+   if (r < 0)
+   return connector_status_disconnected;
+   }
 
encoder = amdgpu_connector_best_single_encoder(connector);
if (!encoder)
@@ -924,8 +932,10 @@ amdgpu_connector_vga_detect(struct drm_connector 
*connector, bool force)
amdgpu_connector_update_scratch_regs(connector, ret);
 
 out:
-   pm_runtime_mark_last_busy(connector->dev->dev);
-   pm_runtime_put_autosuspend(connector->dev->dev);
+   if (!drm_kms_helper_is_poll_worker()) {
+   pm_runtime_mark_last_busy(connector->dev->dev);
+   pm_runtime_put_autosuspend(connector->dev->dev);
+   }
 
return ret;
 }
@@ -988,9 +998,11 @@ amdgpu_connector_dvi_detect(struct drm_connector 
*connector, bool force)
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false, broken_edid = false;
 
-   r = pm_runtime_get_sync(connector->dev->dev);
-   if (r < 0)
-   return connector_status_disconnected;
+   if (!drm_kms_helper_is_poll_worker()) {
+   r = pm_runtime_get_sync(connector->dev->dev);
+   if (r < 0)
+   return connector_status_disconnected;
+   }
 
if (!force && amdgpu_connector_check_hpd_status_unchanged(connector)) {
ret = connector->status;
@@ -1115,8 +1127,10 @@ amdgpu_connector_dvi_detect(struct drm_connector 
*connector, bool force)
amdgpu_connector_update_scratch_regs(connector, ret);
 
 exit:
-   pm_runtime_mark_last_busy(connector->dev->dev);
-   pm_runtime_put_autosuspend(connector->dev->dev);
+   if (!drm_kms_helper_is_poll_worker()) {
+   pm_runtime_mark_last_busy(connector->dev->dev);
+   pm_runtime_put_autosuspend(connector->dev->dev);
+   }
 
return ret;
 }
@@ -1359,9 +1373,11 @@ amdgpu_connector_dp_detect(struct drm_connector 
*connector, bool force)
struct drm_encoder *encoder = 
amdgpu_connector_best_single_encoder(connector);
int r;
 
-   r = pm_runtime_get_sync(connector->dev->dev);
-   if (r < 0)
-   return connector_status_discon

[PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

Fix a deadlock on hybrid graphics laptops that's been present since 2013:

DRM drivers poll connectors in 10 sec intervals.  The poll worker is
stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
the poll worker invokes the DRM drivers' ->detect callbacks, which call
pm_runtime_get_sync().  If the poll worker starts after runtime suspend
has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
with the intention of runtime resuming the device afterwards.  The result
is a circular wait between poll worker and autosuspend worker.

I'm seeing this deadlock so often it's not funny anymore. I've also found
3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
[4/5].)

One theoretical solution would be to add a flag to the ->detect callback
to tell it that it's running in the poll worker's context.  In that case
it doesn't need to call pm_runtime_get_sync() because the poll worker is
only enabled while runtime active and we know that ->runtime_suspend
waits for it to finish.  But this approach would require touching every
single DRM driver's ->detect hook.  Moreover the ->detect hook is called
from numerous other places, both in the DRM library as well as in each
driver, making it necessary to trace every possible call chain and check
if it's coming from the poll worker or not.  I've tried to do that for
nouveau (see the call sites listed in the commit message of patch [3/5])
and concluded that this approach is a nightmare to implement.

Another reason for the infeasibility of this approach is that ->detect
is called from within the DRM library without driver involvement, e.g.
via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
have to be called by the DRM library, but the DRM library is supposed to
stay generic, wheras runtime PM is driver-specific.

So instead, I've come up with this much simpler solution which gleans
from the current task's flags if it's a workqueue worker, retrieves the
work_struct and checks if it's the poll worker.  All that's needed is
one small helper in the workqueue code and another small helper in the
DRM library.  This solution lends itself nicely to stable-backporting.

The patches for radeon and amdgpu are compile-tested only, I only have a
MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
"msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
This ensures that the poll worker runs after ->runtime_suspend has begun.
Wait 12 sec after the GPU has begun runtime suspend, then check
/sys/bus/pci/devices/:01:00.0/power/runtime_status.  Without this
series, the status will be stuck at "suspending" and you'll get hung task
errors in dmesg after a few minutes.

i915, malidp and msm "solved" this issue by not stopping the poll worker
on runtime suspend.  But this results in the GPU bouncing back and forth
between D0 and D3 continuously.  That's a total no-go for GPUs which
runtime suspend to D3cold since every suspend/resume cycle costs a
significant amount of time and energy.  (i915 and malidp do not seem
to acquire a runtime PM ref in the ->detect callbacks, which seems
questionable.  msm however does and would also deadlock if it disabled
the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

Please review.  Thanks,

Lukas

Lukas Wunner (5):
  workqueue: Allow retrieval of current task's work struct
  drm: Allow determining if current task is output poll worker
  drm/nouveau: Fix deadlock on runtime suspend
  drm/radeon: Fix deadlock on runtime suspend
  drm/amdgpu: Fix deadlock on runtime suspend

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +---
 drivers/gpu/drm/drm_probe_helper.c | 14 +
 drivers/gpu/drm/nouveau/nouveau_connector.c| 18 +--
 drivers/gpu/drm/radeon/radeon_connectors.c | 74 +-
 include/drm/drm_crtc_helper.h  |  1 +
 include/linux/workqueue.h  |  1 +
 kernel/workqueue.c | 16 ++
 7 files changed, 132 insertions(+), 50 deletions(-)

-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/5] workqueue: Allow retrieval of current task's work struct

[Lukas Wunner]

Introduce a helper to retrieve the current task's work struct if it is
a workqueue worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for a specific worker to
finish and that worker in turn calls a function which waits for runtime
suspend to finish.  That function is invoked from multiple call sites
and waiting for runtime suspend to finish is the correct thing to do
except if it's executing in the context of the worker.

Cc: Tejun Heo 
Cc: Lai Jiangshan 
Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Alex Deucher 
Signed-off-by: Lukas Wunner 
---
 include/linux/workqueue.h |  1 +
 kernel/workqueue.c| 16 
 2 files changed, 17 insertions(+)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 4a54ef96aff5..bc0cda180c8b 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -465,6 +465,7 @@ extern bool cancel_delayed_work_sync(struct delayed_work 
*dwork);
 
 extern void workqueue_set_max_active(struct workqueue_struct *wq,
 int max_active);
+extern struct work_struct *current_work(void);
 extern bool current_is_workqueue_rescuer(void);
 extern bool workqueue_congested(int cpu, struct workqueue_struct *wq);
 extern unsigned int work_busy(struct work_struct *work);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 017044c26233..bb9a519cbf50 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4179,6 +4179,22 @@ void workqueue_set_max_active(struct workqueue_struct 
*wq, int max_active)
 }
 EXPORT_SYMBOL_GPL(workqueue_set_max_active);
 
+/**
+ * current_work - retrieve %current task's work struct
+ *
+ * Determine if %current task is a workqueue worker and what it's working on.
+ * Useful to find out the context that the %current task is running in.
+ *
+ * Return: work struct if %current task is a workqueue worker, %NULL otherwise.
+ */
+struct work_struct *current_work(void)
+{
+   struct worker *worker = current_wq_worker();
+
+   return worker ? worker->current_work : NULL;
+}
+EXPORT_SYMBOL(current_work);
+
 /**
  * current_is_workqueue_rescuer - is %current workqueue rescuer?
  *
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

Introduce a helper to determine if the current task is an output poll
worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish.  The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Alex Deucher 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/drm_probe_helper.c | 14 ++
 include/drm/drm_crtc_helper.h  |  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe54d6e2..019881d15ce1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct *work)
schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
+/**
+ * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
+ *
+ * Determine if %current task is an output poll worker.  This can be used
+ * to select distinct code paths for output polling versus other contexts.
+ */
+bool drm_kms_helper_is_poll_worker(void)
+{
+   struct work_struct *work = current_work();
+
+   return work && work->func == output_poll_execute;
+}
+EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
+
 /**
  * drm_kms_helper_poll_disable - disable output polling
  * @dev: drm_device
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 76e237bd989b..6914633037a5 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
 
 void drm_kms_helper_poll_disable(struct drm_device *dev);
 void drm_kms_helper_poll_enable(struct drm_device *dev);
+bool drm_kms_helper_is_poll_worker(void);
 
 #endif
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/radeon: Fix deadlock on runtime suspend

[Lukas Wunner]

radeon's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.

The output poll worker meanwhile calls pm_runtime_get_sync() in
radeon's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.

Fix by not acquiring a runtime PM ref if the ->detect hooks are called
in the output poll worker's context.  This is safe because the poll
worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.

Stack trace for posterity:

  INFO: task kworker/0:3:31847 blocked for more than 120 seconds
  Workqueue: events output_poll_execute [drm_kms_helper]
  Call Trace:
   schedule+0x3c/0x90
   rpm_resume+0x1e2/0x690
   __pm_runtime_resume+0x3f/0x60
   radeon_lvds_detect+0x39/0xf0 [radeon]
   output_poll_execute+0xda/0x1e0 [drm_kms_helper]
   process_one_work+0x14b/0x440
   worker_thread+0x48/0x4a0

  INFO: task kworker/2:0:10493 blocked for more than 120 seconds.
  Workqueue: pm pm_runtime_work
  Call Trace:
   schedule+0x3c/0x90
   schedule_timeout+0x1b3/0x240
   wait_for_common+0xc2/0x180
   wait_for_completion+0x1d/0x20
   flush_work+0xfc/0x1a0
   __cancel_work_timer+0xa5/0x1d0
   cancel_delayed_work_sync+0x13/0x20
   drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper]
   radeon_pmops_runtime_suspend+0x3d/0xa0 [radeon]
   pci_pm_runtime_suspend+0x61/0x1a0
   vga_switcheroo_runtime_suspend+0x21/0x70
   __rpm_callback+0x32/0x70
   rpm_callback+0x24/0x80
   rpm_suspend+0x12b/0x640
   pm_runtime_work+0x6f/0xb0
   process_one_work+0x14b/0x440
   worker_thread+0x48/0x4a0

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94147
Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)")
Cc: sta...@vger.kernel.org # v3.13+: 1234567890ab: workqueue: Allow retrieval 
of current task's work struct
Cc: sta...@vger.kernel.org # v3.13+: 1234567890ab: drm: Allow determining if 
current task is output poll worker
Cc: Ismo Toijala 
Cc: Alex Deucher 
Cc: Dave Airlie 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 74 --
 1 file changed, 49 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5012f5e47a1e..2e2ca3c6b47d 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -899,9 +899,11 @@ radeon_lvds_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status ret = connector_status_disconnected;
int r;
 
-   r = pm_runtime_get_sync(connector->dev->dev);
-   if (r < 0)
-   return connector_status_disconnected;
+   if (!drm_kms_helper_is_poll_worker()) {
+   r = pm_runtime_get_sync(connector->dev->dev);
+   if (r < 0)
+   return connector_status_disconnected;
+   }
 
if (encoder) {
struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(encoder);
@@ -924,8 +926,12 @@ radeon_lvds_detect(struct drm_connector *connector, bool 
force)
/* check acpi lid status ??? */
 
radeon_connector_update_scratch_regs(connector, ret);
-   pm_runtime_mark_last_busy(connector->dev->dev);
-   pm_runtime_put_autosuspend(connector->dev->dev);
+
+   if (!drm_kms_helper_is_poll_worker()) {
+   pm_runtime_mark_last_busy(connector->dev->dev);
+   pm_runtime_put_autosuspend(connector->dev->dev);
+   }
+
return ret;
 }
 
@@ -1039,9 +1045,11 @@ radeon_vga_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status ret = connector_status_disconnected;
int r;
 
-   r = pm_runtime_get_sync(connector->dev->dev);
-   if (r < 0)
-   return connector_status_disconnected;
+   if (!drm_kms_helper_is_poll_worker()) {
+   r = pm_runtime_get_sync(connector->dev->dev);
+   if (r < 0)
+   return connector_status_disconnected;
+   }
 
encoder = radeon_best_single_encoder(connector);
if (!encoder)
@@ -1108,8 +1116,10 @@ radeon_vga_detect(struct drm_connector *connector, bool 
force)
radeon_connector_update_scratch_regs(connector, ret);
 
 out:
-   pm_runtime_mark_last_busy(connector->dev->dev);
-   pm_runtime_put_autosuspend(connector->dev->dev);
+   if (!drm_kms_helper_is_poll_worker()) {
+   pm_runtime_mark_last_busy(connector->dev->dev);
+   pm_runtime_put_autosuspend(connector->dev->dev);
+   }
 
return ret;
 }
@@ -1173,9 +1183,11 @@ radeon_tv_detect(struct drm_connector *connector, bool 
force)
if (!radeon_connector->dac_load_detect)
return ret;
 
-   r = pm_runtime_get_sync(connector->dev->dev);
-   if (r < 0)
-   return connector_status_disconnected;
+   if (!drm_kms_helper_is_poll_worker()) {
+   r = p

[PATCH 3/5] drm/nouveau: Fix deadlock on runtime suspend

[Lukas Wunner]

nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.

The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.

Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context.  This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.

Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:

  status_store() drm sysfs interface
  ->fill_modes drm callback
  drm_fb_helper_probe_connector_modes()
  drm_mode_getconnector()
  nouveau_connector_hotplug()
  nouveau_display_hpd_work()
  nv17_tv_set_property()

Stack trace for posterity:

  INFO: task kworker/0:1:58 blocked for more than 120 seconds.
  Workqueue: events output_poll_execute [drm_kms_helper]
  Call Trace:
   schedule+0x28/0x80
   rpm_resume+0x107/0x6e0
   __pm_runtime_resume+0x47/0x70
   nouveau_connector_detect+0x7e/0x4a0 [nouveau]
   nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
   drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
   output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
   process_one_work+0x184/0x380
   worker_thread+0x2e/0x390

  INFO: task kworker/0:2:252 blocked for more than 120 seconds.
  Workqueue: pm pm_runtime_work
  Call Trace:
   schedule+0x28/0x80
   schedule_timeout+0x1e3/0x370
   wait_for_completion+0x123/0x190
   flush_work+0x142/0x1c0
   nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
   pci_pm_runtime_suspend+0x5c/0x180
   vga_switcheroo_runtime_suspend+0x1e/0xa0
   __rpm_callback+0xc1/0x200
   rpm_callback+0x1f/0x70
   rpm_suspend+0x13c/0x640
   pm_runtime_work+0x6e/0x90
   process_one_work+0x184/0x380
   worker_thread+0x2e/0x390

Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: sta...@vger.kernel.org # v3.12+: 1234567890ab: workqueue: Allow retrieval 
of current task's work struct
Cc: sta...@vger.kernel.org # v3.12+: 1234567890ab: drm: Allow determining if 
current task is output poll worker
Cc: Ben Skeggs 
Cc: Dave Airlie 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 69d6e61a01ec..6ed9cb053dfa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -570,9 +570,15 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
nv_connector->edid = NULL;
}
 
-   ret = pm_runtime_get_sync(connector->dev->dev);
-   if (ret < 0 && ret != -EACCES)
-   return conn_status;
+   /* Outputs are only polled while runtime active, so acquiring a
+* runtime PM ref here is unnecessary (and would deadlock upon
+* runtime suspend because it waits for polling to finish).
+*/
+   if (!drm_kms_helper_is_poll_worker()) {
+   ret = pm_runtime_get_sync(connector->dev->dev);
+   if (ret < 0 && ret != -EACCES)
+   return conn_status;
+   }
 
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -647,8 +653,10 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
 
  out:
 
-   pm_runtime_mark_last_busy(connector->dev->dev);
-   pm_runtime_put_autosuspend(connector->dev->dev);
+   if (!drm_kms_helper_is_poll_worker()) {
+   pm_runtime_mark_last_busy(connector->dev->dev);
+   pm_runtime_put_autosuspend(connector->dev->dev);
+   }
 
return conn_status;
 }
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel