[PATCH] drm/amd/powerplay: fix memory leak on tdp_table

[Colin King]

From: Colin Ian King 

tdp_table is being leaked on an error exit return path,
fix this by kfree'ing it.  Also swap comparison around to make the
patch warning free with checkpatch.

Leak found via static analysis with CoverityScan

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_processpptables.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_processpptables.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_processpptables.c
index 34f4bef..40b7679 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_processpptables.c
@@ -512,8 +512,10 @@ static int get_cac_tdp_table(

hwmgr->dyn_state.cac_dtp_table = kzalloc(table_size, GFP_KERNEL);

-   if (NULL == hwmgr->dyn_state.cac_dtp_table)
+   if (hwmgr->dyn_state.cac_dtp_table == NULL) {
+   kfree(tdp_table);
return -ENOMEM;
+   }

memset(hwmgr->dyn_state.cac_dtp_table, 0x00, table_size);

-- 
2.7.3

[Bug 94623] [AMDGPU][CIK][bisected] drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Shawn Starr  ---
Patch indeed fixes it, please request review, tested by me tag.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/84470f1a/attachment-0001.html>

[PATCH v3 3/3] drm/omap: panel-dpi: implement support for a vcc regulator

[Uwe Kleine-König]

To allow supporting displays that need some logic to enable power to the
display try to get a vcc-supply property from the device tree and drive
the resulting regulator accordingly.

Reviewed-by: Tomi Valkeinen 
Signed-off-by: Uwe Kleine-König 
---
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index 201a1c1a6f42..8c3f31ebff00 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -32,6 +33,7 @@ struct panel_drv_data {
int backlight_gpio;

struct gpio_desc *enable_gpio;
+   struct regulator *vcc_supply;
 };

 #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
@@ -83,6 +85,12 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (r)
return r;

+   r = regulator_enable(ddata->vcc_supply);
+   if (r) {
+   in->ops.dpi->disable(in);
+   return r;
+   }
+
gpiod_set_value_cansleep(ddata->enable_gpio, 1);

if (gpio_is_valid(ddata->backlight_gpio))
@@ -105,6 +113,7 @@ static void panel_dpi_disable(struct omap_dss_device 
*dssdev)
gpio_set_value_cansleep(ddata->backlight_gpio, 0);

gpiod_set_value_cansleep(ddata->enable_gpio, 0);
+   regulator_disable(ddata->vcc_supply);

in->ops.dpi->disable(in);

@@ -223,6 +232,10 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
if (IS_ERR(gpio))
return PTR_ERR(gpio);

+   ddata->vcc_supply = devm_regulator_get(>dev, "vcc");
+   if (IS_ERR(ddata->vcc_supply))
+   return PTR_ERR(ddata->vcc_supply);
+
ddata->backlight_gpio = -ENOENT;

r = of_get_display_timing(node, "panel-timing", );
-- 
2.7.0

[PATCH v3 2/3] drm/omap: panel-dpi: make (limited) use of a reset gpio

[Uwe Kleine-König]

Some displays have a reset input. To assert that the display is
functional the reset gpio must be deasserted.

Teach the driver to get and drive such a gpio accordingly.

Reviewed-by: Tomi Valkeinen 
Signed-off-by: Uwe Kleine-König 
---
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index e780fd4f8b46..201a1c1a6f42 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -213,6 +213,16 @@ static int panel_dpi_probe_of(struct platform_device *pdev)

ddata->enable_gpio = gpio;

+   /*
+* Many different panels are supported by this driver and there are
+* probably very different needs for their reset pins in regards to
+* timing and order relative to the enable gpio. So for now it's just
+* ensured that the reset line isn't active.
+*/
+   gpio = devm_gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(gpio))
+   return PTR_ERR(gpio);
+
ddata->backlight_gpio = -ENOENT;

r = of_get_display_timing(node, "panel-timing", );
-- 
2.7.0

[PATCH v3 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

[Uwe Kleine-König]

Some displays have a reset input and/or need a regulator to function
properly. Allow to specify them for panel-dpi devices.

Acked-by: Rob Herring 
Reviewed-by: Tomi Valkeinen 
Signed-off-by: Uwe Kleine-König 
---
 Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
index 216c894d4f99..b52ac52757df 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
@@ -7,6 +7,8 @@ Required properties:
 Optional properties:
 - label: a symbolic name for the panel
 - enable-gpios: panel enable gpio
+- reset-gpios: GPIO to control the RESET pin
+- vcc-supply: phandle of regulator that will be used to enable power to the 
display

 Required nodes:
 - "panel-timing" containing video timings
-- 
2.7.0

[PATCH v3 0/3] drm/omap: support reset-gpios and vcc regulator

[Uwe Kleine-König]

Hello,

the only change since v2 is that the patch now applies to the driver
after it was moved to drivers/gpu/drm.

Toni liked v2, only asked to fix the path and then add his review-by
tag. That's what I did.

Best regards
Uwe

Uwe Kleine-König (3):
  devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi
  drm/omap: panel-dpi: make (limited) use of a reset gpio
  drm/omap: panel-dpi: implement support for a vcc regulator

 .../bindings/display/panel/panel-dpi.txt   |  2 ++
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   | 23 ++
 2 files changed, 25 insertions(+)

-- 
2.7.0

[PATCH] drm/amdgpu: fix regression on CIK

[Grigori Goronzy]

Fix a copy/paste error introduced by commit feebe91a, which backported
a stability fix from gfx_v8, but incorrectly forgot to dereference
into the sync_seq array, causing hangs as soon as acceleration was
used. The wait can't finish without the correct seq value.

Signed-off-by: Grigori Goronzy 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 06602df..9b1c430 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -3628,7 +3628,7 @@ static void gfx_v7_0_ring_emit_vm_flush(struct 
amdgpu_ring *ring,
unsigned vm_id, uint64_t pd_addr)
 {
int usepfp = (ring->type == AMDGPU_RING_TYPE_GFX);
-   uint32_t seq = ring->fence_drv.sync_seq;
+   uint32_t seq = ring->fence_drv.sync_seq[ring->idx];
uint64_t addr = ring->fence_drv.gpu_addr;

amdgpu_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
-- 
1.9.1

[Bug 94412] Trine 3 misrender

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Niklas 'Nille' �kerstr�m  ---
I tested this patch and it does fix the missrender.
It should be posted to mesa-dev mailing list for review.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/1146c381/attachment-0001.html>

[Bug 94623] [AMDGPU][CIK][bisected] drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Grigori Goronzy  ---
Created attachment 122466
  --> https://bugs.freedesktop.org/attachment.cgi?id=122466=edit
Possible fix

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/5745b9bf/attachment-0001.html>

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Yakir Yang]

Hi Heiko,

On 03/21/2016 07:29 PM, Heiko Stübner wrote:
> Hi Yakir,
>
> Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
>> This patch set would add the RGA direct rendering based 2d graphics
>> acceleration module.
> very cool to see that.
;)
>> This patch set is based on git repository below:
>> git://people.freedesktop.org/~airlied/linux drm-next
>> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
>>
>> And the RGA driver is based on Exynos G2D driver, it only manages the
>> command lists received from user, so user should make the command list
>> to data and registers needed by operation to use.
>>
>> I have prepared an userspace demo application for testing:
>>  https://github.com/yakir-Yang/libdrm-rockchip
>> That is a rockchip libdrm library, and I have write a simple test case
>> "rockchip_rga_test" that would test the below RGA features:
>> - solid
>> - copy
>> - rotation
>> - flip
>> - window clip
>> - dithering
> Did you submit your libdrm changes as well?
>
> Userspace-interfaces need to be stable so the other side must also get
> accepted - even before the kernel change if I remember correctly.

Got it, and I just saw exynos_fimg2d already landed at mainline libdrm. 
But I don't find the way to submit patches to libdrm, would you like 
share some helps here ;)

- Yakir

>
> Heiko
>
>
>

[PATCH v13 06/14] drm/mediatek: Add HDMI support

[Philipp Zabel]

Hi Daniel, Jie,

Am Mittwoch, den 09.03.2016, 21:52 +0800 schrieb Daniel Kurtz:
> Hi Philipp & Jie,
> 
> Sorry I only now had a chance to dig deeper and review the HDMI driver.

I wish you had had a chance to do this earlier, But better now than
after the merge. I'll split the HDMI patches from the others in the next
round.

> Lots of comments inline below...
>
> On Tue, Mar 8, 2016 at 9:27 PM, Philipp Zabel  
> wrote:
[...]
> > diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
> > b/drivers/gpu/drm/mediatek/mtk_cec.c
> > new file mode 100644
> > index 000..cba3647
> > --- /dev/null
> > +++ b/drivers/gpu/drm/mediatek/mtk_cec.c
> > +void mtk_cec_set_hpd_event(struct device *dev,
> > +  void (*hpd_event)(bool hpd, struct device *dev),
> > +  struct device *hdmi_dev)
> > +{
> > +   struct mtk_cec *cec = dev_get_drvdata(dev);
> > +
> > +   cec->hdmi_dev = hdmi_dev;
> > +   cec->hpd_event = hpd_event;
> 
> Lock this so to prevent race with the irq?

Yes.

[...]
> > +int mtk_cec_irq(struct device *dev)
> 
> AFAICT, this function is never used.

Correct, since the IRQ number is not exported to the sound drivers
anymore, I can drop it now.

[...]
> > +static void mtk_cec_htplg_irq_enable(struct mtk_cec *cec)
> > +{
> > +   mtk_cec_mask(cec, CEC_CKGEN, 0, PDN);
> > +   mtk_cec_mask(cec, CEC_CKGEN, CEC_32K_PDN, CEC_32K_PDN);
> > +   mtk_cec_mask(cec, RX_GEN_WD, HDMI_PORD_INT_32K_CLR,
> > +HDMI_PORD_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, RX_INT_32K_CLR, RX_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, HDMI_HTPLG_INT_32K_CLR,
> > +HDMI_HTPLG_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, 0, HDMI_PORD_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, 0, RX_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, 0, HDMI_HTPLG_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, 0, HDMI_PORD_INT_32K_EN);
> > +   mtk_cec_mask(cec, RX_GEN_WD, 0, RX_INT_32K_EN);
> > +   mtk_cec_mask(cec, RX_GEN_WD, 0, HDMI_HTPLG_INT_32K_EN);
> 
> This is a bit wasteful.  Can you just clear all of these bits in a single 
> write?
> (this applies to this entire file).

I think so. If there are no problems, I'll combine them into a single
update per register.

> > +
> > +   mtk_cec_mask(cec, RX_EVENT, HDMI_PORD_INT_EN, HDMI_PORD_INT_EN);
> > +   mtk_cec_mask(cec, RX_EVENT, HDMI_HTPLG_INT_EN, HDMI_HTPLG_INT_EN);
> > +}
> > +
> > +static void mtk_cec_htplg_irq_disable(struct mtk_cec *cec)
> > +{
> 
> Why does irq_enable do so much more work than irq_disable?

It also clears the interrupt status and sets the clock. I'll move the
initialization out of this function.

> > +   mtk_cec_mask(cec, RX_EVENT, 0, HDMI_PORD_INT_EN);
> > +   mtk_cec_mask(cec, RX_EVENT, 0, HDMI_HTPLG_INT_EN);
> > +}
> > +
> > +static void mtk_cec_clear_htplg_irq(struct mtk_cec *cec)
> > +{
> > +   mtk_cec_mask(cec, TR_CONFIG, CLEAR_CEC_IRQ, CLEAR_CEC_IRQ);
> > +   mtk_cec_mask(cec, NORMAL_INT_CTRL, HDMI_HTPLG_INT_CLR,
> > +HDMI_HTPLG_INT_CLR);
> > +   mtk_cec_mask(cec, NORMAL_INT_CTRL, HDMI_PORD_INT_CLR,
> > +HDMI_PORD_INT_CLR);
> > +   mtk_cec_mask(cec, NORMAL_INT_CTRL, HDMI_FULL_INT_CLR,
> > +HDMI_FULL_INT_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, HDMI_PORD_INT_32K_CLR,
> > +HDMI_PORD_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, RX_INT_32K_CLR, RX_INT_32K_CLR);
> > +   mtk_cec_mask(cec, RX_GEN_WD, HDMI_HTPLG_INT_32K_CLR,
> > +HDMI_HTPLG_INT_32K_CLR);
> > +   udelay(5);
> 
> Do you really need this delay in the middle of the isr handler?

I can turn it into an usleep_range(5, 10). Whether the delay is needed
at all or how long it really has to be, I don't know.

[...]
> > +static irqreturn_t mtk_cec_htplg_isr_thread(int irq, void *arg)
> > +{
> > +   struct device *dev = arg;
> > +   struct mtk_cec *cec = dev_get_drvdata(dev);
> > +   bool hpd;
> > +
> > +   mtk_cec_clear_htplg_irq(cec);
> > +   hpd = mtk_cec_hpd_high(dev);
> > +
> > +   if (cec->hpd != hpd) {
> > +   dev_info(dev, "hotplug event!,cur hpd = %d, hpd = %d\n",
> > +cec->hpd, hpd);
> 
> dev_dbg if anything

Ok.

[...]
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c
> > new file mode 100644
> > index 000..ff661e0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c
[...]
> > +static void mtk_hdmi_bridge_disable(struct drm_bridge *bridge)
> > +{
> > +   struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
> > +
> > +   phy_power_off(hdmi->phy);
> > +   clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PIXEL]);
> > +   clk_disable_unprepare(hdmi->clk[MTK_HDMI_CLK_HDMI_PLL]);
> 
> As far as I can tell, __drm_helper_disable_unused_functions() 

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

[Daniel Vetter]

On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
> drm_framebuffer_remove may fail with -EINTR now, so a straight revert
> is impossible. There is no way to remove the framebuffer from the lists
> and active planes without introducing a race because of the different
> locking requirements. Instead call drm_framebuffer_remove from a
> workqueue, which is unaffected by signals.
>
> Cc: stable at vger.kernel.org #v4.4+
> Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
> Testcase: kms_flip.flip-vs-rmfb-interruptible
> References: 
> https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
> Cc: Thomas Hellstrom 
> Cc: David Herrmann 
> ---
>  drivers/gpu/drm/drm_crtc.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e08f962288d9..b7d0b959f088 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
>   return 0;
>  }
>
> +struct drm_mode_rmfb_work {
> + struct work_struct work;
> + struct drm_framebuffer *fb;
> +};
> +
> +static void drm_mode_rmfb_work_fn(struct work_struct *w)
> +{
> + struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
> +
> + drm_framebuffer_remove(arg->fb);

drm_framebuffer_remove still has the problem of not working correctly with
atomic since atomic commit will complain if we try to do more than 1
commit per ww_acquire_ctx. I think we still need an atomic version of
this. Also probably a more nasty igt testcase which uses the same fb on
more than one plane to be able to hit this case.

> +}
> +
>  /**
>   * drm_mode_rmfb - remove an FB from the configuration
>   * @dev: drm device for the ioctl
> @@ -3454,6 +3466,7 @@ int drm_mode_rmfb(struct drm_device *dev,
>   struct drm_framebuffer *fbl = NULL;
>   uint32_t *id = data;
>   int found = 0;
> + struct drm_mode_rmfb_work arg;
>
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
> @@ -3474,7 +3487,12 @@ int drm_mode_rmfb(struct drm_device *dev,
>   mutex_unlock(>mode_config.fb_lock);
>   mutex_unlock(_priv->fbs_lock);
>
> - drm_framebuffer_unreference(fb);

Needs a comment here to explain that we evade EINTR/signals, and that it's
not a trick to hide a locking inversion from lockdep.

Otherwise I think this patch here is the best fix of all the approaches
discussed on irc, under the constraint that we need some obviously
save for cc: stable.
-Daniel


> + INIT_WORK_ONSTACK(, drm_mode_rmfb_work_fn);
> + arg.fb = fb;
> +
> + schedule_work();
> + flush_work();
> + destroy_work_on_stack();
>
>   return 0;
>
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

On Mon, Mar 21, 2016 at 01:26:58PM +0100, David Herrmann wrote:
> Hi
> 
> On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter  
> wrote:
> > Just a bit of wording polish plus mentioning that it can fail and must
> > be restarted.
> >
> > Requested by Sumit.
> >
> > v2: Fix them typos (Hans).
> >
> > Cc: Chris Wilson 
> > Cc: Tiago Vignatti 
> > Cc: Stéphane Marchesin 
> > Cc: David Herrmann 
> > Cc: Sumit Semwal 
> > Cc: Daniel Vetter 
> > CC: linux-media at vger.kernel.org
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: linaro-mm-sig at lists.linaro.org
> > Cc: intel-gfx at lists.freedesktop.org
> > Cc: devel at driverdev.osuosl.org
> > Cc: Hans Verkuil 
> > Acked-by: Sumit Semwal 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  Documentation/dma-buf-sharing.txt | 11 ++-
> >  drivers/dma-buf/dma-buf.c |  2 +-
> >  2 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/dma-buf-sharing.txt 
> > b/Documentation/dma-buf-sharing.txt
> > index 32ac32e773e1..ca44c5820585 100644
> > --- a/Documentation/dma-buf-sharing.txt
> > +++ b/Documentation/dma-buf-sharing.txt
> > @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 
> > 2 main use-cases:
> >
> > No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> > making
> > sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is 
> > *always*
> > -   used when the access happens. This is discussed next paragraphs.
> > +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> > +   -EAGAIN or -EINTR, in which case it must be restarted.
> 
> What is "restart on EAGAIN" supposed to mean? Or more generally, what
> does EAGAIN tell the caller?

Do what drmIoctl does essentially.

while (ret == -1 && (errno == EAGAIN || errno == EINTR)
ret = ioctl();

Typed from memery, too lazy to look it up in the source ;-) I'm trying to
sell the idea of a real dma-buf manpage to Sumit, we should clarify this
in detail there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/3] drm: introduce drm_connector_plug_all() helper

[Daniel Vetter]

On Mon, Mar 21, 2016 at 11:02:21AM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Sat, 2016-03-19 at 11:02 +0100, Daniel Vetter wrote:
> > On Fri, Mar 18, 2016 at 09:58:49PM +, Alexey Brodkin wrote:
> > > 
> > > Hi Daniel,
> > > 
> > > On Fri, 2016-03-18 at 19:06 +0100, Daniel Vetter wrote:
> > > > 
> > > > On Fri, Mar 18, 2016 at 01:01:42PM +0300, Alexey Brodkin wrote:
> > > > > 
> > > > > 
> > > > > As a pair to already existing drm_connector_unplug_all() we're adding
> > > > > generic implementation of what is already done in some drivers.
> > > > > 
> > > > > Once this helper is implemented we'll be ready to switch existing
> > > > > driver-specific implementations with generic one.
> > > > > 
> > > > > Signed-off-by: Alexey Brodkin 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: David Airlie 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_crtc.c | 44 
> > > > > +++-
> > > > >  drivers/gpu/drm/drm_drv.c  |  3 ++-
> > > > >  include/drm/drm_crtc.h     |  3 ++-
> > > > >  3 files changed, 47 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > > > index 65258ac..ce27420 100644
> > > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > @@ -1080,6 +1080,46 @@ void drm_connector_unregister(struct 
> > > > > drm_connector *connector)
> > > > >  }
> > > > >  EXPORT_SYMBOL(drm_connector_unregister);
> > > > >  
> > > > > +/**
> > > > > + * drm_connector_plug_all - register connector userspace interfaces
> > > > > + * @dev: drm device
> > > > > + *
> > > > > + * This function registers all connector userspace interfaces in 
> > > > > sysfs. Should
> > > > > + * be call when the device is disconnected, e.g. from an usb driver's
> > > > Still talks about disconnect ;-) Please also mention that this just 
> > > > calls
> > > > drm_connector_register() exactly like this including () to generate a
> > > > kerneldoc hyperlink.
> > > Well I intentionally left in description of drm_connector_register_all():
> > > "Should be call when the device is disconnected, e.g. from an usb driver's
> > >  ->connect callback."
> > You use "disconnected" for connecting stuff. That doesn't make sense to me
> > at all - register_all is for when you want to publish something, not for
> > unpublishing when the device disappears. Or maybe this is a case of lost
> > in translation, and you mean something else?
> 
> Let me try to explain what I meant.
> 
> We execute ->connect() callback of USB device when USB device is still in 
> "disconnected" state
> (well at least that was my thought). And only when that ->connect() callback 
> succeeds we're
> entering "connected" state.
> 
> Probably above sentence is not correct. Then could you please help me with 
> correct wording of
> comment to drm_connector_register_all()?

Yeah, your sentence suggests more that register_all should be called when
someone unplugs udl. What about:

"This function registers all connectors in sysfs and other places so that
userspace can start to access them. Drivers can call it after calling
drm_dev_register() to complete the device registration, if they don't call
drm_connector_register() on each connector individually.

When a device is unplugged and should be removed from userspace access,
call drm_connector_unregister_all(), which is the inverse of this
function."

And for drm_connector_unregister_all:

"This functions unregisters all connectors from sysfs and other places so
that userspace can no longer access them. Drivers should call this as the
first step tearing down the device instace, or when the underlying
physical device disappeared (e.g. USB unplug), right before calling
drm_dev_unregister()."

Thinking about this we might want to merge drm_dev_register and
drm_connector_register_all, but that's a long-term goal which will need
some trickery to no break drivers.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC PATCH v1 4/4] ARM: dst: rockchip: enable RGA support on veyron devices

[Yakir Yang]

Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288-veyron.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi 
b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 9fce91f..5eb4e97 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -425,6 +425,10 @@
dr_mode = "host";
 };

+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
1.9.1

[RFC PATCH v1 3/4] ARM: dts: rockchip: add RGA device node for RK3288

[Yakir Yang]

This patch add the RGA dt config of rk3288 SoC.

Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 8ac49f3..af948b9 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -795,6 +795,19 @@
status = "okay";
};

+   rga: rga at ff92 {
+   compatible = "rockchip,rk3288-rga";
+   reg = <0xff92 0x180>;
+   interrupts = ;
+   interrupt-names = "rga";
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA>;
+   clock-names = "aclk", "hclk", "sclk";
+
+   resets = < SRST_RGA_CORE>, < SRST_RGA_AXI>, < 
SRST_RGA_AHB>;
+   reset-names = "sclk", "aclk", "hclk";
+   status = "disabled";
+   };
+
vopb: vop at ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
-- 
1.9.1

[RFC PATCH v1 2/4] drm: rockchip: add RGA driver support

[Yakir Yang]

Rockchip RGA is a separate 2D raster graphic acceleration unit. It
accelerates 2D graphics operations, such as point/line drawing, image
scaling, rotation, BitBLT, alpha blending and image blur/sharpness.

The RGA driver is based on Exynos G2D driver, it is performed by two
tasks simply.
1. Configures the rendering parameters, such as foreground color and
   coordinates data by setting the drawing context registers.
2. Start the rendering process by calling rga_exec() ioctl.

The RGA supports DMA mode as host interface. User can make command list
to reduce HOST(ARM) loads. The contents of The command list is setted to
relevant registers of RGA by DMA.

The command list is composed Header and command sets and Tail.
- Header: The number of command set(4Bytes)
- Command set: Register offset(4Bytes) + Register data(4Bytes)
- Tail: Pointer of base address of the other command list(4Bytes)

By Tail field, the G2D can process many command lists without halt at
one go.

The G2D has following the rendering pipeline.
   ---> Color Fill --->
   |  |
--> DMA (read) ---> Src Bitmap Process > Alpha/ROP ---> Format convert ---> 
DMA (Write)
   |  |
   ---> Dst Bitmap Process --->

And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- rotation
- flip
- 4 operand raster operation(ROP4)
- alpha blending
- color key
- dithering
- etc

User should make the command list to data and registers needed by
operation to use. The Rockchip RGA driver only manages the command lists
received from user. Some registers needs memory base address(physical
address) of image. User doesn't know its physical address, so fills the
gem handle of that memory than address to command sets, then RGA driver
converts it to memory base address.

We adds three ioctls for Rockchip RGA.

- ioctls
DRM_ROCKCHIP_RGA_GET_VER: get the RGA hardware version
DRM_ROCKCHIP_RGA_SET_CMDLIST: set the command list from user to driver
DRM_ROCKCHIP_RGA_EXEC: execute the command lists setted to driver

Signed-off-by: Yakir Yang 
---
 .../bindings/display/rockchip/rockchip-rga.txt |  36 +
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  35 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_rga.c| 977 +
 drivers/gpu/drm/rockchip/rockchip_drm_rga.h| 108 +++
 include/uapi/drm/rockchip_drm.h|  63 ++
 8 files changed, 1232 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_rga.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_rga.h
 create mode 100644 include/uapi/drm/rockchip_drm.h

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt
new file mode 100644
index 000..0c606cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt
@@ -0,0 +1,36 @@
+device-tree bindings for rockchip 2D raster graphic acceleration controller 
(RGA)
+
+RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D
+graphics operations, such as point/line drawing, image scaling, rotation,
+BitBLT, alpha blending and image blur/sharpness.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3228-rga";
+   "rockchip,rk3288-rga";
+   "rockchip,rk3399-rga";
+
+- interrupts: RGA interrupt number.
+
+- clocks: phandle to RGA sclk/hclk/aclk clocks
+
+- clock-names: should be "aclk" "hclk" and "sclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: should be "aclk" "hclk" and "sclk"
+
+Example:
+SoC specific DT entry:
+   rga: rga at ff68 {
+   compatible = "rockchip,rk3399-rga";
+   reg = <0xff68 0x1>;
+   interrupts = ;
+   interrupt-names = "rga";
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA>;
+   clock-names = "aclk", "hclk", "sclk";
+
+   resets = < SRST_A_RGA>, < SRST_H_RGA>, < 
SRST_RGA_CORE>;
+   reset-names = "aclk", "hclk", "sclk";
+   status = "disabled";
+   };
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 76b3362..220221b 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -16,6 +16,15 @@ config DRM_ROCKCHIP
  2D or 3D acceleration; acceleration is performed by other
  IP found on the SoC.

+config ROCKCHIP_DRM_RGA
+   tristate "Rockchip RGA support"
+   depends on 

[RFC PATCH v1 1/4] drm: rockchip: add a common subdrv interfaces

[Yakir Yang]

Introduce a common subdrv register/unregister interfaces, help
external driver to hook the drm open/close event.

Signed-off-by: Yakir Yang 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 49 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 15 +
 2 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 896da09..4e0feb2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -36,6 +36,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0

+static LIST_HEAD(rockchip_drm_subdrv_list);
+
 /*
  * Attach a (component) device to the shared drm dma mapping from master drm
  * device.  This is used by the VOPs to map GEM buffers to a common DMA
@@ -251,6 +253,51 @@ static int rockchip_drm_unload(struct drm_device *drm_dev)
return 0;
 }

+int rockchip_register_subdrv(struct drm_rockchip_subdrv *subdrv)
+{
+   if (!subdrv)
+   return -EINVAL;
+
+   list_add_tail(>list, _drm_subdrv_list);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(rockchip_register_subdrv);
+
+int rockchip_unregister_subdrv(struct drm_rockchip_subdrv *subdrv)
+{
+   if (!subdrv)
+   return -EINVAL;
+
+   list_del(>list);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(rockchip_unregister_subdrv);
+
+static int rockchip_drm_open(struct drm_device *dev, struct drm_file *file)
+{
+   struct drm_rockchip_subdrv *subdrv;
+   int ret = 0;
+
+   list_for_each_entry(subdrv, _drm_subdrv_list, list) {
+   ret = subdrv->open(dev, subdrv->dev, file);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+static void rockchip_drm_preclose(struct drm_device *dev,
+ struct drm_file *file)
+{
+   struct drm_rockchip_subdrv *subdrv;
+
+   list_for_each_entry(subdrv, _drm_subdrv_list, list)
+   subdrv->close(dev, subdrv->dev, file);
+}
+
 void rockchip_drm_lastclose(struct drm_device *dev)
 {
struct rockchip_drm_private *priv = dev->dev_private;
@@ -281,6 +328,8 @@ static struct drm_driver rockchip_drm_driver = {
  DRIVER_PRIME | DRIVER_ATOMIC,
.load   = rockchip_drm_load,
.unload = rockchip_drm_unload,
+   .open   = rockchip_drm_open,
+   .preclose   = rockchip_drm_preclose,
.lastclose  = rockchip_drm_lastclose,
.get_vblank_counter = drm_vblank_no_hw_counter,
.enable_vblank  = rockchip_drm_crtc_enable_vblank,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 3529f69..5ea5fcb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -42,6 +42,17 @@ struct rockchip_crtc_funcs {
void (*wait_for_update)(struct drm_crtc *crtc);
 };

+struct drm_rockchip_subdrv {
+   struct list_head list;
+   struct device *dev;
+   struct drm_device *drm_dev;
+
+   int (*open)(struct drm_device *drm_dev, struct device *dev,
+   struct drm_file *file);
+   void (*close)(struct drm_device *drm_dev, struct device *dev,
+ struct drm_file *file);
+};
+
 struct rockchip_atomic_commit {
struct work_struct  work;
struct drm_atomic_state *state;
@@ -73,4 +84,8 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
+
+int rockchip_register_subdrv(struct drm_rockchip_subdrv *subdrv);
+int rockchip_unregister_subdrv(struct drm_rockchip_subdrv *subdrv);
+
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
-- 
1.9.1

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

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

--- Comment #89 from Orlando Nigro  ---
Hi! I have been reading this bugreport since several days since it seems to be
very cloase to my situation!

I have a MSI r9 390. 
I have debian jessie with kernel 4.3, latest Mesa, and I also installed 
"firmware-amd-graphics" as jonas wrote in Comment 23. 

As it is now I can start debian both with Mate and Gnome, and of course Gnome
freezes much faster while it takes a while for Mate, also because, for some
reason, all the graphic funcionalities are deactivated in Mate, the docky
doesn't allow me to choose 3d icons for instance.
Gnome looks much better with all its windows-effects and nice graphic and it
makes me think that, a part from the freezing, the open source drivers work
fine. 

I have been making lots of tests, using different distribution with different
drivers, kernels and DE but nothing, same problem all the time! I get black
screens while working. I haven't tried yet to change the DPM, and I think that
it could be the solution! (I hope) I intend to do it now and run some tests!
But I have a couple of question first. 
Should I dowload the unicode as recommended by many like this

 http://people.freedesktop.org/~agd5f/radeon_ucode/

or this:

people.freedesktop.org/~agd5f/radeon_ucode/k/hawaii_k_smc.bin

or will the ones I have got in the debian package be enough?

Do I only need to run this command to make the tests: 
echo 'high' > '/sys/class/drm/card0/device/power_dpm_force_performance_level'

Or a do I need to stop the xserver first? (would it be gdm? I choose lightdm
when I installed gnome alongside Mate)

I apologize for all the questions that should be obvious after all the great
work you have done in this report but I'm afraid to do wrong and I'm not much
of an expert.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/9304ab6c/attachment-0001.html>

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Yakir Yang]

Hi, Mark and all.

This patch set would add the RGA direct rendering based 2d graphics
acceleration module.

This patch set is based on git repository below:
git://people.freedesktop.org/~airlied/linux drm-next
commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7

And the RGA driver is based on Exynos G2D driver, it only manages the
command lists received from user, so user should make the command list
to data and registers needed by operation to use.

I have prepared an userspace demo application for testing:
https://github.com/yakir-Yang/libdrm-rockchip
That is a rockchip libdrm library, and I have write a simple test case
"rockchip_rga_test" that would test the below RGA features:
- solid
- copy
- rotation
- flip
- window clip
- dithering

Thanks,
- Yakir


Yakir Yang (4):
  drm: rockchip: add a common subdrv interfaces
  drm: rockchip: add RGA driver support
  ARM: dts: rockchip: add RGA device node for RK3288
  ARM: dst: rockchip: enable RGA support on veyron devices

 .../bindings/display/rockchip/rockchip-rga.txt |  36 +
 arch/arm/boot/dts/rk3288-veyron.dtsi   |   4 +
 arch/arm/boot/dts/rk3288.dtsi  |  13 +
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  82 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|  19 +
 drivers/gpu/drm/rockchip/rockchip_drm_rga.c| 977 +
 drivers/gpu/drm/rockchip/rockchip_drm_rga.h| 108 +++
 include/uapi/drm/rockchip_drm.h|  63 ++
 10 files changed, 1312 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-rga.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_rga.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_rga.h
 create mode 100644 include/uapi/drm/rockchip_drm.h

-- 
1.9.1

[PATCH 2/2] drm/virtio: send vblank event on plane atomic update

[Gustavo Padovan]

From: Gustavo Padovan 

virtio_gpu was failing to send vblank events when using the atomic IOCTL
with the DRM_MODE_PAGE_FLIP_EVENT flag set. This patch fixes each and
enables atomic pageflips updates.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 70b44a2..20260ad 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -63,9 +63,11 @@ static void virtio_gpu_plane_atomic_update(struct drm_plane 
*plane,
 {
struct drm_device *dev = plane->dev;
struct virtio_gpu_device *vgdev = dev->dev_private;
-   struct virtio_gpu_output *output = 
drm_crtc_to_virtio_gpu_output(plane->crtc);
+   struct drm_crtc *crtc = plane->crtc;
+   struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
struct virtio_gpu_framebuffer *vgfb;
struct virtio_gpu_object *bo;
+   unsigned long flags;
uint32_t handle;

if (plane->state->fb) {
@@ -96,6 +98,11 @@ static void virtio_gpu_plane_atomic_update(struct drm_plane 
*plane,
  plane->state->crtc_y,
  plane->state->crtc_w,
  plane->state->crtc_h);
+
+   spin_lock_irqsave(>dev->event_lock, flags);
+   if (crtc->state->event)
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   spin_unlock_irqrestore(>dev->event_lock, flags);
 }


-- 
2.5.0

[PATCH 1/2] drm/virtio: use new drm_crtc_send_vblank_event()

[Gustavo Padovan]

From: Gustavo Padovan 

Simplify code by using the new vblank crtc helpers.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 429aa31..b70bb8b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -163,7 +163,7 @@ static int virtio_gpu_page_flip(struct drm_crtc *crtc,

if (event) {
spin_lock_irqsave(>dev->event_lock, irqflags);
-   drm_send_vblank_event(crtc->dev, -1, event);
+   drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irqrestore(>dev->event_lock, irqflags);
}

-- 
2.5.0

[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Tomeu Vizoso]

On 19 March 2016 at 02:15, Mark yao  wrote:
> On 2016年03月18日 19:22, Tomeu Vizoso wrote:
>>
>> When the VOP is re-enabled, it will start scanning right away the
>> framebuffers that were configured from the last time, even if those have
>> been destroyed already. To prevent the VOP from trying to access freed
>> memory, reset the registers that hold pointers to framebuffers right
>> after we can write to them, but before the VOP is awaken from standby.
>>
>> Signed-off-by: Tomeu Vizoso 
>> Link:
>> http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw 
>> at mail.gmail.com
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index 5e57f5b2e4b0..0df91c28740b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -429,6 +429,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop
>> *vop)
>>   static void vop_enable(struct drm_crtc *crtc)
>>   {
>> struct vop *vop = to_vop(crtc);
>> +   int i;
>> int ret;
>> if (vop->is_enabled)
>> @@ -476,6 +477,18 @@ static void vop_enable(struct drm_crtc *crtc)
>>  */
>> vop->is_enabled = true;
>>   + /*
>> +* Before turning the VOP completely on, unset the registers
>> +* containing FB addresses to avoid the HW start scanning old FBs.
>> +*/
>> +   for (i = 0; i < vop->data->win_size; i++) {
>> +   struct vop_win *vop_win = >win[i];
>> +   const struct vop_win_data *win = vop_win->data;
>> +
>> +   VOP_WIN_SET(vop, win, yrgb_mst, 0x0);
>> +   VOP_WIN_SET(vop, win, uv_mst, 0x0);
>> +   }
>> +
>
> Hi Tomeu
>
> Thanks for your fix.
>
> Set yrgb_mst and uv_mst is not a good idea, because 0x0 also is a memory
> buffer address, ddr will access the 0x0 buffer.
> I think you may enable DRM_FBDEV_EMULATION, the 0x0 address is iommu mmaped
> address for fbdev, so your test can works.
> but if DRM_FBDEV_EMULATION is not define, may be 0x0 address is unmmaped,
> would get the iommu crash.

I have checked with DRM_FBDEV_EMULATION disabled and seems to work equally well.

> I think we can use atomic disable function like this:
> for_each_plane_in_state(old_state, plane, old_plane_state, i) {
> const struct drm_plane_helper_funcs *funcs;
> funcs = plane->helper_private;
> funcs->atomic_disable(plane, old_plane_state);
> }
>
> But I think we'd better find why we need do this hack here.
>
> Does the old FB address is ummaped when crtc disabling? why plane is not
> disabled?

Planes aren't being disabled because the CRTC is being disabled
already, see 
http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_atomic_helper.c#L1306

Exynos is already disabling all planes when a crtc is disabled:

http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_fimd.c#L782

I don't like it because there's state in the drm core and in the
drivers that is left inconsistent.

Regards,

Tomeu

> Thanks.
>
>> spin_lock(>reg_lock);
>> VOP_CTRL_SET(vop, standby, 0);
>
>
>
> --
> ï¼­ark Yao
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Ville Syrjälä]

On Mon, Mar 21, 2016 at 12:30:54PM +0200, Jani Nikula wrote:
> On Fri, 18 Mar 2016, Ville Syrjälä  wrote:
> > On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
> >> On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
> >> > On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
> >> > > -  drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
> >> > 
> >> > NAK
> >> > 
> >> > If people keep intentionally breaking my shit I'm going to become
> >> > really grumpy soon.
> >> 
> >> Oh, and just in case someone wants to come up with a better kludge,
> >> I just spent a few minutes analyzing the behavior of this crappy
> >> monitor a.
> >> 
> >> What happens is that when the monitor is fully powered up (LED is blue)
> >> things are fine. After the monitor goes to sleep (LED turns orange)
> >> the first DPCD read will produce garbage. Further DPCD reads are fine,
> >> even if I wait a significant amount of time between the reads, as long
> >> as the monitor didn't do a power on->off cycle in between. So it looks
> >> like it's always just the first read after power down that gets
> >> corrupted.
> >> 
> >> Now I think I'll go and test how writes behave, assuming I can find a
> >> decently sized chunk of DPCD address space I can write. And maybe I
> >> should also try i2c-over-aux...
> >
> > The first DPCD write after powerdown also got corrupted. But i2c-over-aux
> > seems unaffected for whatever reason.
> 
> Did the display go to sleep on its own, or did we do something? In
> particular, does DPCD DP_SET_POWER register play a role? What if we skip
> writing D3 to it? What if we do that write as the first thing (every
> time)?

User pressing any of the buttons on the monitor is enough to wake it,
and after a short timeout it will power down on its own, leading to
the corrupted access.

Keeping DP_SET_POWER at D0 doesn't change anything.

-- 
Ville Syrjälä
Intel OTC

[PATCH 2/4 v2] drm: introduce drm_connector_register_all() helper

[Laurent Pinchart]

Hi Alexey,

Thank you for the patch.

On Monday 21 Mar 2016 15:28:38 Alexey Brodkin wrote:
> As a pair to already existing drm_connector_unregister_all() we're adding
> generic implementation of what is already done in some drivers.
> 
> Once this helper is implemented we'll be ready to switch existing
> driver-specific implementations with the generic one.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
> 
> Changes v1 -> v2:
>  * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
>  * Use drm_for_each_connector() instead of list_for_each_entry()
>  * Updated kerneldoc for drm_dev_register()
> 
>  drivers/gpu/drm/drm_crtc.c | 50 ---
>  drivers/gpu/drm/drm_drv.c  |  6 +-
>  include/drm/drm_crtc.h |  3 ++-
>  3 files changed, 54 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 76453cd..2ad0ce9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1080,13 +1080,57 @@ void drm_connector_unregister(struct drm_connector
> *connector) }
>  EXPORT_SYMBOL(drm_connector_unregister);
> 
> +/**
> + * drm_connector_register_all - register all connectors
> + * @dev: drm device
> + *
> + * This function just calls drm_connector_register() for all connectors.
> + * Should be called when the device is disconnected, e.g. from an usb
> driver's
> + * ->connect callback.

There's no such thing as a USB driver connect callback :-)

> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_connector_register_all(struct drm_device *dev)
> +{
> + struct drm_connector *connector, *failed;
> + int ret;
> +
> + mutex_lock(>mode_config.mutex);
> +
> + drm_for_each_connector(connector, dev) {
> + ret = drm_connector_register(connector);
> + if (ret) {
> + failed = connector;
> + goto err;
> + }
> + }
> +
> +

One blank line is enough.

> + mutex_unlock(>mode_config.mutex);
> +
> + return 0;
> +
> +err:
> + drm_for_each_connector(connector, dev) {
> + if (failed == connector)
> + break;
> +
> + drm_connector_unregister(connector);
> + }

drm_connector_unregister() can safely be called on unregistered connectors, so 
you could simplify the implementation by calling 
drm_connector_unregister_all() above and remove the goto and this piece of 
error handling code.

> + mutex_unlock(>mode_config.mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_connector_register_all);
> 
>  /**
>   * drm_connector_unregister_all - unregister connector userspace interfaces
> * @dev: drm device
>   *
>   * This function unregisters all connector userspace interfaces in sysfs.
> Should
> - * be call when the device is disconnected, e.g. from an usb driver's
> + * be called when the device is disconnected, e.g. from an usb driver's
>   * ->disconnect callback.
>   */
>  void drm_connector_unregister_all(struct drm_device *dev)
> @@ -1094,9 +1138,9 @@ void drm_connector_unregister_all(struct drm_device
> *dev) struct drm_connector *connector;
> 
>   /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
> - list_for_each_entry(connector, >mode_config.connector_list, head)
> + drm_for_each_connector(connector, dev) {
>   drm_connector_unregister(connector);
> -
> + }
>  }
>  EXPORT_SYMBOL(drm_connector_unregister_all);

I would move these two hunks to the previous patch as you already touch 
drm_connector_unregister_all() there, but that's up to you.

> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 167c8d3..5580a90 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -715,7 +715,11 @@ EXPORT_SYMBOL(drm_dev_unref);
>   *
>   * Register the DRM device @dev with the system, advertise device to
> user-space * and start normal device operation. @dev must be allocated via
> drm_dev_alloc() - * previously.
> + * previously. Right after drm_dev_register() the driver should call
> + * drm_connector_plug_all() to register all connectors in sysfs. This is

s/drm_connector_plug_all/drm_connector_register_all/

> + * a separate call for backward compatibility with drivers still using
> + * the deprecated ->load() callback, where connectors are registered from
> within
> + * the ->load() callback.
>   *
>   * Never call this twice on any device!
>   *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 42d9f4d..6a34117 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2214,7 +2214,8 @@ void drm_connector_unregister(struct drm_connector
> *connector);
> 
>  extern void drm_connector_cleanup(struct drm_connector *connector);
>  extern unsigned int drm_connector_index(struct drm_connector *connector);
> -/* helper to unregister all connectors from sysfs 

[PATCH v2 13/18] mm/compaction: support non-lru movable page migration

[Minchan Kim]

We have allowed migration for only LRU pages until now and it was
enough to make high-order pages. But recently, embedded system(e.g.,
webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
so we have seen several reports about troubles of small high-order
allocation. For fixing the problem, there were several efforts
(e,g,. enhance compaction algorithm, SLUB fallback to 0-order page,
reserved memory, vmalloc and so on) but if there are lots of
non-movable pages in system, their solutions are void in the long run.

So, this patch is to support facility to change non-movable pages
with movable. For the feature, this patch introduces functions related
to migration to address_space_operations as well as some page flags.

Basically, this patch supports two page-flags and two functions related
to page migration. The flag and page->mapping stability are protected
by PG_lock.

PG_movable
PG_isolated

bool (*isolate_page) (struct page *, isolate_mode_t);
void (*putback_page) (struct page *);

Duty of subsystem want to make their pages as migratable are
as follows:

1. It should register address_space to page->mapping then mark
the page as PG_movable via __SetPageMovable.

2. It should mark the page as PG_isolated via SetPageIsolated
if isolation is sucessful and return true.

3. If migration is successful, it should clear PG_isolated and
PG_movable of the page for free preparation then release the
reference of the page to free.

4. If migration fails, putback function of subsystem should
clear PG_isolated via ClearPageIsolated.

Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: dri-devel at lists.freedesktop.org
Cc: virtualization at lists.linux-foundation.org
Signed-off-by: Gioh Kim 
Signed-off-by: Minchan Kim 
---
 Documentation/filesystems/Locking  |   4 +
 Documentation/filesystems/vfs.txt  |   5 ++
 fs/proc/page.c |   3 +
 include/linux/fs.h |   2 +
 include/linux/migrate.h|   2 +
 include/linux/page-flags.h |  29 
 include/uapi/linux/kernel-page-flags.h |   1 +
 mm/compaction.c|  14 +++-
 mm/migrate.c   | 132 +
 9 files changed, 177 insertions(+), 15 deletions(-)

diff --git a/Documentation/filesystems/Locking 
b/Documentation/filesystems/Locking
index 619af9bfdcb3..0bb79560abb3 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -195,7 +195,9 @@ unlocks and drops the reference.
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
+   bool (*isolate_page) (struct page *, isolate_mode_t);
int (*migratepage)(struct address_space *, struct page *, struct page 
*);
+   void (*putback_page) (struct page *);
int (*launder_page)(struct page *);
int (*is_partially_uptodate)(struct page *, unsigned long, unsigned 
long);
int (*error_remove_page)(struct address_space *, struct page *);
@@ -219,7 +221,9 @@ invalidatepage: yes
 releasepage:   yes
 freepage:  yes
 direct_IO:
+isolate_page:  yes
 migratepage:   yes (both)
+putback_page:  yes
 launder_page:  yes
 is_partially_uptodate: yes
 error_remove_page: yes
diff --git a/Documentation/filesystems/vfs.txt 
b/Documentation/filesystems/vfs.txt
index b02a7d598258..4c1b6c3b4bc8 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -592,9 +592,14 @@ struct address_space_operations {
int (*releasepage) (struct page *, int);
void (*freepage)(struct page *);
ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t 
offset);
+   /* isolate a page for migration */
+   bool (*isolate_page) (struct page *, isolate_mode_t);
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct page *, struct page *);
+   /* put the page back to right list */
+   void (*putback_page) (struct page *);
int (*launder_page) (struct page *);
+
int (*is_partially_uptodate) (struct page *, unsigned long,
unsigned long);
void (*is_dirty_writeback) (struct page *, bool *, bool *);
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 712f1b9992cc..e2066e73a9b8 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -157,6 +157,9 @@ u64 stable_page_flags(struct page *page)
if (page_is_idle(page))
u |= 1 << KPF_IDLE;

+   if (PageMovable(page))
+   u |= 1 << KPF_MOVABLE;
+
u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);

u |= kpf_copy_bit(k, KPF_SLAB,  PG_slab);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 14a97194b34b..b7ef2e41fa4a 100644
--- 

[PATCH 4/4 v2] drm: rcar-du - use generic drm_connector_register_all() helper

[Alexey Brodkin]

Now when generic drm_connector_register_all() helper exists we may safely
substiture with it driver-specific implementation of connectors plugging in
sysfs.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Laurent Pinchart 
Cc: linux-renesas-soc at vger.kernel.org
---

No changes v1 -> v2.

 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 644db36..0f251dc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -361,14 +361,7 @@ static int rcar_du_probe(struct platform_device *pdev)
if (ret)
goto error;

-   mutex_lock(>mode_config.mutex);
-   drm_for_each_connector(connector, ddev) {
-   ret = drm_connector_register(connector);
-   if (ret < 0)
-   break;
-   }
-   mutex_unlock(>mode_config.mutex);
-
+   ret = drm_connector_register_all(ddev);
if (ret < 0)
goto error;

-- 
2.5.0

[PATCH 3/4 v2] drm: atmel_hldc - use generic drm_connector_register_all() helper

[Alexey Brodkin]

This driver used to have its own implementation of connector_register_all()
which actually was taken as a prototype of drm_connector_register_all().

Now when drm_connector_register_all() exists reusing it here.

And while at it replace atmel_hlcdc_dc_connector_unplug_all()
with generic drm_connector_unregister_all().

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Boris Brezillon 
---

No changes v1 -> v2.

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 39 ++--
 1 file changed, 2 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 3d8d164..1c537e4 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -584,41 +584,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
destroy_workqueue(dc->wq);
 }

-static int atmel_hlcdc_dc_connector_plug_all(struct drm_device *dev)
-{
-   struct drm_connector *connector, *failed;
-   int ret;
-
-   mutex_lock(>mode_config.mutex);
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
-   ret = drm_connector_register(connector);
-   if (ret) {
-   failed = connector;
-   goto err;
-   }
-   }
-   mutex_unlock(>mode_config.mutex);
-   return 0;
-
-err:
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
-   if (failed == connector)
-   break;
-
-   drm_connector_unregister(connector);
-   }
-   mutex_unlock(>mode_config.mutex);
-
-   return ret;
-}
-
-static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
-{
-   mutex_lock(>mode_config.mutex);
-   drm_connector_unplug_all(dev);
-   mutex_unlock(>mode_config.mutex);
-}
-
 static void atmel_hlcdc_dc_lastclose(struct drm_device *dev)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
@@ -736,7 +701,7 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device 
*pdev)
if (ret)
goto err_unload;

-   ret = atmel_hlcdc_dc_connector_plug_all(ddev);
+   ret = drm_connector_register_all(ddev);
if (ret)
goto err_unregister;

@@ -758,7 +723,7 @@ static int atmel_hlcdc_dc_drm_remove(struct platform_device 
*pdev)
 {
struct drm_device *ddev = platform_get_drvdata(pdev);

-   atmel_hlcdc_dc_connector_unplug_all(ddev);
+   drm_connector_unregister_all(ddev);
drm_dev_unregister(ddev);
atmel_hlcdc_dc_unload(ddev);
drm_dev_unref(ddev);
-- 
2.5.0

[PATCH 2/4 v2] drm: introduce drm_connector_register_all() helper

[Alexey Brodkin]

As a pair to already existing drm_connector_unregister_all() we're adding
generic implementation of what is already done in some drivers.

Once this helper is implemented we'll be ready to switch existing
driver-specific implementations with the generic one.

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
---

Changes v1 -> v2:
 * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
 * Use drm_for_each_connector() instead of list_for_each_entry()
 * Updated kerneldoc for drm_dev_register()

 drivers/gpu/drm/drm_crtc.c | 50 +++---
 drivers/gpu/drm/drm_drv.c  |  6 +-
 include/drm/drm_crtc.h |  3 ++-
 3 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 76453cd..2ad0ce9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1080,13 +1080,57 @@ void drm_connector_unregister(struct drm_connector 
*connector)
 }
 EXPORT_SYMBOL(drm_connector_unregister);

+/**
+ * drm_connector_register_all - register all connectors
+ * @dev: drm device
+ *
+ * This function just calls drm_connector_register() for all connectors.
+ * Should be called when the device is disconnected, e.g. from an usb driver's
+ * ->connect callback.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_connector_register_all(struct drm_device *dev)
+{
+   struct drm_connector *connector, *failed;
+   int ret;
+
+   mutex_lock(>mode_config.mutex);
+
+   drm_for_each_connector(connector, dev) {
+   ret = drm_connector_register(connector);
+   if (ret) {
+   failed = connector;
+   goto err;
+   }
+   }
+
+
+   mutex_unlock(>mode_config.mutex);
+
+   return 0;
+
+err:
+   drm_for_each_connector(connector, dev) {
+   if (failed == connector)
+   break;
+
+   drm_connector_unregister(connector);
+   }
+
+   mutex_unlock(>mode_config.mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_connector_register_all);

 /**
  * drm_connector_unregister_all - unregister connector userspace interfaces
  * @dev: drm device
  *
  * This function unregisters all connector userspace interfaces in sysfs. 
Should
- * be call when the device is disconnected, e.g. from an usb driver's
+ * be called when the device is disconnected, e.g. from an usb driver's
  * ->disconnect callback.
  */
 void drm_connector_unregister_all(struct drm_device *dev)
@@ -1094,9 +1138,9 @@ void drm_connector_unregister_all(struct drm_device *dev)
struct drm_connector *connector;

/* FIXME: taking the mode config mutex ends up in a clash with sysfs */
-   list_for_each_entry(connector, >mode_config.connector_list, head)
+   drm_for_each_connector(connector, dev) {
drm_connector_unregister(connector);
-
+   }
 }
 EXPORT_SYMBOL(drm_connector_unregister_all);

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 167c8d3..5580a90 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -715,7 +715,11 @@ EXPORT_SYMBOL(drm_dev_unref);
  *
  * Register the DRM device @dev with the system, advertise device to user-space
  * and start normal device operation. @dev must be allocated via 
drm_dev_alloc()
- * previously.
+ * previously. Right after drm_dev_register() the driver should call
+ * drm_connector_plug_all() to register all connectors in sysfs. This is
+ * a separate call for backward compatibility with drivers still using
+ * the deprecated ->load() callback, where connectors are registered from 
within
+ * the ->load() callback.
  *
  * Never call this twice on any device!
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 42d9f4d..6a34117 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2214,7 +2214,8 @@ void drm_connector_unregister(struct drm_connector 
*connector);

 extern void drm_connector_cleanup(struct drm_connector *connector);
 extern unsigned int drm_connector_index(struct drm_connector *connector);
-/* helper to unregister all connectors from sysfs for device */
+/* helpers to {un}register all connectors from sysfs for device */
+extern int drm_connector_register_all(struct drm_device *dev);
 extern void drm_connector_unregister_all(struct drm_device *dev);

 extern int drm_bridge_add(struct drm_bridge *bridge);
-- 
2.5.0

[PATCH 1/4 v2] drm: rename drm_connector_unplug_all() to drm_connector_unregister_all()

[Alexey Brodkin]

Current name is a bit misleading because what that helper function
really does it calls drm_connector_unregister() for all connectors.

This all has nothing to do with hotplugging so let's name things
properly.

And while at it remove potentially dangerous locking around
drm_connector_unregister() in rcar_du_remove() as mentioned
in kerneldoc for drm_connector_unregister_all().

Signed-off-by: Alexey Brodkin 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Boris Brezillon 
Cc: Laurent Pinchart 
Cc: linux-renesas-soc at vger.kernel.org
---

Changes v1 -> v2:
 * This patch was only introduced in v2.

 drivers/gpu/drm/drm_crtc.c| 6 +++---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 +
 drivers/gpu/drm/udl/udl_drv.c | 2 +-
 include/drm/drm_crtc.h| 4 ++--
 4 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 65258ac..76453cd 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1082,14 +1082,14 @@ EXPORT_SYMBOL(drm_connector_unregister);


 /**
- * drm_connector_unplug_all - unregister connector userspace interfaces
+ * drm_connector_unregister_all - unregister connector userspace interfaces
  * @dev: drm device
  *
  * This function unregisters all connector userspace interfaces in sysfs. 
Should
  * be call when the device is disconnected, e.g. from an usb driver's
  * ->disconnect callback.
  */
-void drm_connector_unplug_all(struct drm_device *dev)
+void drm_connector_unregister_all(struct drm_device *dev)
 {
struct drm_connector *connector;

@@ -1098,7 +1098,7 @@ void drm_connector_unplug_all(struct drm_device *dev)
drm_connector_unregister(connector);

 }
-EXPORT_SYMBOL(drm_connector_unplug_all);
+EXPORT_SYMBOL(drm_connector_unregister_all);

 /**
  * drm_encoder_init - Init a preallocated encoder
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index ed6006b..644db36 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -278,10 +278,7 @@ static int rcar_du_remove(struct platform_device *pdev)
struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
struct drm_device *ddev = rcdu->ddev;

-   mutex_lock(>mode_config.mutex);
-   drm_connector_unplug_all(ddev);
-   mutex_unlock(>mode_config.mutex);
-
+   drm_connector_unregister_all(ddev);
drm_dev_unregister(ddev);

if (rcdu->fbdev)
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 772ec9e..c204089 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -94,7 +94,7 @@ static void udl_usb_disconnect(struct usb_interface 
*interface)
struct drm_device *dev = usb_get_intfdata(interface);

drm_kms_helper_poll_disable(dev);
-   drm_connector_unplug_all(dev);
+   drm_connector_unregister_all(dev);
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
drm_unplug_dev(dev);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8c7fb3d..42d9f4d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2214,8 +2214,8 @@ void drm_connector_unregister(struct drm_connector 
*connector);

 extern void drm_connector_cleanup(struct drm_connector *connector);
 extern unsigned int drm_connector_index(struct drm_connector *connector);
-/* helper to unplug all connectors from sysfs for device */
-extern void drm_connector_unplug_all(struct drm_device *dev);
+/* helper to unregister all connectors from sysfs for device */
+extern void drm_connector_unregister_all(struct drm_device *dev);

 extern int drm_bridge_add(struct drm_bridge *bridge);
 extern void drm_bridge_remove(struct drm_bridge *bridge);
-- 
2.5.0

[PATCH 0/4 v2] drm: introduce drm_connector_register_all() helper

[Alexey Brodkin]

As a pair to already existing drm_connector_unplug_all()
(which we'll rename in this series to drm_connector_unregister_all())
we're adding generic implementation of what is already done in some drivers
for registering all connectors.

After implementation of that new helper we're updating 2 drivers
that used to use it's own implementation:
 [1] atmel_hlcdc
 [2] rcar_du

And one driver that uses unregister():
 [1] udl

Other drivers still use load() callback and so should be first modified so
their load() gets called from their probe() explicitly.

Build- and run-tested on yet to be upstreamed ARC PGU (part of AXS10x board).

Changes v1 -> v2:
 * Rename drm_connector_unplug_all() to drm_connector_unregister_all()
 * Use drm_for_each_connector() instead of list_for_each_entry()
 * Updated kerneldoc for drm_dev_register()

Alexey Brodkin (4):
  drm: rename drm_connector_unplug_all() to
drm_connector_unregister_all()
  drm: introduce drm_connector_register_all() helper
  drm: atmel_hldc - use generic drm_connector_register_all() helper
  drm: rcar-du - use generic drm_connector_register_all() helper

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 39 +--
 drivers/gpu/drm/drm_crtc.c   | 56 +---
 drivers/gpu/drm/drm_drv.c|  6 ++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c| 14 +--
 drivers/gpu/drm/udl/udl_drv.c|  2 +-
 include/drm/drm_crtc.h   |  5 ++-
 6 files changed, 63 insertions(+), 59 deletions(-)

Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Boris Brezillon 
Cc: Laurent Pinchart 
Cc: linux-renesas-soc at vger.kernel.org
-- 
2.5.0

[PATCH 4/4 v2] drm: rcar-du - use generic drm_connector_register_all() helper

[Laurent Pinchart]

Hi Alexey,

Thank you for the patch.

On Monday 21 Mar 2016 15:28:40 Alexey Brodkin wrote:
> Now when generic drm_connector_register_all() helper exists we may safely

s/Now when/Now that a/

> substiture with it driver-specific implementation of connectors plugging in

s/substiture with it/substitute it for the/

> sysfs.

And while at it, in the subject line,

s/rcar-du - use/rcar-du: Use/

> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Laurent Pinchart 
> Cc: linux-renesas-soc at vger.kernel.org

Apart for the commit message fixes,

Acked-by: Laurent Pinchart 

> ---
> 
> No changes v1 -> v2.
> 
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 644db36..0f251dc 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -361,14 +361,7 @@ static int rcar_du_probe(struct platform_device *pdev)
>   if (ret)
>   goto error;
> 
> - mutex_lock(>mode_config.mutex);
> - drm_for_each_connector(connector, ddev) {
> - ret = drm_connector_register(connector);
> - if (ret < 0)
> - break;
> - }
> - mutex_unlock(>mode_config.mutex);
> -
> + ret = drm_connector_register_all(ddev);
>   if (ret < 0)
>   goto error;

-- 
Regards,

Laurent Pinchart

[PATCH 1/4 v2] drm: rename drm_connector_unplug_all() to drm_connector_unregister_all()

[Laurent Pinchart]

Hi Alexey,

Thank you for the patch.

On Monday 21 Mar 2016 15:28:37 Alexey Brodkin wrote:
> Current name is a bit misleading because what that helper function
> really does it calls drm_connector_unregister() for all connectors.
> 
> This all has nothing to do with hotplugging so let's name things
> properly.
> 
> And while at it remove potentially dangerous locking around
> drm_connector_unregister() in rcar_du_remove() as mentioned
> in kerneldoc for drm_connector_unregister_all().
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Boris Brezillon 
> Cc: Laurent Pinchart 
> Cc: linux-renesas-soc at vger.kernel.org

Acked-by: Laurent Pinchart 

> ---
> 
> Changes v1 -> v2:
>  * This patch was only introduced in v2.
> 
>  drivers/gpu/drm/drm_crtc.c| 6 +++---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 +
>  drivers/gpu/drm/udl/udl_drv.c | 2 +-
>  include/drm/drm_crtc.h| 4 ++--
>  4 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 65258ac..76453cd 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1082,14 +1082,14 @@ EXPORT_SYMBOL(drm_connector_unregister);
> 
> 
>  /**
> - * drm_connector_unplug_all - unregister connector userspace interfaces
> + * drm_connector_unregister_all - unregister connector userspace interfaces
> * @dev: drm device
>   *
>   * This function unregisters all connector userspace interfaces in sysfs.
> Should * be call when the device is disconnected, e.g. from an usb driver's
> * ->disconnect callback.
>   */
> -void drm_connector_unplug_all(struct drm_device *dev)
> +void drm_connector_unregister_all(struct drm_device *dev)
>  {
>   struct drm_connector *connector;
> 
> @@ -1098,7 +1098,7 @@ void drm_connector_unplug_all(struct drm_device *dev)
>   drm_connector_unregister(connector);
> 
>  }
> -EXPORT_SYMBOL(drm_connector_unplug_all);
> +EXPORT_SYMBOL(drm_connector_unregister_all);
> 
>  /**
>   * drm_encoder_init - Init a preallocated encoder
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index ed6006b..644db36 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -278,10 +278,7 @@ static int rcar_du_remove(struct platform_device *pdev)
> struct rcar_du_device *rcdu = platform_get_drvdata(pdev);
>   struct drm_device *ddev = rcdu->ddev;
> 
> - mutex_lock(>mode_config.mutex);
> - drm_connector_unplug_all(ddev);
> - mutex_unlock(>mode_config.mutex);
> -
> + drm_connector_unregister_all(ddev);
>   drm_dev_unregister(ddev);
> 
>   if (rcdu->fbdev)
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 772ec9e..c204089 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -94,7 +94,7 @@ static void udl_usb_disconnect(struct usb_interface
> *interface) struct drm_device *dev = usb_get_intfdata(interface);
> 
>   drm_kms_helper_poll_disable(dev);
> - drm_connector_unplug_all(dev);
> + drm_connector_unregister_all(dev);
>   udl_fbdev_unplug(dev);
>   udl_drop_usb(dev);
>   drm_unplug_dev(dev);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8c7fb3d..42d9f4d 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2214,8 +2214,8 @@ void drm_connector_unregister(struct drm_connector
> *connector);
> 
>  extern void drm_connector_cleanup(struct drm_connector *connector);
>  extern unsigned int drm_connector_index(struct drm_connector *connector);
> -/* helper to unplug all connectors from sysfs for device */
> -extern void drm_connector_unplug_all(struct drm_device *dev);
> +/* helper to unregister all connectors from sysfs for device */
> +extern void drm_connector_unregister_all(struct drm_device *dev);
> 
>  extern int drm_bridge_add(struct drm_bridge *bridge);
>  extern void drm_bridge_remove(struct drm_bridge *bridge);

-- 
Regards,

Laurent Pinchart

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Cc: stable at vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References: 
https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom 
Cc: David Herrmann 
---
 drivers/gpu/drm/drm_crtc.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e08f962288d9..b7d0b959f088 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
return 0;
 }

+struct drm_mode_rmfb_work {
+   struct work_struct work;
+   struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+   struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+   drm_framebuffer_remove(arg->fb);
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3454,6 +3466,7 @@ int drm_mode_rmfb(struct drm_device *dev,
struct drm_framebuffer *fbl = NULL;
uint32_t *id = data;
int found = 0;
+   struct drm_mode_rmfb_work arg;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -3474,7 +3487,12 @@ int drm_mode_rmfb(struct drm_device *dev,
mutex_unlock(>mode_config.fb_lock);
mutex_unlock(_priv->fbs_lock);

-   drm_framebuffer_unreference(fb);
+   INIT_WORK_ONSTACK(, drm_mode_rmfb_work_fn);
+   arg.fb = fb;
+
+   schedule_work();
+   flush_work();
+   destroy_work_on_stack();

return 0;

-- 
2.1.0

[Bug 114991] kernel-oops with radeon in Xorg

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #2 from Alex Deucher  ---
Please also attach your xorg log.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 114991] kernel-oops with radeon in Xorg

[bugzilla-dae...@bugzilla.kernel.org]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your full dmesg output.  Is there a reliable trigger?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 3/4 v2] drm: atmel_hldc - use generic drm_connector_register_all() helper

[Boris Brezillon]

On Mon, 21 Mar 2016 15:28:39 +0300
Alexey Brodkin  wrote:

> This driver used to have its own implementation of connector_register_all()
> which actually was taken as a prototype of drm_connector_register_all().
> 
> Now when drm_connector_register_all() exists reusing it here.
> 
> And while at it replace atmel_hlcdc_dc_connector_unplug_all()
> with generic drm_connector_unregister_all().
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Boris Brezillon 

Acked-by: Boris Brezillon 

> ---
> 
> No changes v1 -> v2.
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 39 
> ++--
>  1 file changed, 2 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 3d8d164..1c537e4 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -584,41 +584,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
>   destroy_workqueue(dc->wq);
>  }
>  
> -static int atmel_hlcdc_dc_connector_plug_all(struct drm_device *dev)
> -{
> - struct drm_connector *connector, *failed;
> - int ret;
> -
> - mutex_lock(>mode_config.mutex);
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - ret = drm_connector_register(connector);
> - if (ret) {
> - failed = connector;
> - goto err;
> - }
> - }
> - mutex_unlock(>mode_config.mutex);
> - return 0;
> -
> -err:
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - if (failed == connector)
> - break;
> -
> - drm_connector_unregister(connector);
> - }
> - mutex_unlock(>mode_config.mutex);
> -
> - return ret;
> -}
> -
> -static void atmel_hlcdc_dc_connector_unplug_all(struct drm_device *dev)
> -{
> - mutex_lock(>mode_config.mutex);
> - drm_connector_unplug_all(dev);
> - mutex_unlock(>mode_config.mutex);
> -}
> -
>  static void atmel_hlcdc_dc_lastclose(struct drm_device *dev)
>  {
>   struct atmel_hlcdc_dc *dc = dev->dev_private;
> @@ -736,7 +701,7 @@ static int atmel_hlcdc_dc_drm_probe(struct 
> platform_device *pdev)
>   if (ret)
>   goto err_unload;
>  
> - ret = atmel_hlcdc_dc_connector_plug_all(ddev);
> + ret = drm_connector_register_all(ddev);
>   if (ret)
>   goto err_unregister;
>  
> @@ -758,7 +723,7 @@ static int atmel_hlcdc_dc_drm_remove(struct 
> platform_device *pdev)
>  {
>   struct drm_device *ddev = platform_get_drvdata(pdev);
>  
> - atmel_hlcdc_dc_connector_unplug_all(ddev);
> + drm_connector_unregister_all(ddev);
>   drm_dev_unregister(ddev);
>   atmel_hlcdc_dc_unload(ddev);
>   drm_dev_unref(ddev);



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v2] fence: add missing descriptions for fence

[Luis de Bethencourt]

The members child_list and active_list were added to the fence struct
without descriptions for the Documentation. Adding these.

Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
Signed-off-by: Luis de Bethencourt 
Reviewed-by: Javier Martinez Canillas 
---
Hi,

This second version fixes the commit message as suggested by Javier Martinez.
https://lkml.org/lkml/2016/3/19/135

Thanks,
Luis

 include/linux/fence.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index bb52201..ba5b678 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -49,6 +49,8 @@ struct fence_cb;
  * @timestamp: Timestamp when the fence was signaled.
  * @status: Optional, only valid if < 0, must be set before calling
  * fence_signal, indicates that the fence has completed with an error.
+ * @child_list: list of children fences
+ * @active_list: list of active fences
  *
  * the flags member must be manipulated and read using the appropriate
  * atomic ops (bit_*), so taking the spinlock will not be needed most
-- 
2.6.4

[PATCH] dma-buf: Update docs for SYNC ioctl

[David Herrmann]

Hi

On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter  
wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org
> Cc: Hans Verkuil 
> Acked-by: Sumit Semwal 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..ca44c5820585 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EAGAIN or -EINTR, in which case it must be restarted.

What is "restart on EAGAIN" supposed to mean? Or more generally, what
does EAGAIN tell the caller?

Thanks
David

> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot rely on coherent access, even when there
> +are systems where it just works without calling these ioctls.
>
>  2. Supporting existing mmap interfaces in importers
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:[in]buffer to complete cpu access for.
>   * @direction: [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>enum dma_data_direction direction)
> --
> 2.8.0.rc3
>

[PATCH v2] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

[Nicolai Stange]

The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id
enum transform 1:1 into bit positions within the 'enabled' bitset as
assembled by evergreen_hpd_init():

  enabled |= 1 << radeon_connector->hpd.hpd;

However, if ->hpd.hpd happens to equal RADEON_HPD_NONE == 0xff, UBSAN
reports

  UBSAN: Undefined behaviour in drivers/gpu/drm/radeon/evergreen.c:1867:16
  shift exponent 255 is too large for 32-bit type 'int'
  [...]
  Call Trace:
   [] dump_stack+0xbc/0x117
   [] ? _atomic_dec_and_lock+0x169/0x169
   [] ubsan_epilogue+0xd/0x4e
   [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [] ? atom_execute_table+0x3e/0x50 [radeon]
   [] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [] ? radeon_get_pll_use_mask+0x130/0x130 [radeon]
   [] ? wake_up_klogd_work_func+0x60/0x60
   [] ? vprintk_default+0x3e/0x60
   [] evergreen_hpd_init+0x274/0x2d0 [radeon]
   [] ? evergreen_hpd_init+0x274/0x2d0 [radeon]
   [] radeon_modeset_init+0x8ce/0x18d0 [radeon]
   [] radeon_driver_load_kms+0x186/0x350 [radeon]
   [] drm_dev_register+0xc6/0x100 [drm]
   [] drm_get_pci_dev+0xe4/0x490 [drm]
   [] ? kfree+0x220/0x370
   [] radeon_pci_probe+0x112/0x140 [radeon]
   [...]
  =
  radeon :01:00.0: No connectors reported connected with modes

At least on x86, there should be no user-visible impact as there

  1 << 0xff == 1 << (0xff & 31) == 1 << 31

holds and 31 > RADEON_MAX_HPD_PINS. Thus, this patch is a cosmetic one.

All of the above applies analogously to evergreen_hpd_fini().

Silence UBSAN by checking ->hpd.hpd for RADEON_HPD_NONE before oring it
into the 'enabled' bitset in evergreen_hpd_init() or the 'disabled' bitset
in evergreen_hpd_fini() respectively.

Signed-off-by: Nicolai Stange 
---
 Applicable to linux-next-20160321.

 Changes to v1:
 - Turn commit message's impact part into a non-impact part.

 drivers/gpu/drm/radeon/evergreen.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 76c4bdf..6360717 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1864,7 +1864,8 @@ void evergreen_hpd_init(struct radeon_device *rdev)
break;
}
radeon_hpd_set_polarity(rdev, radeon_connector->hpd.hpd);
-   enabled |= 1 << radeon_connector->hpd.hpd;
+   if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
+   enabled |= 1 << radeon_connector->hpd.hpd;
}
radeon_irq_kms_enable_hpd(rdev, enabled);
 }
@@ -1907,7 +1908,8 @@ void evergreen_hpd_fini(struct radeon_device *rdev)
default:
break;
}
-   disabled |= 1 << radeon_connector->hpd.hpd;
+   if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
+   disabled |= 1 << radeon_connector->hpd.hpd;
}
radeon_irq_kms_disable_hpd(rdev, disabled);
 }
-- 
2.7.3

[PATCH] dma-buf: Update docs for SYNC ioctl

[Sumit Semwal]

On 21 March 2016 at 13:00, Daniel Vetter  wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org
> Signed-off-by: Daniel Vetter 
Acked-by: Sumit Semwal 

> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..5c4e3e586ec8 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EGAIN or -EINTR, in which case it must be restarted.
>
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot on coherent access, even when there are
> +systems where it just works without calling these ioctls.
>
>  2. Supporting existing mmap interfaces in importers
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:[in]buffer to complete cpu access for.
>   * @direction: [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>enum dma_data_direction direction)
> --
> 2.8.0.rc3
>

Best regards,
Sumit.

[Bug 115051] New: HD 5870, GPU lockup

[bugzilla-dae...@bugzilla.kernel.org]

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

Bug ID: 115051
   Summary: HD 5870, GPU lockup
   Product: Drivers
   Version: 2.5
Kernel Version: 4.4;4.5-rc7
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: quentindeldycke at gmail.com
Regression: No

Hi,


Using debian, actually with linux 4.5-rc7 kernel. (bug also present in 4.4).

When i use DRI_PRIME=1, with dri3 enabled (or not) and unigine valley
benchmark, the computer freeze.

Here are the only kernel log available (as whole pc freeze, i activated
netconsole...)


[ 3023.618712] radeon :02:00.0: ring 0 stalled for more than 20040msec
[ 3023.618719] radeon :02:00.0: GPU lockup (current fence id
0x0001bef2 last fence id 0x0001bf04 on ring 0)
[ 3023.618769] radeon :02:00.0: failed to get a new IB (-35)
[ 3023.618797] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to get ib !
[ 3024.181910] radeon :02:00.0: Saved 567 dwords of commands on ring 0.
[ 3024.181925] radeon :02:00.0: GPU softreset: 0x0009
[ 3024.181945] radeon :02:00.0:   GRBM_STATUS   = 0xF5700828
[ 3024.181947] radeon :02:00.0:   GRBM_STATUS_SE0   = 0x8803
[ 3024.181950] radeon :02:00.0:   GRBM_STATUS_SE1   = 0xFC01
[ 3024.181952] radeon :02:00.0:   SRBM_STATUS   = 0x2CC0
[ 3024.181956] radeon :02:00.0:   SRBM_STATUS2  = 0x
[ 3024.181969] radeon :02:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[ 3024.181972] radeon :02:00.0:   R_008678_CP_STALLED_STAT2 = 0x400C
[ 3024.181974] radeon :02:00.0:   R_00867C_CP_BUSY_STAT = 0x00048006
[ 3024.181976] radeon :02:00.0:   R_008680_CP_STAT  = 0x80268647
[ 3024.181979] radeon :02:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[ 3024.447603] radeon :02:00.0: Wait for MC idle timedout !
[ 3024.447609] radeon :02:00.0: GRBM_SOFT_RESET=0x7F6B
[ 3024.447662] radeon :02:00.0: SRBM_SOFT_RESET=0x0100
[ 3024.448818] radeon :02:00.0:   GRBM_STATUS   = 0x3828
[ 3024.448821] radeon :02:00.0:   GRBM_STATUS_SE0   = 0x0007
[ 3024.448823] radeon :02:00.0:   GRBM_STATUS_SE1   = 0x0007
[ 3024.448825] radeon :02:00.0:   SRBM_STATUS   = 0x2CC0
[ 3024.448827] radeon :02:00.0:   SRBM_STATUS2  = 0x
[ 3024.448847] radeon :02:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[ 3024.448851] radeon :02:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[ 3024.448853] radeon :02:00.0:   R_00867C_CP_BUSY_STAT = 0x
[ 3024.448855] radeon :02:00.0:   R_008680_CP_STAT  = 0x
[ 3024.448858] radeon :02:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[ 3024.448878] radeon :02:00.0: GPU reset succeeded, trying to resume
[ 3024.652028] [drm] PCIE gen 2 link speeds already enabled


I tried with kernel parameters:
radeon.hard_reset=1 radeon.audio=0 radeon.dpm=1 radeon.lockup_timeout=2

But none of them seems to have any effect. Note that differently to other bugs
i could find on the tracker, the computer is completely frozen.

Card is a HD 5870 vapor x. It works using a 4x pcie slot. (16x is used on a
vga-passthrough configuration, but not used during this test).

Here are revelant informations:
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD CYPRESS (DRM 2.43.0, LLVM 3.7.1) (0x6898)
Version: 11.2.0
Accelerated: yes
Video memory: 1024MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.1
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CYPRESS (DRM 2.43.0, LLVM 3.7.1)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-rc3
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:

xorg-server 2:1.18.2-1

Radeon module info:
[ 4.422] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[ 4.425] (II) Module radeon: vendor="X.Org Foundation"
[ 4.425]compiled for 1.18.0, module version = 7.6.1
[ 4.425]Module class: X.Org Video Driver
[ 4.425]ABI class: X.Org Video Driver, version 20.0


I know i use a not stable mesa version. It was a last try. But appears also in
mesa 11.1.2...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Lyude Paul]

On Fri, 2016-03-18 at 20:05 +0200, Ville Syrjälä wrote:
> On Fri, Mar 18, 2016 at 07:00:29PM +0100, Daniel Vetter wrote:
> > 
> > On Fri, Mar 18, 2016 at 06:41:40PM +0200, Ville Syrjälä wrote:
> > > 
> > > On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
> > > > 
> > > > On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
> > > > > 
> > > > > On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
> > > > > > 
> > > > > > Since we've fixed up drm_dp_dpcd_read() to allow for retries when
> > > > > > things
> > > > > > timeout, there's no use for having this function anymore. Good
> > > > > > riddens.
> > > > > > 
> > > > > > Signed-off-by: Lyude 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_dp.c | 79 
> > > > > > -
> > > > > >  1 file changed, 22 insertions(+), 57 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index cdc2c15..fb4cbbe5 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct
> > > > > > intel_encoder *encoder)
> > > > > >  }
> > > > > >  
> > > > > >  /*
> > > > > > - * Native read with retry for link status and receiver capability
> > > > > > reads for
> > > > > > - * cases where the sink may still be asleep.
> > > > > > - *
> > > > > > - * Sinks are *supposed* to come up within 1ms from an off state,
> > > > > > but we're also
> > > > > > - * supposed to retry 3 times per the spec.
> > > > > > - */
> > > > > > -static ssize_t
> > > > > > -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int
> > > > > > offset,
> > > > > > -   void *buffer, size_t size)
> > > > > > -{
> > > > > > -   ssize_t ret;
> > > > > > -   int i;
> > > > > > -
> > > > > > -   /*
> > > > > > -    * Sometime we just get the same incorrect byte repeated
> > > > > > -    * over the entire buffer. Doing just one throw away read
> > > > > > -    * initially seems to "solve" it.
> > > > > > -    */
> > > > > > -   drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
> > > > > NAK
> > > > > 
> > > > > If people keep intentionally breaking my shit I'm going to become
> > > > > really grumpy soon.
> > > > Oh, and just in case someone wants to come up with a better kludge,
> > > > I just spent a few minutes analyzing the behavior of this crappy
> > > > monitor a.
> > > > 
> > > > What happens is that when the monitor is fully powered up (LED is blue)
> > > > things are fine. After the monitor goes to sleep (LED turns orange)
> > > > the first DPCD read will produce garbage. Further DPCD reads are fine,
> > > > even if I wait a significant amount of time between the reads, as long
> > > > as the monitor didn't do a power on->off cycle in between. So it looks
> > > > like it's always just the first read after power down that gets
> > > > corrupted.
> > > > 
> > > > Now I think I'll go and test how writes behave, assuming I can find a
> > > > decently sized chunk of DPCD address space I can write. And maybe I
> > > > should also try i2c-over-aux...
> > > The first DPCD write after powerdown also got corrupted. But i2c-over-aux
> > > seems unaffected for whatever reason.
> > Do you have an amd card nearby to test there?
> Nope.
I also work on radeon so I have plenty. The issue with that though is that this
is an issue that only really happens with the thinkpad docks, and as far as I'm
aware we don't have any ThinkPads that have AMD hardware in them…
> > 
> > Would be interesting to
> > confirm that this is indeed a sink bug, and hence that it really all
> > should be in the shared code.
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

[PATCH] dma-buf/sync_file: de-stage sync_file

[Sumit Semwal]

Thanks for the patch, Gustavo!

On 18 March 2016 at 19:49, Gustavo Padovan  wrote:
> From: Gustavo Padovan 
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
I think it is worthwhile to add relevant bits to the Documentation as
well - care to add relevant stuff to either Documentation/dma_buf.txt,
or to a file of its own? (I'd prefer the former, but would leave it
upto you.)

> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/Kconfig|   2 +
>  drivers/dma-buf/Kconfig|  11 +
>  drivers/dma-buf/Makefile   |   1 +
>  drivers/dma-buf/sync_file.c| 382 
> +
>  drivers/staging/android/Kconfig|   1 +
>  drivers/staging/android/sync.c | 362 ---
>  drivers/staging/android/sync.h |  92 +
>  drivers/staging/android/sync_debug.c   |   1 +
>  include/linux/sync_file.h  | 106 ++
>  .../uapi/sync.h => include/uapi/linux/sync_file.h  |   0
>  10 files changed, 506 insertions(+), 452 deletions(-)
>  create mode 100644 drivers/dma-buf/Kconfig
>  create mode 100644 drivers/dma-buf/sync_file.c
>  create mode 100644 include/linux/sync_file.h
>  rename drivers/staging/android/uapi/sync.h => include/uapi/linux/sync_file.h 
> (100%)
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index d2ac339..430f761 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -114,6 +114,8 @@ source "drivers/rtc/Kconfig"
>
>  source "drivers/dma/Kconfig"
>
> +source "drivers/dma-buf/Kconfig"
> +
>  source "drivers/dca/Kconfig"
>
>  source "drivers/auxdisplay/Kconfig"
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> new file mode 100644
> index 000..9824bc4
> --- /dev/null
> +++ b/drivers/dma-buf/Kconfig
> @@ -0,0 +1,11 @@
> +menu "DMABUF options"
> +
> +config SYNC_FILE
> +   bool "sync_file support for fences"
> +   default n
> +   select ANON_INODES
> +   select DMA_SHARED_BUFFER
> +   ---help---
> + This option enables the fence framework synchronization to export
> + sync_files to userspace that can represent one or more fences.
> +endmenu
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 57a675f..4a424ec 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1 +1,2 @@
>  obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
> +obj-$(CONFIG_SYNC_FILE)+= sync_file.o
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> new file mode 100644
> index 000..df786a2
> --- /dev/null
> +++ b/drivers/dma-buf/sync_file.c
> @@ -0,0 +1,382 @@
> +/*
> + * drivers/dma-buf/sync_file.c
> + *
> + * Copyright (C) 2012 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct file_operations sync_file_fops;
> +
> +static struct sync_file *sync_file_alloc(int size, const char *name)
> +{
> +   struct sync_file *sync_file;
> +
> +   sync_file = kzalloc(size, GFP_KERNEL);
> +   if (!sync_file)
> +   return NULL;
> +
> +   sync_file->file = anon_inode_getfile("sync_file", _file_fops,
> +sync_file, 0);
> +   if (IS_ERR(sync_file->file))
> +   goto err;
> +
> +   kref_init(_file->kref);
> +   strlcpy(sync_file->name, name, sizeof(sync_file->name));
> +
> +   init_waitqueue_head(_file->wq);
> +
> +   return sync_file;
> +
> +err:
> +   kfree(sync_file);
> +   return NULL;
> +}
> +
> +static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
> +{
> +   struct sync_file_cb *check;
> +   struct sync_file *sync_file;
> +
> +   check = container_of(cb, struct sync_file_cb, cb);
> +   sync_file = check->sync_file;
> +
> +   if (atomic_dec_and_test(_file->status))
> +   wake_up_all(_file->wq);
> +}
> +
> +/* TODO: implement a create which takes more that one fence */
> +struct sync_file *sync_file_create(const char *name, struct fence *fence)
> +{
> +   struct sync_file *sync_file;
> +
> +   sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]),
> +   name);
> +   if (!sync_file)
> +   

[Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

[Jani Nikula]

On Fri, 18 Mar 2016, Ville Syrjälä  wrote:
> On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote:
>> On Fri, Mar 18, 2016 at 04:13:45PM +0200, Ville Syrjälä wrote:
>> > On Thu, Mar 17, 2016 at 11:40:45AM -0400, Lyude wrote:
>> > > -drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
>> > 
>> > NAK
>> > 
>> > If people keep intentionally breaking my shit I'm going to become
>> > really grumpy soon.
>> 
>> Oh, and just in case someone wants to come up with a better kludge,
>> I just spent a few minutes analyzing the behavior of this crappy
>> monitor a.
>> 
>> What happens is that when the monitor is fully powered up (LED is blue)
>> things are fine. After the monitor goes to sleep (LED turns orange)
>> the first DPCD read will produce garbage. Further DPCD reads are fine,
>> even if I wait a significant amount of time between the reads, as long
>> as the monitor didn't do a power on->off cycle in between. So it looks
>> like it's always just the first read after power down that gets
>> corrupted.
>> 
>> Now I think I'll go and test how writes behave, assuming I can find a
>> decently sized chunk of DPCD address space I can write. And maybe I
>> should also try i2c-over-aux...
>
> The first DPCD write after powerdown also got corrupted. But i2c-over-aux
> seems unaffected for whatever reason.

Did the display go to sleep on its own, or did we do something? In
particular, does DPCD DP_SET_POWER register play a role? What if we skip
writing D3 to it? What if we do that write as the first thing (every
time)?


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[RFC PATCH v1 0/4] Add Rockchip RGA support

[Heiko Stübner]

Hi Yakir,

Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang:
> This patch set would add the RGA direct rendering based 2d graphics
> acceleration module.

very cool to see that.

> This patch set is based on git repository below:
> git://people.freedesktop.org/~airlied/linux drm-next
> commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7
> 
> And the RGA driver is based on Exynos G2D driver, it only manages the
> command lists received from user, so user should make the command list
> to data and registers needed by operation to use.
> 
> I have prepared an userspace demo application for testing:
>   https://github.com/yakir-Yang/libdrm-rockchip
> That is a rockchip libdrm library, and I have write a simple test case
> "rockchip_rga_test" that would test the below RGA features:
> - solid
> - copy
> - rotation
> - flip
> - window clip
> - dithering

Did you submit your libdrm changes as well?

Userspace-interfaces need to be stable so the other side must also get 
accepted - even before the kernel change if I remember correctly.


Heiko

[PATCH v2] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

[Alex Deucher]

On Mon, Mar 21, 2016 at 8:10 AM, Nicolai Stange  wrote:
> The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id
> enum transform 1:1 into bit positions within the 'enabled' bitset as
> assembled by evergreen_hpd_init():
>
>   enabled |= 1 << radeon_connector->hpd.hpd;
>
> However, if ->hpd.hpd happens to equal RADEON_HPD_NONE == 0xff, UBSAN
> reports
>
>   UBSAN: Undefined behaviour in drivers/gpu/drm/radeon/evergreen.c:1867:16
>   shift exponent 255 is too large for 32-bit type 'int'
>   [...]
>   Call Trace:
>[] dump_stack+0xbc/0x117
>[] ? _atomic_dec_and_lock+0x169/0x169
>[] ubsan_epilogue+0xd/0x4e
>[] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
>[] ? atom_execute_table+0x3e/0x50 [radeon]
>[] ? __ubsan_handle_load_invalid_value+0x158/0x158
>[] ? radeon_get_pll_use_mask+0x130/0x130 [radeon]
>[] ? wake_up_klogd_work_func+0x60/0x60
>[] ? vprintk_default+0x3e/0x60
>[] evergreen_hpd_init+0x274/0x2d0 [radeon]
>[] ? evergreen_hpd_init+0x274/0x2d0 [radeon]
>[] radeon_modeset_init+0x8ce/0x18d0 [radeon]
>[] radeon_driver_load_kms+0x186/0x350 [radeon]
>[] drm_dev_register+0xc6/0x100 [drm]
>[] drm_get_pci_dev+0xe4/0x490 [drm]
>[] ? kfree+0x220/0x370
>[] radeon_pci_probe+0x112/0x140 [radeon]
>[...]
>   =
>   radeon :01:00.0: No connectors reported connected with modes
>
> At least on x86, there should be no user-visible impact as there
>
>   1 << 0xff == 1 << (0xff & 31) == 1 << 31
>
> holds and 31 > RADEON_MAX_HPD_PINS. Thus, this patch is a cosmetic one.
>
> All of the above applies analogously to evergreen_hpd_fini().
>
> Silence UBSAN by checking ->hpd.hpd for RADEON_HPD_NONE before oring it
> into the 'enabled' bitset in evergreen_hpd_init() or the 'disabled' bitset
> in evergreen_hpd_fini() respectively.
>
> Signed-off-by: Nicolai Stange 

Can you please fix all instances of this?  This same pattern is
repeated in various asic families.

Alex


> ---
>  Applicable to linux-next-20160321.
>
>  Changes to v1:
>  - Turn commit message's impact part into a non-impact part.
>
>  drivers/gpu/drm/radeon/evergreen.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 76c4bdf..6360717 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1864,7 +1864,8 @@ void evergreen_hpd_init(struct radeon_device *rdev)
> break;
> }
> radeon_hpd_set_polarity(rdev, radeon_connector->hpd.hpd);
> -   enabled |= 1 << radeon_connector->hpd.hpd;
> +   if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
> +   enabled |= 1 << radeon_connector->hpd.hpd;
> }
> radeon_irq_kms_enable_hpd(rdev, enabled);
>  }
> @@ -1907,7 +1908,8 @@ void evergreen_hpd_fini(struct radeon_device *rdev)
> default:
> break;
> }
> -   disabled |= 1 << radeon_connector->hpd.hpd;
> +   if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
> +   disabled |= 1 << radeon_connector->hpd.hpd;
> }
> radeon_irq_kms_disable_hpd(rdev, disabled);
>  }
> --
> 2.7.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105711] amdgpu: no monitor signal (modprobe amdgpu fails)

[bugzilla-dae...@bugzilla.kernel.org]

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

Lars W.  changed:

   What|Removed |Added

 Kernel Version|4.3-rc4 |4.5

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 2/2] drm/amdgpu: add invalidate_page callback for userptrs

[Alex Deucher]

On Fri, Mar 18, 2016 at 2:29 PM, Christian König
 wrote:
> From: Christian König 
>
> Otherwise we can run into problems with the writeback code.
>
> Signed-off-by: Christian König 

Applied the series.

Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 98 
> +-
>  1 file changed, 72 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> index c47f..9f4a45c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> @@ -106,6 +106,76 @@ static void amdgpu_mn_release(struct mmu_notifier *mn,
>  }
>
>  /**
> + * amdgpu_mn_invalidate_node - unmap all BOs of a node
> + *
> + * @node: the node with the BOs to unmap
> + *
> + * We block for all BOs and unmap them by move them
> + * into system domain again.
> + */
> +static void amdgpu_mn_invalidate_node(struct amdgpu_mn_node *node,
> + unsigned long start,
> + unsigned long end)
> +{
> +   struct amdgpu_bo *bo;
> +   long r;
> +
> +   list_for_each_entry(bo, >bos, mn_list) {
> +
> +   if (!amdgpu_ttm_tt_affect_userptr(bo->tbo.ttm, start, end))
> +   continue;
> +
> +   r = amdgpu_bo_reserve(bo, true);
> +   if (r) {
> +   DRM_ERROR("(%ld) failed to reserve user bo\n", r);
> +   continue;
> +   }
> +
> +   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
> +   true, false, MAX_SCHEDULE_TIMEOUT);
> +   if (r <= 0)
> +   DRM_ERROR("(%ld) failed to wait for user bo\n", r);
> +
> +   amdgpu_ttm_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
> +   r = ttm_bo_validate(>tbo, >placement, false, false);
> +   if (r)
> +   DRM_ERROR("(%ld) failed to validate user bo\n", r);
> +
> +   amdgpu_bo_unreserve(bo);
> +   }
> +}
> +
> +/**
> + * amdgpu_mn_invalidate_page - callback to notify about mm change
> + *
> + * @mn: our notifier
> + * @mn: the mm this callback is about
> + * @address: address of invalidate page
> + *
> + * Invalidation of a single page. Blocks for all BOs mapping it
> + * and unmap them by move them into system domain again.
> + */
> +static void amdgpu_mn_invalidate_page(struct mmu_notifier *mn,
> + struct mm_struct *mm,
> + unsigned long address)
> +{
> +   struct amdgpu_mn *rmn = container_of(mn, struct amdgpu_mn, mn);
> +   struct interval_tree_node *it;
> +
> +   mutex_lock(>lock);
> +
> +   it = interval_tree_iter_first(>objects, address, address);
> +   if (it) {
> +   struct amdgpu_mn_node *node;
> +
> +   node = container_of(it, struct amdgpu_mn_node, it);
> +   amdgpu_mn_invalidate_node(node, address, address);
> +   }
> +
> +   mutex_unlock(>lock);
> +}
> +
> +/**
>   * amdgpu_mn_invalidate_range_start - callback to notify about mm change
>   *
>   * @mn: our notifier
> @@ -132,36 +202,11 @@ static void amdgpu_mn_invalidate_range_start(struct 
> mmu_notifier *mn,
> it = interval_tree_iter_first(>objects, start, end);
> while (it) {
> struct amdgpu_mn_node *node;
> -   struct amdgpu_bo *bo;
> -   long r;
>
> node = container_of(it, struct amdgpu_mn_node, it);
> it = interval_tree_iter_next(it, start, end);
>
> -   list_for_each_entry(bo, >bos, mn_list) {
> -
> -   if (!amdgpu_ttm_tt_affect_userptr(bo->tbo.ttm, start,
> - end))
> -   continue;
> -
> -   r = amdgpu_bo_reserve(bo, true);
> -   if (r) {
> -   DRM_ERROR("(%ld) failed to reserve user 
> bo\n", r);
> -   continue;
> -   }
> -
> -   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
> -   true, false, MAX_SCHEDULE_TIMEOUT);
> -   if (r <= 0)
> -   DRM_ERROR("(%ld) failed to wait for user 
> bo\n", r);
> -
> -   amdgpu_ttm_placement_from_domain(bo, 
> AMDGPU_GEM_DOMAIN_CPU);
> -   r = ttm_bo_validate(>tbo, >placement, false, 
> false);
> -   if (r)
> -   DRM_ERROR("(%ld) failed to validate user 
> bo\n", r);
> -
> -   amdgpu_bo_unreserve(bo);
> -   }
> +   amdgpu_mn_invalidate_node(node, start, end);
> }
>
> mutex_unlock(>lock);
> @@ -169,6 +214,7 @@ static void 

[PATCH 01/14] drm/radeon: consolidate r600 uvd initialization and startup code.

[Alex Deucher]

On Fri, Mar 18, 2016 at 12:44 PM, Christian König
 wrote:
> Am 18.03.2016 um 16:58 schrieb Jérôme Glisse:
>>
>> From: Jérome Glisse 
>>
>> This match the exact same control flow as existing code. It just
>> use goto instead of multiple levels of if/else. It also clarify
>> early initialization failures by clearing rdev->has_uvd doing so
>> does not change end result from hardware point of view, it only
>> avoids printing more error messages down the line and thus only
>> the original error is reported.
>>
>> Signed-off-by: Jérôme Glisse 
>> Cc: Alex Deucher 
>> Cc: Christian König 
>
>
> Patches #7 and #11-#14 are Reviewed-by: Christian König
> 
>
> Patches #1-#6 and #8-#10 are Acked-by: Christian König
> 
>

Applied.  thanks!

Alex

> Thanks,
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/radeon/r600.c | 99
>> ++-
>>   1 file changed, 70 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index f86ab69..24fa982 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -3035,6 +3035,73 @@ void r600_clear_surface_reg(struct radeon_device
>> *rdev, int reg)
>> /* FIXME: implement */
>>   }
>>   +static void r600_uvd_init(struct radeon_device *rdev)
>> +{
>> +   int r;
>> +
>> +   if (!rdev->has_uvd)
>> +   return;
>> +
>> +   r = radeon_uvd_init(rdev);
>> +   if (r) {
>> +   dev_err(rdev->dev, "failed UVD (%d) init.\n", r);
>> +   /*
>> +* At this point rdev->uvd.vcpu_bo is NULL which trickles
>> down
>> +* to early fails uvd_v1_0_resume() and thus nothing
>> happens
>> +* there. So it is pointless to try to go through that
>> code
>> +* hence why we disable uvd here.
>> +*/
>> +   rdev->has_uvd = 0;
>> +   return;
>> +   }
>> +   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_obj = NULL;
>> +   r600_ring_init(rdev, >ring[R600_RING_TYPE_UVD_INDEX], 4096);
>> +}
>> +
>> +static void r600_uvd_start(struct radeon_device *rdev)
>> +{
>> +   int r;
>> +
>> +   if (!rdev->has_uvd)
>> +   return;
>> +
>> +   r = uvd_v1_0_resume(rdev);
>> +   if (r) {
>> +   dev_err(rdev->dev, "failed UVD resume (%d).\n", r);
>> +   goto error;
>> +   }
>> +   r = radeon_fence_driver_start_ring(rdev,
>> R600_RING_TYPE_UVD_INDEX);
>> +   if (r) {
>> +   dev_err(rdev->dev, "failed initializing UVD fences
>> (%d).\n", r);
>> +   goto error;
>> +   }
>> +   return;
>> +
>> +error:
>> +   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
>> +}
>> +
>> +static void r600_uvd_resume(struct radeon_device *rdev)
>> +{
>> +   struct radeon_ring *ring;
>> +   int r;
>> +
>> +   if (!rdev->has_uvd ||
>> !rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size)
>> +   return;
>> +
>> +   ring = >ring[R600_RING_TYPE_UVD_INDEX];
>> +   r = radeon_ring_init(rdev, ring, ring->ring_size, 0,
>> RADEON_CP_PACKET2);
>> +   if (r) {
>> +   dev_err(rdev->dev, "failed initializing UVD ring (%d).\n",
>> r);
>> +   return;
>> +   }
>> +   r = uvd_v1_0_init(rdev);
>> +   if (r) {
>> +   dev_err(rdev->dev, "failed initializing UVD (%d).\n", r);
>> +   return;
>> +   }
>> +}
>> +
>>   static int r600_startup(struct radeon_device *rdev)
>>   {
>> struct radeon_ring *ring;
>> @@ -3070,17 +3137,7 @@ static int r600_startup(struct radeon_device *rdev)
>> return r;
>> }
>>   - if (rdev->has_uvd) {
>> -   r = uvd_v1_0_resume(rdev);
>> -   if (!r) {
>> -   r = radeon_fence_driver_start_ring(rdev,
>> R600_RING_TYPE_UVD_INDEX);
>> -   if (r) {
>> -   dev_err(rdev->dev, "failed initializing
>> UVD fences (%d).\n", r);
>> -   }
>> -   }
>> -   if (r)
>> -   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size =
>> 0;
>> -   }
>> +   r600_uvd_start(rdev);
>> /* Enable IRQ */
>> if (!rdev->irq.installed) {
>> @@ -3110,17 +3167,7 @@ static int r600_startup(struct radeon_device *rdev)
>> if (r)
>> return r;
>>   - if (rdev->has_uvd) {
>> -   ring = >ring[R600_RING_TYPE_UVD_INDEX];
>> -   if (ring->ring_size) {
>> -   r = radeon_ring_init(rdev, ring, ring->ring_size,
>> 0,
>> -RADEON_CP_PACKET2);
>> -   if (!r)
>> -   r = uvd_v1_0_init(rdev);
>> -   if (r)
>> -   DRM_ERROR("radeon: failed initializing UVD
>> (%d).\n", r);
>> -   }
>> -   }
>> +   

[PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()

[Sumit Semwal]

On 19 March 2016 at 15:39, Daniel Vetter  wrote:
> On Fri, Mar 18, 2016 at 08:02:39PM +, Chris Wilson wrote:
>> Drivers, especially i915.ko, can fail during the initial migration of a
>> dma-buf for CPU access. However, the error code from the driver was not
>> being propagated back to ioctl and so userspace was blissfully ignorant
>> of the failure. Rendering corruption ensues.
>>
>> Whilst fixing the ioctl to return the error code from
>> dma_buf_start_cpu_access(), also do the same for
>> dma_buf_end_cpu_access().  For most drivers, dma_buf_end_cpu_access()
>> cannot fail. i915.ko however, as most drivers would, wants to avoid being
>> uninterruptible (as would be required to guarrantee no failure when
>> flushing the buffer to the device). As userspace already has to handle
>> errors from the SYNC_IOCTL, take advantage of this to be able to restart
>> the syscall across signals.
>>
>> This fixes a coherency issue for i915.ko as well as reducing the
>> uninterruptible hold upon its BKL, the struct_mutex.
>>
>> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
>> Author: Daniel Vetter 
>> Date:   Thu Feb 11 20:04:51 2016 -0200
>>
>> dma-buf: Add ioctls to allow userspace to flush
>>
>> Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
>> Testcase: igt/prime_mmap_coherency/ioctl-errors
>> Signed-off-by: Chris Wilson 
>> Cc: Tiago Vignatti 
>> Cc: Stéphane Marchesin 
>> Cc: David Herrmann 
>> Cc: Sumit Semwal 
>> Cc: Daniel Vetter 
>> CC: linux-media at vger.kernel.org
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: linaro-mm-sig at lists.linaro.org
>> Cc: intel-gfx at lists.freedesktop.org
>> Cc: devel at driverdev.osuosl.org
>
> Applied to drm-misc, I'll send a pull to Dave the next few days if no one
> screams.
> -Daniel
Thanks for pulling it via drm-misc, Daniel.
Chris, I feel since this is an API change, it also needs an update to
the Documentation file.
With that, and a minor nit below, please feel free to add
Acked-by: Sumit Semwal 

>
>> ---
>>  drivers/dma-buf/dma-buf.c | 17 +++--
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
>>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  5 +++--
>>  drivers/gpu/drm/udl/udl_fb.c  |  4 ++--
>>  drivers/staging/android/ion/ion.c |  6 --
>>  include/linux/dma-buf.h   |  6 +++---
>>  6 files changed, 28 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 9810d1df0691..774a60f4309a 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
>>   struct dma_buf *dmabuf;
>>   struct dma_buf_sync sync;
>>   enum dma_data_direction direction;
>> + int ret;
>>
>>   dmabuf = file->private_data;
>>
>> @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
>>   }
>>
>>   if (sync.flags & DMA_BUF_SYNC_END)
>> - dma_buf_end_cpu_access(dmabuf, direction);
>> + ret = dma_buf_end_cpu_access(dmabuf, direction);
>>   else
>> - dma_buf_begin_cpu_access(dmabuf, direction);
>> + ret = dma_buf_begin_cpu_access(dmabuf, direction);
>>
>> - return 0;
>> + return ret;
>>   default:
>>   return -ENOTTY;
>>   }
>> @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>>   *
>>   * This call must always succeed.
>>   */
Perhaps update the above comment to reflect the change as well?

>> -void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>> - enum dma_data_direction direction)
>> +int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>> +enum dma_data_direction direction)
>>  {
>> + int ret = 0;
>> +
>>   WARN_ON(!dmabuf);
>>
>>   if (dmabuf->ops->end_cpu_access)
>> - dmabuf->ops->end_cpu_access(dmabuf, direction);
>> + ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
>> +
>> + return ret;
>>  }
<< snip>>

Best regards,
Sumit.

[PATCH 1/3] drm: introduce drm_connector_plug_all() helper

[Alexey Brodkin]

Hi Daniel,

On Sat, 2016-03-19 at 11:02 +0100, Daniel Vetter wrote:
> On Fri, Mar 18, 2016 at 09:58:49PM +, Alexey Brodkin wrote:
> > 
> > Hi Daniel,
> > 
> > On Fri, 2016-03-18 at 19:06 +0100, Daniel Vetter wrote:
> > > 
> > > On Fri, Mar 18, 2016 at 01:01:42PM +0300, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > As a pair to already existing drm_connector_unplug_all() we're adding
> > > > generic implementation of what is already done in some drivers.
> > > > 
> > > > Once this helper is implemented we'll be ready to switch existing
> > > > driver-specific implementations with generic one.
> > > > 
> > > > Signed-off-by: Alexey Brodkin 
> > > > Cc: Daniel Vetter 
> > > > Cc: David Airlie 
> > > > ---
> > > >  drivers/gpu/drm/drm_crtc.c | 44 
> > > > +++-
> > > >  drivers/gpu/drm/drm_drv.c  |  3 ++-
> > > >  include/drm/drm_crtc.h     |  3 ++-
> > > >  3 files changed, 47 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > > index 65258ac..ce27420 100644
> > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -1080,6 +1080,46 @@ void drm_connector_unregister(struct 
> > > > drm_connector *connector)
> > > >  }
> > > >  EXPORT_SYMBOL(drm_connector_unregister);
> > > >  
> > > > +/**
> > > > + * drm_connector_plug_all - register connector userspace interfaces
> > > > + * @dev: drm device
> > > > + *
> > > > + * This function registers all connector userspace interfaces in 
> > > > sysfs. Should
> > > > + * be call when the device is disconnected, e.g. from an usb driver's
> > > Still talks about disconnect ;-) Please also mention that this just calls
> > > drm_connector_register() exactly like this including () to generate a
> > > kerneldoc hyperlink.
> > Well I intentionally left in description of drm_connector_register_all():
> > "Should be call when the device is disconnected, e.g. from an usb driver's
> >  ->connect callback."
> You use "disconnected" for connecting stuff. That doesn't make sense to me
> at all - register_all is for when you want to publish something, not for
> unpublishing when the device disappears. Or maybe this is a case of lost
> in translation, and you mean something else?

Let me try to explain what I meant.

We execute ->connect() callback of USB device when USB device is still in 
"disconnected" state
(well at least that was my thought). And only when that ->connect() callback 
succeeds we're
entering "connected" state.

Probably above sentence is not correct. Then could you please help me with 
correct wording of
comment to drm_connector_register_all()?

-Alexey

[Bug 106901] Brightness / WIFI Key does not generate any events

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #31 from Roman Gruber  ---
Do you guys need any additional data?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 106901] Brightness / WIFI Key does not generate any events

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #30 from Roman Gruber  ---
Updated kernel, same behaviour

[  256.292089] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292190] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292247] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292301] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292381] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292435] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292487] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292544] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.292668] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.664925] ACPI Warning: \_SB.PCI0.PEG0.GFX0._DSM: Argument #4 type
mismatch - Found [Buffer], ACPI requires [Package] (20160108/nsarguments-95)
[  256.850043] i2c i2c-0: adapter [NVIDIA i2c adapter 0 at 1:00.0] registered
[  256.850231] i2c i2c-1: adapter [NVIDIA i2c adapter 1 at 1:00.0] registered
[  256.850272] i2c i2c-2: adapter [NVIDIA i2c adapter 2 at 1:00.0] registered
[  256.850309] i2c i2c-3: adapter [NVIDIA i2c adapter 6 at 1:00.0] registered
[  256.850396] i2c i2c-4: adapter [NVIDIA i2c adapter 8 at 1:00.0] registered
[  256.850454] i2c i2c-5: adapter [NVIDIA i2c adapter 10 at 1:00.0] registered
[  256.856793] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for
UNIX platforms  361.28  Wed Feb  3 15:15:17 PST 2016
[  256.857323] nvidia-modeset: Allocated GPU:0
(GPU-f0386eeb-393c-7918-1fe8-3be667a9f4e7) @ PCI::01:00.0
ASUS-G75VW roman # uname -a
Linux ASUS-G75VW 4.5.0-gentoo_03_21_2016 #1 SMP Mon Mar 21 11:25:43 CET 2016
x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 106901] Brightness / WIFI Key does not generate any events

[bugzilla-dae...@bugzilla.kernel.org]

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

Roman Gruber  changed:

   What|Removed |Added

 Kernel Version|Linux ASUS-G75VW|4.5.0
   |4.4.4-gentoo_03/09/2016 #2  |
   |SMP Wed Mar 9 12:38:37 CET  |
   |2016 x86_64 Intel(R)|
   |Core(TM) i7-3610QM CPU @|
   |2.30GHz GenuineIntel|
   |GNU/Linux   |

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] dma-buf: Update docs for SYNC ioctl

[Tiago Vignatti]

On 03/21/2016 04:51 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org
> Cc: Hans Verkuil 
> Acked-by: Sumit Semwal 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Tiago Vignatti 

Best regards,

Tiago


> ---
>   Documentation/dma-buf-sharing.txt | 11 ++-
>   drivers/dma-buf/dma-buf.c |  2 +-
>   2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..ca44c5820585 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>
>  No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
>  sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is 
> *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EAGAIN or -EINTR, in which case it must be restarted.
>
>  Some systems might need some sort of cache coherency management e.g. when
>  CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
>  want (with the new data being consumed by the GPU or say scanout 
> device)
>- munmap once you don't need the buffer any more
>
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot rely on coherent access, even when there
> +are systems where it just works without calling these ioctls.
>
>   2. Supporting existing mmap interfaces in importers
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>* @dmabuf: [in]buffer to complete cpu access for.
>* @direction:  [in]length of range for cpu access.
>*
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>*/
>   int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>  enum dma_data_direction direction)
>

[PATCH] dma-buf,drm,ion: Propagate error code from dma_buf_start_cpu_access()

[Tiago Vignatti]

On 03/18/2016 05:02 PM, Chris Wilson wrote:
> Drivers, especially i915.ko, can fail during the initial migration of a
> dma-buf for CPU access. However, the error code from the driver was not
> being propagated back to ioctl and so userspace was blissfully ignorant
> of the failure. Rendering corruption ensues.
>
> Whilst fixing the ioctl to return the error code from
> dma_buf_start_cpu_access(), also do the same for
> dma_buf_end_cpu_access().  For most drivers, dma_buf_end_cpu_access()
> cannot fail. i915.ko however, as most drivers would, wants to avoid being
> uninterruptible (as would be required to guarrantee no failure when
> flushing the buffer to the device). As userspace already has to handle
> errors from the SYNC_IOCTL, take advantage of this to be able to restart
> the syscall across signals.
>
> This fixes a coherency issue for i915.ko as well as reducing the
> uninterruptible hold upon its BKL, the struct_mutex.
>
> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
> Author: Daniel Vetter 
> Date:   Thu Feb 11 20:04:51 2016 -0200
>
>  dma-buf: Add ioctls to allow userspace to flush
>
> Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
> Testcase: igt/prime_mmap_coherency/ioctl-errors
> Signed-off-by: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org

Reviewed-by: Tiago Vignatti 

Best regards,

Tiago

[PATCH v8 6/6] ARM: dts: am335x-boneblack: Add HDMI audio support

[Jyri Sarha]

On 03/19/16 08:39, Jean-Francois Moine wrote:
> On Thu, 17 Mar 2016 14:22:34 +0200
> Jyri Sarha  wrote:
> 
>> @@ -76,16 +87,22 @@
>>  };
>>  
>>   {
>> -tda19988 {
>> +tda19988: tda19988 {
>>  compatible = "nxp,tda998x";
>>  reg = <0x70>;
>> +
>>  pinctrl-names = "default", "off";
>>  pinctrl-0 = <_hdmi_bonelt_pins>;
>>  pinctrl-1 = <_hdmi_bonelt_off_pins>;
>>  
>> -port {
>> -hdmi_0: endpoint at 0 {
>> -remote-endpoint = <_0>;
>> +#sound-dai-cells = <0>;
>> +audio-ports = < AFMT_I2S0x03>;
>> +
>> +ports {
>> +port at 0 {
>> +hdmi_0: endpoint at 0 {
>> +remote-endpoint = <_0>;
>> +};
>>  };
>>  };
>>  };
> 
> Why did you add a 'ports' container? As there is only one port,
> it is useless.
> 

Well, I just left it there. The node parsing code should handle the
container if it follows graph[1] binding. Putting the ports container
node is equally correct as leaving it out, but surely I can leave it out
next time (when ever it comes).

> Also, you don't need '@0' in the 'port' and 'endpoint'.
> If you want to keep it, you must add 'reg = 0;'s.
> 

I am still not sure about the "must" part. From all that I have read[2]
the unit number should be the same as reg property if possible. But then
again if the reg property consists of multiple addresses, how do you put
them in the unit address? To me no unit address at all is an analogue
situation and I see no point in adding an artificial reg property if I
need multiple nodes by same name. This actually happens quite often with
sound-nodes when I have multiple audio devices in the same system.

But still, there is no need for the unit address here and it should be
removed. I'll do that next time.

Best regard,
Jyri

[1] Documentation/devicetree/bindings/graph.txt
[2] http://devicetree.org/Device_Tree_Usage

[PATCHv13 01/17] dts: exynos4*: add HDMI CEC pin definition to pinctrl

[Krzysztof Kozlowski]

On 19.03.2016 17:15, Hans Verkuil wrote:
> On 03/19/2016 03:50 AM, Krzysztof Kozlowski wrote:
>> On Fri, Mar 18, 2016 at 03:07:00PM +0100, Hans Verkuil wrote:
>>> From: Kamil Debski 
>>>
>>> Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
>>> Exynos4x12 SoCs. These are required by the HDMI CEC device.
>>>
>>> Signed-off-by: Kamil Debski 
>>> Signed-off-by: Hans Verkuil 
>>> Acked-by: Krzysztof Kozlowski 
>>> ---
>>>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++
>>>  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++
>>>  2 files changed, 14 insertions(+)
>>
>> Hi Hans,
>>
>> I see you have been carrying these three patches for a long time.
>> Initially I thought that there are some dependencies... but maybe there
>> are not?
>>
>> Can I take these Exynos DTS patches to samsung-soc?
> 
> That would be very nice!

I'll apply them after merge window.


> BTW, it would be nice if someone from Samsung could try to improve the s5p
> CEC driver from this patch series.
> 
> The problem is that it expects userspace to tell it the physical address,
> which is read from the EDID. But the HDMI driver in the kernel already knows
> this, so requiring userspace to handle this is not nice.
> 
> Basically the CEC driver needs to know when a new EDID has been read and
> when the hotplug detect goes low (EDID has been lost).
> 
> If someone who actually knows the HDMI code could provide me with a patch,
> then I can fix the CEC driver. I have an odroid to test with, so I can check
> the code.

Not quite my area of knowledge but I'll keep it in mind.

Best regards,
Krzysztof

[PATCH] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

[Nicolai Stange]

Nicolai Stange  writes:

> The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id
> enum transform 1:1 into bit positions within the 'enabled' bitset as
> assembled by evergreen_hpd_init():
>
>   enabled |= 1 << radeon_connector->hpd.hpd;
>
> However, if ->hpd.hpd happens to equal RADEON_HPD_NONE == 0xff, UBSAN
> reports
>
>   UBSAN: Undefined behaviour in drivers/gpu/drm/radeon/evergreen.c:1867:16
>   shift exponent 255 is too large for 32-bit type 'int'
>   [...]
>   Call Trace:
>[] dump_stack+0xbc/0x117
>[] ? _atomic_dec_and_lock+0x169/0x169
>[] ubsan_epilogue+0xd/0x4e
>[] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
>[] ? atom_execute_table+0x3e/0x50 [radeon]
>[] ? __ubsan_handle_load_invalid_value+0x158/0x158
>[] ? radeon_get_pll_use_mask+0x130/0x130 [radeon]
>[] ? wake_up_klogd_work_func+0x60/0x60
>[] ? vprintk_default+0x3e/0x60
>[] evergreen_hpd_init+0x274/0x2d0 [radeon]
>[] ? evergreen_hpd_init+0x274/0x2d0 [radeon]
>[] radeon_modeset_init+0x8ce/0x18d0 [radeon]
>[] radeon_driver_load_kms+0x186/0x350 [radeon]
>[] drm_dev_register+0xc6/0x100 [drm]
>[] drm_get_pci_dev+0xe4/0x490 [drm]
>[] ? kfree+0x220/0x370
>[] radeon_pci_probe+0x112/0x140 [radeon]
>[...]
>   =
>   radeon :01:00.0: No connectors reported connected with modes
>
> The net effect is that radeon_irq_kms_enable_hpd() enables the HPD
> interrupts for all HPD pins in the range from 0 to RADEON_MAX_HPD_PINS.


And this is obviously wrong: I mixed the shift count 0xff with the final
value when reasoning about the implications :(
1 << 0xff == 1 << 0x1f == 2^31 on x86 at least. Thus the net effect is
nothing.

I will resend later this day with an updated description.




> The system seems to work without any noticeable glitches though.
>
> All of the above applies analogously to evergreen_hpd_fini().
>
> Silence UBSAN by checking ->hpd.hpd for RADEON_HPD_NONE before oring it
> into the 'enabled' bitset in evergreen_hpd_init() or the 'disabled' bitset
> in evergreen_hpd_fini() respectively.
>
> Signed-off-by: Nicolai Stange 
> ---
>  Applicable to linux-next-20160318.
>
>  drivers/gpu/drm/radeon/evergreen.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 76c4bdf..6360717 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1864,7 +1864,8 @@ void evergreen_hpd_init(struct radeon_device *rdev)
>   break;
>   }
>   radeon_hpd_set_polarity(rdev, radeon_connector->hpd.hpd);
> - enabled |= 1 << radeon_connector->hpd.hpd;
> + if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
> + enabled |= 1 << radeon_connector->hpd.hpd;
>   }
>   radeon_irq_kms_enable_hpd(rdev, enabled);
>  }
> @@ -1907,7 +1908,8 @@ void evergreen_hpd_fini(struct radeon_device *rdev)
>   default:
>   break;
>   }
> - disabled |= 1 << radeon_connector->hpd.hpd;
> + if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
> + disabled |= 1 << radeon_connector->hpd.hpd;
>   }
>   radeon_irq_kms_disable_hpd(rdev, disabled);
>  }

[PATCH] dma-buf: Update docs for SYNC ioctl

[Hans Verkuil]

On 03/21/2016 08:51 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
> 
> Requested by Sumit.
> 
> v2: Fix them typos (Hans).
> 
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org
> Cc: Hans Verkuil 
> Acked-by: Sumit Semwal 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..ca44c5820585 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>  
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EAGAIN or -EINTR, in which case it must be restarted.
>  
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>  
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot rely on coherent access, even when there
> +are systems where it just works without calling these ioctls.
>  
>  2. Supporting existing mmap interfaces in importers
>  
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:  [in]buffer to complete cpu access for.
>   * @direction:   [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>  enum dma_data_direction direction)
> 

Much better :-)

Acked-by: Hans Verkuil 

Regards,

Hans

[PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

Just a bit of wording polish plus mentioning that it can fail and must
be restarted.

Requested by Sumit.

v2: Fix them typos (Hans).

Cc: Chris Wilson 
Cc: Tiago Vignatti 
Cc: Stéphane Marchesin 
Cc: David Herrmann 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
CC: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: intel-gfx at lists.freedesktop.org
Cc: devel at driverdev.osuosl.org
Cc: Hans Verkuil 
Acked-by: Sumit Semwal 
Signed-off-by: Daniel Vetter 
---
 Documentation/dma-buf-sharing.txt | 11 ++-
 drivers/dma-buf/dma-buf.c |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 32ac32e773e1..ca44c5820585 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:

No special interfaces, userspace simply calls mmap on the dma-buf fd, making
sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
-   used when the access happens. This is discussed next paragraphs.
+   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
+   -EAGAIN or -EINTR, in which case it must be restarted.

Some systems might need some sort of cache coherency management e.g. when
CPU and GPU domains are being accessed through dma-buf at the same time. To
@@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
want (with the new data being consumed by the GPU or say scanout device)
  - munmap once you don't need the buffer any more

-Therefore, for correctness and optimal performance, systems with the memory
-cache shared by the GPU and CPU i.e. the "coherent" and also the
-"incoherent" are always required to use SYNC_START and SYNC_END before and
-after, respectively, when accessing the mapped address.
+For correctness and optimal performance, it is always required to use
+SYNC_START and SYNC_END before and after, respectively, when accessing the
+mapped address. Userspace cannot rely on coherent access, even when there
+are systems where it just works without calling these ioctls.

 2. Supporting existing mmap interfaces in importers

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 774a60f4309a..4a2c07ee6677 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
  * @dmabuf:[in]buffer to complete cpu access for.
  * @direction: [in]length of range for cpu access.
  *
- * This call must always succeed.
+ * Can return negative error values, returns 0 on success.
  */
 int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
   enum dma_data_direction direction)
-- 
2.8.0.rc3

[PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

On Mon, Mar 21, 2016 at 8:40 AM, Hans Verkuil  wrote:
>> +For correctness and optimal performance, it is always required to use
>> +SYNC_START and SYNC_END before and after, respectively, when accessing 
>> the
>> +mapped address. Userspace cannot on coherent access, even when there are
>
> "Userspace cannot on coherent access"? Do you mean "cannot do"? Sorry, the
> meaning isn't clear to me.

"cannot rely on". I'll send out v2 asap (and let's hope the coffee
works this time around).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] dma-buf: Update docs for SYNC ioctl

[Hans Verkuil]

Hi Daniel,

Two small comments:

On 03/21/2016 08:30 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
> 
> Requested by Sumit.
> 
> Cc: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/dma-buf-sharing.txt | 11 ++-
>  drivers/dma-buf/dma-buf.c |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/dma-buf-sharing.txt 
> b/Documentation/dma-buf-sharing.txt
> index 32ac32e773e1..5c4e3e586ec8 100644
> --- a/Documentation/dma-buf-sharing.txt
> +++ b/Documentation/dma-buf-sharing.txt
> @@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
> main use-cases:
>  
> No special interfaces, userspace simply calls mmap on the dma-buf fd, 
> making
> sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
> -   used when the access happens. This is discussed next paragraphs.
> +   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
> +   -EGAIN or -EINTR, in which case it must be restarted.

EGAIN -> EAGAIN

>  
> Some systems might need some sort of cache coherency management e.g. when
> CPU and GPU domains are being accessed through dma-buf at the same time. 
> To
> @@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 
> 2 main use-cases:
> want (with the new data being consumed by the GPU or say scanout 
> device)
>   - munmap once you don't need the buffer any more
>  
> -Therefore, for correctness and optimal performance, systems with the 
> memory
> -cache shared by the GPU and CPU i.e. the "coherent" and also the
> -"incoherent" are always required to use SYNC_START and SYNC_END before 
> and
> -after, respectively, when accessing the mapped address.
> +For correctness and optimal performance, it is always required to use
> +SYNC_START and SYNC_END before and after, respectively, when accessing 
> the
> +mapped address. Userspace cannot on coherent access, even when there are

"Userspace cannot on coherent access"? Do you mean "cannot do"? Sorry, the
meaning isn't clear to me.

Regards,

Hans

> +systems where it just works without calling these ioctls.
>  
>  2. Supporting existing mmap interfaces in importers
>  
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 774a60f4309a..4a2c07ee6677 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   * @dmabuf:  [in]buffer to complete cpu access for.
>   * @direction:   [in]length of range for cpu access.
>   *
> - * This call must always succeed.
> + * Can return negative error values, returns 0 on success.
>   */
>  int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>  enum dma_data_direction direction)
> 

[PATCH] dma-buf: Update docs for SYNC ioctl

[Daniel Vetter]

Just a bit of wording polish plus mentioning that it can fail and must
be restarted.

Requested by Sumit.

Cc: Chris Wilson 
Cc: Tiago Vignatti 
Cc: Stéphane Marchesin 
Cc: David Herrmann 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
CC: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: intel-gfx at lists.freedesktop.org
Cc: devel at driverdev.osuosl.org
Signed-off-by: Daniel Vetter 
---
 Documentation/dma-buf-sharing.txt | 11 ++-
 drivers/dma-buf/dma-buf.c |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 32ac32e773e1..5c4e3e586ec8 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -352,7 +352,8 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:

No special interfaces, userspace simply calls mmap on the dma-buf fd, making
sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
-   used when the access happens. This is discussed next paragraphs.
+   used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with
+   -EGAIN or -EINTR, in which case it must be restarted.

Some systems might need some sort of cache coherency management e.g. when
CPU and GPU domains are being accessed through dma-buf at the same time. To
@@ -366,10 +367,10 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
want (with the new data being consumed by the GPU or say scanout device)
  - munmap once you don't need the buffer any more

-Therefore, for correctness and optimal performance, systems with the memory
-cache shared by the GPU and CPU i.e. the "coherent" and also the
-"incoherent" are always required to use SYNC_START and SYNC_END before and
-after, respectively, when accessing the mapped address.
+For correctness and optimal performance, it is always required to use
+SYNC_START and SYNC_END before and after, respectively, when accessing the
+mapped address. Userspace cannot on coherent access, even when there are
+systems where it just works without calling these ioctls.

 2. Supporting existing mmap interfaces in importers

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 774a60f4309a..4a2c07ee6677 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -612,7 +612,7 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
  * @dmabuf:[in]buffer to complete cpu access for.
  * @direction: [in]length of range for cpu access.
  *
- * This call must always succeed.
+ * Can return negative error values, returns 0 on success.
  */
 int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
   enum dma_data_direction direction)
-- 
2.8.0.rc3

[PATCH 2/4 v3] drm: Add DT bindings documentation for ARC PGU display controller

[Rob Herring]

On Fri, Mar 11, 2016 at 06:42:37PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: devicetree at vger.kernel.org
> Cc: linux-snps-arc at lists.infradead.org
> ---
> 
> Changes v2 -> v3:
>  * Reverted back to initial larger version of example
>with minor fixes (thanks Rob for spotting those).
> 
> Changes v1 -> v2:
>  * Removed everything except PGU node itself.
> 
>  .../devicetree/bindings/display/snps,arcpgu.txt| 72 
> ++
>  1 file changed, 72 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..b130924
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,72 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> +  - compatible: "snps,arcpgu"
> +  - reg: Physical base address and length of the controller's registers.
> +  - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> +  - clock-names: A list of clock names. For ARC PGU it should contain:
> +  - "pxlclk" for the clock feeding the output PLL of the controller.
> +  - encoder-slave: Phandle of encoder chip.

Drop this as discussed.

> +
> +Required sub-nodes:
> +  - port: The PGU connection to an encoder chip.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu at  {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <_node>;
> +
> + port {
> + pgu_output: endpoint {
> + remote-endpoint = <_enc_input>;
> + };
> + };
> + };
> +
> + /* HDMI encoder on I2C bus */
> + i2c at  {
> + compatible = "...";
> +
> + encoder_node:encoder_node at 0xXX{

Don't use underscores in node names. Just "hdmi at xx"

> + compatible="...";
> +
> + ports {
> + port at 0 {
> + reg = <0>;
> + hdmi_enc_input:endpoint {
> + remote-endpoint = <_output>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + hdmi_enc_output:endpoint {
> + remote-endpoint = 
> <_connector_in>;
> + };
> + };
> + };
> + };
> + }
> +
> + hdmi0: connector {
> + compatible = "hdmi-connector";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <_enc_output>;
> + };
> + };
> + };
> +};
> -- 
> 2.5.0
> 

[PATCH 4/5] drm/vc4: Add DPI driver

[Rob Herring]

On Fri, Mar 18, 2016 at 07:42:45PM -0700, Eric Anholt wrote:
> The DPI interface involves taking a ton of our GPIOs to be used as
> outputs, and routing display signals over them in parallel.
> 
> Signed-off-by: Eric Anholt 
> ---
>  .../devicetree/bindings/display/brcm,bcm-vc4.txt   |  67 +++
>  drivers/gpu/drm/vc4/Kconfig|   1 +
>  drivers/gpu/drm/vc4/Makefile   |   1 +
>  drivers/gpu/drm/vc4/vc4_debugfs.c  |   1 +
>  drivers/gpu/drm/vc4/vc4_dpi.c  | 518 
> +
>  drivers/gpu/drm/vc4/vc4_drv.c  |   1 +
>  drivers/gpu/drm/vc4/vc4_drv.h  |   5 +
>  7 files changed, 594 insertions(+)
>  create mode 100644 drivers/gpu/drm/vc4/vc4_dpi.c
> 
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt 
> b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> index 56a961a..1782c3f 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
> @@ -35,6 +35,44 @@ Optional properties for HDMI:
> as an interrupt/status bit in the HDMI controller
> itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
>  
> +Required properties for DPI:
> +- compatible:Should be "brcm,bcm2835-dpi"
> +- reg:   Physical base address and length of the 
> registers
> +- clocks:a) core: The core clock the unit runs on
> + b) pixel: The pixel clock that feeds the pixelvalve
> +- port:  Port node with a single endpoint connecting to 
> the
> +   panel device, as defined in [1]
> +- brcm,output-format:Output data format, must be one of:
> + 0) disabled
> + 1) rggb
> + 2) 000r00gg000b
> + 3) 00r000gg00b0
> + 4) 00rrggbb
> + 5) 00rr00gg00bb
> + 6) 
> +
> +Optional properties for DPI:
> +- brcm,rgb-order:RGB reordering, must be one of:
> + 0) RGB
> + 1) BGR
> + 2) GRB
> + 3) BRG

> +- brcm,hsync-disable:Disables the hsync signal
> +- brcm,vsync-disable:Disables the vsync signal
> +- brcm,output-enable-disable:Disables the output enable signal
> +- brcm,hsync-falling:Outputs the hsync signal on the falling 
> clk edge
> +- brcm,vsync-falling:Outputs the vsync signal on the falling 
> clk edge
> +- brcm,output-enable-falling:Outputs the output enable signal on the
> +   falling clk edge
> +- brcm,output-enable-invert: Inverts the polarity of the output enable
> +   signal
> +- brcm,pixel-clk-invert: Inverts the polarity of the pixel clk signal
> +- brcm,output-enable-mode:   Sets output enable when (vsync | hsync)
> +   instead of (hactive & vactive)

These are all really properties of what the panel requires and we 
already have video timings binding that would cover some of these.

Also, do you have actual users? Some of these seem like they would be 
rare or never. I've not seen panels caring about which clock edge the 
sync signals are on.

Rob

[PATCH 2/5] panel-simple: Add the 7" DPI panel from Adafruit.

[Rob Herring]

On Fri, Mar 18, 2016 at 07:42:43PM -0700, Eric Anholt wrote:
> This is a basic TFT panel with a 40-pin FPC connector on it.  The
> specification doesn't define timings, but the Adafruit instructions
> were setting up 800x480 CVT.
> 
> Signed-off-by: Eric Anholt 
> ---
>  .../bindings/display/panel/ontat,yx700wv03.txt |  7 +
>  drivers/gpu/drm/panel/panel-simple.c   | 33 
> ++
>  2 files changed, 40 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt

Acked-by: Rob Herring 

[PATCH 1/5] of: Add vendor prefix for On Tat Industrial Company.

[Rob Herring]

On Fri, Mar 18, 2016 at 07:42:42PM -0700, Eric Anholt wrote:
> This is the vendor for a 7" DPI panel sold by Adafruit which I'd like
> to describe in DT.
> 
> Signed-off-by: Eric Anholt 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

[git pull] drm pull for 4.6-rc1

[Dave Airlie]

Hi Linus,

This is the main drm pull request for 4.6 kernel.

The highlights are below, and there are a few merge conflicts,
but I think they should all be simple enough for you to take
care off. At least at the moment they are just the writecombine
interface changes.

Overall the coolest thing here for me is the nouveau maxwell
signed firmware support from NVidia, it's taken a long while
to extract this from them.

I also wish the ARM vendors just designed one set of display IP,
ARM display block proliferation is definitely increasing.

Core:
drm_event cleanups
Internal API cleanup making mode_fixup optional.
Apple GMUX vga switcheroo support.
DP AUX testing interface

Panel:
Refactoring of DSI core for use over more transports.

New driver:
ARM hdlcd driver

i915:
FBC/PSR (framebuffer compression, panel self refresh) enabled by 
default.
Ongoing atomic display support work
Ongoing runtime PM work
Pixel clock limit checks
VBT DSI description support
GEM fixes
GuC firmware scheduler enhancements

amdkfd:
Deferred probing fixes to avoid make file or link ordering.

amdgpu/radeon:
ACP support for i2s audio support.
Command Submission/GPU scheduler/GPUVM optimisations
Initial GPU reset support for amdgpu

vmwgfx:
Support for DX10 gen mipmaps
Pageflipping and other fixes.

exynos:
Exynos5420 SoC support for FIMD
Exynos5422 SoC support for MIPI-DSI

nouveau:
GM20x secure boot support - adds acceleration for Maxwell GPUs.
GM200 support
GM20B clock driver support
Power sensors work

etnaviv:
Correctness fixes for GPU cache flushing
Better support for i.MX6 systems.

imx-drm:
VBlank IRQ support
Fence support
OF endpoint support

msm:
HDMI support for 8996 (snapdragon 820)
Adreno 430 support
Timestamp queries support

virtio-gpu:
Fixes for Android support.

rockchip:
Add support for Innosilicion HDMI

rcar-du:
Support for 4 crtcs
R8A7795 support
RCar Gen 3 support

omapdrm:
HDMI interlace output support
dma-buf import support
Refactoring to remove a lot of legacy code.

tilcdc:
Rewrite of pageflipping code
dma-buf support
pinctrl support

vc4:
HDMI modesetting bug fixes
Significant 3D performance improvement.

fsl-dcu (FreeScale):
Lots of fixes

tegra:
Two small fixes

sti:
Atomic support for planes
Improved HDMI support

The following changes since commit 2a4fb270daa9c1f1d1b86a53d66ed86cc64ad232:

  Merge tag 'armsoc-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2016-03-11 12:35:54 
-0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7:

  drm/amdgpu: release_pages requires linux/pagemap.h (2016-03-21 13:22:52 +1000)


Abhay Kumar (1):
  drm/i915: edp resume/On time optimization.

Akshay Bhat (1):
  drm/panel: simple: Fix g121x1_l03 hsync/vsync polarity

Alan (1):
  i915: cast before shifting in i915_pte_count

Alan Cox (1):
  gma500: clean up an excessive and confusing helper

Alex Dai (7):
  drm/i915/guc: Move GuC wq_check_space to alloc_request_extras
  drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation
  drm/i915/guc: Add GuC ADS - scheduler policies
  drm/i915/guc: Add GuC ADS - MMIO reg state
  drm/i915/guc: Add GuC ADS - enabling ADS
  drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed
  drm/i915/guc: Decouple GuC engine id from ring id

Alex Deucher (33):
  drm/amdgpu: remove some more semaphore leftovers
  drm/amdgpu: clean up asic level reset for CI
  drm/amdgpu: clean up asic level reset for VI
  drm/amdgpu: post card after hard reset
  drm/amdgpu: add a debugfs property to trigger a GPU reset
  drm/amdgpu: drop hard_reset module parameter
  drm/amd: add dce8 enum register header
  drm/amdgpu: remove unused function
  drm/amdgpu: add check for atombios GPU virtualization table
  drm/amdgpu: track whether the asic supports SR-IOV
  drm/amdgpu: always repost cards that support SR-IOV
  drm/amdgpu/gmc8: skip MC ucode loading on SR-IOV capable boards
  drm/amdgpu/smu: skip SMC ucode loading on SR-IOV capable boards (v2)
  drm/amdgpu/gfx: minor code cleanup
  drm/amdgpu/gfx: clean up harvest configuration (v2)
  drm/amdgpu/gfx7: rework gpu_init()
  drm/amdgpu/cik: move sdma tiling config setup into sdma code
  drm/amdgpu/cik: move uvd tiling config setup into uvd code
  drm/amdgpu/vi: move sdma tiling config setup into sdma code
  drm/amdgpu/vi: move 

[Bug 94581] Red flood in dmesg when running applications

[bugzilla-dae...@freedesktop.org]

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

Vladislav Kamenev  changed:

   What|Removed |Added

   Keywords||regression

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160321/d87e7f97/attachment.html>