[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #12 from Alex Deucher  ---
(In reply to comment #11)
> 
> Sorry Alex, but is this intended (it is in the logs since 3.16+, too)?
> 
> [   11.316570] radeon :01:00.0: (-1) pin WB bo failed
> [   11.316582] radeon :01:00.0: f2fb0c00 unpin not necessary
> [   11.316601] radeon :01:00.0: disabling GPU acceleration
> [   11.369220] radeon :01:00.0: f6064000 unpin not necessary
> 
> [   11.433188] [TTM] Finalizing pool allocator
> [   11.433309] [TTM] Zone  kernel: Used memory at exit: 0 kiB
> [   11.433317] [TTM] Zone highmem: Used memory at exit: 0 kiB
> [   11.433320] [drm] radeon: ttm finalized
> 
> [   11.433325] [drm] Forcing AGP to PCIE mode
> 
> So, maybe GTT/GART grows to big?

AGP should work.  You'll have to bisect.  Anyway, this is not related to this
bug.  Please open a new one.

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #11 from Dieter N?tzel  ---
(In reply to comment #10)
> (In reply to comment #7)
> > This fixes ONE of the bugs Christian and me are hunting for some days, now.
> > Making my RV730 AGP (!!!) working with 3.17-rcX/drm-next-3.18-wip, again.
> > 
> > Crashed with mplayer -vo vdpau XXX immediatly.
> > 
> > But 'allow UVD to use a second 256MB segment' gave no speedup, at least for
> > me.
> > 
> > Maybe it is the 'second' bug (regression) introduced with the switch from
> > 3.16 to 3.17 (drm-next).
> > 
> [snip]
> > 
> > Tried after bisection with reverting:
> > drm-radeon-fix-display-handling-in-radeon_gpu_reset.patch
> > 
> > Any ideas, Alex/Christian?
> 
> I'm not sure what you are asking.  What issue are you having?

Sorry Alex, but is this intended (it is in the logs since 3.16+, too)?

[   11.316570] radeon :01:00.0: (-1) pin WB bo failed
[   11.316582] radeon :01:00.0: f2fb0c00 unpin not necessary
[   11.316601] radeon :01:00.0: disabling GPU acceleration
[   11.369220] radeon :01:00.0: f6064000 unpin not necessary

[   11.433188] [TTM] Finalizing pool allocator
[   11.433309] [TTM] Zone  kernel: Used memory at exit: 0 kiB
[   11.433317] [TTM] Zone highmem: Used memory at exit: 0 kiB
[   11.433320] [drm] radeon: ttm finalized

[   11.433325] [drm] Forcing AGP to PCIE mode

So, maybe GTT/GART grows to big?

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

[Bug 82588] X fails to start with linus-tip or drm-next

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

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

--- Comment #10 from Dieter N?tzel  ---
Please have a look, here:

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

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #10 from Alex Deucher  ---
(In reply to comment #7)
> This fixes ONE of the bugs Christian and me are hunting for some days, now.
> Making my RV730 AGP (!!!) working with 3.17-rcX/drm-next-3.18-wip, again.
> 
> Crashed with mplayer -vo vdpau XXX immediatly.
> 
> But 'allow UVD to use a second 256MB segment' gave no speedup, at least for
> me.
> 
> Maybe it is the 'second' bug (regression) introduced with the switch from
> 3.16 to 3.17 (drm-next).
> 
[snip]
> 
> Tried after bisection with reverting:
> drm-radeon-fix-display-handling-in-radeon_gpu_reset.patch
> 
> Any ideas, Alex/Christian?

I'm not sure what you are asking.  What issue are you having?

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

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #131 from Marti Raudsepp  ---
Created attachment 105927
  --> https://bugs.freedesktop.org/attachment.cgi?id=105927=edit
GPU lockup followed by "GPU fault detected: 147"

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

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #130 from Marti Raudsepp  ---
Created attachment 105926
  --> https://bugs.freedesktop.org/attachment.cgi?id=105926=edit
double-hang after "failed to get a new IB (-35)"

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

[Bug 82912] radeon doesn't detect R 5 kaveri chipset

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

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

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #7 from Alex Deucher  ---
All patches are committed.

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

[Bug 82912] radeon doesn't detect R 5 kaveri chipset

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

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

--- Comment #6 from Alex Deucher  ---
*** Bug 83630 has been marked as a duplicate of this bug. ***

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #9 from Dieter N?tzel  ---
Created attachment 105923
  --> https://bugs.freedesktop.org/attachment.cgi?id=105923=edit
Xorg.0.log-drm-next-3.18-wip

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #8 from Dieter N?tzel  ---
Created attachment 105922
  --> https://bugs.freedesktop.org/attachment.cgi?id=105922=edit
dmesg-drm-next-3.18-wip.log

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

-2
[   12.448132] [drm]   HPD1
[   12.448135] [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c
0x7e2c
[   12.448137] [drm]   Encoders:
[   12.448138] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   12.448140] [drm] DFP1: INTERNAL_UNIPHY
[   12.448142] [drm] Connector 2:
[   12.448143] [drm]   DIN-1
[   12.448145] [drm]   Encoders:
[   12.448147] [drm] TV1: INTERNAL_KLDSCP_DAC2
[   12.548120] [drm] fb mappable at 0xC045F000
[   12.548129] [drm] vram apper at 0xC000
[   12.548131] [drm] size 8294400
[   12.548133] [drm] fb depth is 24
[   12.548135] [drm]pitch is 7680
[   12.548539] fbcon: radeondrmfb (fb0) is primary device
[   12.549685] Console: switching to colour frame buffer device 240x67
[   12.600307] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[   12.600311] radeon :01:00.0: registered panic notifier
[   12.603112] [drm] Initialized radeon 2.40.0 20080528 for :01:00.0 on
minor 0

Tried after bisection with reverting:
drm-radeon-fix-display-handling-in-radeon_gpu_reset.patch

Any ideas, Alex/Christian?

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #6 from Bug  ---
I made a mistake, I tested it again with your patch on a clean 3.17-rc4 and it
works now, thanks

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

XDC2014: Call for paper

[Martin Peres]

Le 02/05/2014 00:52, Martin Peres a ?crit :
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2014
> will
> be held in Bordeaux, France from October 8th to October 10th. The venue is
> located in the campus of the University of Bordeaux 1, in the computer
> science
> research lab called LaBRI.
>
> The official page for the event is http://www.x.org/wiki/Events/XDC2014
> while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2014/
>
> As usual, we are open to talks across the layers of the graphics stack,
> from
> the kernel to desktop environments / graphical applications and about how
> to make things better for the developers who build them. If you're not sure
> if something might fit, mail me or add it to the ideas list found in the
> program page.
>
> The conference is free of charge and opened to the general public. If
> you plan
> on coming, please add yourself to the attendees list. We'll use this
> list to
> make badges and plan for the catering.
>
> I am looking forward to seeing you there, if you have any
> inquiries/questions,
> please send them to me (please also CC: board at foundation.x.org).
>
> Martin Peres

Two days left for submitting your talk proposal for the XDC2014.

After this date, the remaining slots will be attributed on a first-come, 
first-served basis.

[Intel-gfx] [PATCH -v4 0/4] split plane's updates functions into check() and commit()

[Daniel Vetter]

On Mon, Sep 08, 2014 at 04:59:42PM +0300, Ville Syrj?l? wrote:
> On Fri, Sep 05, 2014 at 05:04:45PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> > 
> > This is the beginning of the work to prepare i915 for the upcoming
> > atomic modesetting API. Here we split the plane update fucntions in
> > the check and commit states.
> > 
> > v2: use struct intel_plane_state to keep states between check and
> > commit stages.
> > 
> > v3: take Ville's comments:
> > - rename pstate to state
> > - get rid of non-drm_rect coordinates in intel_plane_state
> > - keep 'clip' const
> > 
> > v4: take more Ville's comments:
> > - populates orig_dst and orig_src too
> > - use orig_dst coordinates to program the cursor plane
> > 
> > Gustavo Padovan (4):
> >   drm/i915: create struct intel_plane_state
> >   drm/i915: split intel_update_plane into check() and commit()
> >   drm/i915: split intel_cursor_plane_update() into check() and commit()
> >   drm/i915: split intel_primary_plane_setplane() into check() and
> > commit()
> 
> It's looking pretty nice. I didn't spot any more problems, so for the
> series:
> Reviewed-by: Ville Syrj?l? 

Queued for -next, thanks for the patch.
-Daniel

> 
> > 
> >  drivers/gpu/drm/i915/intel_display.c | 240 
> > +--
> >  drivers/gpu/drm/i915/intel_drv.h |  12 ++
> >  drivers/gpu/drm/i915/intel_sprite.c  | 233 
> > --
> >  3 files changed, 298 insertions(+), 187 deletions(-)
> > 
> > -- 
> > 1.9.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrj?l?
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/radeon: reduce memory footprint for debugging

[Alex Deucher]

On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko
 wrote:
> There is no need to use hex_dump_to_buffer() since we have a kernel helper to
> dump up to 64 bytes just via printk(). In our case the actual size is 15 
> bytes.
>
> Signed-off-by: Andy Shevchenko 

Patch generates the following warning:
  CC [M]  drivers/gpu/drm/radeon/atombios_dp.o
drivers/gpu/drm/radeon/atombios_dp.c: In function ?radeon_dp_getdpcd?:
drivers/gpu/drm/radeon/atombios_dp.c:413:3: warning: field width
specifier ?*? expects argument of type ?int?, but argument 3 has type
?u8 *? [-Wformat=]
   DRM_DEBUG_KMS("DPCD: %*ph\n", dig_connector->dpcd,
   ^
drivers/gpu/drm/radeon/atombios_dp.c:413:3: warning: format ?%p?
expects argument of type ?void *?, but argument 4 has type ?int?
[-Wformat=]
  LD [M]  drivers/gpu/drm/radeon/radeon.o
  Building modules, stage 2.
  MODPOST 2485 modules
  LD [M]  drivers/gpu/drm/radeon/radeon.ko



> ---
>  drivers/gpu/drm/radeon/atombios_dp.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 95ea276..4e75c48 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -405,16 +405,13 @@ bool radeon_dp_getdpcd(struct radeon_connector 
> *radeon_connector)
> u8 msg[DP_DPCD_SIZE];
> int ret;
>
> -   char dpcd_hex_dump[DP_DPCD_SIZE * 3];
> -
> ret = drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_DPCD_REV, 
> msg,
>DP_DPCD_SIZE);
> if (ret > 0) {
> memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
>
> -   hex_dump_to_buffer(dig_connector->dpcd, 
> sizeof(dig_connector->dpcd),
> -  32, 1, dpcd_hex_dump, 
> sizeof(dpcd_hex_dump), false);
> -   DRM_DEBUG_KMS("DPCD: %s\n", dpcd_hex_dump);
> +   DRM_DEBUG_KMS("DPCD: %*ph\n", dig_connector->dpcd,
> + (int)sizeof(dig_connector->dpcd));
>
> radeon_dp_probe_oui(radeon_connector);
>
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #5 from Alex Deucher  ---
(In reply to comment #4)
> it didnt solve the bug with my RV730 chip,
> but when I commented out the whole if block it did work
> so maybe my chip is from before chedar

Your chip is before cedar so the patch prevents that block from executing on
your chip, the same as commenting out the entire block.  Are you sure you
tested the right kernel?

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

[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

[Michel Dänzer]

On 06.09.2014 01:49, Mikael Pettersson wrote:
> Michel D?nzer writes:
>   > On 30.08.2014 22:59, Mikael Pettersson wrote:
>   > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen 
> corruption
>   > > after a while in X + firefox.  This still occurs with yesterday's HEAD
>   > > of Linus' repo.  3.16 and ealier kernels are fine.
>   > >
>   > > I ran a bisect, which identified:
>   > >
>   > > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
>   > > Author: Michel D??nzer 
>   > > Date:   Thu Jul 31 18:43:49 2014 +0900
>   > >
>   > >  drm/radeon: Always flush the HDP cache before submitting a CS to 
> the GPU
>   > >
>   > > as the cause of my screen corruption.  Reverting this from 3.17-rc2
>   > > (which requires manual intervention due to subsequent changes in
>   > > radeon_ring_commit()) eliminates the screen corruption.
>   >
>   > Does the patch below help?
> 
> Tested, sorry no joy.  I first reconfirmed the screen corruption with 
> 3.17-rc3.
> I then applied this and rebuilt/rebooted, and after a few minutes X had a 
> hickup
> (screen went black, came back after a few seconds, but then no cursor or
> reaction to mouse events), but I was able to kill it via my Terminate_Server
> key binding.

I was afraid so, thanks for testing it.


I can't see any other option than the patch below then. Can you confirm that 
this
fixes the screen corruption?


diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4c5ec44..b0098e7 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -821,6 +821,20 @@ u32 r100_get_vblank_counter(struct radeon_device *rdev, 
int crtc)
return RREG32(RADEON_CRTC2_CRNT_FRAME);
 }

+/**
+ * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
+ * rdev: radeon device structure
+ * ring: ring buffer struct for emitting packets
+ */
+static void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring 
*ring)
+{
+   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
+   RADEON_HDP_READ_BUFFER_INVALIDATE);
+   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
+}
+
 /* Who ever call radeon_fence_emit should call ring_lock and ask
  * for enough space (today caller are ib schedule and buffer move) */
 void r100_fence_ring_emit(struct radeon_device *rdev,
@@ -1056,20 +1070,6 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
(void)RREG32(RADEON_CP_RB_WPTR);
 }

-/**
- * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
- * rdev: radeon device structure
- * ring: ring buffer struct for emitting packets
- */
-void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring *ring)
-{
-   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
-   radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
-   RADEON_HDP_READ_BUFFER_INVALIDATE);
-   radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
-   radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
-}
-
 static void r100_cp_load_microcode(struct radeon_device *rdev)
 {
const __be32 *fw_data;
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index abe..2dd5847 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -185,7 +185,6 @@ static struct radeon_asic_ring r100_gfx_ring = {
.get_rptr = _gfx_get_rptr,
.get_wptr = _gfx_get_wptr,
.set_wptr = _gfx_set_wptr,
-   .hdp_flush = _ring_hdp_flush,
 };

 static struct radeon_asic r100_asic = {
@@ -332,7 +331,6 @@ static struct radeon_asic_ring r300_gfx_ring = {
.get_rptr = _gfx_get_rptr,
.get_wptr = _gfx_get_wptr,
.set_wptr = _gfx_set_wptr,
-   .hdp_flush = _ring_hdp_flush,
 };

 static struct radeon_asic r300_asic = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index 275a5dc..7756bc1 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -148,8 +148,7 @@ u32 r100_gfx_get_wptr(struct radeon_device *rdev,
  struct radeon_ring *ring);
 void r100_gfx_set_wptr(struct radeon_device *rdev,
   struct radeon_ring *ring);
-void r100_ring_hdp_flush(struct radeon_device *rdev,
-struct radeon_ring *ring);
+
 /*
  * r200,rv250,rs300,rv280
  */
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index a773830..ef5b60a 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -83,7 +83,7 @@
  *CIK: 1D and linear tiling modes contain valid PIPE_CONFIG
  *   2.39.0 - Add INFO query for number of active CUs
  *   2.40.0 - Add RADEON_GEM_GTT_WC/UC, flush HDP cache before 

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #4 from Bug  ---
it didnt solve the bug with my RV730 chip,
but when I commented out the whole if block it did work
so maybe my chip is from before chedar

thanks

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

[Bug 83184] Screen flickering at low resolution when monitor is attached via VGA dongle to DVI port

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

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

--- Comment #3 from Alex Deucher  ---
Created attachment 105905
  --> https://bugs.freedesktop.org/attachment.cgi?id=105905=edit
fix display connector configuration

Does the attached patch fix the issue?

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

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #4 from Garri  ---
Created attachment 149461
  --> https://bugzilla.kernel.org/attachment.cgi?id=149461=edit
journalctl -b _EXE=/usr/bin/Xorg _PID=7729

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

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #3 from Garri  ---
Created attachment 149451
  --> https://bugzilla.kernel.org/attachment.cgi?id=149451=edit
journalctl -b _EXE=/usr/bin/Xorg _PID=2217

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

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #2 from Garri  ---
Created attachment 149441
  --> https://bugzilla.kernel.org/attachment.cgi?id=149441=edit
journalctl -b -k

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #3 from Alex Deucher  ---
Created attachment 105904
  --> https://bugs.freedesktop.org/attachment.cgi?id=105904=edit
only enable me/pfp sync evergreen+

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

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #2 from Bug  ---
not fixed in rc4 it wasnt

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

[Intel-gfx] [PATCH -v4 0/4] split plane's updates functions into check() and commit()

[Ville Syrjälä]

On Fri, Sep 05, 2014 at 05:04:45PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This is the beginning of the work to prepare i915 for the upcoming
> atomic modesetting API. Here we split the plane update fucntions in
> the check and commit states.
> 
> v2: use struct intel_plane_state to keep states between check and
> commit stages.
> 
> v3: take Ville's comments:
> - rename pstate to state
> - get rid of non-drm_rect coordinates in intel_plane_state
> - keep 'clip' const
> 
> v4: take more Ville's comments:
>   - populates orig_dst and orig_src too
>   - use orig_dst coordinates to program the cursor plane
> 
> Gustavo Padovan (4):
>   drm/i915: create struct intel_plane_state
>   drm/i915: split intel_update_plane into check() and commit()
>   drm/i915: split intel_cursor_plane_update() into check() and commit()
>   drm/i915: split intel_primary_plane_setplane() into check() and
> commit()

It's looking pretty nice. I didn't spot any more problems, so for the
series:
Reviewed-by: Ville Syrj?l? 

> 
>  drivers/gpu/drm/i915/intel_display.c | 240 
> +--
>  drivers/gpu/drm/i915/intel_drv.h |  12 ++
>  drivers/gpu/drm/i915/intel_sprite.c  | 233 --
>  3 files changed, 298 insertions(+), 187 deletions(-)
> 
> -- 
> 1.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrj?l?
Intel OTC

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/Gallium/r600|DRM/Radeon

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

[Intel-gfx] [PATCH -v4 0/4] split plane's updates functions into check() and commit()

[Ville Syrjälä]

On Fri, Sep 05, 2014 at 05:04:45PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This is the beginning of the work to prepare i915 for the upcoming
> atomic modesetting API. Here we split the plane update fucntions in
> the check and commit states.
> 
> v2: use struct intel_plane_state to keep states between check and
> commit stages.
> 
> v3: take Ville's comments:
> - rename pstate to state
> - get rid of non-drm_rect coordinates in intel_plane_state
> - keep 'clip' const
> 
> v4: take more Ville's comments:
>   - populates orig_dst and orig_src too
>   - use orig_dst coordinates to program the cursor plane

In the future please include such changelogs in the patches themselves.
Makes for easier review and also it gets recorded in the commit message
so we can see a bit of the history even years later. Also makes it
possible to figure out which version of a patch got pushed and which
were discarded.

> 
> Gustavo Padovan (4):
>   drm/i915: create struct intel_plane_state
>   drm/i915: split intel_update_plane into check() and commit()
>   drm/i915: split intel_cursor_plane_update() into check() and commit()
>   drm/i915: split intel_primary_plane_setplane() into check() and
> commit()
> 
>  drivers/gpu/drm/i915/intel_display.c | 240 
> +--
>  drivers/gpu/drm/i915/intel_drv.h |  12 ++
>  drivers/gpu/drm/i915/intel_sprite.c  | 233 --
>  3 files changed, 298 insertions(+), 187 deletions(-)
> 
> -- 
> 1.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrj?l?
Intel OTC

[PATCH v2 5/8] ARM: dts: am33xx: Add external clock provider

[Tony Lindgren]

* Jyri Sarha  [140818 14:49]:
> Add external clock provider for am33xx devices.

Please send all the .dts and defconfig changes separately
so I can pick them up and we don't get pointless merge
conflicts.

Regards,

TOny

> Signed-off-by: Jyri Sarha 
> ---
>  arch/arm/boot/dts/am33xx.dtsi |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 3a0a161..d2cc397 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -92,6 +92,16 @@
>   pinctrl-single,function-mask = <0x7f>;
>   };
>  
> + ext_clocks {
> + compatible = "ti,external-clocks";
> +
> + ext_clocks: clocks {
> + };
> +
> + ext_clockdomains: clockdomains {
> + };
> + };
> +
>   /*
>* XXX: Use a flat representation of the AM33XX interconnect.
>* The real AM33XX interconnect network is quite complex. Since
> -- 
> 1.7.9.5
> 

[PATCH 8/9] drm/omap: fix preclose to wait for scheduled work

[Tomi Valkeinen]

On 03/09/14 17:32, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 02:55:09PM +0300, Tomi Valkeinen wrote:
>> We already wait for all scheduled work to be done on the driver's unload
>> function. However, I think we need to wait on preclose() also, so that
>> when an application closes the drm file descriptor, we are sure that
>> there's no left around.

Hmm, that's supposed to say "there's no work left around".

> The justification (likely, didn't check omapdrm code) for this is that we
> need to clear out all outstanding drm_events. Currently i915 and some
> other drivers (but not all) have that open-coded. We should probably track
> drm_events on a per-fd list and move this logic into the core instead of
> adding more driver-specific hacks.

To be honest, I'm not 100% sure what we need to wait for =). I'm still
learning DRM, and omapdrm's work handling is not the easiest one to
follow. But yes, at least the page-flip event is one that rings alarm
bells in my head, if the fb is allowed to be closed and there's still an
event outstanding.

With this patch we wait until all work is done in the preclose. The
performance is not an issue here, so I went for "better safe than sorry".

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/64d19aba/attachment-0001.sig>

[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

[Tomi Valkeinen]

On 03/09/14 17:27, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote:
>> omap_crtc_flush() is used to wait for scheduled work to be done for the
>> give crtc. However, it's not quite right at the moment.
>>
>> omap_crtc_flush() does wait for work that is ran via vsync irq to be
>> done. However, work is also queued to the driver's priv->wq workqueue,
>> which is not handled by omap_crtc_flush().
>>
>> Improve omap_crtc_flush() to flush the workqueue so that work there will
>> be ran.
>>
>> This fixes a race issue on module unload, where an unpin work may be on
>> the work queue, but does not get ran before drm core starts tearing the
>> driver down, leading to a WARN.
>>
>> Signed-off-by: Tomi Valkeinen 
> 
> I didn't really dig into details, but isn't that the same workqueue as
> used by the async modeset code? So the same deadlocks might happen ...

Yes, we have just one workqueue in the driver.

Hmm, deadlocks with what lock? The modeconfig or crtc->mutex? I don't
think they are locked at any place where omap_crtc_flush is called.

> lockdep won't complain though since you essentially open-code a
> workqueue_flush, and lockdep also doesn't complain about all possible
> deadlocks (due to some design issues with lockdep).

What do you mean "open-code a workqueue_flush"?. I use flush_workqueue
there. We have two things to wait for: work on the workqueue and work
which is triggered by the vsync irq. So we loop and test for both of
those, until there's no more work.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/07dced87/attachment-0001.sig>

[PATCH 4/9] drm/omap: make modesetting synchronous

[Tomi Valkeinen]

On 03/09/14 17:25, Daniel Vetter wrote:
> On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> Currently modesetting is not done synchronously, but it queues work that
>> is done later. In theory this is fine, but the driver doesn't handle it
>> at properly. This means that if an application first does a full
>> modeset, then immediately afterwards starts page flipping, the page
>> flipping will not work properly as there's modeset work still in the
>> queue.
>>
>> The result with my test application was that a backbuffer was shown on
>> the screen.
>>
>> Fixing this properly would be rather big undertaking. Thus this patch
>> fixes the issue by making the modesetting synchronous, by waiting for
>> the queued work to be done at the end of omap_crtc->commit().
>>
>> The ugly part here is that the background work takes crtc->mutex, and
>> the modesetting also holds that lock, which means that the background
>> work never gets done. To get around this, we unclock, wait, and lock
>> again.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> index 193979f97bdb..3261fbf94957 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
>>  static void omap_crtc_commit(struct drm_crtc *crtc)
>>  {
>>  struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> +struct drm_device *dev = crtc->dev;
>>  DBG("%s", omap_crtc->name);
>>  omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>> +
>> +drm_modeset_unlock_all(dev);
> 
> This will run afoul of the upcoming locking rework in the atomic work. And
> I'm fairly sure that the crtc helpers will fall over badly if someone
> submits a concurrent setCrtc while you've dropped the locks here.
> 
> Can't you instead just drop the locking from the worker? As long as you
> synchronize like here at the right places it can't race. I expect that you
> might want to synchronize in the crtc_prepare hook, too. But beyond that
> it should work.
> 
> As-is nacked because future headaches for me ;-)

Yes, it's ugly. But doing it with either queuing or caching would be a
major change. I was just trying to do smallish fixes to the driver for now.

How about only unlocking/locking the crtc->mutex as Rob suggested? I
think it should work, but I didn't try it yet. Would that be as bad for
the locking rework?

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/ccfea5f8/attachment-0001.sig>

[PATCH 4/9] drm/omap: make modesetting synchronous

[Daniel Vetter]

On Mon, Sep 08, 2014 at 09:39:40AM -0400, Rob Clark wrote:
> On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter  wrote:
> > On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
> >> On 03/09/14 17:25, Daniel Vetter wrote:
> >> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
> >> >> Currently modesetting is not done synchronously, but it queues work that
> >> >> is done later. In theory this is fine, but the driver doesn't handle it
> >> >> at properly. This means that if an application first does a full
> >> >> modeset, then immediately afterwards starts page flipping, the page
> >> >> flipping will not work properly as there's modeset work still in the
> >> >> queue.
> >> >>
> >> >> The result with my test application was that a backbuffer was shown on
> >> >> the screen.
> >> >>
> >> >> Fixing this properly would be rather big undertaking. Thus this patch
> >> >> fixes the issue by making the modesetting synchronous, by waiting for
> >> >> the queued work to be done at the end of omap_crtc->commit().
> >> >>
> >> >> The ugly part here is that the background work takes crtc->mutex, and
> >> >> the modesetting also holds that lock, which means that the background
> >> >> work never gets done. To get around this, we unclock, wait, and lock
> >> >> again.
> >> >>
> >> >> Signed-off-by: Tomi Valkeinen 
> >> >> ---
> >> >>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
> >> >>  1 file changed, 5 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> >> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> >> index 193979f97bdb..3261fbf94957 100644
> >> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> >> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc 
> >> >> *crtc)
> >> >>  static void omap_crtc_commit(struct drm_crtc *crtc)
> >> >>  {
> >> >>struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> >> >> +  struct drm_device *dev = crtc->dev;
> >> >>DBG("%s", omap_crtc->name);
> >> >>omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
> >> >> +
> >> >> +  drm_modeset_unlock_all(dev);
> >> >
> >> > This will run afoul of the upcoming locking rework in the atomic work. 
> >> > And
> >> > I'm fairly sure that the crtc helpers will fall over badly if someone
> >> > submits a concurrent setCrtc while you've dropped the locks here.
> >> >
> >> > Can't you instead just drop the locking from the worker? As long as you
> >> > synchronize like here at the right places it can't race. I expect that 
> >> > you
> >> > might want to synchronize in the crtc_prepare hook, too. But beyond that
> >> > it should work.
> >> >
> >> > As-is nacked because future headaches for me ;-)
> >>
> >> Yes, it's ugly. But doing it with either queuing or caching would be a
> >> major change. I was just trying to do smallish fixes to the driver for now.
> >>
> >> How about only unlocking/locking the crtc->mutex as Rob suggested? I
> >> think it should work, but I didn't try it yet. Would that be as bad for
> >> the locking rework?
> >
> > Same problem really, you shouldn't drop ww mutexes and reacquire them in
> > the atomic world. ww mutexes have some debug infrastructure for that
> > (ww_acquire_done) to catch abusers of this.
> >
> > So if you want to go forward with this it needs at least a big FIXME
> > comment explaining that this is wrong. If you use locking to enforce
> > ordering constraints that usually doesn't work well, and dropping locks to
> > wait for async workers is plainly a locking design bug.
> 
> well, the locking in core makes it in some ways a bit of a midlayer.. ;-)

It's the locking for the drm core layer, it better be done in drm core.
Drivers are free to use it, but if it doesn't fit they can always do their
own. And if you look at i915 we actually have a metric pile of mutexes
taken from modeset code and other places exactly because the drm core
modeset locking can't work for everyone.

> Some crtc->funcs->wait_until_flushed() sort of thing that
> drm_mode_setcrtc() could call after dropping locks would go a long
> ways to fix this case.  (Although post-atomic, may no longer be
> required.)

Now _this_ smells like a proper midlayer - it enforces behaviour
sequencing by providing a bunch of callbacks for drivers to hook into.

Also, locking isn't to enforce ordering constraints at all, that's the job
of flush_workqueue, completion and friends. And if such a sync point would
result in deadlocks if your worker also uses the modeset locks then your
driver needs to grow internal mutexes to coordinate the data accessed by
workers. In i915 we've added a pile of such cases in the past (and will
add more), e.g. the pps mutex, backlight spinlock, edp mutex, ...

ADF does the same mistake of "hey let's do the synchronization in the core
because driver writers get it wrong all the time". Which doesn't make it
better ;-)

Now if your idea was to provide this as a helper, which either enforces
the ordering correctly to 

[PATCH] drm: Drop modeset locking from crtc init function

[Daniel Vetter]

On Mon, Sep 08, 2014 at 02:57:23PM +0200, Thomas Hellstrom wrote:
> On 09/08/2014 09:03 AM, Daniel Vetter wrote:
> > At driver init no one can access modeset objects and we're
> > single-threaded. So locking is just cargo-culting here. Worse, with
> > the new ww mutexes and ww mutex slowpath debugging the mutex_lock
> > might actually fail, and we don't have the full-blown ww recovery
> > dance.
> >
> > Which then leads to fireworks when we try to unlock the not-locked
> > crtc lock.
> >
> > An audit of all the functions called from here shows that none of them
> > contain locking checks, so there's also no reason to keep the locking
> > around just for consistency of caller contexts. Besides that I have
> > the rule (at least in i915) that such places where we take locks just
> > to simplify locking checks and not for correctness always require a
> > comment.
> 
> I'm not really opposed to any of the patches. It's clear that trylock
> will work, and it's also clear that locking is not strictly needed, at
> least not of a lock that has not been published yet.
> 
> However, I tend to go for the  "lock even if it's unnecessary" version
> for a couple of reasons:
> 
> a) If that turns out to be impossible or very hard, then something is
> probably wrong with the design.
> b) It's good to think of locks where possible as "protecting data"
> rather than serializing something. With that in mind, and if we in the
> future were to have tools to automatically check that relevant locks are
> held while accessing lock-protected stuff, we're in trouble.
> c) Even if there aren't any functions now that check for relevant locks
> held, there might be in the future.
> d) People will probably spend time wondering why locking is done
> elsewhere but not here.
> 
> So at least considering d) and b) I'd like to see documentation the
> other way around:
> If we avoid taking locks around data accesses that are supposed to be
> protected by the lock for whatever reason, the reason should be documented.

Well my argument nowadays is that you should never abuse locking to
enforce ordering constraints. And an objects that's just getting
initialized but isn't published anywhere really has no reason to have
locking for data consistency, so really only justified to be held if it
makes the "protecting data" self-checks easier. E.g. we have a bunch of
checks about manipulating the connector mode list all over, so init code
must hold the relevant locks.

Also ime locking sprawl (which happens escpecially with big locks like
dev->struct_mutex) is really bad for long-term maintainability, so by
default I want as little locking as possible.

I guess a comment can make sense if there's no locking to explain the odd
case. But if everything is sanely designed then imo pure init functions
really should have comments about locks they take and not if they take no
locks. Since with a sane design the no-locks case really should be the
default. And if that makes people question the locking scheme and learn
something about "locking for ordering" vs. "locking to protect data"
that's a feature ;-) Note that this is specifically about init/teardown
(suspend/resume is similar), which is all about ordering and otherwise
rather single-threaded (at least if you don't botch up the synchronization
with async workers on teardown).

So at least in i915 I'll keep on rejecting patches that add random
carg-culted locking to init/shutdown paths.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 83616] Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

--- Comment #1 from Bug  ---
commit 86302eeadebfab94530b00f5e53a23f911ff41e4
Author: Christian K?nig 
Date:   Mon Aug 18 16:30:12 2014 +0200

drm/radeon: Sync ME and PFP after CP semaphore waits v4

Fixes lockups due to CP read GPUVM faults when running piglit on Cape
Verde.

v2 (chk): apply the fix to R600+ as well, on CIK only the GFX CP has
  a PFP, add more comments to R600 code, enable flushing again
v3: (agd5f): only apply to 7xx+.  r6xx does not have the packet.
v4: (agd5f): split flush change into a separate patch, fix formatting

Signed-off-by: Michel D?nzer 
Signed-off-by: Christian K?nig 
Signed-off-by: Alex Deucher 
Tested-by: Michel D?nzer 

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

[Bug 83616] New: Sydtem crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4

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

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

  Priority: medium
Bug ID: 83616
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Sydtem crashes in xonotic with kernel 3.17-rc since
linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: freedesktop at voorpost.net
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

linux git 86302eeadebfab94530b00f5e53a23f911ff41e4 is the first bad commit

launching xonotic hangs and resets the gpu, game video output looks corrupted, 
then eventually reboots the system, or can only sysrq out


mesa git current
xorg server 1.16
[   414.741] (--) RADEON(0): Chipset: "ATI RV730XT [Radeon HD 4670]" 
 (ChipID = 0x9490)

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

[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue

[Daniel Vetter]

On Mon, Sep 08, 2014 at 04:03:18PM +0300, Tomi Valkeinen wrote:
> On 03/09/14 17:27, Daniel Vetter wrote:
> > On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote:
> >> omap_crtc_flush() is used to wait for scheduled work to be done for the
> >> give crtc. However, it's not quite right at the moment.
> >>
> >> omap_crtc_flush() does wait for work that is ran via vsync irq to be
> >> done. However, work is also queued to the driver's priv->wq workqueue,
> >> which is not handled by omap_crtc_flush().
> >>
> >> Improve omap_crtc_flush() to flush the workqueue so that work there will
> >> be ran.
> >>
> >> This fixes a race issue on module unload, where an unpin work may be on
> >> the work queue, but does not get ran before drm core starts tearing the
> >> driver down, leading to a WARN.
> >>
> >> Signed-off-by: Tomi Valkeinen 
> > 
> > I didn't really dig into details, but isn't that the same workqueue as
> > used by the async modeset code? So the same deadlocks might happen ...
> 
> Yes, we have just one workqueue in the driver.
> 
> Hmm, deadlocks with what lock? The modeconfig or crtc->mutex? I don't
> think they are locked at any place where omap_crtc_flush is called.

Oh, I presumed you're using _flush in the relevant modeset functions - we
do that in i915 to make sure that all the pageflips and other stuff
completed before we do another modeset. But omap only calls this at driver
unload, so no direct problem.

> > lockdep won't complain though since you essentially open-code a
> > workqueue_flush, and lockdep also doesn't complain about all possible
> > deadlocks (due to some design issues with lockdep).
> 
> What do you mean "open-code a workqueue_flush"?. I use flush_workqueue
> there. We have two things to wait for: work on the workqueue and work
> which is triggered by the vsync irq. So we loop and test for both of
> those, until there's no more work.

Oops, missed that. Ordering looks wrong though since if the irq can latch
the workqueue you need to wait for irqs to happen first before flushing.
And obviously queue the work before signalling the completion of the
interrupt. But since this seems to lack locking anyway and is only used
for unload it doesn't really matter.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 4/9] drm/omap: make modesetting synchronous

[Daniel Vetter]

On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
> On 03/09/14 17:25, Daniel Vetter wrote:
> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
> >> Currently modesetting is not done synchronously, but it queues work that
> >> is done later. In theory this is fine, but the driver doesn't handle it
> >> at properly. This means that if an application first does a full
> >> modeset, then immediately afterwards starts page flipping, the page
> >> flipping will not work properly as there's modeset work still in the
> >> queue.
> >>
> >> The result with my test application was that a backbuffer was shown on
> >> the screen.
> >>
> >> Fixing this properly would be rather big undertaking. Thus this patch
> >> fixes the issue by making the modesetting synchronous, by waiting for
> >> the queued work to be done at the end of omap_crtc->commit().
> >>
> >> The ugly part here is that the background work takes crtc->mutex, and
> >> the modesetting also holds that lock, which means that the background
> >> work never gets done. To get around this, we unclock, wait, and lock
> >> again.
> >>
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> index 193979f97bdb..3261fbf94957 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
> >>  static void omap_crtc_commit(struct drm_crtc *crtc)
> >>  {
> >>struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> >> +  struct drm_device *dev = crtc->dev;
> >>DBG("%s", omap_crtc->name);
> >>omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
> >> +
> >> +  drm_modeset_unlock_all(dev);
> > 
> > This will run afoul of the upcoming locking rework in the atomic work. And
> > I'm fairly sure that the crtc helpers will fall over badly if someone
> > submits a concurrent setCrtc while you've dropped the locks here.
> > 
> > Can't you instead just drop the locking from the worker? As long as you
> > synchronize like here at the right places it can't race. I expect that you
> > might want to synchronize in the crtc_prepare hook, too. But beyond that
> > it should work.
> > 
> > As-is nacked because future headaches for me ;-)
> 
> Yes, it's ugly. But doing it with either queuing or caching would be a
> major change. I was just trying to do smallish fixes to the driver for now.
> 
> How about only unlocking/locking the crtc->mutex as Rob suggested? I
> think it should work, but I didn't try it yet. Would that be as bad for
> the locking rework?

Same problem really, you shouldn't drop ww mutexes and reacquire them in
the atomic world. ww mutexes have some debug infrastructure for that
(ww_acquire_done) to catch abusers of this.

So if you want to go forward with this it needs at least a big FIXME
comment explaining that this is wrong. If you use locking to enforce
ordering constraints that usually doesn't work well, and dropping locks to
wait for async workers is plainly a locking design bug.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Drop modeset locking from crtc init function

[Thomas Hellstrom]

On 09/08/2014 09:03 AM, Daniel Vetter wrote:
> At driver init no one can access modeset objects and we're
> single-threaded. So locking is just cargo-culting here. Worse, with
> the new ww mutexes and ww mutex slowpath debugging the mutex_lock
> might actually fail, and we don't have the full-blown ww recovery
> dance.
>
> Which then leads to fireworks when we try to unlock the not-locked
> crtc lock.
>
> An audit of all the functions called from here shows that none of them
> contain locking checks, so there's also no reason to keep the locking
> around just for consistency of caller contexts. Besides that I have
> the rule (at least in i915) that such places where we take locks just
> to simplify locking checks and not for correctness always require a
> comment.

I'm not really opposed to any of the patches. It's clear that trylock
will work, and it's also clear that locking is not strictly needed, at
least not of a lock that has not been published yet.

However, I tend to go for the  "lock even if it's unnecessary" version
for a couple of reasons:

a) If that turns out to be impossible or very hard, then something is
probably wrong with the design.
b) It's good to think of locks where possible as "protecting data"
rather than serializing something. With that in mind, and if we in the
future were to have tools to automatically check that relevant locks are
held while accessing lock-protected stuff, we're in trouble.
c) Even if there aren't any functions now that check for relevant locks
held, there might be in the future.
d) People will probably spend time wondering why locking is done
elsewhere but not here.

So at least considering d) and b) I'd like to see documentation the
other way around:
If we avoid taking locks around data accesses that are supposed to be
protected by the lock for whatever reason, the reason should be documented.

Thanks,
Thomas

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit a4bf214ffc72
("drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to
haswell_crtc_disable()") from Linus' tree and commit 575f7ab754c4
("drm/i915: Pass intel_crtc to intel_disable_pipe() and
intel_wait_for_pipe_off()") from the drm-intel tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/i915/intel_display.c
index 18da8349a070,b912107a1392..
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4168,7 -4253,11 +4264,7 @@@ static void ironlake_crtc_disable(struc
if (intel_crtc->config.has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev, pipe, false);

-   intel_disable_pipe(dev_priv, pipe);
+   intel_disable_pipe(intel_crtc);
 -
 -  if (intel_crtc->config.dp_encoder_is_mst)
 -  intel_ddi_set_vc_payload_alloc(crtc, false);
 -
ironlake_pfit_disable(intel_crtc);

for_each_encoder_on_crtc(dev, crtc, encoder)
@@@ -4231,11 -4319,8 +4326,11 @@@ static void haswell_crtc_disable(struc

if (intel_crtc->config.has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, false);
-   intel_disable_pipe(dev_priv, pipe);
+   intel_disable_pipe(intel_crtc);

 +  if (intel_crtc->config.dp_encoder_is_mst)
 +  intel_ddi_set_vc_payload_alloc(crtc, false);
 +
intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);

ironlake_pfit_disable(intel_crtc);
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/0dd44acb/attachment.sig>

[PATCH] drm/vmwgfx: Fix drm.h include

[Thomas Hellstrom]

Hi!

On 09/08/2014 02:01 PM, Emil Velikov wrote:
> Hi Josh
>
> On 05/09/14 18:19, Josh Boyer wrote:
>> The userspace drm.h include doesn't prefix the drm directory.  This can lead
>> to compile failures as /usr/include/drm/ isn't in the standard gcc include
>> paths.  Fix it to be , which matches the rest of the driver drm
>> header files that get installed into /usr/include/drm.
>>
> Is this an actual issue or a hypothetical one ? Afaict no-one is using the
> kernel drm headers, but instead the ones from libdrm are in place.
> linux-headers does not even ship /usr/include/drm on my Archlinux box.
>
> Additionally most (all?) vmwgfx components (mesa, ddx) use a local version of
> the header, which albeit not ideal should not cause issues.
>
> Or perhaps I'm missing something ?
>
>
> To the VMware guys,
>
> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>
> Cheers,
> Emil
Hi!

vmwgfx libdrm is pretty obsolete and AFAIK not used by anyone.
As such, it's unnecessary to release a new version of libdrm each time
the vmwgfx header is updated, and I'd like to avoid that dependency.
Better to keep the local copies in the gallium winsys and the DDX. Since
the ioctl interface is backwards compatible, it doesn't really matter if
the headers are slightly out of sync.

/Thomas






>
> P.S. I'm against the patch in any way :)
>
>> Red Hat Bugzilla: 
>> https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.redhat.com/show_bug.cgi?id%3D1138759=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A=YR9QcTDSKJ%2BRxDHr%2BlEBv%2Fo37iPucyP5QKdoQnUPjcU%3D%0A=c8f9a09bb72428883d57b5ba757295a82326cfc0cac094c56c7754836054ae13
>>
>> Fixes: 1d7a5cbf8f74e
>> Reported-by: Jeffrey Bastian 
>> Signed-off-by: Josh Boyer 
>> ---
>>  include/uapi/drm/vmwgfx_drm.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
>> index 4fc66f6b12ce..c472bedbe38e 100644
>> --- a/include/uapi/drm/vmwgfx_drm.h
>> +++ b/include/uapi/drm/vmwgfx_drm.h
>> @@ -29,7 +29,7 @@
>>  #define __VMWGFX_DRM_H__
>>  
>>  #ifndef __KERNEL__
>> -#include 
>> +#include 
>>  #endif
>>  
>>  #define DRM_VMW_MAX_SURFACE_FACES 6
>>

[PATCH 00/18] Final batch of Android related fixes

[Daniel Vetter]

On Mon, Sep 08, 2014 at 01:10:59PM +0200, Jakob Bornecrantz wrote:
> On Sun, Sep 7, 2014 at 11:29 PM, Emil Velikov  
> wrote:
> > Hello list,
> >
> > Here is the final batch that I've been planning to get upstreamed.
> > Everything else that remains are some custom downstream "hacks" that
> > will get upstreamed by their original authors in due time :)
> >
> >
> > Highlights:
> >  - Drop a few unneeded Makefiles.
> >  - Android support for libkms & modetest. Inspired by Benjamin
> > Gaignard's work.
> >  - Private mmap/munmap wrappers to hide all the love that bionic has for
> > us :)
> >
> >
> > The series is available in branch 'android-final-fixes' at
> > https://github.com/evelikov/libdrm
> >
> >
> > Any comments, reviews, it builds or it works are appreciated.
> 
> While I'm not that familiar with the Android build system patches
> 01, 02 and 03 - 18 are
> 
> Reviewed-by: Jakob Bornecrantz 
> 
> You will have to ask the intel people about 810 and 830 headers removal.

I've thought libdrm provides the canonical sources for drm headers, but
grepping current mesa and intel ddx didn't show any hits. I have no idea
whether we still need them and whether they've ever been part of the
libdrm api. In case of doubt I'd keep them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/vmwgfx: Fix drm.h include

[Emil Velikov]

On 08/09/14 13:15, Thomas Hellstrom wrote:
> Hi!
> 
> On 09/08/2014 02:01 PM, Emil Velikov wrote:
[snip]
>>
>> To the VMware guys,
>>
>> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>>
>> Cheers,
>> Emil
> Hi!
> 
> vmwgfx libdrm is pretty obsolete and AFAIK not used by anyone.
> As such, it's unnecessary to release a new version of libdrm each time
> the vmwgfx header is updated, and I'd like to avoid that dependency.
> Better to keep the local copies in the gallium winsys and the DDX. Since
> the ioctl interface is backwards compatible, it doesn't really matter if
> the headers are slightly out of sync.
> 
Afaict libdrm releases are dirt cheap, and should not cause any issues. Yet
it's your code so you'll be the judge of it all.

I'm just a de-duplication fanatic :)

-Emil

[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag

[Alex Deucher]

On Thu, Aug 28, 2014 at 9:46 PM, Michel D?nzer  wrote:
> On 29.08.2014 00:01, Alex Deucher wrote:
>> On Thu, Aug 28, 2014 at 4:57 AM, Christian K?nig
>>  wrote:
>>> Am 28.08.2014 um 08:56 schrieb Michel D?nzer:
>>>
>>>> From: Michel D?nzer 
>>>>
>>>> This flag is a hint that userspace expects the BO to be accessed by the
>>>> CPU. We can use that hint to prevent such BOs from ever being stored in
>>>> the CPU inaccessible part of VRAM.
>>>>
>>>> Signed-off-by: Michel D?nzer 
>>>
>>>
>>> This patch is Reviewed-by: Christian K?nig 
>>
>> Applied to my -next tree.
>
> Thanks!
>
>
>>> I think we need a similar negative flags as well, e.g.
>>> RADEON_GEM_NO_CPU_ACCESS.
>>>
>>> This way we can stop forcing buffers into the visible VRAM while pinning
>>> them for scanout.
>>
>> How about the attached patch?
>
> [...]
>
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
>> b/drivers/gpu/drm/radeon/radeon_object.c
>> index 09b039a..b71e8e0 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -314,10 +314,14 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32 
>> domain, u64 max_offset,
>>   unsigned lpfn = 0;
>>
>>   /* force to pin into visible video ram */
>> - if (bo->placements[i].flags & TTM_PL_FLAG_VRAM)
>> - lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
>> - else
>> + if (bo->placements[i].flags & TTM_PL_FLAG_VRAM) {
>> + if (bo->flags & RADEON_GEM_NO_CPU_ACCESS)
>> + lpfn = bo->rdev->mc.real_vram_size >> 
>> PAGE_SHIFT;
>> + else
>> + lpfn = bo->rdev->mc.visible_vram_size >> 
>> PAGE_SHIFT;
>
> lpfn can be left at 0 if RADEON_GEM_NO_CPU_ACCESS is set, so this can
> be simplified to:
>
> if (!(bo->flags & RADEON_GEM_NO_CPU_ACCESS))
> lpfn = bo->rdev->mc.visible_vram_size >> 
> PAGE_SHIFT;
>
>
>> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
>> index f755f20..d2346fd 100644
>> --- a/include/uapi/drm/radeon_drm.h
>> +++ b/include/uapi/drm/radeon_drm.h
>> @@ -803,6 +803,8 @@ struct drm_radeon_gem_info {
>>  #define RADEON_GEM_GTT_WC(1 << 2)
>>  /* BO is expected to be accessed by the CPU */
>>  #define RADEON_GEM_CPU_ACCESS(1 << 3)
>> +/* BO is expected to not be accessed by the CPU */
>> +#define RADEON_GEM_NO_CPU_ACCESS (1 << 4)
>
> I'd use stronger wording for this, e.g.
>
> /* CPU access is not expected to work for this BO */

Updated version with comments integrated.

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-add-RADEON_GEM_NO_CPU_ACCESS-BO-creation-.patch
Type: text/x-diff
Size: 1882 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140908/3fc2b801/attachment.patch>

[PATCH] drm/vmwgfx: Fix drm.h include

[Emil Velikov]

On 08/09/14 13:14, Josh Boyer wrote:
> On Mon, Sep 8, 2014 at 8:01 AM, Emil Velikov  
> wrote:
[snip]
>> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>>
>> Cheers,
>> Emil
>>
>> P.S. I'm against the patch in any way :)
> 
> Was that meant to say "I'm not against the patch in any way" ?
> 
Indeed. Quite a silly typo on my behalf.

-Emil

> josh
> 

[PATCH] drm/radeon: fix semaphore value init

[Alex Deucher]

On Sun, Sep 7, 2014 at 6:06 AM, Christian K?nig  
wrote:
> From: Christian K?nig 
>
> Semaphore values have 64 bits, not 32. This fixes a very subtle bug
> that disables synchronization when the upper 32bits wasn't zero.
>
> Signed-off-by: Christian K?nig 
> Cc: stable at vger.kernel.org

Applied to my fixes tree.  thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_semaphore.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c 
> b/drivers/gpu/drm/radeon/radeon_semaphore.c
> index 56d9fd6..abd6753 100644
> --- a/drivers/gpu/drm/radeon/radeon_semaphore.c
> +++ b/drivers/gpu/drm/radeon/radeon_semaphore.c
> @@ -34,7 +34,7 @@
>  int radeon_semaphore_create(struct radeon_device *rdev,
> struct radeon_semaphore **semaphore)
>  {
> -   uint32_t *cpu_addr;
> +   uint64_t *cpu_addr;
> int i, r;
>
> *semaphore = kmalloc(sizeof(struct radeon_semaphore), GFP_KERNEL);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #88 from Aaron B  ---
(In reply to comment #87)
> (In reply to comment #86)
> > https://bugs.freedesktop.org/show_bug.cgi?id=83500
> 
> I think in the meantime Grigori has seen GPU hangs even with that patch
> though, with 2D tiling.
> 
> However, can you avoid the problem if you start Chromium with the
> environment variable R600_DEBUG=nodma?

I was waiting for someone to comment before I updated my status. I have had one
crash, one of the ones where X dies because of 3 quick lock ups+recovers. But,
considering that was the only crash in 2 days, it's much better than before. I
also didn't know if the crash was Chromium or not, because I was alt+tabing
into other windows, but I'd bet it was. Let me recompile mesa fresh and try
launching Chromium and let you know the end of today if disabling also fixes
it.

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

[PATCH 00/18] Final batch of Android related fixes

[Jakob Bornecrantz]

On Sun, Sep 7, 2014 at 11:29 PM, Emil Velikov  
wrote:
> Hello list,
>
> Here is the final batch that I've been planning to get upstreamed.
> Everything else that remains are some custom downstream "hacks" that
> will get upstreamed by their original authors in due time :)
>
>
> Highlights:
>  - Drop a few unneeded Makefiles.
>  - Android support for libkms & modetest. Inspired by Benjamin
> Gaignard's work.
>  - Private mmap/munmap wrappers to hide all the love that bionic has for
> us :)
>
>
> The series is available in branch 'android-final-fixes' at
> https://github.com/evelikov/libdrm
>
>
> Any comments, reviews, it builds or it works are appreciated.

While I'm not that familiar with the Android build system patches
01, 02 and 03 - 18 are

Reviewed-by: Jakob Bornecrantz 

You will have to ask the intel people about 810 and 830 headers removal.

Cheers, Jakob.

[PATCH] drm/vmwgfx: Fix drm.h include

[Emil Velikov]

Hi Josh

On 05/09/14 18:19, Josh Boyer wrote:
> The userspace drm.h include doesn't prefix the drm directory.  This can lead
> to compile failures as /usr/include/drm/ isn't in the standard gcc include
> paths.  Fix it to be , which matches the rest of the driver drm
> header files that get installed into /usr/include/drm.
> 
Is this an actual issue or a hypothetical one ? Afaict no-one is using the
kernel drm headers, but instead the ones from libdrm are in place.
linux-headers does not even ship /usr/include/drm on my Archlinux box.

Additionally most (all?) vmwgfx components (mesa, ddx) use a local version of
the header, which albeit not ideal should not cause issues.

Or perhaps I'm missing something ?


To the VMware guys,

Any objections if we update the libdrm header and drop the mesa/ddx copies ?

Cheers,
Emil

P.S. I'm against the patch in any way :)

> Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138759
> 
> Fixes: 1d7a5cbf8f74e
> Reported-by: Jeffrey Bastian 
> Signed-off-by: Josh Boyer 
> ---
>  include/uapi/drm/vmwgfx_drm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h
> index 4fc66f6b12ce..c472bedbe38e 100644
> --- a/include/uapi/drm/vmwgfx_drm.h
> +++ b/include/uapi/drm/vmwgfx_drm.h
> @@ -29,7 +29,7 @@
>  #define __VMWGFX_DRM_H__
>  
>  #ifndef __KERNEL__
> -#include 
> +#include 
>  #endif
>  
>  #define DRM_VMW_MAX_SURFACE_FACES 6
> 

[PATCH 1/4] imx-drm: ipuv3-plane: allow local alpha in ipu_plane_mode_set()

[Greg Kroah-Hartman]

On Tue, Jul 29, 2014 at 11:57:06AM +0200, Philipp Zabel wrote:
> For the overlay plane scanning out a framebuffer with an alpha component,
> enable the DP local alpha feature on the partial plane.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/staging/imx-drm/ipuv3-plane.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)

Russell, are these ok to take?

thanks,

greg k-h

[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"

[Mikael Pettersson]

Michel D?nzer writes:
 > On 06.09.2014 01:49, Mikael Pettersson wrote:
 > > Michel D?nzer writes:
 > >   > On 30.08.2014 22:59, Mikael Pettersson wrote:
 > >   > > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen 
 > > corruption
 > >   > > after a while in X + firefox.  This still occurs with yesterday's 
 > > HEAD
 > >   > > of Linus' repo.  3.16 and ealier kernels are fine.
 > >   > >
 > >   > > I ran a bisect, which identified:
 > >   > >
 > >   > > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
 > >   > > Author: Michel D??nzer 
 > >   > > Date:   Thu Jul 31 18:43:49 2014 +0900
 > >   > >
 > >   > >  drm/radeon: Always flush the HDP cache before submitting a CS 
 > > to the GPU
 > >   > >
 > >   > > as the cause of my screen corruption.  Reverting this from 3.17-rc2
 > >   > > (which requires manual intervention due to subsequent changes in
 > >   > > radeon_ring_commit()) eliminates the screen corruption.
 > >   >
 > >   > Does the patch below help?
 > > 
 > > Tested, sorry no joy.  I first reconfirmed the screen corruption with 
 > > 3.17-rc3.
 > > I then applied this and rebuilt/rebooted, and after a few minutes X had a 
 > > hickup
 > > (screen went black, came back after a few seconds, but then no cursor or
 > > reaction to mouse events), but I was able to kill it via my 
 > > Terminate_Server
 > > key binding.
 > 
 > I was afraid so, thanks for testing it.
 > 
 > 
 > I can't see any other option than the patch below then. Can you confirm that 
 > this
 > fixes the screen corruption?

I'll test this on Friday evening when I'm back home and have access to the
affected machine.

/Mikael


 > 
 > 
 > diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
 > index 4c5ec44..b0098e7 100644
 > --- a/drivers/gpu/drm/radeon/r100.c
 > +++ b/drivers/gpu/drm/radeon/r100.c
 > @@ -821,6 +821,20 @@ u32 r100_get_vblank_counter(struct radeon_device *rdev, 
 > int crtc)
 >  return RREG32(RADEON_CRTC2_CRNT_FRAME);
 >  }
 >  
 > +/**
 > + * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
 > + * rdev: radeon device structure
 > + * ring: ring buffer struct for emitting packets
 > + */
 > +static void r100_ring_hdp_flush(struct radeon_device *rdev, struct 
 > radeon_ring *ring)
 > +{
 > +radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > +radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
 > +RADEON_HDP_READ_BUFFER_INVALIDATE);
 > +radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > +radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 > +}
 > +
 >  /* Who ever call radeon_fence_emit should call ring_lock and ask
 >   * for enough space (today caller are ib schedule and buffer move) */
 >  void r100_fence_ring_emit(struct radeon_device *rdev,
 > @@ -1056,20 +1070,6 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
 >  (void)RREG32(RADEON_CP_RB_WPTR);
 >  }
 >  
 > -/**
 > - * r100_ring_hdp_flush - flush Host Data Path via the ring buffer
 > - * rdev: radeon device structure
 > - * ring: ring buffer struct for emitting packets
 > - */
 > -void r100_ring_hdp_flush(struct radeon_device *rdev, struct radeon_ring 
 > *ring)
 > -{
 > -radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > -radeon_ring_write(ring, rdev->config.r100.hdp_cntl |
 > -RADEON_HDP_READ_BUFFER_INVALIDATE);
 > -radeon_ring_write(ring, PACKET0(RADEON_HOST_PATH_CNTL, 0));
 > -radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
 > -}
 > -
 >  static void r100_cp_load_microcode(struct radeon_device *rdev)
 >  {
 >  const __be32 *fw_data;
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
 > b/drivers/gpu/drm/radeon/radeon_asic.c
 > index abe..2dd5847 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.c
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
 > @@ -185,7 +185,6 @@ static struct radeon_asic_ring r100_gfx_ring = {
 >  .get_rptr = _gfx_get_rptr,
 >  .get_wptr = _gfx_get_wptr,
 >  .set_wptr = _gfx_set_wptr,
 > -.hdp_flush = _ring_hdp_flush,
 >  };
 >  
 >  static struct radeon_asic r100_asic = {
 > @@ -332,7 +331,6 @@ static struct radeon_asic_ring r300_gfx_ring = {
 >  .get_rptr = _gfx_get_rptr,
 >  .get_wptr = _gfx_get_wptr,
 >  .set_wptr = _gfx_set_wptr,
 > -.hdp_flush = _ring_hdp_flush,
 >  };
 >  
 >  static struct radeon_asic r300_asic = {
 > diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
 > b/drivers/gpu/drm/radeon/radeon_asic.h
 > index 275a5dc..7756bc1 100644
 > --- a/drivers/gpu/drm/radeon/radeon_asic.h
 > +++ b/drivers/gpu/drm/radeon/radeon_asic.h
 > @@ -148,8 +148,7 @@ u32 r100_gfx_get_wptr(struct radeon_device *rdev,
 >struct radeon_ring *ring);
 >  void r100_gfx_set_wptr(struct radeon_device *rdev,
 > struct radeon_ring *ring);
 > -void r100_ring_hdp_flush(struct radeon_device *rdev,
 > - struct radeon_ring *ring);
 > +
 >  /*
 >   * 

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

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

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

--- Comment #21 from t3st3r at mail.ru ---
2) About 3.17... I attempted 3.17-rc1 and it crashed in about 30 seconds of run
of problematic work. 

I will try newer -RCs as well, as I can see there were some extra changes to
radeon-related code.

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

[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)

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

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

--- Comment #20 from t3st3r at mail.ru ---
1) About 3.15 + patch: I gave it a try and it took quite a while to get opinion
about it. Overall it is quite stable and survives about several days of run of
problematic load. But eventually GPU still could encounter crash. Intereating
thing in this occurence I caught is that regardless of scary message about
failed DPM resume, GPU seems to be operable after successful recovery. I got
couple of similar crashes as well within a week. It looked like this:

===cut===
[815114.959250] SysRq : Emergency Sync
[815115.071974] Emergency Sync complete
[815116.935547] radeon :01:00.0: ring 0 stalled for more than 10082msec
[815116.935556] radeon :01:00.0: GPU lockup (waiting for 0x07f39f60
last fence id 0x07f39f5f on ring 0)
[815116.935564] radeon :01:00.0: failed to get a new IB (-35)
[815116.942472] radeon :01:00.0: sa_manager is not empty, clearing anyway
[815117.134467] SysRq : Keyboard mode set to system default
[815117.500079] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0
domain=0x0018 address=0x80406640 flags=0x]
[815117.500092] radeon :01:00.0: Saved 6061 dwords of commands on ring 0.
[815117.500097] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0
domain=0x0018 address=0x80406650 flags=0x0020]
[815117.500104] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0
domain=0x0018 address=0x8100 flags=0x0020]
[815117.500110] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0
domain=0x0018 address=0x80404500 flags=0x]
[815117.500222] radeon :01:00.0: GPU softreset: 0x006C
[815117.500226] radeon :01:00.0:   GRBM_STATUS   = 0xA0003028
[815117.500229] radeon :01:00.0:   GRBM_STATUS_SE0   = 0x0006
[815117.500231] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0006
[815117.500233] radeon :01:00.0:   SRBM_STATUS   = 0x22C0
[815117.500349] radeon :01:00.0:   SRBM_STATUS2  = 0x
[815117.500351] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[815117.500353] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x0001
[815117.500356] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x0002
[815117.500358] radeon :01:00.0:   R_008680_CP_STAT  = 0x80010243
[815117.500360] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44483106
[815117.500362] radeon :01:00.0:   R_00D834_DMA_STATUS_REG   = 0x44C84246
[815117.500365] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[815117.500368] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x
[815118.057253] radeon :01:00.0: GRBM_SOFT_RESET=0xDDFF
[815118.057308] radeon :01:00.0: SRBM_SOFT_RESET=0x00100140
[815118.058465] radeon :01:00.0:   GRBM_STATUS   = 0x3028
[815118.058468] radeon :01:00.0:   GRBM_STATUS_SE0   = 0x0006
[815118.058470] radeon :01:00.0:   GRBM_STATUS_SE1   = 0x0006
[815118.058472] radeon :01:00.0:   SRBM_STATUS   = 0x20C0
[815118.058583] radeon :01:00.0:   SRBM_STATUS2  = 0x
[815118.058585] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[815118.058588] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[815118.058590] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[815118.058592] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[815118.058594] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[815118.058597] radeon :01:00.0:   R_00D834_DMA_STATUS_REG   = 0x44C83D57
[815118.058843] radeon :01:00.0: GPU reset succeeded, trying to resume
[815118.086936] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0
[815118.086939] [drm] PCIE gen 2 link speeds already enabled
[815118.090599] [drm] PCIE GART of 1024M enabled (table at 0x00276000).
[815118.090704] radeon :01:00.0: WB enabled
[815118.090707] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x8c00 and cpu addr 0x880414545c00
[815118.090709] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x8c04 and cpu addr 0x880414545c04
[815118.090711] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x8c08 and cpu addr 0x880414545c08
[815118.090713] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x8c0c and cpu addr 0x880414545c0c
[815118.090715] radeon :01:00.0: fence driver on ring 4 use gpu addr
0x8c10 and cpu addr 0x880414545c10
[815118.091689] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x00075a18 and cpu addr 0xc90012135a18
[815118.278813] [drm] ring test on 0 succeeded in 3 usecs
[815118.278819] [drm] ring test on 1 succeeded in 1 usecs
[815118.278824] [drm] ring test on 2 succeeded in 1 usecs
[815118.27] [drm] ring test on 3 succeeded in 2 

[PATCH 05/18] libkms: build the intel backend only when needed

[Jakob Bornecrantz]

On Sun, Sep 7, 2014 at 11:30 PM, Emil Velikov  
wrote:
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac   |  3 +++
>  libkms/Makefile.am |  5 -
>  libkms/linux.c | 16 +++-
>  3 files changed, 18 insertions(+), 6 deletions(-)

Reviewed-by: Jakob Bornecrantz 

Cheers, Jakob.

>
> diff --git a/configure.ac b/configure.ac
> index 484084f..f1d3451 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -270,6 +270,9 @@ fi
>  AM_CONDITIONAL(HAVE_LIBKMS, [test "x$LIBKMS" = xyes])
>
>  AM_CONDITIONAL(HAVE_INTEL, [test "x$INTEL" = xyes])
> +if test "x$INTEL" = xyes; then
> +   AC_DEFINE(HAVE_INTEL, 1, [Have intel support])
> +fi
>
>  AM_CONDITIONAL(HAVE_VMWGFX, [test "x$VMWGFX" = xyes])
>  if test "x$VMWGFX" = xyes; then
> diff --git a/libkms/Makefile.am b/libkms/Makefile.am
> index 449a73b..dae44e9 100644
> --- a/libkms/Makefile.am
> +++ b/libkms/Makefile.am
> @@ -15,7 +15,6 @@ libkms_la_LIBADD = ../libdrm.la
>  libkms_la_SOURCES = \
> internal.h \
> linux.c \
> -   intel.c \
> dumb.c \
> api.c
>
> @@ -23,6 +22,10 @@ if HAVE_VMWGFX
>  libkms_la_SOURCES += vmwgfx.c
>  endif
>
> +if HAVE_INTEL
> +libkms_la_SOURCES += intel.c
> +endif
> +
>  if HAVE_NOUVEAU
>  libkms_la_SOURCES += nouveau.c
>  endif
> diff --git a/libkms/linux.c b/libkms/linux.c
> index 17e1d58..77a0bbe 100644
> --- a/libkms/linux.c
> +++ b/libkms/linux.c
> @@ -103,25 +103,31 @@ linux_from_sysfs(int fd, struct kms_driver **out)
> if (ret)
> return ret;
>
> +#ifdef HAVE_INTEL
> if (!strcmp(name, "intel"))
> ret = intel_create(fd, out);
> +   else
> +#endif
>  #ifdef HAVE_VMWGFX
> -   else if (!strcmp(name, "vmwgfx"))
> +   if (!strcmp(name, "vmwgfx"))
> ret = vmwgfx_create(fd, out);
> +   else
>  #endif
>  #ifdef HAVE_NOUVEAU
> -   else if (!strcmp(name, "nouveau"))
> +   if (!strcmp(name, "nouveau"))
> ret = nouveau_create(fd, out);
> +   else
>  #endif
>  #ifdef HAVE_RADEON
> -   else if (!strcmp(name, "radeon"))
> +   if (!strcmp(name, "radeon"))
> ret = radeon_create(fd, out);
> +   else
>  #endif
>  #ifdef HAVE_EXYNOS
> -   else if (!strcmp(name, "exynos"))
> +   if (!strcmp(name, "exynos"))
> ret = exynos_create(fd, out);
> -#endif
> else
> +#endif
> ret = -ENOSYS;
>
> free(name);
> --
> 2.0.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/18] libkms: add Android build

[Jakob Bornecrantz]

On Sun, Sep 7, 2014 at 11:30 PM, Emil Velikov  
wrote:
> Cc: Benjamin Gaignard 
> Signed-off-by: Emil Velikov 
> ---
>  Android.mk|  3 ++-
>  libkms/Android.mk | 53 +
>  2 files changed, 55 insertions(+), 1 deletion(-)
>  create mode 100644 libkms/Android.mk

Not super familiar with Android build system but it looks good to me:

Reviewed-by: Jakob Bornecrantz 

Cheers, Jakob.

>
> diff --git a/Android.mk b/Android.mk
> index 97a7d75..4d02b05 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -55,7 +55,8 @@ SUBDIRS := \
> freedreno \
> intel \
> nouveau \
> -   radeon
> +   radeon \
> +   libkms
>
>  mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS))
>  include $(mkfiles)
> diff --git a/libkms/Android.mk b/libkms/Android.mk
> new file mode 100644
> index 000..d2df32a
> --- /dev/null
> +++ b/libkms/Android.mk
> @@ -0,0 +1,53 @@
> +DRM_GPU_DRIVERS := $(strip $(filter-out swrast, $(BOARD_GPU_DRIVERS)))
> +
> +intel_drivers := i915 i965 i915g ilo
> +radeon_drivers := r300g r600g radeonsi
> +nouveau_drivers := nouveau
> +vmwgfx_drivers := vmwgfx
> +
> +valid_drivers := \
> +   $(intel_drivers) \
> +   $(radeon_drivers) \
> +   $(nouveau_drivers) \
> +   $(vmwgfx_drivers)
> +
> +# warn about invalid drivers
> +invalid_drivers := $(filter-out $(valid_drivers), $(DRM_GPU_DRIVERS))
> +ifneq ($(invalid_drivers),)
> +$(warning invalid GPU drivers: $(invalid_drivers))
> +# tidy up
> +DRM_GPU_DRIVERS := $(filter-out $(invalid_drivers), $(DRM_GPU_DRIVERS))
> +endif
> +
> +LOCAL_PATH := $(call my-dir)
> +
> +include $(CLEAR_VARS)
> +include $(LOCAL_PATH)/Makefile.sources
> +
> +LOCAL_SRC_FILES := $(LIBKMS_FILES)
> +
> +ifneq ($(filter $(vmwgfx_drivers), $(DRM_GPU_DRIVERS)),)
> +LOCAL_SRC_FILES += $(LIBKMS_VMWGFX_FILES)
> +endif
> +
> +ifneq ($(filter $(intel_drivers), $(DRM_GPU_DRIVERS)),)
> +LOCAL_SRC_FILES += $(LIBKMS_INTEL_FILES)
> +endif
> +
> +ifneq ($(filter $(nouveau_drivers), $(DRM_GPU_DRIVERS)),)
> +LOCAL_SRC_FILES += $(LIBKMS_NOUVEAU_FILES)
> +endif
> +
> +ifneq ($(filter $(radeon_drivers), $(DRM_GPU_DRIVERS)),)
> +LOCAL_SRC_FILES += $(LIBKMS_RADEON_FILES)
> +endif
> +
> +LOCAL_MODULE := libkms
> +LOCAL_SHARED_LIBRARIES := libdrm
> +
> +LOCAL_C_INCLUDES += $(TARGET_OUT_HEADERS)/libdrm
> +
> +LOCAL_COPY_HEADERS_TO := libdrm
> +LOCAL_COPY_HEADERS := $(LIBKMS_H_FILES)
> +
> +include $(BUILD_SHARED_LIBRARY)
> --
> 2.0.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Two imx-drm oops fixes

[Greg Kroah-Hartman]

On Mon, Sep 08, 2014 at 12:08:59PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote:
> > Greg,
> > 
> > Here's two oops fixes for imx-drm, which I've had queued up for a number
> > of months now.  Shawn posted different fixes for the same oops recently
> > as well.
> 
> So do I take your patches, or Shawn's?

Actually, yours are "smaller", so I'll defer to you and take yours...

thanks,

gerg "small is good" k-h

[PATCH 0/2] Two imx-drm oops fixes

[Greg Kroah-Hartman]

On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote:
> Greg,
> 
> Here's two oops fixes for imx-drm, which I've had queued up for a number
> of months now.  Shawn posted different fixes for the same oops recently
> as well.

So do I take your patches, or Shawn's?

confused,

greg k-h

[PATCH v5 11/11] ARM: at91/dt: enable the LCD panel on sama5d3xek boards

[Boris BREZILLON]

Enable LCD related nodes.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d31ek.dts | 20 
 arch/arm/boot/dts/sama5d33ek.dts | 20 
 arch/arm/boot/dts/sama5d34ek.dts | 20 
 arch/arm/boot/dts/sama5d36ek.dts | 20 
 4 files changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d31ek.dts b/arch/arm/boot/dts/sama5d31ek.dts
index 04eec0d..6e605fe 100644
--- a/arch/arm/boot/dts/sama5d31ek.dts
+++ b/arch/arm/boot/dts/sama5d31ek.dts
@@ -33,6 +33,10 @@
status = "okay";
};

+   hlcdc: hlcdc at f003 {
+   status = "okay";
+   };
+
macb1: ethernet at f802c000 {
status = "okay";
};
@@ -46,6 +50,22 @@
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d33ek.dts b/arch/arm/boot/dts/sama5d33ek.dts
index cbd6a3f..0400641 100644
--- a/arch/arm/boot/dts/sama5d33ek.dts
+++ b/arch/arm/boot/dts/sama5d33ek.dts
@@ -36,9 +36,29 @@
macb0: ethernet at f0028000 {
status = "okay";
};
+
+   hlcdc: hlcdc at f003 {
+   status = "okay";
+   };
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d34ek.dts b/arch/arm/boot/dts/sama5d34ek.dts
index 878aa16..9cf473e 100644
--- a/arch/arm/boot/dts/sama5d34ek.dts
+++ b/arch/arm/boot/dts/sama5d34ek.dts
@@ -46,6 +46,10 @@
macb0: ethernet at f0028000 {
status = "okay";
};
+
+   hlcdc: hlcdc at f003 {
+   status = "okay";
+   };
};
};

@@ -56,6 +60,22 @@
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d36ek.dts b/arch/arm/boot/dts/sama5d36ek.dts
index 59576c6..1c65741 100644
--- a/arch/arm/boot/dts/sama5d36ek.dts
+++ b/arch/arm/boot/dts/sama5d36ek.dts
@@ -41,12 +41,32 @@
status = "okay";
};

+   hlcdc: hlcdc at f003 {
+   status = "okay";
+   };
+
macb1: ethernet at f802c000 {
status = "okay";
};
};
};

+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
-- 
1.9.1

[PATCH v5 10/11] ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi

[Boris BREZILLON]

Add LCD panel related nodes (backlight, regulators and panel) to sama5d3
Display Module dtsi.

Reference LCD pin muxing used by sama5d3xek boards.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3xdm.dtsi | 58 +++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3xdm.dtsi 
b/arch/arm/boot/dts/sama5d3xdm.dtsi
index 035ab72..91975eb 100644
--- a/arch/arm/boot/dts/sama5d3xdm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xdm.dtsi
@@ -36,6 +36,64 @@
};
};
};
+
+   hlcdc: hlcdc at f003 {
+   hlcdc-display-controller {
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_base 
_lcd_rgb888_alt>;
+
+   port at 0 {
+   hlcdc_panel_output: endpoint at 
0 {
+   reg = <0>;
+   remote-endpoint = 
<_input>;
+   };
+   };
+   };
+   };
+   };
+   };
+
+   bl_reg: backlight_regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "backlight-power-supply";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   status = "disabled";
+   };
+
+   panel_reg: panel_regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "panel-power-supply";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   status = "disabled";
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <_pwm 0 5 0>;
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+   power-supply = <_reg>;
+   status = "disabled";
+   };
+
+   panel: panel {
+   compatible = "foxlink,fl500wvr00-a0t", "simple-panel";
+   backlight = <>;
+   power-supply = <_reg>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_panel_output>;
+   };
};
};
 };
-- 
1.9.1

[PATCH v5 09/11] ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs

[Boris BREZILLON]

Define the HLCDC (HLCD Controller) IP available on some sama5d3 SoCs
(i.e. sama5d31, sama5d33, sama5d34 and sama5d36) in sama5d3 dtsi file.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index e7581f6..1874cf7 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -166,6 +166,34 @@
};
};

+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", 
"slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = 
"atmel,hlcdc-display-controller";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+   };
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
+
pmc: pmc at fc00 {
periphck {
lcdc_clk: lcdc_clk {
-- 
1.9.1

[PATCH v5 08/11] ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins

[Boris BREZILLON]

Define alternative pin muxing for the LCDC pins.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 2186b89..e7581f6 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -82,6 +82,28 @@
 AT91_PIOA 13 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD13 pin */
 AT91_PIOA 14 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD14 pin */
 AT91_PIOA 15 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD15 pin */
+AT91_PIOA 16 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD16 pin */
+AT91_PIOA 17 
AT91_PERIPH_A AT91_PINCTRL_NONE>; /* LCDD17 pin */
+   };
+
+   pinctrl_lcd_rgb666_alt: lcd-rgb-2-alt {
+   atmel,pins =
+   ; /* LCDD17 pin */
};
@@ -104,6 +126,34 @@
 AT91_PIOA 13 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD13 pin */
 AT91_PIOA 14 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD14 pin */
 AT91_PIOA 15 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD15 pin */
+AT91_PIOA 16 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD16 pin */
+AT91_PIOA 17 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD17 pin */
+AT91_PIOA 18 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD18 pin */
+AT91_PIOA 19 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD19 pin */
+AT91_PIOA 20 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD20 pin */
+AT91_PIOA 21 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD21 pin */
+AT91_PIOA 22 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD22 pin */
+AT91_PIOA 23 
AT91_PERIPH_A AT91_PINCTRL_NONE>; /* LCDD23 pin */
+   };
+
+   pinctrl_lcd_rgb888_alt: lcd-rgb-3-alt {
+   atmel,pins =
+   

[PATCH v5 07/11] ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode configs

[Boris BREZILLON]

The HLCDC (HLCD Controller) IP supports 4 different output mode (RGB444,
RGB565, RGB666 and RGB888) and the pin muxing will depend on the chosen
RGB mode.

Split pin definitions to be able to set pin config according to the
selected mode.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 127 -
 1 file changed, 96 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 85d3027..2186b89 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -15,38 +15,103 @@
apb {
pinctrl at f200 {
lcd {
-   pinctrl_lcd: lcd-0 {
+   pinctrl_lcd_pwm: lcd-pwm-0 {
+   atmel,pins = ;/* LCDPWM */
+   };
+
+   pinctrl_lcd_base: lcd-base-0 {
+   atmel,pins =
+   ; /* LCDPCK */
+   };
+
+   pinctrl_lcd_rgb444: lcd-rgb-0 {
+   atmel,pins =
+   ; /* LCDD11 pin */
+   };
+
+   pinctrl_lcd_rgb565: lcd-rgb-1 {
+   atmel,pins =
+   ; /* LCDD15 pin */
+   };
+
+   pinctrl_lcd_rgb666: lcd-rgb-2 {
+   atmel,pins =
+   ; /* LCDD17 pin */
+   };
+
+   pinctrl_lcd_rgb888: lcd-rgb-3 {
atmel,pins =
-   ; /* PE28 periph C LCDD23 pin */
+   ; /* LCDD23 pin */
};
};
};
-- 
1.9.1

[PATCH v5 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver

[Boris BREZILLON]

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.

The atmel,panel property link the HLCDC RGB output with the LCD panel
connected on this port (note that the HLCDC RGB connector implementation
makes use of the DRM panel framework).

Connection to other external devices (DRM bridges) might be added later by
mean of a new atmel,xxx (atmel,bridge) property.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/drm/atmel-hlcdc-dc.txt | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt

diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt 
b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
new file mode 100644
index 000..73b9860
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
@@ -0,0 +1,54 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
+
+The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
+See ../mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be "atmel,hlcdc-display-controller"
+ - interrupts: the HLCDC interrupt definition
+ - pinctrl-names: the pin control state names. Should contain "default".
+ - pinctrl-0: should contain the default pinctrl states.
+ - #address-cells: should be set to 1.
+ - #size-cells: should be set to 0.
+
+Required children nodes:
+ Children nodes are encoding available output ports and their connections
+ to external devices using the OF graph reprensentation (see ../graph.txt).
+ At least one port node is required.
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-display-controller";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_base _lcd_rgb888>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hlcdc_panel_output: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+   };
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.9.1

[PATCH v5 05/11] drm: add Atmel HLCDC Display Controller support

[Boris BREZILLON]

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

At the moment, this driver only implements an RGB connector to interface
with LCD panels, but support for other kind of external devices might be
added later.

Signed-off-by: Boris BREZILLON 
Tested-by: Ludovic Desroches 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig  |  13 +
 drivers/gpu/drm/atmel-hlcdc/Makefile |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 286 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 488 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 224 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c  | 656 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h  | 403 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 476 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 836 +++
 11 files changed, 3392 insertions(+)
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f512004..9183a78 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -184,6 +184,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"

 source "drivers/gpu/drm/armada/Kconfig"

+source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
+
 source "drivers/gpu/drm/rcar-du/Kconfig"

 source "drivers/gpu/drm/shmobile/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index af9a609..07d388c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
 obj-$(CONFIG_DRM_ARMADA) += armada/
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc/
 obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig 
b/drivers/gpu/drm/atmel-hlcdc/Kconfig
new file mode 100644
index 000..6d0d785
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig
@@ -0,0 +1,13 @@
+config DRM_ATMEL_HLCDC
+   tristate "DRM Support for ATMEL HLCDC Display Controller"
+   depends on DRM && OF && MFD_ATMEL_HLCDC && COMMON_CLK
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL
+   select MFD_ATMEL_HLCDC
+   depends on OF
+   help
+ Choose this option if you have an ATMEL SoC with an HLCDC display
+ controller (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family).
diff --git a/drivers/gpu/drm/atmel-hlcdc/Makefile 
b/drivers/gpu/drm/atmel-hlcdc/Makefile
new file mode 100644
index 000..10ae426
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Makefile
@@ -0,0 +1,7 @@
+atmel-hlcdc-dc-y := atmel_hlcdc_crtc.o \
+   atmel_hlcdc_dc.o \
+   atmel_hlcdc_layer.o \
+   atmel_hlcdc_output.o \
+   atmel_hlcdc_plane.o
+
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc-dc.o
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
new file mode 100644
index 000..2186830
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -0,0 +1,286 @@
+/*
+ * Copyright (C) 2014 Traphandler
+ * Copyright (C) 2014 Free Electrons
+ *
+ * Author: Jean-Jacques Hiblot 
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+

[PATCH v5 04/11] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver

[Boris BREZILLON]

The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.

The DT bindings used for this PWM device is following the default 3 cells
bindings described in Documentation/devicetree/bindings/pwm/pwm.txt.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt| 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt 
b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
new file mode 100644
index 000..86ad3e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
@@ -0,0 +1,55 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) PWM driver
+
+The Atmel HLCDC PWM is subdevice of the HLCDC MFD device.
+See ../mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,hlcdc-pwm"
+ - pinctr-names: the pin control state names. Should contain "default".
+ - pinctrl-0: should contain the pinctrl states described by pinctrl
+   default.
+ - #pwm-cells: should be set to 3. This PWM chip use the default 3 cells
+   bindings defined in Documentation/devicetree/bindings/pwm/pwm.txt.
+   The first cell encodes the PWM id (0 is the only acceptable value here,
+   because the chip only provide one PWM).
+   The second cell encodes the PWM period in nanoseconds.
+   The third cell encodes the PWM flags (the only supported flag is
+   PWM_POLARITY_INVERTED)
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-display-controller";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_base _lcd_rgb888>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hlcdc_panel_output: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+   };
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.9.1

[PATCH v5 03/11] pwm: add support for atmel-hlcdc-pwm device

[Boris BREZILLON]

The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.

This driver add support for a PWM chip exposing a single PWM device (which
will most likely be used to drive a backlight device).

Signed-off-by: Boris BREZILLON 
---
 drivers/pwm/Kconfig   |  10 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-atmel-hlcdc.c | 229 ++
 3 files changed, 240 insertions(+)
 create mode 100644 drivers/pwm/pwm-atmel-hlcdc.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 4ad7b89..ad1f362 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -50,6 +50,16 @@ config PWM_ATMEL
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel.

+config PWM_ATMEL_HLCDC_PWM
+   tristate "Atmel HLCDC PWM support"
+   select MFD_ATMEL_HLCDC
+   depends on OF
+   help
+ Generic PWM framework driver for Atmel HLCDC PWM.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel.
+
 config PWM_ATMEL_TCB
tristate "Atmel TC Block PWM support"
depends on ATMEL_TCLIB && OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 5c86a19..26ae965 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_PWM)   += core.o
 obj-$(CONFIG_PWM_SYSFS)+= sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
+obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM)  += pwm-atmel-hlcdc.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
 obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
new file mode 100644
index 000..0238f7a
--- /dev/null
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ * Copyright (C) 2014 Atmel
+ *
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_HLCDC_PWMCVAL_MASK   GENMASK(15, 8)
+#define ATMEL_HLCDC_PWMCVAL(x) ((x << 8) & ATMEL_HLCDC_PWMCVAL_MASK)
+#define ATMEL_HLCDC_PWMPOL BIT(4)
+#define ATMEL_HLCDC_PWMPS_MASK GENMASK(2, 0)
+#define ATMEL_HLCDC_PWMPS_MAX  0x6
+#define ATMEL_HLCDC_PWMPS(x)   ((x) & ATMEL_HLCDC_PWMPS_MASK)
+
+struct atmel_hlcdc_pwm_chip {
+   struct pwm_chip chip;
+   struct atmel_hlcdc *hlcdc;
+   struct clk *cur_clk;
+};
+
+static inline struct atmel_hlcdc_pwm_chip *
+pwm_chip_to_atmel_hlcdc_pwm_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct atmel_hlcdc_pwm_chip, chip);
+}
+
+static int atmel_hlcdc_pwm_config(struct pwm_chip *c,
+ struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+   struct atmel_hlcdc_pwm_chip *chip =
+   pwm_chip_to_atmel_hlcdc_pwm_chip(c);
+   struct atmel_hlcdc *hlcdc = chip->hlcdc;
+   struct clk *new_clk = hlcdc->slow_clk;
+   u64 pwmcval = duty_ns * 256;
+   unsigned long clk_freq;
+   u64 clk_period_ns;
+   u32 pwmcfg;
+   int pres;
+
+   clk_freq = clk_get_rate(new_clk);
+   clk_period_ns = 10;
+   clk_period_ns *= 256;
+   do_div(clk_period_ns, clk_freq);
+
+   if (clk_period_ns > period_ns) {
+   new_clk = hlcdc->sys_clk;
+   clk_freq = clk_get_rate(new_clk);
+   clk_period_ns = 10;
+   clk_period_ns *= 256;
+   do_div(clk_period_ns, clk_freq);
+   }
+
+   for (pres = 0; pres <= ATMEL_HLCDC_PWMPS_MAX; pres++) {
+   if ((clk_period_ns << pres) >= period_ns)
+   break;
+   }
+
+   if (pres > ATMEL_HLCDC_PWMPS_MAX)
+   return -EINVAL;
+
+   pwmcfg = ATMEL_HLCDC_PWMPS(pres);
+
+   if (new_clk != chip->cur_clk) {
+   u32 gencfg = 0;
+
+   clk_prepare_enable(new_clk);
+   clk_disable_unprepare(chip->cur_clk);
+   chip->cur_clk = new_clk;
+
+   if (new_clk != hlcdc->slow_clk)
+   gencfg = ATMEL_HLCDC_CLKPWMSEL;
+   

[PATCH v5 02/11] mfd: add documentation for atmel-hlcdc DT bindings

[Boris BREZILLON]

The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip

This patch adds documentation for atmel-hlcdc DT bindings.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/mfd/atmel-hlcdc.txt| 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt

diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt 
b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
new file mode 100644
index 000..e9cc1b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
@@ -0,0 +1,50 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,sama5d3-hlcdc"
+ - reg: base address and size of the HLCDC device registers.
+ - clock-names: the name of the 3 clocks requested by the HLCDC device.
+   Should contain "periph_clk", "sys_clk" and "slow_clk".
+ - clocks: should contain the 3 clocks requested by the HLCDC device.
+
+The HLCDC IP exposes two subdevices:
+ - a PWM chip: see ../pwm/atmel-hlcdc-pwm.txt
+ - a Display Controller: see ../drm/atmel-hlcdc-dc.txt
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-display-controller";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_base _lcd_rgb888>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hlcdc_panel_output: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+   };
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.9.1

[PATCH v5 01/11] mfd: add atmel-hlcdc driver

[Boris BREZILLON]

The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip

The MFD device provides a regmap and several clocks (those connected
to this hardware block) to its subdevices.

This way concurrent accesses to the iomem range are handled by the regmap
framework, and each subdevice can safely access HLCDC registers.

Signed-off-by: Boris BREZILLON 
Acked-by: Lee Jones 
Tested-by: Ludovic Desroches 
---
 drivers/mfd/Kconfig |   6 ++
 drivers/mfd/Makefile|   1 +
 drivers/mfd/atmel-hlcdc.c   | 118 
 include/linux/mfd/atmel-hlcdc.h |  78 ++
 4 files changed, 203 insertions(+)
 create mode 100644 drivers/mfd/atmel-hlcdc.c
 create mode 100644 include/linux/mfd/atmel-hlcdc.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6cc4b6a..dbd1a16 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -59,6 +59,12 @@ config MFD_AAT2870_CORE
  additional drivers must be enabled in order to use the
  functionality of the device.

+config MFD_ATMEL_HLCDC
+   tristate
+   select MFD_CORE
+   select REGMAP_MMIO
+   depends on OF
+
 config MFD_BCM590XX
tristate "Broadcom BCM590xx PMUs"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8afedba..5f25b0d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -156,6 +156,7 @@ obj-$(CONFIG_MFD_PM8921_CORE)   += pm8921-core.o ssbi.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_ATMEL_HLCDC)  += atmel-hlcdc.o
 obj-$(CONFIG_MFD_INTEL_MSIC)   += intel_msic.o
 obj-$(CONFIG_MFD_PALMAS)   += palmas.o
 obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
new file mode 100644
index 000..aadb371
--- /dev/null
+++ b/drivers/mfd/atmel-hlcdc.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ * Copyright (C) 2014 Atmel
+ *
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_HLCDC_REG_MAX(0x4000 - 0x4)
+
+static const struct mfd_cell atmel_hlcdc_cells[] = {
+   {
+   .name = "atmel-hlcdc-pwm",
+   .of_compatible = "atmel,hlcdc-pwm",
+   },
+   {
+   .name = "atmel-hlcdc-dc",
+   .of_compatible = "atmel,hlcdc-display-controller",
+   },
+};
+
+static const struct regmap_config atmel_hlcdc_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .max_register = ATMEL_HLCDC_REG_MAX,
+};
+
+static int atmel_hlcdc_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct atmel_hlcdc *hlcdc;
+   struct resource *res;
+   void __iomem *regs;
+
+   hlcdc = devm_kzalloc(dev, sizeof(*hlcdc), GFP_KERNEL);
+   if (!hlcdc)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
+
+   hlcdc->periph_clk = devm_clk_get(dev, "periph_clk");
+   if (IS_ERR(hlcdc->periph_clk)) {
+   dev_err(dev, "failed to get peripheral clock\n");
+   return PTR_ERR(hlcdc->periph_clk);
+   }
+
+   hlcdc->sys_clk = devm_clk_get(dev, "sys_clk");
+   if (IS_ERR(hlcdc->sys_clk)) {
+   dev_err(dev, "failed to get system clock\n");
+   return PTR_ERR(hlcdc->sys_clk);
+   }
+
+   hlcdc->slow_clk = devm_clk_get(dev, "slow_clk");
+   if (IS_ERR(hlcdc->slow_clk)) {
+   dev_err(dev, "failed to get slow clock\n");
+   return PTR_ERR(hlcdc->slow_clk);
+   }
+
+   hlcdc->regmap = devm_regmap_init_mmio(dev, regs,
+ _hlcdc_regmap_config);
+   if (IS_ERR(hlcdc->regmap))
+   return PTR_ERR(hlcdc->regmap);
+
+   dev_set_drvdata(dev, hlcdc);
+
+   return mfd_add_devices(dev, -1, atmel_hlcdc_cells,
+  ARRAY_SIZE(atmel_hlcdc_cells),
+   

[PATCH v5 00/11] drm: add support for Atmel HLCDC Display Controller

[Boris BREZILLON]

Hello,

This patch series adds support for Atmel HLCDC (HLCD Controller) available
on some Atmel SoCs (i.e. the sama5d3 family).

The HLCDC actually provides a Display Controller and a PWM device, hence I
decided to declare an MFD device exposing 2 subdevices: a display
controller and a PWM chip.
This also solves a circular dependency issue preventing HLCDC driver from
unloading.
The HLCDC request a drm_panel device, which request a backlight device
(a PWM backlight), which depends on a PWM which is provided by the HLCDC
driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)).

The current implementation only supports sama5d3 SoCs but other SoCs should
be easily ported by defining new compatible strings and adding HLCDC
description structures for these SoCs (Ludovic tested this driver on an
at91sam9x5 board).

The drivers supports basic CRTC functionalities, several overlays and an
hardware cursor.

At the moment, it only supports connection to LCD panels through an RGB
connector (defined as an LVDS connector in my implementation), though
connection to other kind of devices (like DRM bridges) could be added later.

It also supports several RGB formats on all planes and some YUV formats on
the HEO overlay plane.

This series depends those series: [1] and [2].

I know you're all quite busy, but I was expecting to get support for
atmel's HLCDC block in 3.18, and given the lack of review I got on the
DRM and PWM parts I doubt it can happen :-(.

Moreover, the dependencies ([1] and [2]) are stuck too.
The first one has been reviewed by Rob, but didn't get any feedback after
that. David, Rob, is there anything blocking this series ?
The second patch series contains some rework I've done to describe the
transfer format used on a connector bus. Laurent, Thierry, you're the one
who suggested this rework. Could you give your opinion on my
implementation ?

Best Regards,

Boris

[1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html
[2]http://www.spinics.net/lists/kernel/msg1791681.html

Changes since v4:
- fix a few more bugs in rotation handling (rotation was buggy on some
  formats)
- return connector_status_unknown until a panel is exposed by the
  drm_panel infrastructure (prevent fbdev creation until everyting is
  in place)
- rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration
  (automatically select this option when selecting the HLCDC PMW or DRM
  driver, instead of depending on this option)

Changes since v3:
- rework the layer code to simplify several parts (locking and layer
  disabling)
- make use of the drm_flip_work infrastructure
- rely on default HW cursor implementation using on the cursor plane
- rework the display controller DT bindings (based on OF graph
  representation)
- add rotation support
- retrive RGB bus format from drm_display_info
- drop the dynamic pinctrl state selection
- rework HLCDC output handling (previously specialized to interface
  with LCD panels)
- drop ".module = THIS_MODULE" lines
- change display controller compatible string

Changes since v2:
- fix coding style issues (macro indentation)
- make use of GENMASK in several places
- declare regmap config as a static structure
- rework hlcdc plane update API
- rework cursor handling to make use of the new plane update API
- fix backporch config
- do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
  clk disable calls when accessing registers
- explicitely include regmap and clk headers instead of relying on
  atmel-hlcdc.h inclusions
- make the atmel-hlcdc driver depends on CONFIG_OF
- separate DT bindings documentation from driver implementation
- support several pin muxing for HLCDC pins on sama5d3 SoCs

Changes since v1:
- replace the backlight driver by a PWM driver
- make use of drm_panel infrastructure
- split driver code in several subsystem: MFD, PWM and DRM
- add support for overlays
- add support for hardware cursor

Boris BREZILLON (11):
  mfd: add atmel-hlcdc driver
  mfd: add documentation for atmel-hlcdc DT bindings
  pwm: add support for atmel-hlcdc-pwm device
  pwm: add DT bindings documentation for atmel-hlcdc-pwm driver
  drm: add Atmel HLCDC Display Controller support
  drm: add DT bindings documentation for atmel-hlcdc-dc driver
  ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode
configs
  ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins
  ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs
  ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi
  ARM: at91/dt: enable the LCD panel on sama5d3xek boards

 .../devicetree/bindings/drm/atmel-hlcdc-dc.txt |  54 ++
 .../devicetree/bindings/mfd/atmel-hlcdc.txt|  50 ++
 .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt|  55 ++
 arch/arm/boot/dts/sama5d31ek.dts   |  20 +
 arch/arm/boot/dts/sama5d33ek.dts   |  20 +
 arch/arm/boot/dts/sama5d34ek.dts   |  20 +
 arch/arm/boot/dts/sama5d36ek.dts   |  20 +
 

Using a HD 4670 still possible?

[Michel Dänzer]

On 07.09.2014 01:01, Christoph Brill wrote:
>
> I'm currently trying to get a HD 4670 aka RV730 XT to work against X.org
> 1.16, xf86-video-ati 7.4.0 on a Linux 3.16.1.
>
> Can anyone tell me: Should this card be able to handle an average Gnome
> desktop?

Of course.


> The problem was: 3D rendering did not work at all.
>
> Starting gdm lead to hanging Xorg. Calling glxgears on a twm session
> just rendered a black window, which stayed even if the process was
> killed by CTRL+C. I managed to get glxgears do do its job by setting
> "vblank_mode=0".
>
> I guessed my card does not like to play along with vsync at all. So I
> went ahead to disable vsyncing (tearing is still better than no display
> at all). Setting it globally in /etc/drirc seems to get glxgears running.
>
> Testing Xonotic on twm showed, that the card was now able to handle 3D.
> But: gdm still was extremely sluggish and eventually froze. Starting
> gnome-shell directly from startx gets me to the desktop, but any action
> freezes the process.
>
> Is there still hope for this card or should I get rid of it?

It sounds like there's a problem with interrupt processing on your 
system. Please provide the dmesg output. You might try 
disabling/enabling MSI to see if that works around the problem.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

[RFC v2] device coredump: add new device coredump class

[Johannes Berg]

On Fri, 2014-09-05 at 15:13 -0700, Greg Kroah-Hartman wrote:

> > +   /*
> > +* this seems racy, but I don't see a notifier or such on
> > +* a struct device to know when it goes away?
> > +*/
> > +   if (devcd->failing_dev->kobj.sd)
> > +   sysfs_delete_link(>failing_dev->kobj, >kobj,
> > + "dev_coredump");
> 
> What is this link?  It should "just go away" if this:
> 
> > +   put_device(devcd->failing_dev);
> 
> was the last put_device() call on the failing_dev, right?  So you
> shouldn't need to make this call to sysfs_delete_link().

I looked at this again, and it's the other way around. This is the link
that Daniel requested, from the original device to the one that's being
freed. For whatever reason though, symlinks don't automatically go away
when freed:

(with a test patch that makes "mac80211-hwsim" crash whenever we have
radar)

# echo 1 > /sys/kernel/debug/ieee80211/phy0/hwsim/dfs_simulate_radar
# ls /sys/class/devcoredump/
devcd1
# ls /sys/class/devcoredump/devcd1/
datafailing_device/ power/  subsystem/  uevent
# ls -l /sys/class/mac80211_hwsim/hwsim0/dev_coredump
lrwxrwxrwx 1 root root 0 Sep  8 08:34 
/sys/class/mac80211_hwsim/hwsim0/dev_coredump -> ../../devcoredump/devcd1
# echo > /sys/class/devcoredump/devcd1/data
# ls /sys/class/devcoredump/
# ls -l /sys/class/mac80211_hwsim/hwsim0/dev_coredump
lrwxrwxrwx 1 root root 0 Sep  8 08:34 
/sys/class/mac80211_hwsim/hwsim0/dev_coredump -> ../../devcoredump/devcd1

(but the link is now dead)

Maybe I'm creating the links in the wrong way so they don't
automatically get removed when the struct device is released?

johannes

[RFC v2] device coredump: add new device coredump class

[Arend van Spriel]

On 09/05/14 10:50, Johannes Berg wrote:
> From: Johannes Berg
>
> Many devices run firmware and/or complex hardware, and most of that
> can have bugs. When it misbehaves, however, it is often much harder
> to debug than software running on the host.
>
> Introduce a "device coredump" mechanism to allow dumping internal
> device/firmware state through a generalized mechanism. As devices
> are different and information needed can vary accordingly, this
> doesn't prescribe a file format - it just provides mechanism to
> get data to be able to capture it in a generalized way (e.g. in
> distributions.)

Although it can be found in the patch it would not hurt to point out 
where the coredump can be found in sysfs in this patch description.

[...]

> +static struct class devcd_class = {
> + .name   = "devcoredump",
> + .owner  = THIS_MODULE,
> + .dev_release= devcd_dev_release,
> + .dev_groups = devcd_dev_groups,
> +};

[...]

> +/**
> + * dev_coredumpm - create firmware coredump with read/free methods
> + * @dev: the struct device for the crashed device
> + * @data: data cookie for the @read/@free functions
> + * @datalen: length of the data
> + * @gfp: allocation flags
> + * @read: function to read from the given buffer
> + * @free: function to free the given buffer
> + */
> +void dev_coredumpm(struct device *dev, struct module *owner,
> +const void *data, size_t datalen, gfp_t gfp,
> +ssize_t (*read)(char *buffer, loff_t offset, size_t count,
> +const void *data, size_t datalen),
> +void (*free)(const void *data))
> +{
> + static atomic_t devcd_count = ATOMIC_INIT(0);
> + struct devcd_entry *devcd;
> + struct device *existing;
> +
> + existing = class_find_device(_class, NULL, dev,
> +  devcd_match_failing);
> + if (existing) {
> + put_device(existing);
> + return;
> + }
> +
> + if (!try_module_get(owner))
> + return;
> +
> + devcd = kzalloc(sizeof(*devcd), gfp);
> + if (!devcd)
> + goto put_module;
> +
> + devcd->owner = owner;
> + devcd->data = data;
> + devcd->datalen = datalen;
> + devcd->read = read;
> + devcd->free = free;
> + devcd->failing_dev = get_device(dev);
> +
> + device_initialize(>devcd_dev);
> +
> + dev_set_name(>devcd_dev, "devcd%d",
> +  atomic_inc_return(_count));
> + devcd->devcd_dev.class =_class;
> +
> + if (device_add(>devcd_dev))
> + goto put_device;
> +
> + if (sysfs_create_link(>devcd_dev.kobj,>kobj,
> +   "failing_device"))
> + /* nothing - symlink will be missing */;
> +
> + if (sysfs_create_link(>kobj,>devcd_dev.kobj,
> +   "dev_coredump"))
> + /* nothing - symlink will be missing */;

The class is called "devcoredump" so you may want to be consistent here 
and get rid of the underscore.

Regards,
Arend

[PATCH] drm/radeon: fix semaphore value init

[Christian König]

Am 07.09.2014 um 19:41 schrieb Grigori Goronzy:
> On 07.09.2014 12:06, Christian K?nig wrote:
>> From: Christian K?nig 
>>
>> Semaphore values have 64 bits, not 32. This fixes a very subtle bug
>> that disables synchronization when the upper 32bits wasn't zero.
>>
> So essentially, half the semaphore values were never properly
> initialized and some loads with a lot of semaphore synchronization going
> on tried to use the uninitialized semaphores. I think the description in
> the commit could be improved according to that.
Thinking about it that's actually not correct either.

What we did here was allocating space for four semaphores, but only 
initializing the first two because the pointer didn't had the correct size.

Needing more than two semaphores is rather unlikely anyway and even then 
we would have only messed up the syncing to UVD or VCE which wouldn't 
cause a lockup.  I don't think we ever hit this bug in practice.

> I didn't get any DMA L2T copy hangs with semaphores disabled completely,
> but unfortunately this doesn't fix the hangs.

As expected, I just found it while going over the code once more. My 
suspicion with your L2T copy problems is that we either do something 
wrong with the tilling setup on the DMA engines or that we still do 
something wrong with the VM setup, but since you don't see any VM 
related messages it's not very likely that it's a VM issue.

We should probably try to get a bit more infos from the DMA status 
registers, but I'm not sure if we have released the documentation for 
those yet.

> Anyway,
> Reviewed-By: Grigori Goronzy 

Thanks,
Christian.

>
> Grigori
>
>> Signed-off-by: Christian K?nig 
>> Cc: stable at vger.kernel.org
>> ---
>>   drivers/gpu/drm/radeon/radeon_semaphore.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_semaphore.c 
>> b/drivers/gpu/drm/radeon/radeon_semaphore.c
>> index 56d9fd6..abd6753 100644
>> --- a/drivers/gpu/drm/radeon/radeon_semaphore.c
>> +++ b/drivers/gpu/drm/radeon/radeon_semaphore.c
>> @@ -34,7 +34,7 @@
>>   int radeon_semaphore_create(struct radeon_device *rdev,
>>  struct radeon_semaphore **semaphore)
>>   {
>> -uint32_t *cpu_addr;
>> +uint64_t *cpu_addr;
>>  int i, r;
>>   
>>  *semaphore = kmalloc(sizeof(struct radeon_semaphore), GFP_KERNEL);
>>
>

[PATCH 4/9] drm/omap: make modesetting synchronous

[Rob Clark]

On Mon, Sep 8, 2014 at 9:50 AM, Daniel Vetter  wrote:
> On Mon, Sep 08, 2014 at 09:39:40AM -0400, Rob Clark wrote:
>> On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter  wrote:
>> > On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
>> >> On 03/09/14 17:25, Daniel Vetter wrote:
>> >> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> >> >> Currently modesetting is not done synchronously, but it queues work 
>> >> >> that
>> >> >> is done later. In theory this is fine, but the driver doesn't handle it
>> >> >> at properly. This means that if an application first does a full
>> >> >> modeset, then immediately afterwards starts page flipping, the page
>> >> >> flipping will not work properly as there's modeset work still in the
>> >> >> queue.
>> >> >>
>> >> >> The result with my test application was that a backbuffer was shown on
>> >> >> the screen.
>> >> >>
>> >> >> Fixing this properly would be rather big undertaking. Thus this patch
>> >> >> fixes the issue by making the modesetting synchronous, by waiting for
>> >> >> the queued work to be done at the end of omap_crtc->commit().
>> >> >>
>> >> >> The ugly part here is that the background work takes crtc->mutex, and
>> >> >> the modesetting also holds that lock, which means that the background
>> >> >> work never gets done. To get around this, we unclock, wait, and lock
>> >> >> again.
>> >> >>
>> >> >> Signed-off-by: Tomi Valkeinen 
>> >> >> ---
>> >> >>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
>> >> >>  1 file changed, 5 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> >> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> >> index 193979f97bdb..3261fbf94957 100644
>> >> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> >> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc 
>> >> >> *crtc)
>> >> >>  static void omap_crtc_commit(struct drm_crtc *crtc)
>> >> >>  {
>> >> >>struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> >> >> +  struct drm_device *dev = crtc->dev;
>> >> >>DBG("%s", omap_crtc->name);
>> >> >>omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>> >> >> +
>> >> >> +  drm_modeset_unlock_all(dev);
>> >> >
>> >> > This will run afoul of the upcoming locking rework in the atomic work. 
>> >> > And
>> >> > I'm fairly sure that the crtc helpers will fall over badly if someone
>> >> > submits a concurrent setCrtc while you've dropped the locks here.
>> >> >
>> >> > Can't you instead just drop the locking from the worker? As long as you
>> >> > synchronize like here at the right places it can't race. I expect that 
>> >> > you
>> >> > might want to synchronize in the crtc_prepare hook, too. But beyond that
>> >> > it should work.
>> >> >
>> >> > As-is nacked because future headaches for me ;-)
>> >>
>> >> Yes, it's ugly. But doing it with either queuing or caching would be a
>> >> major change. I was just trying to do smallish fixes to the driver for 
>> >> now.
>> >>
>> >> How about only unlocking/locking the crtc->mutex as Rob suggested? I
>> >> think it should work, but I didn't try it yet. Would that be as bad for
>> >> the locking rework?
>> >
>> > Same problem really, you shouldn't drop ww mutexes and reacquire them in
>> > the atomic world. ww mutexes have some debug infrastructure for that
>> > (ww_acquire_done) to catch abusers of this.
>> >
>> > So if you want to go forward with this it needs at least a big FIXME
>> > comment explaining that this is wrong. If you use locking to enforce
>> > ordering constraints that usually doesn't work well, and dropping locks to
>> > wait for async workers is plainly a locking design bug.
>>
>> well, the locking in core makes it in some ways a bit of a midlayer.. ;-)
>
> It's the locking for the drm core layer, it better be done in drm core.
> Drivers are free to use it, but if it doesn't fit they can always do their
> own. And if you look at i915 we actually have a metric pile of mutexes
> taken from modeset code and other places exactly because the drm core
> modeset locking can't work for everyone.

note that I'm not actually advocating removing/changing the locking in
core.. I was just pointing out that the way it is currently structured
can get in the way.

>> Some crtc->funcs->wait_until_flushed() sort of thing that
>> drm_mode_setcrtc() could call after dropping locks would go a long
>> ways to fix this case.  (Although post-atomic, may no longer be
>> required.)
>
> Now _this_ smells like a proper midlayer - it enforces behaviour
> sequencing by providing a bunch of callbacks for drivers to hook into.

well, I was thinking more in terms of an optional callback so that
drivers which (at least currently) need to work like omapdrm can
actually do what they need to do.

that said, I think when atomic eventually lands, it would be a good
idea to revisit how omapdrm works.. I think atomic should give a
better way for it to do what it needs to do..

In the mean time, 

[PATCH 4/9] drm/omap: make modesetting synchronous

[Rob Clark]

On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter  wrote:
> On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote:
>> On 03/09/14 17:25, Daniel Vetter wrote:
>> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:
>> >> Currently modesetting is not done synchronously, but it queues work that
>> >> is done later. In theory this is fine, but the driver doesn't handle it
>> >> at properly. This means that if an application first does a full
>> >> modeset, then immediately afterwards starts page flipping, the page
>> >> flipping will not work properly as there's modeset work still in the
>> >> queue.
>> >>
>> >> The result with my test application was that a backbuffer was shown on
>> >> the screen.
>> >>
>> >> Fixing this properly would be rather big undertaking. Thus this patch
>> >> fixes the issue by making the modesetting synchronous, by waiting for
>> >> the queued work to be done at the end of omap_crtc->commit().
>> >>
>> >> The ugly part here is that the background work takes crtc->mutex, and
>> >> the modesetting also holds that lock, which means that the background
>> >> work never gets done. To get around this, we unclock, wait, and lock
>> >> again.
>> >>
>> >> Signed-off-by: Tomi Valkeinen 
>> >> ---
>> >>  drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +
>> >>  1 file changed, 5 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> index 193979f97bdb..3261fbf94957 100644
>> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> >> @@ -277,8 +277,13 @@ static void omap_crtc_prepare(struct drm_crtc *crtc)
>> >>  static void omap_crtc_commit(struct drm_crtc *crtc)
>> >>  {
>> >>struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> >> +  struct drm_device *dev = crtc->dev;
>> >>DBG("%s", omap_crtc->name);
>> >>omap_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>> >> +
>> >> +  drm_modeset_unlock_all(dev);
>> >
>> > This will run afoul of the upcoming locking rework in the atomic work. And
>> > I'm fairly sure that the crtc helpers will fall over badly if someone
>> > submits a concurrent setCrtc while you've dropped the locks here.
>> >
>> > Can't you instead just drop the locking from the worker? As long as you
>> > synchronize like here at the right places it can't race. I expect that you
>> > might want to synchronize in the crtc_prepare hook, too. But beyond that
>> > it should work.
>> >
>> > As-is nacked because future headaches for me ;-)
>>
>> Yes, it's ugly. But doing it with either queuing or caching would be a
>> major change. I was just trying to do smallish fixes to the driver for now.
>>
>> How about only unlocking/locking the crtc->mutex as Rob suggested? I
>> think it should work, but I didn't try it yet. Would that be as bad for
>> the locking rework?
>
> Same problem really, you shouldn't drop ww mutexes and reacquire them in
> the atomic world. ww mutexes have some debug infrastructure for that
> (ww_acquire_done) to catch abusers of this.
>
> So if you want to go forward with this it needs at least a big FIXME
> comment explaining that this is wrong. If you use locking to enforce
> ordering constraints that usually doesn't work well, and dropping locks to
> wait for async workers is plainly a locking design bug.

well, the locking in core makes it in some ways a bit of a midlayer.. ;-)

Some crtc->funcs->wait_until_flushed() sort of thing that
drm_mode_setcrtc() could call after dropping locks would go a long
ways to fix this case.  (Although post-atomic, may no longer be
required.)

BR,
-R


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[no subject]

[Markus Trippelsdorf]

On 2014.09.07 at 23:47 -0400, Alex Deucher wrote:
> On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf
>  wrote:
> > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
> >> Let me know if it works for you, cause we don't really have any hardware
> >> any more to test it.
> >
> > I've tested your patch series today (using drm-next-3.18 from
> > ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
> > videos. While it sometimes works as expected, it stalled the GPU far too
> > often to be usable. The stalls are not recoverable and the machine ends
> > up with a black sreen, but still accepts SysRq keyboard inputs.
> 
> 
> Does it work any better if dpm is disabled?

Unfortunately no. The symptoms are unchanged.

-- 
Markus

[PATCH] drm: Drop modeset locking from crtc init function

[Daniel Vetter]

At driver init no one can access modeset objects and we're
single-threaded. So locking is just cargo-culting here. Worse, with
the new ww mutexes and ww mutex slowpath debugging the mutex_lock
might actually fail, and we don't have the full-blown ww recovery
dance.

Which then leads to fireworks when we try to unlock the not-locked
crtc lock.

An audit of all the functions called from here shows that none of them
contain locking checks, so there's also no reason to keep the locking
around just for consistency of caller contexts. Besides that I have
the rule (at least in i915) that such places where we take locks just
to simplify locking checks and not for correctness always require a
comment.

This regression was introduced in

commit 51fd371bbaf94018a1223b4e2cf20b9880fd92d4
Author: Rob Clark 
Date:   Tue Nov 19 12:10:12 2013 -0500

drm: convert crtc and connection_mutex to ww_mutex (v5)

v2: Don't drop the lock_init call, spotted by the 0day builder.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=83341
Cc: Rob Clark 
Cc: thellstrom at vmware.com
Cc: maarten.lankhorst at canonical.com
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e2f4b8c21440..b1271a8d8ce7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -679,11 +679,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
crtc->funcs = funcs;
crtc->invert_dimensions = false;

-   drm_modeset_lock_all(dev);
drm_modeset_lock_init(>mutex);
-   /* dropped by _unlock_all(): */
-   drm_modeset_lock(>mutex, config->acquire_ctx);
-
ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_CRTC);
if (ret)
goto out;
@@ -701,7 +697,6 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
cursor->possible_crtcs = 1 << drm_crtc_index(crtc);

  out:
-   drm_modeset_unlock_all(dev);

return ret;
 }
-- 
2.0.1

[PATCH] drm: use trylock to avoid fault injection antics

[Thomas Hellstrom]

On 09/07/2014 05:02 PM, Rob Clark wrote:
> On Fri, Sep 5, 2014 at 8:25 AM, Daniel Vetter  wrote:
>> On Fri, Sep 05, 2014 at 07:59:45AM -0400, Rob Clark wrote:
>>> While in real life, we could never fail to grab the newly created mutex,
>>> ww_mutex fault injection has no way to know this.  Which could result
>>> that kernels built with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y might fail to
>>> acquire the new crtc lock.  Which results in bad things when the locks
>>> are dropped.
>>>
>>> See: https://bugzilla.kernel.org/show_bug.cgi?id=83341
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  drivers/gpu/drm/drm_crtc.c | 10 +-
>>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index 7d7c1fd..8bb11fa 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -682,7 +682,15 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
>>> struct drm_crtc *crtc,
>>>   drm_modeset_lock_all(dev);
>>>   drm_modeset_lock_init(>mutex);
>>>   /* dropped by _unlock_all(): */
>>> - drm_modeset_lock(>mutex, config->acquire_ctx);
>>> + /* NOTE: use trylock here for the benefit of ww_mutex fault
>>> +  * injection.  We cannot actually fail to grab this lock (as
>>> +  * it has only just been created), but fault injection does
>>> +  * not know this, which can result in the this lock failing,
>>> +  * and hilarity when we later try to drop the locks.  See:
>>> +  * https://bugzilla.kernel.org/show_bug.cgi?id=83341
>>> +  */
>>> + ret = ww_mutex_trylock(>mutex.mutex);
>>> + WARN_ON(ret);
>> Hm, I've thought on our quick discussion on irc we've agreed that the
>> locking here in the init path is useless anyway and best dropped? Not just
>> remove the crtc locking, but the entire modeset_lock_all.
> well, 0day appears to disagree with you..   I still think we should go
> the trylock route for 3.17, as it is more the more conservative patch.
>
> I'm not against getting rid of that locking (which is in fact
> overkill) once the other fallout is fixed up.  But that seems more
> like a merge-window thing, so probably best to wait for 3.18.
>
> BR,
> -R
>

FWIW,
Reviewed-by: Thomas Hellstrom 



>> -Daniel
>>
>>>   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_CRTC);
>>>   if (ret)
>>> --
>>> 1.9.3
>>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Unlock crtc mutex acquired in drm_modeset_lock_crtc()

[Daniel Vetter]

On Mon, Sep 8, 2014 at 7:27 AM, Michael N. Henry  
wrote:
> crtc->mutex is acquired in drm_modeset_lock_crtc(). The next call
> to drm_modeset_unlock_crt() would not unlock it, causing a deadlock
> during the next call to drm_modest_lock_crtc().
> ---
>  drivers/gpu/drm/drm_modeset_lock.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 474e4d1..fab3aa8 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -236,6 +236,8 @@ void drm_modeset_unlock_crtc(struct drm_crtc *crtc)
> drm_modeset_drop_locks(ctx);
> drm_modeset_acquire_fini(ctx);
>
> +   drm_modeset_unlock(>mutex);
> +

drm_mode_drop_locks should drop all mutexes (and so also the crtc
mutex acquired with ctx. Also acquire_fini should complain if you
unlock afterwards.

I suspect that some other caller completely forgets to unlock the crtc
somehow, but I can't see where that happens. Can you please re-run
with CONFIG_PROVE_LOCKING enabled in your kernel build?

And a small nitpick on your patch submission: When you submit just one
patch, please don't do a cover letter - all the information you
provide in there (backtrace, bisect result) should be part of the
commit message anyway. And your patch is missing the signed-off-by
line, so can't be merged. And please also don't forget to cc relevant
mailing lists.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/vmwgfx: Fix drm.h include

[Josh Boyer]

On Mon, Sep 8, 2014 at 8:01 AM, Emil Velikov  
wrote:
> Hi Josh
>
> On 05/09/14 18:19, Josh Boyer wrote:
>> The userspace drm.h include doesn't prefix the drm directory.  This can lead
>> to compile failures as /usr/include/drm/ isn't in the standard gcc include
>> paths.  Fix it to be , which matches the rest of the driver drm
>> header files that get installed into /usr/include/drm.
>>
> Is this an actual issue or a hypothetical one ? Afaict no-one is using the
> kernel drm headers, but instead the ones from libdrm are in place.
> linux-headers does not even ship /usr/include/drm on my Archlinux box.

It's shipped in kernel-headers in Fedora and I'm guessing someone hit
it at one point, but I don't know what the actual initial problem was.

> Additionally most (all?) vmwgfx components (mesa, ddx) use a local version of
> the header, which albeit not ideal should not cause issues.
>
> Or perhaps I'm missing something ?
>
>
> To the VMware guys,
>
> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>
> Cheers,
> Emil
>
> P.S. I'm against the patch in any way :)

Was that meant to say "I'm not against the patch in any way" ?

josh

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #87 from Michel D?nzer  ---
(In reply to comment #86)
> https://bugs.freedesktop.org/show_bug.cgi?id=83500

I think in the meantime Grigori has seen GPU hangs even with that patch though,
with 2D tiling.

However, can you avoid the problem if you start Chromium with the environment
variable R600_DEBUG=nodma?

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

[Bug 83531] radeon 6650m cannot boot without radeon.runpm=0

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output.

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

[Bug 83556] Problem with resolution using adapter dvi to dsub

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

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

Alex Deucher  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/Gallium/radeonsi|DRM/Radeon

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.  Does the adapter work on other
cards or OSes?  Some cheap adapters don't properly connect the ddc pins.

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

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #40 from Matt  ---
Okay. Thanks.

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

[Bug 83262] Radeon DPM re-clocking fails after resume from suspend

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

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

Alex Deucher  changed:

   What|Removed |Added

   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Driver/Radeon   |DRM/Radeon

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output and your xorg log.

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

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #39 from Alex Deucher  ---
You can check the stable branches here:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
Note that some stable trees are closed so they will not be getting any more
updates.

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

[Bug 83461] hdmi screen flicker/unusable

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Does booting with radeon.audio=0 on the kernel command line in grub fix the
issue?  You can also disable audio on the fly xrandr.  E.g.,

xrandr --output HDMI-0 --set audio off

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

[Bug 83453] dpm not working in Gigabyte RADEON HD 7870 (bios F11)

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 73338 ***

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

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #30 from Alex Deucher  ---
*** Bug 83453 has been marked as a duplicate of this bug. ***

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

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output and xorg log.

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

[Bug 83861] radeon power management cause audio skips and glitch

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output and xorg log.

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

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #241 from Alex Deucher  ---
(In reply to comment #239)
> echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
> 
> echo performance > /sys/class/drm/card0/device/power_dpm_state


This is effectively the same as disabling dpm.

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

[PATCH 01/20] drm/radeon: move drm_buffer to drm/radeon/

[Alex Deucher]

On Fri, Aug 29, 2014 at 6:12 AM, David Herrmann  
wrote:
> Radeon UMS is the last user of drm_buffer. Move it out of sight so radeon
> can drop it together with UMS.
>
> Signed-off-by: David Herrmann 


Reviewed-by: Alex Deucher 

We can probably dump radeon UMS support as well at this point.

Alex

> ---
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_buffer.c  | 181 
> --
>  drivers/gpu/drm/radeon/Makefile   |   2 +-
>  drivers/gpu/drm/radeon/drm_buffer.c   | 177 +
>  drivers/gpu/drm/radeon/drm_buffer.h   | 148 +++
>  drivers/gpu/drm/radeon/r300_cmdbuf.c  |   2 +-
>  drivers/gpu/drm/radeon/radeon_state.c |   2 +-
>  include/drm/drm_buffer.h  | 148 ---
>  8 files changed, 329 insertions(+), 333 deletions(-)
>  delete mode 100644 drivers/gpu/drm/drm_buffer.c
>  create mode 100644 drivers/gpu/drm/radeon/drm_buffer.c
>  create mode 100644 drivers/gpu/drm/radeon/drm_buffer.h
>  delete mode 100644 include/drm/drm_buffer.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 4a55d59..9b7cb3f 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -4,7 +4,7 @@
>
>  ccflags-y := -Iinclude/drm
>
> -drm-y   := drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \
> +drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
> drm_context.o drm_dma.o \
> drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
> drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> diff --git a/drivers/gpu/drm/drm_buffer.c b/drivers/gpu/drm/drm_buffer.c
> deleted file mode 100644
> index 86a4a4a..000
> --- a/drivers/gpu/drm/drm_buffer.c
> +++ /dev/null
> @@ -1,181 +0,0 @@
> -/**
> - *
> - * Copyright 2010 Pauli Nieminen.
> - * All Rights Reserved.
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the
> - * "Software"), to deal in the Software without restriction, including
> - * without limitation the rights to use, copy, modify, merge, publish,
> - * distribute, sub license, and/or sell copies of the Software, and to
> - * permit persons to whom the Software is furnished to do so, subject to
> - * the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the
> - * next paragraph) shall be included in all copies or substantial portions
> - * of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> - * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY 
> CLAIM,
> - * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> - * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> - * USE OR OTHER DEALINGS IN THE SOFTWARE.
> - *
> - *
> - **/
> -/*
> - * Multipart buffer for coping data which is larger than the page size.
> - *
> - * Authors:
> - * Pauli Nieminen 
> - */
> -
> -#include 
> -#include 
> -
> -/**
> - * Allocate the drm buffer object.
> - *
> - *   buf: Pointer to a pointer where the object is stored.
> - *   size: The number of bytes to allocate.
> - */
> -int drm_buffer_alloc(struct drm_buffer **buf, int size)
> -{
> -   int nr_pages = size / PAGE_SIZE + 1;
> -   int idx;
> -
> -   /* Allocating pointer table to end of structure makes drm_buffer
> -* variable sized */
> -   *buf = kzalloc(sizeof(struct drm_buffer) + nr_pages*sizeof(char *),
> -   GFP_KERNEL);
> -
> -   if (*buf == NULL) {
> -   DRM_ERROR("Failed to allocate drm buffer object to hold"
> -   " %d bytes in %d pages.\n",
> -   size, nr_pages);
> -   return -ENOMEM;
> -   }
> -
> -   (*buf)->size = size;
> -
> -   for (idx = 0; idx < nr_pages; ++idx) {
> -
> -   (*buf)->data[idx] =
> -   kmalloc(min(PAGE_SIZE, size - idx * PAGE_SIZE),
> -   GFP_KERNEL);
> -
> -
> -   if ((*buf)->data[idx] == NULL) {
> -   DRM_ERROR("Failed to allocate %dth page for drm"
> -   " buffer with %d bytes and %d 
> pages.\n",
> -   idx + 1, size, nr_pages);
> -   goto error_out;
> -   }
> -
> -   }
> -
> -   return 0;
> -
> -error_out:
> -
> -   for (; idx >= 0; --idx)
> -   kfree((*buf)->data[idx]);
> -
> -   kfree(*buf);
> -   return -ENOMEM;
> -}
> 

[no subject]

[Alex Deucher]

On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf
 wrote:
> On 2014.08.25 at 11:10 +0200, Christian K?nig wrote:
>> Let me know if it works for you, cause we don't really have any hardware
>> any more to test it.
>
> I've tested your patch series today (using drm-next-3.18 from
> ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264
> videos. While it sometimes works as expected, it stalled the GPU far too
> often to be usable. The stalls are not recoverable and the machine ends
> up with a black sreen, but still accepts SysRq keyboard inputs.


Does it work any better if dpm is disabled?

Alex

>
> Here are some logs:
>
> vdpauinfo:
> display: :0   screen: 0
> API version: 1
> Information string: G3DVL VDPAU Driver Shared Library version 1.0
>
> Video surface:
>
> name   width height types
> ---
> 420 8192  8192  NV12 YV12
> 422 8192  8192  UYVY YUYV
> 444 8192  8192  Y8U8V8A8 V8U8Y8A8
>
> Decoder capabilities:
>
> name   level macbs width height
> ---
> MPEG1 0  9216  2048  1152
> MPEG2_SIMPLE  3  9216  2048  1152
> MPEG2_MAIN3  9216  2048  1152
> H264_BASELINE41  9216  2048  1152
> H264_MAIN41  9216  2048  1152
> H264_HIGH41  9216  2048  1152
> VC1_ADVANCED  4  9216  2048  1152
>
> Output surface:
>
> name  width height nat types
> 
> B8G8R8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> R8G8B8A8  8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> R10G10B10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
> B10G10R10A2   8192  8192y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8
>
> Bitmap surface:
>
> name  width height
> --
> B8G8R8A8  8192  8192
> R8G8B8A8  8192  8192
> R10G10B10A2   8192  8192
> B10G10R10A2   8192  8192
> A88192  8192
>
> Video mixer:
>
> feature namesup
> 
> DEINTERLACE_TEMPORAL y
> DEINTERLACE_TEMPORAL_SPATIAL -
> INVERSE_TELECINE -
> NOISE_REDUCTION  y
> SHARPNESSy
> LUMA_KEY -
> HIGH QUALITY SCALING - L1-
> HIGH QUALITY SCALING - L2-
> HIGH QUALITY SCALING - L3-
> HIGH QUALITY SCALING - L4-
> HIGH QUALITY SCALING - L5-
> HIGH QUALITY SCALING - L6-
> HIGH QUALITY SCALING - L7-
> HIGH QUALITY SCALING - L8-
> HIGH QUALITY SCALING - L9-
>
> parameter name  sup  min  max
> -
> VIDEO_SURFACE_WIDTH  y48 2048
> VIDEO_SURFACE_HEIGHT y48 1152
> CHROMA_TYPE  y
> LAYERS   y 04
>
> attribute name  sup  min  max
> -
> BACKGROUND_COLOR y
> CSC_MATRIX   y
> NOISE_REDUCTION_LEVELy  0.00 1.00
> SHARPNESS_LEVEL  y -1.00 1.00
> LUMA_KEY_MIN_LUMAy
> LUMA_KEY_MAX_LUMAy
>
>
> Sep  7 14:03:45 x4 kernel: [drm] Initialized drm 1.1.0 20060810
> Sep  7 14:03:45 x4 kernel: [drm] radeon kernel modesetting enabled.
> Sep  7 14:03:45 x4 kernel: [drm] initializing kernel modesetting (RS780 
> 0x1002:0x9614 0x1043:0x834D).
> Sep  7 14:03:45 x4 kernel: [drm] register mmio base: 0xFBEE
> Sep  7 14:03:45 x4 kernel: [drm] register mmio size: 65536
> Sep  7 14:03:45 x4 kernel: ATOM BIOS: 113
> Sep  7 14:03:45 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 
> - 0xC7FF (128M used)
> Sep  7 14:03:45 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 
> - 0xBFFF
> Sep  7 14:03:45 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
> Sep  7 14:03:45 x4 kernel: [drm] RAM width 32bits DDR
> Sep  7 14:03:45 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
> 4083350 kiB
> Sep  7 14:03:45 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
> 2097152 kiB
> Sep  7 14:03:45 x4 kernel: [TTM] Initializing pool allocator
> Sep  7 14:03:45 x4 kernel: [TTM] Initializing DMA pool allocator
> Sep  7 14:03:45 x4 kernel: [drm] radeon: 128M of VRAM memory ready
> Sep  7 14:03:45 x4 kernel: [drm] radeon: 512M of GTT memory ready.
> Sep  7 14:03:45 x4 kernel: [drm] Loading RS780 Microcode
> Sep  7 14:03:45 x4 kernel: == power state 0 ==
> Sep  7 14:03:45 x4 kernel:  ui class: none
> Sep  7 14:03:45 x4 kernel:  internal class: boot
> Sep  7 14:03:45 x4 kernel:  caps: video
> Sep  7 14:03:45 x4 kernel:  uvdvclk: 0 dclk: 0
> Sep  7 14:03:45 x4 kernel:  power level 0sclk: 

[Bug 79862] Driver crash while playing YouTube video (flash)

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

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

--- Comment #15 from nucrap at hotmail.com ---
Ok, I think the Heading is not really correct anymore. I'm on Linux 3.16.1 now
and still get this misbehaviour even without watching yt videos (maybe because
of some KDE effects).

It is extremely annoying and I basically cannot use Linux productively. In fact
I am not even sure if this is a software issue. I also got some Problems on
Windows with this card even though this is already my second one (from RMA).

And I am not the only one having issues. In fact, everybody using OC versions
of the R7 260x has severe issues. It's a shame. The first company so far
solving it was ASUS: They updated the firmware and it appears they just reduced
the GPU clock and voltages.
Also see
http://vip.asus.com/forum/view.aspx?id=20140427164821450_id=9=R7260X-DC2OC-2GD5=1=en-us
Sapphire also updated their firmware. MSI appears to don't care.


I don't know if this is related, but considering the poor state even on
Windows, one never knows...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: