[Bug 60802] Corruption with DMA ring on cayman

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #76590|0   |1
is obsolete||

--- Comment #63 from Alex Deucher  ---
Created attachment 76592
  --> https://bugs.freedesktop.org/attachment.cgi?id=76592=edit
take 5

After further investigation this seems to be an alignment issue with large
block sizes on the DMA engine on cayman.  For now just use the blitter for
large block sizes.

-- 
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/20130315/a98b3a75/attachment-0001.html>

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Chris Wilson]

On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote:
> On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> > That's what I thought too. Looking at the stack trace, the empirical
> > evidence is that we need the check.
> > -Chris
> 
> I think we need to investigate the issue more then, or put a BUG_ON() in
> the drm code and run it through trinity. We have other places where arg
> can't/shouldn't be NULL and we don't check.

Actually we are both wrong. drm_ioctl() does not validate that the
user struct matches the expected size, just ensures that if that user
cmd specifies that the arg is to be used that it only up to the known
size is copied.

A hostile userspace can bludgen a NULL pointer through drm_ioctl() into
the driver->ioctl->func().

If we used driver->ioctl->cmd instead of the user supplied cmd, we would
have a whole other can of worms to deal with (as we suddenly get a
struct of zeroes). However, those worms should already be treated as
invalid. Choose your poison.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 6192] System hard locks when attempting to run HQ Dragothic (3D Mark 2001SE) demo in Wine

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

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

--- Comment #2 from Neil Skrypuch  ---
Seven years later... I can't really test this now, I don't have an X server on
that machine anymore.

-- 
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/20130315/46eeefa9/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #62 from Alex Deucher  ---
The way to properly handle T2L or L2T conversions of compressed textures with
the DMA engine is to hack up the formats like we do in the blitter code so that
it looks like a PIPE_FORMAT_R16G16B16A16_UINT or PIPE_FORMAT_R32G32B32A32_UINT
T2L or L2T blit.

-- 
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/20130315/4f3b940b/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #61 from Alex Deucher  ---
(In reply to comment #59)
> Alex, a couple of things changed in your last attachment. You removed the
> L2T part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed
> the binary offset for 28 (instead of 27). Am I right to understand you set
> "non_disp" back to 1 because your are offsetting one more bit (according to
> your comment in v2)?

The non_disp field is two bits on cayman and one bit evergreen.  Bit 28 in this
packet represents bit 0 of the non_disp field and bit 27 represents bit 1 of
the non_disp field so that it's compatible with evergreen.  So just setting bit
28 covers us for both evergreen and cayman since we only care about non_dip bit
0.

-- 
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/20130315/56abefcd/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #76563|0   |1
is obsolete||

--- Comment #60 from Alex Deucher  ---
Created attachment 76590
  --> https://bugs.freedesktop.org/attachment.cgi?id=76590=edit
use blitter for compressed textures

This patch fixes the issue here.

-- 
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/20130315/cf3f05a7/attachment.html>

[pull] radeon drm-fixes-3.9

[alexdeuc...@gmail.com]

From: Alex Deucher 

Hi Dave,

   Mostly just small bug fixes.  Big change is new pci ids
for Richland APUs.

The following changes since commit 8698080ee092bdbd6ee2cd5e7f707ceea2812bd8:

  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-03-11 
13:53:58 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.9

Alex Deucher (6):
  drm/radeon: fix S/R on VM systems (cayman/TN/SI)
  drm/radeon: fix backend map setup on 1 RB trinity boards
  drm/radeon/benchmark: make sure bo blit copy exists before using it
  drm/radeon/benchmark: allow same domains for dma copy
  drm/radeon: add support for Richland APUs
  drm/radeon: add Richland pci ids

 drivers/gpu/drm/radeon/ni.c   |   33 +++-
 drivers/gpu/drm/radeon/radeon_benchmark.c |   21 -
 drivers/gpu/drm/radeon/si.c   |1 +
 include/drm/drm_pciids.h  |   13 ++-
 4 files changed, 50 insertions(+), 18 deletions(-)

[Bug 8634] [r128] Driver does not support GLX_SGI_make_current_read

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

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

Ian Romanick  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Ian Romanick  ---
The r128 driver was removed from Mesa years ago.

-- 
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/20130315/1e02f92e/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #59 from Alexandre Demers  ---
Alex, a couple of things changed in your last attachment. You removed the L2T
part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed the
binary offset for 28 (instead of 27). Am I right to understand you set
"non_disp" back to 1 because your are offsetting one more bit (according to
your comment in v2)?

If that's right, I don't see how v3 is different from v2 except for the L2T
change. And since non_disp=1 is not set at all in the main branch, how would
that fix the corruption problem. Aren't we back to v0 for the L2T path (which
is broken) and to v2 for the T2L path (which is also not better)?

-- 
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/20130315/5813526e/attachment-0001.html>

[Bug 7111] racer: [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock

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

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

--- Comment #15 from mrsteven at gmx.de ---
Though I am not pmhere, I want to inform you that for me this problem has been
gone for a long while now. Don't know exactly with which software versions.
Sorry for not posting earlier.

-- 
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/20130315/231d7207/attachment.html>

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Greg KH wrote:

> > > > > I have the same problem on my Lenovo T500. I think the graphics card 
> > > > > is
> > > > > involved.
> > > > > 
> > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 
> > > > > 16:
> > > > > nobody cared" during boot, not when I boot with the ATI card.
> > > > 
> > > > Confirming this. After a lot of hassle, I have bisected this reliably to
> > > > 
> > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
> > > > Author: Daniel Vetter 
> > > > Date:   Sat Dec 1 13:53:45 2012 +0100
> > > > 
> > > > drm/i915: use the gmbus irq for waits
> > > > 
> > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out 
> > > > what's 
> > > > happening in parallel.
> > > 
> > > Wasn't this fixed by the merge from David
> > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?
> > 
> > Why do you think it should, please?
> 
> The line:
>   - Fix PCH irq handling race which resulted in missed gmbus/dp
> aux irqs and subsequent fallout (Paulo)

Ah, that one. I believe that should be irrelevant for GM chipsets, as they 
don't have AUX line, right?

> > (I am seeing this with a2362d247 still).
> 
> Ok, I guess it isn't still fixed properly, just was guessing :)

Seems like this is a different issue.

Thanks,

-- 
Jiri Kosina
SUSE Labs

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Sergei Shtylyov]

Hello.

On 14-03-2013 18:35, Laurent Pinchart wrote:

> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> and DU1 LVDS outputs will require information about the panels that will
> be connected to those outputs.

> Signed-off-by: Laurent Pinchart 
[...]

> diff --git a/arch/arm/mach-shmobile/board-marzen.c 
> b/arch/arm/mach-shmobile/board-marzen.c
> index cdcb799..0020506 100644
> --- a/arch/arm/mach-shmobile/board-marzen.c
> +++ b/arch/arm/mach-shmobile/board-marzen.c
[...]
> @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
>   .num_resources  = ARRAY_SIZE(hspi_resources),
>   };
>
> +/* DU */
> +static struct resource rcar_du_resources[] = {
> + [0] = {
> + .name   = "Display Unit",
> + .start  = 0xfff8,
> + .end= 0xfffb1007,
> + .flags  = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start  = gic_spi(31),

Forgot to add: we're supoosed to use the new gic_iid() macro instead.

WBR, Sergei

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Sergei Shtylyov]

Hello.

On 15-03-2013 5:36, Laurent Pinchart wrote:

> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> and DU1 LVDS outputs will require information about the panels that will
> be connected to those outputs.

> Signed-off-by: Laurent Pinchart
> 
> ---

> arch/arm/configs/marzen_defconfig |  2 ++
> arch/arm/mach-shmobile/board-marzen.c | 65
> +
> 2 files changed, 67 insertions(+)

> diff --git a/arch/arm/mach-shmobile/board-marzen.c
> b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
> --- a/arch/arm/mach-shmobile/board-marzen.c
> +++ b/arch/arm/mach-shmobile/board-marzen.c

 [...]

> @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
>   .num_resources  = ARRAY_SIZE(hspi_resources),
> };
>
> +/* DU */
> +static struct resource rcar_du_resources[] = {
> + [0] = {
> + .name   = "Display Unit",
> + .start  = 0xfff8,
> + .end= 0xfffb1007,
> + .flags  = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start  = gic_spi(31),
> + .flags  = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct rcar_du_platform_data rcar_du_pdata = {
> + .encoders = {
> + [0] = {
> + .encoder = RCAR_DU_ENCODER_VGA,
> + },
> + },
> +};
> +
> +static struct platform_device rcar_du_device = {
> + .name   = "rcar-du",
> + .num_resources  = ARRAY_SIZE(rcar_du_resources),
> + .resource   = rcar_du_resources,
> + .dev= {
> + .platform_data = _du_pdata,
> + .coherent_dma_mask = ~0,
> + },
> +};
> +

 Are we seeing again SoC device declared in the board file? That simply
 doesn't scale...

>>> The goal is obviously to move all that to DT, but there's no DT bindings
>>> for the DU DRM driver yet.

>> I don't see how it justifies dubious non-DT design. Let me tell/remind you
>> about the LTSI-3.4 tree where all this stuff can be backported and which
>> doesn't have DT support, AFAIR.

> This patch is an example only, I should have marked it as such. If I need to
> push something similar to mainline I will keep your comment in mind and see
> how I can move the platform device to setup-r8a7779.c. Platform data, however,
> need to be provided on a per-board basis.

Yes, it's the usual case of their usage.
Thanks for heeding to my comment.

WBR, Sergei

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Ben Widawsky]

On Fri, Mar 15, 2013 at 10:06:19PM +, Chris Wilson wrote:
> On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote:
> > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> > > That's what I thought too. Looking at the stack trace, the empirical
> > > evidence is that we need the check.
> > > -Chris
> > 
> > I think we need to investigate the issue more then, or put a BUG_ON() in
> > the drm code and run it through trinity. We have other places where arg
> > can't/shouldn't be NULL and we don't check.
> 
> Actually we are both wrong. drm_ioctl() does not validate that the
> user struct matches the expected size, just ensures that if that user
> cmd specifies that the arg is to be used that it only up to the known
> size is copied.
> 
> A hostile userspace can bludgen a NULL pointer through drm_ioctl() into
> the driver->ioctl->func().

> > > +   if (args == NULL)
> > > +   return -EINVAL;
> > > +

I must be failing to see the obvious, but I'm still not getting how args
can ever be NULL. kdata which is passed to us as "data" and cast to
"args' is either always some stack variable, or some kmalloc'd memory. I
see how the arguments themselves can be crap which is really only when
user size != drv_size.

So tell me, which case can result in a NULL arg?
1. user size == drv_size // better not be this one
2. user size < driver size
3. user size > driver size

It seems to me we still must [simply] be missing something in our
parameter validation.

> 
> If we used driver->ioctl->cmd instead of the user supplied cmd, we would
> have a whole other can of worms to deal with (as we suddenly get a
> struct of zeroes). However, those worms should already be treated as
> invalid. Choose your poison.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre


-- 
Ben Widawsky, Intel Open Source Technology Center

nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).

[Martin Peres]

Hi everyone,

As a follow up, Konrad sent me in private his vbios and the issue turned 
out to be trivial.
The reason why it behaved this way was that his vbios didn't have sensor 
calibration values.
The fix is available here: 
http://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commit/59b4006b5b30828bbd094dffe3937333b43d1e12

This fix is part of a pull request I sent to Ben.

Thanks again Konrad for reporting and testing the patches, I'll add you 
as a tester to this patch :)

Cheers,
Mupuf

PS: For the records, here is a fwd of our private conversation.

 Message original 
Sujet:  Re: nouveau shuts the machine down with v3.9-rc1 (temperature 
(72 C) hit the 'shutdown' threshold).
Date :  Fri, 15 Mar 2013 11:16:17 -0400
De :Konrad Rzeszutek Wilk 
Pour :  Martin Peres 


On Fri, Mar 15, 2013 at 02:30:44AM +0100, Martin Peres wrote:
> On 13/03/2013 03:20, Konrad Rzeszutek Wilk wrote:
> >>Ah ah, what challenge? The reason why the temperature is messed up
> >>is ... trivial.
> >>
> >>Will send a patch for that!
> >Heh. Pls CC me so I can test it and add the Tested-by flag:
> >>Thanks for reporting the bug!
> >Of course.
> >>Martin
> Hey Konrad,
>
> Here are the thermal patches I sent to Ben Skeggs for review. The
> patch that should solve your problem is the patch 6.
>
> Let me know if it solves your issue (that I managed to reproduce by
> faking a different vbios).
>

> dmesg | grep nou
[   12.177930] calling  nouveau_drm_init+0x0/0x1000 [nouveau] @ 1488
[   12.330206] nouveau :00:0d.0: setting latency timer to 64
[   12.353307] nouveau  [  DEVICE][:00:0d.0] BOOT0  : 0x04c000a2
[   12.359398] nouveau  [  DEVICE][:00:0d.0] Chipset: C61 (NV4C)
[   12.365477] nouveau  [  DEVICE][:00:0d.0] Family : NV40
[   12.371621] nouveau  [   VBIOS][:00:0d.0] checking PRAMIN for image...
[   12.416327] nouveau  [   VBIOS][:00:0d.0] ... appears to be valid
[   12.422758] nouveau  [   VBIOS][:00:0d.0] using image from PRAMIN
[   12.429324] nouveau  [   VBIOS][:00:0d.0] BIT signature found
[   12.429326] nouveau  [   VBIOS][:00:0d.0] version 05.61.32.22.01
[   12.443160] nouveau  [ PFB][:00:0d.0] RAM type: unknown
[   12.443161] nouveau  [ PFB][:00:0d.0] RAM size: 128 MiB
[   12.443162] nouveau  [ PFB][:00:0d.0]ZCOMP: 0 tags
[   12.50] nouveau  [  PTHERM][:00:0d.0] FAN control: none / external
[   12.514647] nouveau  [  PTHERM][:00:0d.0] fan management: disabled
[   12.521161] nouveau  [  PTHERM][:00:0d.0] internal sensor: no
[   12.547272] nouveau  [  PTHERM][:00:0d.0] programmed thresholds [ 90(2), 
95(3), 145(2), 135(5) ]
[   12.573758] nouveau  [ DRM] VRAM: 125 MiB
[   12.579153] nouveau  [ DRM] GART: 512 MiB
[   12.584887] nouveau  [ DRM] TMDS table version 1.1
[   12.590018] nouveau  [ DRM] DCB version 3.0
[   12.594555] nouveau  [ DRM] DCB outp 00: 01000310 0023
[   12.601754] nouveau  [ DRM] DCB outp 01: 00110204 97e5
[   12.607585] nouveau  [ DRM] DCB conn 00: 
[   12.612424] nouveau  [ DRM] Saving VGA fonts
[   12.656034] nouveau W[ DRM] DCB type 4 not known
[   12.660991] nouveau W[ DRM] Unknown-1 has no encoders, removing
[   12.681157] nouveau  [ DRM] 1 available performance level(s)
[   12.687714] nouveau  [ DRM] 0: core 425MHz shader 425MHz fanspeed 100%
[   12.694575] nouveau  [ DRM] c:
[   12.699270] nouveau  [ DRM] MM: using M2MF for buffer copies
[   12.738742] nouveau :00:0d.0: No connectors reported connected with modes
[   12.752063] nouveau  [ DRM] allocated 1024x768 fb: 0x9000, bo 
88012dffbc00
[   12.763397] fbcon: nouveaufb (fb0) is primary device
[   12.780410] nouveau :00:0d.0: fb0: nouveaufb frame buffer device
[   12.786754] nouveau :00:0d.0: registered panic notifier
[   12.792330] [drm] Initialized nouveau 1.1.0 20120801 for :00:0d.0 on 
minor 0
[   12.800071] initcall nouveau_drm_init+0x0/0x1000 [nouveau] returned 0 after 
602409 usecs


and no poweroffs :-)

So definitly Tested-by: Konrad Rzeszutek Wilk 
all of the patches.

Thanks!
> Cheers,
> Martin

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130315/e5c9a2e6/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #58 from Anthony Waters  ---
That didn't work either, the L2T path is the one that keeps getting executed. 
In my case dst_mode is RADEON_SURF_MODE_2D or RADEON_SURF_MODE_1D and src_mode
is RADEON_SURF_MODE_LINEAR_ALIGNED.

I'll see if I can get some more specifics about 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/20130315/22b36440/attachment.html>

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Greg KH wrote:

> > > I have the same problem on my Lenovo T500. I think the graphics card is
> > > involved.
> > > 
> > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > > nobody cared" during boot, not when I boot with the ATI card.
> > 
> > Confirming this. After a lot of hassle, I have bisected this reliably to
> > 
> > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
> > Author: Daniel Vetter 
> > Date:   Sat Dec 1 13:53:45 2012 +0100
> > 
> > drm/i915: use the gmbus irq for waits
> > 
> > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
> > happening in parallel.
> 
> Wasn't this fixed by the merge from David
> (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?

Why do you think it should, please?

(I am seeing this with a2362d247 still).

-- 
Jiri Kosina
SUSE Labs

[PATCH] nouveau: nv10_fence.c: avoid sparse warning

[Laurent Navet]

fix this warning :
sparse: symbol 'nv10_fence_context_new' was not declared. Should it be static?

Signed-off-by: Laurent Navet 
---
 drivers/gpu/drm/nouveau/nouveau_fence.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h 
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index c899434..61ee43a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -64,6 +64,7 @@ int  nv17_fence_sync(struct nouveau_fence *, struct 
nouveau_channel *,
 struct nouveau_channel *);
 u32  nv10_fence_read(struct nouveau_channel *);
 void nv10_fence_context_del(struct nouveau_channel *);
+int  nv10_fence_context_new(struct nouveau_channel *);
 void nv10_fence_destroy(struct nouveau_drm *);
 int  nv10_fence_create(struct nouveau_drm *);

-- 
1.7.10.4

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Jiri Kosina wrote:

> > I have the same problem on my Lenovo T500. I think the graphics card is
> > involved.
> > 
> > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > nobody cared" during boot, not when I boot with the ATI card.
> 
> Confirming this. After a lot of hassle, I have bisected this reliably to
> 
>   commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
>   Author: Daniel Vetter 
>   Date:   Sat Dec 1 13:53:45 2012 +0100
> 
>   drm/i915: use the gmbus irq for waits
> 
> Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
> happening in parallel.
> 
> Attaching dmesg.txt from the machine with 28c70f162a as head, with 
> drm.debug=0xe.

Just a datapoint -- I have put a trivial debugging patch in place, and it 
reveals that "nobody cared" for irq 16 happens long after last

I915_WRITE(GMBUS4 + reg_offset, 0);

has been performed in gmbus_wait_hw_status(). On the other hand, if I 
comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), 
then it of course falls back to GPIO bit-banging, but the "nobody cared" 
for irq 16 is gone. 

So it seems like something gets severely confused by the I915_WRITE to 
GMBUS4 + reg_offset. So far this seems to have been reported solely on 
Lenovos as far as I can see (although a completely different types), so it 
might be some platform-specific quirk?

Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 
16 at all. 

-- 
Jiri Kosina
SUSE Labs

compat-drivers based on v3.8.3

[Luis R. Rodriguez]

Greg has blessed Linux v3.8.3 so we get to backport drivers for this
release for usage on older kernels through compat-drivers, you can
either visit the v3.8.3 release page [0] or the temporary release page
[1]. This release has been test compiled against vanilla Linux kernel
releases v2.6.24 - v3.7. Below I provide the ChangeLog for this
release for the changes made to compat and compat-drivers, for the
full ChangeLog that includes Linux kernel changes you can refer to the
upstream full ChangeLog [2].

We have 5 type of releases based on v3.8.3, there is a vanilla release
and then 4 releases which incorporate additional patches from sources
on their way to get upstream to the Linux kernel. The additional
releases are designed to ensure we prioritize Linux upstream
development but at the same time allow OEMs / users / mothers to get
releases with additional patches vendors deem important for
functionality, we simply categorize where those patches are on their
way upstream to the Linux kernel. For more information on this see the
additional-patches documentation on the backports wiki [3].

Thanks to everyone who has contributed to this release!

[0] https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/
[1] http://drvbp1.linux-foundation.org/~mcgrof/rel-html/compat-drivers/
[2] 
https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.8.3/ChangeLog-3.8.3-2
[3] 
https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches


ChangeLog for compat-drivers-v3.8.3-2 based on linux-3.8.3


This is the ChangeLog for the Linux kernel project compat-drivers.
It provides a backport of a few Linux kernel subsystems down to
older kernels:

  * 802.11
  * Bluetooth
  * Ethernet
  * DRM

For more details refer to the home pages:

https://backports.wiki.kernel.org

The compat-drivers project consists of code from three projects:

  * The Linux kernel: linux-stable.git
  * Compat-wirelesS: compat-drivers.git
  * Compat: compat.git

The compat-drivers stable releases incorporates code from from
each of these git trees for the respective upstream Linux kernel
stable release. A branch called linux-3.x.y exists for each
stable release. Below we provide the ChangeLog of changes from
the previous branched release to the new branched release.

Release: linux-3.8


Updates from the compat.git project:


git shortlog linux-3.7.y..linux-3.8.y

Felix Fietkau (1):
  compat: fix compile errors when assembly is built into modules

Hauke Mehrtens (21):
  compat: update list of kernel headers
  compat: add USB_SUBCLASS_VENDOR_SPEC
  compat: make compat load without CONFIG_CPU_FREQ
  compat: add eth_zero_addr()
  compat: add kref_get_unless_zero()
  compat: move config_enabled to compat-3.4.h
  compat: fix compiler warning in nla_get_s64()
  compat: export platform_device_register_data()
  compat: fix warning of missing struct netdev_queue
  compat: add missing return value to netif_set_real_num_tx_queues
  compat: add simple_write_to_buffer
  compat: add ETHTOOL_FWVERS_LEN
  compat: fix warning in usb_autopm_get_interface_no_{resume,suspend}
  compat: do not access default_ethtool_ops
  compat: ckmake: make return code 2 is error
  compat: ckmake: remove lots of warning spam for the log
  compat: ckmake: do not start all build at the same time
  compat: add efi_enabled()
  compat: netdev_set_default_ethtool_ops() is not in kernel 3.7.5
  compat: check if efi_enabled() was already backported
  compat: deactivate netdev_set_default_ethtool_ops() for some 3.7 kernels

Johannes Berg (1):
  compat: backport unsigned netlink attribute accessors

Luis R. Rodriguez (42):
  compat: fix libc dependency on bin/get-compat-kernels
  compat: fix typo in bin/get-compat-kernels
  compat: run ckmake with num cpu threads
  compat: fix get-compat-kernels for libc issue again
  compat: change count to 4 for glibc kernel fix
  compat: add gpio header for kernels older than 2.6.24
  compat: backport ethtool_rxfh_indir_default()
  compat: backport ethtool to mii advertisment conversion helpers
  compat: backport BQL helpers
  compat: define NETIF_F_RXCSUM
  compat: fix addition of NETIF_F_RXCSUM
  compat: backport PCI MSI-X entry definitions
  compat: backport alloc_etherdev_mqs()
  compat: backport definition of PCI_MSIX_ENTRY_CTRL_MASKBIT
  compat: backport PTR_RET()
  compat: backport netif_set_real_num_tx_queues()
  compat: backport netif_set_real_num_rx_queues()
  compat: rename MDIO exported symbols
  compat: backplane mode negotiation ethtool definitions
  compat: backport napi_gro_receive()
  compat: generate CONFIG_COMPAT_KERNEL_3_8
  compat: backport 

[Bug 60802] Corruption with DMA ring on cayman

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #76557|0   |1
is obsolete||

--- Comment #57 from Alex Deucher  ---
Created attachment 76563
  --> https://bugs.freedesktop.org/attachment.cgi?id=76563=edit
take 3

Only set the non_disp bit for tiled to linear copies.

-- 
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/20130315/4b8a31d4/attachment.html>

[PATCHv7 10/10] drm: tegra: Add gr2d device

[Terje Bergström]

On 15.03.2013 14:13, Thierry Reding wrote:
> On Wed, Mar 13, 2013 at 02:36:26PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
> [...]
>> +static inline struct host1x_drm_context *tegra_drm_get_context(
>> + struct list_head *contexts,
>> + struct host1x_drm_context *_ctx)
>> +{
>> + struct host1x_drm_context *ctx;
>> +
>> + list_for_each_entry(ctx, contexts, list)
>> + if (ctx == _ctx)
>> + return ctx;
>> + return NULL;
>> +}
> 
> Maybe make this a little more high-level, such as:
> 
> static bool host1x_drm_file_owns_context(struct host1x_drm_file *file,
>  struct host1x_drm_context *context)
> 
> ?

We only need the true/false value, so changing signature makes sense.

> 
>> +static int tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
>> + struct drm_file *file_priv)
>> +{
>> + struct tegra_drm_open_channel_args *args = data;
>> + struct host1x_client *client;
>> + struct host1x_drm_context *context;
>> + struct host1x_drm_file *fpriv = file_priv->driver_priv;
>> + struct host1x_drm *host1x = drm->dev_private;
>> + int err = -ENODEV;
>> +
>> + context = kzalloc(sizeof(*context), GFP_KERNEL);
>> + if (!context)
>> + return -ENOMEM;
>> +
>> + list_for_each_entry(client, >clients, list)
>> + if (client->class == args->class) {
>> + context->client = client;
> 
> Why do you assign this here? Should it perhaps be assigned only when the
> opening of the channel succeeds? The .open_channel() already receives a
> pointer to the client as parameter, so it doesn't have to be associated
> with the context.

True, we can move the assignment to happen after checking the
open_channel result.

> 
>> +static int tegra_drm_ioctl_get_syncpoint(struct drm_device *drm, void *data,
>> +  struct drm_file *file_priv)
>> +{
>> + struct tegra_drm_get_syncpoint *args = data;
>> + struct host1x_drm_file *fpriv = file_priv->driver_priv;
>> + struct host1x_drm_context *context =
>> + (struct host1x_drm_context *)(uintptr_t)args->context;
>> +
>> + if (!tegra_drm_get_context(>contexts, context))
>> + return -ENODEV;
>> +
>> + if (context->client->num_syncpts < args->param)
>> + return -ENODEV;
> 
> I think this might be easier to read as:
> 
> if (args->param >= context->client->num_syncpts)
> return -ENODEV;

Ok, will do.

> 
>> + args->value = host1x_syncpt_id(context->client->syncpts[args->param]);
> 
> This could use a temporary variable "syncpt" to make it easier to read.

Ok.

> 
>> +static int tegra_drm_gem_create_ioctl(struct drm_device *drm, void *data,
>> +   struct drm_file *file_priv)
> 
> tegra_drm_ioctl_gem_create()?

Sure.

> 
>> +{
>> + struct tegra_drm_create *args = data;
>> + struct drm_gem_cma_object *cma_obj;
>> + struct tegra_drm_bo *cma_bo;
> 
> These can probably just be named "cma"/"gem" and "bo" instead.

Ok.

> 
>> +static int tegra_drm_ioctl_get_offset(struct drm_device *drm, void *data,
>> +   struct drm_file *file_priv)
> 
> I think this might be more generically named tegra_drm_ioctl_mmap()
> which might come in handy if we ever need to do something more than just
> retrieve the offset.

Yeah, that changes the API semantics a bit, but in general there
shouldn't be a need to just get the offset without doing the actual mmap.

> 
>> +{
>> + struct tegra_drm_get_offset *args = data;
>> + struct drm_gem_cma_object *cma_obj;
>> + struct drm_gem_object *obj;
>> +
>> + obj = drm_gem_object_lookup(drm, file_priv, args->handle);
>> + if (!obj)
>> + return -EINVAL;
>> + cma_obj = to_drm_gem_cma_obj(obj);
> 
> The above two lines should be separated by a blank line.

Ok.

> 
>> +
>> + args->offset = cma_obj->base.map_list.hash.key << PAGE_SHIFT;
> 
> Perhaps a better way would be to export the get_gem_mmap_offset() from
> drivers/gpu/drm/drm_gem_cma_helper.c and reuse that.

Ok, we'll add that as a patch to the series.

> 
>>  static struct drm_ioctl_desc tegra_drm_ioctls[] = {
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_GEM_CREATE,
>> + tegra_drm_gem_create_ioctl, DRM_UNLOCKED | DRM_AUTH),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_READ,
>> + tegra_drm_ioctl_syncpt_read, DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_INCR,
>> + tegra_drm_ioctl_syncpt_incr, DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_WAIT,
>> + tegra_drm_ioctl_syncpt_wait, DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_OPEN_CHANNEL,
>> + 

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Jiri Kosina wrote:

> Attaching dmesg.txt from the machine with 28c70f162a as head, with 
> drm.debug=0xe.

OK, now actually attaching it, sorry.

-- 
Jiri Kosina
SUSE Labs
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.txt
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130315/20554fc4/attachment-0001.txt>

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Harald Arnesen wrote:

> I have the same problem on my Lenovo T500. I think the graphics card is
> involved.
> 
> This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> nobody cared" during boot, not when I boot with the ATI card.

Confirming this. After a lot of hassle, I have bisected this reliably to

commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
Author: Daniel Vetter 
Date:   Sat Dec 1 13:53:45 2012 +0100

drm/i915: use the gmbus irq for waits

Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
happening in parallel.

Attaching dmesg.txt from the machine with 28c70f162a as head, with 
drm.debug=0xe.

-- 
Jiri Kosina
SUSE Labs

[Bug 9576] Screen corruption at 24-bit color depth on radeon

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

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

--- Comment #7 from chemtech  ---
David Brigada
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/01826be5/attachment.html>

[Bug 9457] Restricting drm open file descriptors (AIGLX deadlock)

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

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

--- Comment #4 from chemtech  ---
Thomas Hellstr?m 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/491e0f1e/attachment.html>

[Bug 9348] Hard Lockup with Ati X600 X.Org >7.1.1 caused by libdri.so

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

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

--- Comment #3 from chemtech  ---
Oliver Pahl 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/6756afed/attachment.html>

[Bug 9851] Bad via entries in pci ids list both for kernel tree and drm tree.

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

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

--- Comment #1 from chemtech  ---
Xavier Bachelot 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/80c76f4d/attachment.html>

[Bug 9506] r300 crash on Misfit Model 3D

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

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

--- Comment #15 from chemtech  ---
Jacek Poplawski 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/8986a951/attachment.html>

[Bug 5999] problems with r300 and metacity compositing manager

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

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

--- Comment #13 from chemtech  ---
Diego 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/2b7b3d37/attachment.html>

[Bug 9301] FreeBSD system locks up with DRI enabled on Radeon RS300

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

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

--- Comment #15 from chemtech  ---
Yong-Jhen Hong 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/c13ebc7e/attachment.html>

[Bug 8896] X error when using off-screen rendering with DRI enabled

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

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

--- Comment #1 from chemtech  ---
cbeau
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/954267e6/attachment.html>

[Bug 7111] racer: [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock

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

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

--- Comment #14 from chemtech  ---
pmhere 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/17f13842/attachment-0001.html>

[Bug 3380] Dynamically generate GL dispatch functions for PowerPC

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

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

--- Comment #8 from chemtech  ---
Ian Romanick 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/7b25d1ba/attachment.html>

[Bug 8258] drm_handle_t isn't 64bit safe

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

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

--- Comment #3 from chemtech  ---
Andres Salomon 
Do you still experience this issue with newer soft ?
Please check the status of your 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/20130315/989405f8/attachment.html>

[Bug 7971] radeon driver unable to claim hw lock from abusive dri clients

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

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

--- Comment #2 from chemtech  ---
Aapo Tahkola 
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/e3a70992/attachment.html>

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Laurent Pinchart]

Hi Sergei,

On Friday 15 March 2013 16:55:58 Sergei Shtylyov wrote:
> On 14-03-2013 18:35, Laurent Pinchart wrote:
> > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> > and DU1 LVDS outputs will require information about the panels that will
> > be connected to those outputs.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> [...]
> 
> > diff --git a/arch/arm/mach-shmobile/board-marzen.c
> > b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
> > --- a/arch/arm/mach-shmobile/board-marzen.c
> > +++ b/arch/arm/mach-shmobile/board-marzen.c
> 
> [...]
> 
> > @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
> > .num_resources  = ARRAY_SIZE(hspi_resources),
> >   };
> > 
> > +/* DU */
> > +static struct resource rcar_du_resources[] = {
> > +   [0] = {
> > +   .name   = "Display Unit",
> > +   .start  = 0xfff8,
> > +   .end= 0xfffb1007,
> > +   .flags  = IORESOURCE_MEM,
> > +   },
> > +   [1] = {
> > +   .start  = gic_spi(31),
> 
> Forgot to add: we're supoosed to use the new gic_iid() macro instead.

Thanks for pointing this out. I've based this patch on mainline where 
gic_iid() isn't available yet. I'll make sure to rebase on Simon's tree before 
sending a pull request.

-- 
Regards,

Laurent Pinchart

[Bug 6249] VIA ME600 + XvMC + mplayer hang

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

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

--- Comment #2 from chemtech  ---
Dan Smolik 
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/0771be54/attachment.html>

[Bug 6192] System hard locks when attempting to run HQ Dragothic (3D Mark 2001SE) demo in Wine

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

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

--- Comment #1 from chemtech  ---
Neil Skrypuch 
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/f6be95a4/attachment.html>

[Bug 6090] Texture bitmap not displaying correctly in games similar to tuxracer for r200 based cards.

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

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

--- Comment #2 from chemtech  ---
Brian Beardall 
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/4c7ed08c/attachment.html>

[Bug 5569] savage: glxgears only shows monochrome flicker

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

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

--- Comment #6 from chemtech  ---
Steffen Schwientek 
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/119e0a6f/attachment-0001.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #56 from Anthony Waters  ---
take 2 didn't work for me, I also tried (non_disp << 28) to (non_disp << 30)
and those didn't fix it either.

-- 
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/20130315/38dc12ce/attachment.html>

[Bug 5531] DRI enabled freezes X when running any opengl app

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

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

--- Comment #1 from chemtech  ---
Juan Luis Baptiste 
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/3865cb27/attachment.html>

[Bug 5477] sis_dri hangs server, causes certain apps (glxcontexts) to segfault

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

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

--- Comment #1 from chemtech  ---
ugenn 
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/ce8ec095/attachment.html>

[Bug 3267] Rendering errors running foobillard on Radeon 7500

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

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

--- Comment #9 from chemtech  ---
Grzegorz Nimoski
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/a55b5f20/attachment.html>

[Bug 3832] Can't use R128 and Mach64 simultaniously.

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

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

--- Comment #2 from chemtech  ---
Alan Grimes
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/93d44bc3/attachment.html>

[Bug 733] kernel total freeze switching X->fb (matrox)

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

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

--- Comment #8 from chemtech  ---
Alessandro Lepore,
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/82451265/attachment.html>

[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22

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

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

--- Comment #20 from Miroslav ?ustek  ---
(In reply to comment #19)
> Miroslav ?ustek,
> Do you still experience this issue with newer drivers ?
> Please check the status of your issue.

I'm sorry, I no longer have the HW to test 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/20130315/73d90a81/attachment.html>

[PATCHv7 10/10] drm: tegra: Add gr2d device

[Thierry Reding]

int gr2d_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct host1x_drm *host1x = host1x_get_drm_data(dev->parent);
> + int err;
> + struct gr2d *gr2d = NULL;
> + struct host1x_syncpt **syncpts;

I don't think there's a need for this temporary variable. You could just
use gr2d->client.syncpts directly.

> + gr2d = devm_kzalloc(dev, sizeof(*gr2d), GFP_KERNEL);
> + if (!gr2d)
> + return -ENOMEM;
> +
> + syncpts = devm_kzalloc(dev, sizeof(*syncpts), GFP_KERNEL);
> + if (!syncpts)
> + return -ENOMEM;
> +
> + gr2d->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(gr2d->clk)) {
> + dev_err(dev, "cannot get clock\n");
> + return PTR_ERR(gr2d->clk);
> + }
> +
> + err = clk_prepare_enable(gr2d->clk);
> + if (err) {
> + dev_err(dev, "cannot turn on clock\n");
> + return err;
> + }
> +
> + gr2d->channel = host1x_channel_alloc(dev);
> + if (!gr2d->channel)
> + return -ENOMEM;
> +
> + *syncpts = host1x_syncpt_request(dev, 0);
> + if (!(*syncpts)) {
> + host1x_channel_free(gr2d->channel);
> + return -ENOMEM;
> + }
> +
> + gr2d->client.ops = _client_ops;
> + gr2d->client.dev = dev;
> + gr2d->client.class = HOST1X_CLASS_GR2D;
> + gr2d->client.syncpts = syncpts;
> + gr2d->client.num_syncpts = 1;
> +
> + err = host1x_register_client(host1x, >client);
> + if (err < 0) {
> + dev_err(dev, "failed to register host1x client: %d\n", err);
> + return err;
> + }
> +
> + gr2d_init_addr_reg_map(dev, gr2d);
> +
> + dev_set_drvdata(dev, gr2d);

Nit: I think it'd be nicer to use platform_set_drvdata() here to mirror
the platform_get_drvdata() from gr2d_remove().

> diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
[...]
> +struct tegra_drm_create {

struct tegra_drm_gem_create?

> + __u64 size;
> + u32 flags;
> + u32 handle;
> + u32 offset;
> + u32 padding;

Also since we have a separate IOCTL for this, I think you can leave out
the offset field (and also padding since it isn't required anymore).

> +struct tegra_drm_get_offset {
> + __u32 handle;
> + __u32 offset;
> +};

struct tegra_drm_gem_mmap to go along with the name change of the IOCTL.

> +struct tegra_drm_syncpt_incr_args {
> + __u32 id;
> + __u32 pad;
> +};

Shouldn't this second field be something like "value" to allow this
IOCTL to increment by more than 1?

> +#define DRM_TEGRA_NO_TIMEOUT (0x)

No need for the parentheses.

> +struct tegra_drm_reloc {
> + __u32 cmdbuf_mem;
> + __u32 cmdbuf_offset;
> + __u32 target;
> + __u32 target_offset;
> + __u32 shift;
> + __u32 pad;
> +};

I've found this to be a little inconsistent. Why does the cmdbuf_mem
have the _mem suffix, but not the target field? Given that this will
eventually be used by userspace software once merged it will be fixed
forever. I had noticed the same for the in-kernel structures but didn't
think it important enough to hold up the patches. In this case I think
we should make them consistent, though.

> +#define DRM_TEGRA_DRM_GEM_CREATE 0x00
> +#define DRM_TEGRA_DRM_SYNCPT_READ0x01
> +#define DRM_TEGRA_DRM_SYNCPT_INCR0x02
> +#define DRM_TEGRA_DRM_SYNCPT_WAIT0x03
> +#define DRM_TEGRA_DRM_OPEN_CHANNEL   0x04
> +#define DRM_TEGRA_DRM_CLOSE_CHANNEL  0x05
> +#define DRM_TEGRA_DRM_GET_SYNCPOINT  0x06
> +#define DRM_TEGRA_DRM_SUBMIT 0x08
> +#define DRM_TEGRA_DRM_GEM_GET_OFFSET 0x09
> +
> +#define DRM_IOCTL_TEGRA_DRM_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_GEM_CREATE, struct tegra_drm_create)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_READ DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_SYNCPT_READ, struct tegra_drm_syncpt_read_args)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_INCR DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_SYNCPT_INCR, struct tegra_drm_syncpt_incr_args)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_WAIT DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_SYNCPT_WAIT, struct tegra_drm_syncpt_wait_args)
> +#define DRM_IOCTL_TEGRA_DRM_OPEN_CHANNEL DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_OPEN_CHANNEL, struct tegra_drm_open_channel_args)
> +#define DRM_IOCTL_TEGRA_DRM_CLOSE_CHANNEL DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_CLOSE_CHANNEL, struct tegra_drm_open_channel_args)
> +#define DRM_IOCTL_TEGRA_DRM_GET_SYNCPOINT DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_GET_SYNCPOINT, struct tegra_drm_get_syncpoint)
> +#define DRM_IOCTL_TEGRA_DRM_SUBMIT DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_SUBMIT, struct tegra_drm_submit_args)
> +#define DRM_IOCTL_TEGRA_DRM_GEM_GET_OFFSET DRM_IOWR(DRM_COMMAND_BASE + 
> DRM_TEGRA_DRM_GEM_GET_OFFSET, struct tegra_drm_get_offset)

Same comment regarding reordering and GET_OFFSET -> MMAP rename.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130315/aea2033f/attachment.pgp>

[Bug 60802] Corruption with DMA ring on cayman

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #76544|0   |1
is obsolete||

--- Comment #55 from Alex Deucher  ---
Created attachment 76557
  --> https://bugs.freedesktop.org/attachment.cgi?id=76557=edit
take 2

Try this patch.  The bits of the non_disp field are inverted for compatibility
with 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/20130315/b63f4612/attachment.html>

[Bug 37112] GPU lockup when trying to use profile based frequency switching

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

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


Hrvoje Senjan  changed:

   What|Removed |Added

 Kernel Version|2.35-2.6.39 |2.35-3.9-rc2
   Severity|normal  |high




--- Comment #12 from Hrvoje Senjan   2013-03-15 
12:33:54 ---
Would really appreciate for some further info, the situation is the same with
low and mid methods, it tries to change the memory clock too low.
Thanks

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Intel-gfx] [PATCH v3] drm/i915: bounds check execbuffer relocation count

[Damien Lespiau]

On Thu, Mar 14, 2013 at 12:32:00PM -0700, Kees Cook wrote:
> On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter  
> wrote:
> > On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter  wrote:
> >> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
> >>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
> >>> > It is possible to wrap the counter used to allocate the buffer for
> >>> > relocation copies. This could lead to heap writing overflows.
> >>> >
> >>> > CVE-2013-0913
> >>> >
> >>> > v3: collapse test, improve comment
> >>> > v2: move check into validate_exec_list
> >>> >
> >>> > Signed-off-by: Kees Cook 
> >>> > Reported-by: Pinkie Pie
> >>> > Cc: stable at vger.kernel.org
> >>>
> >>> Looks good to me. The only bikeshed that remains is whether we should
> >>> just collapse the two variables into one, but the current 'max - count'
> >>> is more idiomatic and so preferrable.
> >>> Reviewed-by: Chris Wilson 
> >>
> >> Picked up for -fixes, thanks for the patch.
> >
> > I've forgotten to dump my wishlist: Can I have an i-g-t for this? For
> > this bug here specifically an execbuf with just one buffer with too
> > many relocs plus another execbuf with two buffers with relocation so
> > that the 2nd relocation list will overflow should be sufficient.
> 
> Sure thing. Where do these live? (Or what docs should I read for
> this?) I'm assuming i-g-t means "intel graphics test"? :)

Close :) GPU Tools. The tests lives in the tests directory of:
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

-- 
Damien

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina  wrote:

> Just a datapoint -- I have put a trivial debugging patch in place, and it
> reveals that "nobody cared" for irq 16 happens long after last
>
> I915_WRITE(GMBUS4 + reg_offset, 0);
>
> has been performed in gmbus_wait_hw_status(). On the other hand, if I
> comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
> then it of course falls back to GPIO bit-banging, but the "nobody cared"
> for irq 16 is gone.
>
> So it seems like something gets severely confused by the I915_WRITE to
> GMBUS4 + reg_offset. So far this seems to have been reported solely on
> Lenovos as far as I can see (although a completely different types), so it
> might be some platform-specific quirk?
>
> Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
> 16 at all.

that device is using
i915 :00:02.0: irq 44 for MSI/MSI-X

so can you try to boot with pci=nomsi?

[PATCH 1/2] drm/radeon: add support for Richland APUs

[Jerome Glisse]

On Fri, Mar 15, 2013 at 9:50 AM,   wrote:
> From: Alex Deucher 
>
> Richland APUs are a new version of the Trinity APUs
> with performance and power management improvements.
>
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

For the serie:
Reviewed-by: Jerome Glisse 

> ---
>  drivers/gpu/drm/radeon/ni.c |   11 ++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index a7d3de7..27769e7 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -468,13 +468,19 @@ static void cayman_gpu_init(struct radeon_device *rdev)
> (rdev->pdev->device == 0x9907) ||
> (rdev->pdev->device == 0x9908) ||
> (rdev->pdev->device == 0x9909) ||
> +   (rdev->pdev->device == 0x990B) ||
> +   (rdev->pdev->device == 0x990C) ||
> +   (rdev->pdev->device == 0x990F) ||
> (rdev->pdev->device == 0x9910) ||
> -   (rdev->pdev->device == 0x9917)) {
> +   (rdev->pdev->device == 0x9917) ||
> +   (rdev->pdev->device == 0x)) {
> rdev->config.cayman.max_simds_per_se = 6;
> rdev->config.cayman.max_backends_per_se = 2;
> } else if ((rdev->pdev->device == 0x9903) ||
>(rdev->pdev->device == 0x9904) ||
>(rdev->pdev->device == 0x990A) ||
> +  (rdev->pdev->device == 0x990D) ||
> +  (rdev->pdev->device == 0x990E) ||
>(rdev->pdev->device == 0x9913) ||
>(rdev->pdev->device == 0x9918)) {
> rdev->config.cayman.max_simds_per_se = 4;
> @@ -483,6 +489,9 @@ static void cayman_gpu_init(struct radeon_device *rdev)
>(rdev->pdev->device == 0x9990) ||
>(rdev->pdev->device == 0x9991) ||
>(rdev->pdev->device == 0x9994) ||
> +  (rdev->pdev->device == 0x9995) ||
> +  (rdev->pdev->device == 0x9996) ||
> +  (rdev->pdev->device == 0x999A) ||
>(rdev->pdev->device == 0x99A0)) {
> rdev->config.cayman.max_simds_per_se = 3;
> rdev->config.cayman.max_backends_per_se = 1;
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 21284] [KMS] Radeon rv280 black screen with modeset=1

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

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

Andrew Randrianasulu  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Randrianasulu  ---
Sorry, I  completely  forgot  about  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/20130315/56dbb55c/attachment.html>

[PATCH 2/2] drm/radeon: add Richland pci ids

[alexdeuc...@gmail.com]

From: Alex Deucher 

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 include/drm/drm_pciids.h |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index a386b0b..918e8fe 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -581,7 +581,11 @@
{0x1002, 0x9908, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9909, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x990A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
-   {0x1002, 0x990F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x990B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x990C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x990D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x990E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x990F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9910, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9913, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9917, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
@@ -592,6 +596,13 @@
{0x1002, 0x9992, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9993, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9994, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9995, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9996, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9997, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x9998, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x999A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+   {0x1002, 0x999B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x99A0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x99A2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x99A4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
-- 
1.7.7.5

[PATCH 1/2] drm/radeon: add support for Richland APUs

[alexdeuc...@gmail.com]

From: Alex Deucher 

Richland APUs are a new version of the Trinity APUs
with performance and power management improvements.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/ni.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index a7d3de7..27769e7 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -468,13 +468,19 @@ static void cayman_gpu_init(struct radeon_device *rdev)
(rdev->pdev->device == 0x9907) ||
(rdev->pdev->device == 0x9908) ||
(rdev->pdev->device == 0x9909) ||
+   (rdev->pdev->device == 0x990B) ||
+   (rdev->pdev->device == 0x990C) ||
+   (rdev->pdev->device == 0x990F) ||
(rdev->pdev->device == 0x9910) ||
-   (rdev->pdev->device == 0x9917)) {
+   (rdev->pdev->device == 0x9917) ||
+   (rdev->pdev->device == 0x)) {
rdev->config.cayman.max_simds_per_se = 6;
rdev->config.cayman.max_backends_per_se = 2;
} else if ((rdev->pdev->device == 0x9903) ||
   (rdev->pdev->device == 0x9904) ||
   (rdev->pdev->device == 0x990A) ||
+  (rdev->pdev->device == 0x990D) ||
+  (rdev->pdev->device == 0x990E) ||
   (rdev->pdev->device == 0x9913) ||
   (rdev->pdev->device == 0x9918)) {
rdev->config.cayman.max_simds_per_se = 4;
@@ -483,6 +489,9 @@ static void cayman_gpu_init(struct radeon_device *rdev)
   (rdev->pdev->device == 0x9990) ||
   (rdev->pdev->device == 0x9991) ||
   (rdev->pdev->device == 0x9994) ||
+  (rdev->pdev->device == 0x9995) ||
+  (rdev->pdev->device == 0x9996) ||
+  (rdev->pdev->device == 0x999A) ||
   (rdev->pdev->device == 0x99A0)) {
rdev->config.cayman.max_simds_per_se = 3;
rdev->config.cayman.max_backends_per_se = 1;
-- 
1.7.7.5

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Ben Widawsky]

On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> > On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> > > In order to prevent a potential NULL deference with hostile userspace,
> > > we need to check whether the ioctl was passed an invalid args pointer.
> > > 
> > > Reported-by: Tommi Rantala 
> > > Link: 
> > > http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow
> > >  at mail.gmail.com
> > > Signed-off-by: Chris Wilson 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 +--
> > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > index 365e41a..9f5602e 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void 
> > > *data,
> > >   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > >   int ret, i;
> > >  
> > > - if (args->buffer_count < 1) {
> > > + if (args == NULL)
> > > + return -EINVAL;
> > > +
> > > + if (args->buffer_count < 1 ||
> > > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > >   DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
> > >   return -EINVAL;
> > >   }
> > > @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void 
> > > *data,
> > >   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > >   int ret;
> > >  
> > > + if (args == NULL)
> > > + return -EINVAL;
> > > +
> > >   if (args->buffer_count < 1 ||
> > > - args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> > > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > >   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
> > >   return -EINVAL;
> > >   }
> > 
> > Why did you change UINT_MAX to INT_MAX?
> 
> Because we check later against INT_MAX, and I didn't like the confusion.
> If we are going to pick an arbitrary limit, lets at least be consistent.
> 
> > TBH, I'm confused what we're
> > trying to achieve, and why we need anything other than:
> > if (!args->buffer_count)
> 
> Because we then promptly do a u32 multiply and we need to be sure that
> userspace can't trigger an overflow there and cause us to read
> unallocated memory later.
> > 
> > I'm also not seeing how the NULL checks are needed since at least it
> > seems to be for execbuffer (IOW) we could never have NULL args.
> 
> That's what I thought too. Looking at the stack trace, the empirical
> evidence is that we need the check.
> -Chris

I think we need to investigate the issue more then, or put a BUG_ON() in
the drm code and run it through trinity. We have other places where arg
can't/shouldn't be NULL and we don't check.

-- 
Ben Widawsky, Intel Open Source Technology Center

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Greg KH]

On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Greg KH wrote:
> 
> > > > I have the same problem on my Lenovo T500. I think the graphics card is
> > > > involved.
> > > > 
> > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > > > nobody cared" during boot, not when I boot with the ATI card.
> > > 
> > > Confirming this. After a lot of hassle, I have bisected this reliably to
> > > 
> > >   commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
> > >   Author: Daniel Vetter 
> > >   Date:   Sat Dec 1 13:53:45 2012 +0100
> > > 
> > >   drm/i915: use the gmbus irq for waits
> > > 
> > > Adding Daniel, Imre and Daniel to CC while I will try to figure out 
> > > what's 
> > > happening in parallel.
> > 
> > Wasn't this fixed by the merge from David
> > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?
> 
> Why do you think it should, please?

The line:
- Fix PCH irq handling race which resulted in missed gmbus/dp
  aux irqs and subsequent fallout (Paulo)

> (I am seeing this with a2362d247 still).

Ok, I guess it isn't still fixed properly, just was guessing :)

greg k-h

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Greg KH]

On Fri, Mar 15, 2013 at 02:33:13PM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Harald Arnesen wrote:
> 
> > I have the same problem on my Lenovo T500. I think the graphics card is
> > involved.
> > 
> > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > nobody cared" during boot, not when I boot with the ATI card.
> 
> Confirming this. After a lot of hassle, I have bisected this reliably to
> 
>   commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
>   Author: Daniel Vetter 
>   Date:   Sat Dec 1 13:53:45 2012 +0100
> 
>   drm/i915: use the gmbus irq for waits
> 
> Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
> happening in parallel.

Wasn't this fixed by the merge from David
(2cc79544bd0aabb4b3cf467ead5df526d9134c64)?  I can't figure out the
exact commit that the merge message referred to though...

greg k-h

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Chris Wilson]

On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> > In order to prevent a potential NULL deference with hostile userspace,
> > we need to check whether the ioctl was passed an invalid args pointer.
> > 
> > Reported-by: Tommi Rantala 
> > Link: 
> > http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow
> >  at mail.gmail.com
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 365e41a..9f5602e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void 
> > *data,
> > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > int ret, i;
> >  
> > -   if (args->buffer_count < 1) {
> > +   if (args == NULL)
> > +   return -EINVAL;
> > +
> > +   if (args->buffer_count < 1 ||
> > +   args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
> > return -EINVAL;
> > }
> > @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void 
> > *data,
> > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > int ret;
> >  
> > +   if (args == NULL)
> > +   return -EINVAL;
> > +
> > if (args->buffer_count < 1 ||
> > -   args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> > +   args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
> > return -EINVAL;
> > }
> 
> Why did you change UINT_MAX to INT_MAX?

Because we check later against INT_MAX, and I didn't like the confusion.
If we are going to pick an arbitrary limit, lets at least be consistent.

> TBH, I'm confused what we're
> trying to achieve, and why we need anything other than:
> if (!args->buffer_count)

Because we then promptly do a u32 multiply and we need to be sure that
userspace can't trigger an overflow there and cause us to read
unallocated memory later.
> 
> I'm also not seeing how the NULL checks are needed since at least it
> seems to be for execbuffer (IOW) we could never have NULL args.

That's what I thought too. Looking at the stack trace, the empirical
evidence is that we need the check.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 6409] XvMC on Intel i810

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

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

--- Comment #2 from chemtech  ---
Jos? JORGE,
Do you still experience this issue with newer soft?
Please check the status of your 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/20130315/f256dff9/attachment-0001.html>

[Bug 7445] AMD64+Radeon display corruption

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

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

--- Comment #15 from chemtech  ---
Frank Kingswood,
Do you still experience this issue with newer soft?
Please check the status of your 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/20130315/5b7a2176/attachment.html>

[Bug 7034] via_cmdbuf_wait timed out hw

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

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

--- Comment #1 from chemtech  ---
Alexander Skwar,
Do you still experience this issue with newer soft?
Please check the status of your 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/20130315/a1940142/attachment.html>

[Bug 704] Should MACCESS be validated?

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

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

--- Comment #1 from chemtech  ---
ajax at nwnk dot net,
Do you still experience this issue with newer soft?
Please check the status of your 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/20130315/a37f61c2/attachment.html>

[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22

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

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

--- Comment #19 from chemtech  ---
Miroslav ?ustek,
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/bf9d498d/attachment.html>

[Bug 8634] [r128] Driver does not support GLX_SGI_make_current_read

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

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

--- Comment #3 from chemtech  ---
Ian Romanick,
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/d51cdcaf/attachment.html>

[Bug 3493] r128: Entire X-windowing system hangs during normal 3D gaming

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

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

--- Comment #17 from chemtech  ---
Alan Grimes,
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/3ab8727e/attachment.html>

[Bug 20537] piglit failures on ATI Mobility M6

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

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

--- Comment #9 from chemtech  ---
jsado_sc3 at comcast.net,
Do you still experience this issue with newer drivers ?
Please check the status of your 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/20130315/720752a1/attachment.html>

[Bug 21284] [KMS] Radeon rv280 black screen with modeset=1

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

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

--- Comment #5 from chemtech  ---
Andrew Randrianasulu,
Please attach full dmesg and output of lspci -vv
Please check the status of your 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/20130315/8dd69b6f/attachment.html>

[Bug 21122] If DRI is enabled ,System will freeze after X quit

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

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

--- Comment #8 from chemtech  ---
TeF,
Please attach full dmesg.
Please check the status of your 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/20130315/a1797241/attachment-0001.html>

[Bug 20751] 2D acceleration on R6xx freezes my computer

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

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

--- Comment #3 from chemtech  ---
Nicolas Bareil,
Please attach full dmesg and output of lspci -vv
Please check the status of your 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/20130315/5ae4af06/attachment.html>

[Bug 20129] Large texture object obscuring display with radeon driver in dxx-rebirth

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

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

--- Comment #14 from chemtech  ---
jsado_sc3 at comcast.net,
Please attach full dmesg and output of lspci -vv
Please check the status of your 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/20130315/e2b8ad41/attachment.html>

[Bug 20211] Runing Kubrick game maximized freezes X and causes kernel panic

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

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

--- Comment #2 from chemtech  ---
Jure Repinc,
Please attach full dmesg and output of lspci -vv
Please check the status of your 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/20130315/105f5eae/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #54 from Alexandre Demers  ---
(In reply to comment #51)
> Created attachment 76544 [details] [review]
> set non_disp tiling bit for cayman
> 
> Good catch!  I believe the attached patch should fix the issue.

Since this bug is pretty much the same as previous one I had identified in
comment 29 (pointing to bug 38173) and since the proposed patch is also pretty
similar to 1 of the 2 patches needed to fix that identified bug, is it possible
there is something missing that would look like the second patch that was
needed?

patch 1 from bug 38173 (similar to the one proposed with your attachment
76544):
http://cgit.freedesktop.org/mesa/mesa/commit/?id=5e1495b2d9311fa2b320766a1d299053904bd9c3
patch 2 from bug 38173 (possibly similar to what is missing to complete your
proposed patch):
http://cgit.freedesktop.org/mesa/mesa/commit/?id=acca690c259824636ef1ff684a10bd1caca4751f

In other words, are we sure we are offsetting the non_disp variable correctly
for Cayman? Because according to the second patch, the offset was different.

-- 
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/20130315/1e77d102/attachment.html>

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Laurent Pinchart]

On Friday 15 March 2013 02:11:05 Sergei Shtylyov wrote:
> On 15.03.2013 0:11, Laurent Pinchart wrote:
> >>> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> >>> and DU1 LVDS outputs will require information about the panels that will
> >>> be connected to those outputs.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> ---
> >>> 
> >>>arch/arm/configs/marzen_defconfig |  2 ++
> >>>arch/arm/mach-shmobile/board-marzen.c | 65
> >>>+
> >>>2 files changed, 67 insertions(+)
> >>> 
> >>> diff --git a/arch/arm/mach-shmobile/board-marzen.c
> >>> b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
> >>> --- a/arch/arm/mach-shmobile/board-marzen.c
> >>> +++ b/arch/arm/mach-shmobile/board-marzen.c
> >> 
> >> [...]
> >> 
> >>> @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
> >>>   .num_resources  = ARRAY_SIZE(hspi_resources),
> >>>};
> >>> 
> >>> +/* DU */
> >>> +static struct resource rcar_du_resources[] = {
> >>> + [0] = {
> >>> + .name   = "Display Unit",
> >>> + .start  = 0xfff8,
> >>> + .end= 0xfffb1007,
> >>> + .flags  = IORESOURCE_MEM,
> >>> + },
> >>> + [1] = {
> >>> + .start  = gic_spi(31),
> >>> + .flags  = IORESOURCE_IRQ,
> >>> + },
> >>> +};
> >>> +
> >>> +static struct rcar_du_platform_data rcar_du_pdata = {
> >>> + .encoders = {
> >>> + [0] = {
> >>> + .encoder = RCAR_DU_ENCODER_VGA,
> >>> + },
> >>> + },
> >>> +};
> >>> +
> >>> +static struct platform_device rcar_du_device = {
> >>> + .name   = "rcar-du",
> >>> + .num_resources  = ARRAY_SIZE(rcar_du_resources),
> >>> + .resource   = rcar_du_resources,
> >>> + .dev= {
> >>> + .platform_data = _du_pdata,
> >>> + .coherent_dma_mask = ~0,
> >>> + },
> >>> +};
> >>> +
> >> 
> >> Are we seeing again SoC device declared in the board file? That simply
> >> doesn't scale...
> > 
> > The goal is obviously to move all that to DT, but there's no DT bindings
> > for the DU DRM driver yet.
> 
> I don't see how it justifies dubious non-DT design. Let me tell/remind you
> about the LTSI-3.4 tree where all this stuff can be backported and which
> doesn't have DT support, AFAIR.

This patch is an example only, I should have marked it as such. If I need to 
push something similar to mainline I will keep your comment in mind and see 
how I can move the platform device to setup-r8a7779.c. Platform data, however, 
need to be provided on a per-board basis.

-- 
Regards,

Laurent Pinchart

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Sergei Shtylyov]

On 15.03.2013 0:11, Laurent Pinchart wrote:

>>> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
>>> and DU1 LVDS outputs will require information about the panels that will
>>> be connected to those outputs.

>>> Signed-off-by: Laurent Pinchart
>>> 
>>> ---

>>>arch/arm/configs/marzen_defconfig |  2 ++
>>>arch/arm/mach-shmobile/board-marzen.c | 65 +
>>>2 files changed, 67 insertions(+)

>>> diff --git a/arch/arm/mach-shmobile/board-marzen.c
>>> b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
>>> --- a/arch/arm/mach-shmobile/board-marzen.c
>>> +++ b/arch/arm/mach-shmobile/board-marzen.c

>> [...]

>>> @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
>>> .num_resources  = ARRAY_SIZE(hspi_resources),
>>>};
>>>
>>> +/* DU */
>>> +static struct resource rcar_du_resources[] = {
>>> +   [0] = {
>>> +   .name   = "Display Unit",
>>> +   .start  = 0xfff8,
>>> +   .end= 0xfffb1007,
>>> +   .flags  = IORESOURCE_MEM,
>>> +   },
>>> +   [1] = {
>>> +   .start  = gic_spi(31),
>>> +   .flags  = IORESOURCE_IRQ,
>>> +   },
>>> +};
>>> +
>>> +static struct rcar_du_platform_data rcar_du_pdata = {
>>> +   .encoders = {
>>> +   [0] = {
>>> +   .encoder = RCAR_DU_ENCODER_VGA,
>>> +   },
>>> +   },
>>> +};
>>> +
>>> +static struct platform_device rcar_du_device = {
>>> +   .name   = "rcar-du",
>>> +   .num_resources  = ARRAY_SIZE(rcar_du_resources),
>>> +   .resource   = rcar_du_resources,
>>> +   .dev= {
>>> +   .platform_data = _du_pdata,
>>> +   .coherent_dma_mask = ~0,
>>> +   },
>>> +};
>>> +

>> Are we seeing again SoC device declared in the board file? That simply
>> doesn't scale...

> The goal is obviously to move all that to DT, but there's no DT bindings for
> the DU DRM driver yet.

I don't see how it justifies dubious non-DT design. Let me tell/remind you 
about the LTSI-3.4 tree where all this stuff can be backported and which 
doesn't have DT support, AFAIR.

WBR, Sergei

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #53 from Alexandre Demers  ---
(In reply to comment #50)
> I believe I have the source of the bug, it appears that there is a special
> case for Caymen GPUs that isn't handled in the DMA code path.  In
> evergreen_state.c within the method evergreen_create_sampler_view_custom
> there is the chunk of code
> 
>   /* 128 bit formats require tile type = 1 */
>   if (rscreen->chip_class == CAYMAN) {
>   if (util_format_get_blocksize(pipe_format) >= 16)
>   non_disp_tiling = 1;
>   }
> 
> however, within evergreen_dma_copy_tile in the same source file no such code
> exists.  I tested whether this was the case or not by placing the lines of
> code
> 
>   if (util_format_get_blocksize(dst->format) >= 16) {
>   printf("Caymen non disp tiling skipping dma tile\n");
>   return FALSE;
>   }
> 
> before the call to evergreen_dma_copy_tile in evergreen_dma_blit, and the
> corruption no longer appeared. (having this checks skips the DMA path for
> this case and goes through the normal path, which would be
> evergreen_create_sampler_view_custom I believe)
> 
> I'm not sure which bits in the DMA packet control this setting.

Your observations are right, using your trick does indeed remove the
corruptions.

-- 
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/20130315/8a302b29/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #52 from Alexandre Demers  ---
(In reply to comment #51)
> Created attachment 76544 [details] [review]
> set non_disp tiling bit for cayman
> 
> Good catch!  I believe the attached patch should fix the issue.

I don't know for others, but it doesn't fix the corruption over here.

-- 
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/20130315/65c410be/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #51 from Alex Deucher  ---
Created attachment 76544
  --> https://bugs.freedesktop.org/attachment.cgi?id=76544=edit
set non_disp tiling bit for cayman

Good catch!  I believe the attached patch should 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/20130315/16b07244/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

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

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

--- Comment #50 from Anthony Waters  ---
I believe I have the source of the bug, it appears that there is a special case
for Caymen GPUs that isn't handled in the DMA code path.  In evergreen_state.c
within the method evergreen_create_sampler_view_custom there is the chunk of
code

/* 128 bit formats require tile type = 1 */
if (rscreen->chip_class == CAYMAN) {
if (util_format_get_blocksize(pipe_format) >= 16)
non_disp_tiling = 1;
}

however, within evergreen_dma_copy_tile in the same source file no such code
exists.  I tested whether this was the case or not by placing the lines of code

if (util_format_get_blocksize(dst->format) >= 16) {
printf("Caymen non disp tiling skipping dma tile\n");
return FALSE;
}

before the call to evergreen_dma_copy_tile in evergreen_dma_blit, and the
corruption no longer appeared. (having this checks skips the DMA path for this
case and goes through the normal path, which would be
evergreen_create_sampler_view_custom I believe)

I'm not sure which bits in the DMA packet control this setting.

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

[Bug 60802] Corruption with DMA ring on cayman

[bugzilla-daemon]

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

--- Comment #54 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #51)
 Created attachment 76544 [details] [review]
 set non_disp tiling bit for cayman
 
 Good catch!  I believe the attached patch should fix the issue.

Since this bug is pretty much the same as previous one I had identified in
comment 29 (pointing to bug 38173) and since the proposed patch is also pretty
similar to 1 of the 2 patches needed to fix that identified bug, is it possible
there is something missing that would look like the second patch that was
needed?

patch 1 from bug 38173 (similar to the one proposed with your attachment
76544):
http://cgit.freedesktop.org/mesa/mesa/commit/?id=5e1495b2d9311fa2b320766a1d299053904bd9c3
patch 2 from bug 38173 (possibly similar to what is missing to complete your
proposed patch):
http://cgit.freedesktop.org/mesa/mesa/commit/?id=acca690c259824636ef1ff684a10bd1caca4751f

In other words, are we sure we are offsetting the non_disp variable correctly
for Cayman? Because according to the second patch, the offset was different.

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

[PATCH v2 0/3] R-Car Display Unit DRM driver

[Laurent Pinchart]

Hello,

Here's the second version of the Renesas R-Car Display Unit (DU) DRM driver.

The DU features two superposition processors (modeled as CRTCs) and eight
planes that can be shared between the superposition processors.

The driver supports the superposition processors, all eight planes and all
hardware supported formats except 8-bit indexed color mode and 32-bit RGB666
mode (that would be [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian, not
supported by DRM at the moment).

On the output side only sync master non-interlaced modes are currently
supported. Both the VGA and the LVDS outputs have been tested.

Platform data are subject to change with the common display framework. This is
why I haven't implemented DT bindings yet.

Changes since v1:

 - Use drm_encoder_cleanup() directly as .destroy handlers
 - Enable alpha blending support
 - Don't re-reserve hardware plane at each update
 - Fix planes allocation for multiplanar formats
 - Add DRM PRIME support
 - Fix race condition between page flip request and handler
 - Add configurable z-order support for planes
 - Support configurable color keying for planes
 - Update plane format after releasing hardware planes
 - Fix register access for global registers
 - Fix plane index wrap-around for multi-planar overlays

Please note that this version depends on the GEM CMA DRM PRIME patches I have
previously sent to the dri-devel mailing list.

I've included necessary arch/ modifications to allow easy testing. The r8a7779
clock patch should already be on its way to mainline, the Marzen board code
will be resubmitted separately through the ARM tree after the DU driver gets
pulled in the DRM tree.

Laurent Pinchart (2):
  drm: Renesas R-Car Display Unit DRM driver
  ARM: shmobile: marzen: Add Display Unit support

Phil Edworthy (1):
  r8a7779: Add Display Unit clock support

 arch/arm/configs/marzen_defconfig   |   2 +
 arch/arm/mach-shmobile/board-marzen.c   |  65 +
 arch/arm/mach-shmobile/clock-r8a7779.c  |   4 +-
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/rcar-du/Kconfig |   9 +
 drivers/gpu/drm/rcar-du/Makefile|   8 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 499 
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  48 +++
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 270 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  59 
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 163 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.h   |  33 +++
 drivers/gpu/drm/rcar-du/rcar_du_lvds.c  | 242 
 drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |  25 ++
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 444 
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  61 
 drivers/gpu/drm/rcar-du/rcar_du_regs.h  | 443 
 drivers/gpu/drm/rcar-du/rcar_du_vga.c   | 188 
 drivers/gpu/drm/rcar-du/rcar_du_vga.h   |  24 ++
 include/linux/platform_data/rcar-du.h   |  51 
 21 files changed, 2640 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rcar-du/Kconfig
 create mode 100644 drivers/gpu/drm/rcar-du/Makefile
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_regs.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.h
 create mode 100644 include/linux/platform_data/rcar-du.h

-- 
Regards,

Laurent Pinchart

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

[PATCH v2 1/3] r8a7779: Add Display Unit clock support

[Laurent Pinchart]

From: Phil Edworthy phil.edwor...@renesas.com

Signed-off-by: Phil Edworthy phil.edwor...@renesas.com
[Rename device from to rcarfb to rcar-du]
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 arch/arm/mach-shmobile/clock-r8a7779.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/clock-r8a7779.c 
b/arch/arm/mach-shmobile/clock-r8a7779.c
index 1db3653..9ea6087 100644
--- a/arch/arm/mach-shmobile/clock-r8a7779.c
+++ b/arch/arm/mach-shmobile/clock-r8a7779.c
@@ -87,7 +87,7 @@ static struct clk div4_clks[DIV4_NR] = {
 };
 
 enum { MSTP323, MSTP322, MSTP321, MSTP320,
-   MSTP101, MSTP100,
+   MSTP103, MSTP101, MSTP100,
MSTP030,
MSTP029, MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, 
MSTP021,
MSTP016, MSTP015, MSTP014,
@@ -99,6 +99,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(div4_clks[DIV4_P], MSTPCR3, 22, 0), /* SDHI1 
*/
[MSTP321] = SH_CLK_MSTP32(div4_clks[DIV4_P], MSTPCR3, 21, 0), /* SDHI2 
*/
[MSTP320] = SH_CLK_MSTP32(div4_clks[DIV4_P], MSTPCR3, 20, 0), /* SDHI3 
*/
+   [MSTP103] = SH_CLK_MSTP32(div4_clks[DIV4_S], MSTPCR1,  3, 0), /* DU */
[MSTP101] = SH_CLK_MSTP32(div4_clks[DIV4_P], MSTPCR1,  1, 0), /* USB2 
*/
[MSTP100] = SH_CLK_MSTP32(div4_clks[DIV4_P], MSTPCR1,  0, 0), /* 
USB0/1 */
[MSTP030] = SH_CLK_MSTP32(div4_clks[DIV4_P], MSTPCR0, 30, 0), /* I2C0 
*/
@@ -180,6 +181,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID(sh_mobile_sdhi.1, mstp_clks[MSTP322]), /* SDHI1 */
CLKDEV_DEV_ID(sh_mobile_sdhi.2, mstp_clks[MSTP321]), /* SDHI2 */
CLKDEV_DEV_ID(sh_mobile_sdhi.3, mstp_clks[MSTP320]), /* SDHI3 */
+   CLKDEV_DEV_ID(rcar-du.0, mstp_clks[MSTP103]), /* DU */
 };
 
 void __init r8a7779_clock_init(void)
-- 
1.8.1.5

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

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Laurent Pinchart]

Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
and DU1 LVDS outputs will require information about the panels that will
be connected to those outputs.

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 arch/arm/configs/marzen_defconfig |  2 ++
 arch/arm/mach-shmobile/board-marzen.c | 65 +++
 2 files changed, 67 insertions(+)

diff --git a/arch/arm/configs/marzen_defconfig 
b/arch/arm/configs/marzen_defconfig
index afb17d6..76f9402 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -79,6 +79,8 @@ CONFIG_GPIO_SYSFS=y
 CONFIG_THERMAL=y
 CONFIG_RCAR_THERMAL=y
 CONFIG_SSB=y
+CONFIG_DRM=y
+CONFIG_DRM_RCAR_DU=y
 CONFIG_USB=y
 CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y
diff --git a/arch/arm/mach-shmobile/board-marzen.c 
b/arch/arm/mach-shmobile/board-marzen.c
index cdcb799..0020506 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -38,6 +38,7 @@
 #include linux/usb/ehci_pdriver.h
 #include linux/usb/ohci_pdriver.h
 #include linux/pm_runtime.h
+#include linux/platform_data/rcar-du.h
 #include mach/hardware.h
 #include mach/r8a7779.h
 #include mach/common.h
@@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
.num_resources  = ARRAY_SIZE(hspi_resources),
 };
 
+/* DU */
+static struct resource rcar_du_resources[] = {
+   [0] = {
+   .name   = Display Unit,
+   .start  = 0xfff8,
+   .end= 0xfffb1007,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .start  = gic_spi(31),
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct rcar_du_platform_data rcar_du_pdata = {
+   .encoders = {
+   [0] = {
+   .encoder = RCAR_DU_ENCODER_VGA,
+   },
+   },
+};
+
+static struct platform_device rcar_du_device = {
+   .name   = rcar-du,
+   .num_resources  = ARRAY_SIZE(rcar_du_resources),
+   .resource   = rcar_du_resources,
+   .dev= {
+   .platform_data = rcar_du_pdata,
+   .coherent_dma_mask = ~0,
+   },
+};
+
 /* USB PHY */
 static struct resource usb_phy_resources[] = {
[0] = {
@@ -173,6 +206,7 @@ static struct platform_device *marzen_devices[] __initdata 
= {
thermal_device,
hspi_device,
usb_phy_device,
+   rcar_du_device,
 };
 
 /* USB */
@@ -363,6 +397,37 @@ static void __init marzen_init(void)
gpio_request(GPIO_FN_HSPI_TX0,  NULL);
gpio_request(GPIO_FN_HSPI_RX0,  NULL);
 
+   /* Display Unit 0 (CN10: ARGB0) */
+   gpio_request(GPIO_FN_DU0_DR7, NULL);
+   gpio_request(GPIO_FN_DU0_DR6, NULL);
+   gpio_request(GPIO_FN_DU0_DR5, NULL);
+   gpio_request(GPIO_FN_DU0_DR4, NULL);
+   gpio_request(GPIO_FN_DU0_DR3, NULL);
+   gpio_request(GPIO_FN_DU0_DR2, NULL);
+   gpio_request(GPIO_FN_DU0_DR1, NULL);
+   gpio_request(GPIO_FN_DU0_DR0, NULL);
+   gpio_request(GPIO_FN_DU0_DG7, NULL);
+   gpio_request(GPIO_FN_DU0_DG6, NULL);
+   gpio_request(GPIO_FN_DU0_DG5, NULL);
+   gpio_request(GPIO_FN_DU0_DG4, NULL);
+   gpio_request(GPIO_FN_DU0_DG3, NULL);
+   gpio_request(GPIO_FN_DU0_DG2, NULL);
+   gpio_request(GPIO_FN_DU0_DG1, NULL);
+   gpio_request(GPIO_FN_DU0_DG0, NULL);
+   gpio_request(GPIO_FN_DU0_DB7, NULL);
+   gpio_request(GPIO_FN_DU0_DB6, NULL);
+   gpio_request(GPIO_FN_DU0_DB5, NULL);
+   gpio_request(GPIO_FN_DU0_DB4, NULL);
+   gpio_request(GPIO_FN_DU0_DB3, NULL);
+   gpio_request(GPIO_FN_DU0_DB2, NULL);
+   gpio_request(GPIO_FN_DU0_DB1, NULL);
+   gpio_request(GPIO_FN_DU0_DB0, NULL);
+   gpio_request(GPIO_FN_DU0_EXVSYNC_DU0_VSYNC, NULL);
+   gpio_request(GPIO_FN_DU0_EXHSYNC_DU0_HSYNC, NULL);
+   gpio_request(GPIO_FN_DU0_DOTCLKOUT0, NULL);
+   gpio_request(GPIO_FN_DU0_DOTCLKOUT1, NULL);
+   gpio_request(GPIO_FN_DU0_DISP, NULL);
+
/* USB (CN21) */
gpio_request(GPIO_FN_USB_OVC0, NULL);
gpio_request(GPIO_FN_USB_OVC1, NULL);
-- 
1.8.1.5

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

Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Sergei Shtylyov]

Hello.

On 14-03-2013 18:35, Laurent Pinchart wrote:


Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
and DU1 LVDS outputs will require information about the panels that will
be connected to those outputs.



Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
  arch/arm/configs/marzen_defconfig |  2 ++
  arch/arm/mach-shmobile/board-marzen.c | 65 +++
  2 files changed, 67 insertions(+)



diff --git a/arch/arm/mach-shmobile/board-marzen.c 
b/arch/arm/mach-shmobile/board-marzen.c
index cdcb799..0020506 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c

[...]

@@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
.num_resources  = ARRAY_SIZE(hspi_resources),
  };

+/* DU */
+static struct resource rcar_du_resources[] = {
+   [0] = {
+   .name   = Display Unit,
+   .start  = 0xfff8,
+   .end= 0xfffb1007,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .start  = gic_spi(31),
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct rcar_du_platform_data rcar_du_pdata = {
+   .encoders = {
+   [0] = {
+   .encoder = RCAR_DU_ENCODER_VGA,
+   },
+   },
+};
+
+static struct platform_device rcar_du_device = {
+   .name   = rcar-du,
+   .num_resources  = ARRAY_SIZE(rcar_du_resources),
+   .resource   = rcar_du_resources,
+   .dev= {
+   .platform_data = rcar_du_pdata,
+   .coherent_dma_mask = ~0,
+   },
+};
+


   Are we seeing again SoC device declared in the board file? That simply 
doesn't scale...


WBR, Sergei

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

Re: [PATCH 2/2] ppc64: Add arch-specific pcie_get_speed_cap_mask

[Thadeu Lima de Souza Cascardo]

On Thu, Mar 14, 2013 at 02:45:47PM -0300, luca...@linux.vnet.ibm.com wrote:
 From: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com
 
 Betters support for gen2 speed detections on PCI buses on ppc64
 architectures.
 
 Signed-off-by: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com
 ---
  arch/powerpc/platforms/pseries/pci.c |   32 
  1 files changed, 32 insertions(+), 0 deletions(-)
 
 diff --git a/arch/powerpc/platforms/pseries/pci.c 
 b/arch/powerpc/platforms/pseries/pci.c
 index 0b580f4..58469fe 100644
 --- a/arch/powerpc/platforms/pseries/pci.c
 +++ b/arch/powerpc/platforms/pseries/pci.c
 @@ -24,6 +24,7 @@
  #include linux/kernel.h
  #include linux/pci.h
  #include linux/string.h
 +#include linux/device.h
 
  #include asm/eeh.h
  #include asm/pci-bridge.h
 @@ -108,3 +109,34 @@ static void fixup_winbond_82c105(struct pci_dev* dev)
  }
  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
fixup_winbond_82c105);
 +
 +int pcibios_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
 +{
 + struct device_node *dn, *pdn;
 + const uint32_t *pcie_link_speed_stats = NULL;
 +
 + *mask = 0;
 + dn = pci_bus_to_OF_node(dev-bus);
 +
 + /* Find nearest ibm,pcie-link-speed-stats, walking up the device tree */
 + for (pdn = dn; pdn != NULL; pdn = pdn-parent) {
 + pcie_link_speed_stats = (const uint32_t *) of_get_property(pdn,
 + ibm,pcie-link-speed-stats, NULL);
 + if (pcie_link_speed_stats != NULL)
 + break;
 + }
 +
 + if (pcie_link_speed_stats == NULL) {
 + dev_info(dev-dev, no ibm,pcie-link-speed-stats property\n);
 + return -EINVAL;
 + }
 +
 + switch (pcie_link_speed_stats[0]) {
 + case 0x02:
 + *mask |= PCIE_SPEED_50;
 + case 0x01:
 + *mask |= PCIE_SPEED_25;
 + }

I recall seeing this returns 0x00 as well. Maybe you should include both
0x00 and a default case and return EINVAL.

Regards.
Cascardo.

 +
 + return 0;
 +}
 -- 
 1.7.4.4
 

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

Re: [PATCH 1/2] drm: Move drm_pcie_get_speed_cap_mask to PCI

[Thadeu Lima de Souza Cascardo]

On Thu, Mar 14, 2013 at 02:45:46PM -0300, luca...@linux.vnet.ibm.com wrote:
 From: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com
 
 This function was more architecture related than drm related, as such it was
 moved to the PCI driver.
 
 This patch also allows it to be overwritten by architecture-dependent
 implementations, and fixes the radeon driver (only one that uses it).
 
 Signed-off-by: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com
 ---
  drivers/gpu/drm/drm_pci.c  |   38 ---
  drivers/gpu/drm/radeon/evergreen.c |5 ++-
  drivers/gpu/drm/radeon/r600.c  |5 ++-
  drivers/gpu/drm/radeon/rv770.c |5 ++-
  drivers/pci/pci.c  |   43 
 
  include/drm/drmP.h |6 -
  include/linux/pci.h|6 +
  7 files changed, 58 insertions(+), 50 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
 index bd719e9..ba70844 100644
 --- a/drivers/gpu/drm/drm_pci.c
 +++ b/drivers/gpu/drm/drm_pci.c
 @@ -439,44 +439,6 @@ int drm_pci_init(struct drm_driver *driver, struct 
 pci_driver *pdriver)
   return 0;
  }
 
 -int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 *mask)
 -{
 - struct pci_dev *root;
 - u32 lnkcap, lnkcap2;
 -
 - *mask = 0;
 - if (!dev-pdev)
 - return -EINVAL;
 -
 - root = dev-pdev-bus-self;
 -
 - /* we've been informed via and serverworks don't make the cut */
 - if (root-vendor == PCI_VENDOR_ID_VIA ||
 - root-vendor == PCI_VENDOR_ID_SERVERWORKS)
 - return -EINVAL;
 -
 - pcie_capability_read_dword(root, PCI_EXP_LNKCAP, lnkcap);
 - pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, lnkcap2);
 -
 - if (lnkcap2) {  /* PCIe r3.0-compliant */
 - if (lnkcap2  PCI_EXP_LNKCAP2_SLS_2_5GB)
 - *mask |= DRM_PCIE_SPEED_25;
 - if (lnkcap2  PCI_EXP_LNKCAP2_SLS_5_0GB)
 - *mask |= DRM_PCIE_SPEED_50;
 - if (lnkcap2  PCI_EXP_LNKCAP2_SLS_8_0GB)
 - *mask |= DRM_PCIE_SPEED_80;
 - } else {/* pre-r3.0 */
 - if (lnkcap  PCI_EXP_LNKCAP_SLS_2_5GB)
 - *mask |= DRM_PCIE_SPEED_25;
 - if (lnkcap  PCI_EXP_LNKCAP_SLS_5_0GB)
 - *mask |= (DRM_PCIE_SPEED_25 | DRM_PCIE_SPEED_50);
 - }
 -
 - DRM_INFO(probing gen 2 caps for device %x:%x = %x/%x\n, root-vendor, 
 root-device, lnkcap, lnkcap2);
 - return 0;
 -}
 -EXPORT_SYMBOL(drm_pcie_get_speed_cap_mask);
 -
  #else
 
  int drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver)
 diff --git a/drivers/gpu/drm/radeon/evergreen.c 
 b/drivers/gpu/drm/radeon/evergreen.c
 index 305a657..6ba204d 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -24,6 +24,7 @@
  #include linux/firmware.h
  #include linux/platform_device.h
  #include linux/slab.h
 +#include linux/pci.h
  #include drm/drmP.h
  #include radeon.h
  #include radeon_asic.h
 @@ -3871,11 +3872,11 @@ void evergreen_pcie_gen2_enable(struct radeon_device 
 *rdev)
   if (ASIC_IS_X2(rdev))
   return;
 
 - ret = drm_pcie_get_speed_cap_mask(rdev-ddev, mask);
 + ret = pcie_get_speed_cap_mask(rdev-ddev-pdev, mask);
   if (ret != 0)
   return;
 
 - if (!(mask  DRM_PCIE_SPEED_50))
 + if (!(mask  PCIE_SPEED_50))
   return;
 
   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
 diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
 index 0740db3..89a7387 100644
 --- a/drivers/gpu/drm/radeon/r600.c
 +++ b/drivers/gpu/drm/radeon/r600.c
 @@ -30,6 +30,7 @@
  #include linux/firmware.h
  #include linux/platform_device.h
  #include linux/module.h
 +#include linux/pci.h
  #include drm/drmP.h
  #include drm/radeon_drm.h
  #include radeon.h
 @@ -4371,11 +4372,11 @@ static void r600_pcie_gen2_enable(struct 
 radeon_device *rdev)
   if (rdev-family = CHIP_R600)
   return;
 
 - ret = drm_pcie_get_speed_cap_mask(rdev-ddev, mask);
 + ret = pcie_get_speed_cap_mask(rdev-ddev-pdev, mask);
   if (ret != 0)
   return;
 
 - if (!(mask  DRM_PCIE_SPEED_50))
 + if (!(mask  PCIE_SPEED_50))
   return;
 
   speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
 diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
 index d63fe1d..81c7f1c 100644
 --- a/drivers/gpu/drm/radeon/rv770.c
 +++ b/drivers/gpu/drm/radeon/rv770.c
 @@ -28,6 +28,7 @@
  #include linux/firmware.h
  #include linux/platform_device.h
  #include linux/slab.h
 +#include linux/pci.h
  #include drm/drmP.h
  #include radeon.h
  #include radeon_asic.h
 @@ -1254,11 +1255,11 @@ static void rv770_pcie_gen2_enable(struct 
 radeon_device *rdev)
   if (ASIC_IS_X2(rdev))
   return;
 
 - ret = drm_pcie_get_speed_cap_mask(rdev-ddev, mask);
 + ret 

Re: [PATCH v3] drm/i915: bounds check execbuffer relocation count

[Kees Cook]

On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
 On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
  It is possible to wrap the counter used to allocate the buffer for
  relocation copies. This could lead to heap writing overflows.
 
  CVE-2013-0913
 
  v3: collapse test, improve comment
  v2: move check into validate_exec_list
 
  Signed-off-by: Kees Cook keesc...@chromium.org
  Reported-by: Pinkie Pie
  Cc: sta...@vger.kernel.org

 Looks good to me. The only bikeshed that remains is whether we should
 just collapse the two variables into one, but the current 'max - count'
 is more idiomatic and so preferrable.
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

 Picked up for -fixes, thanks for the patch.

 I've forgotten to dump my wishlist: Can I have an i-g-t for this? For
 this bug here specifically an execbuf with just one buffer with too
 many relocs plus another execbuf with two buffers with relocation so
 that the 2nd relocation list will overflow should be sufficient.

Sure thing. Where do these live? (Or what docs should I read for
this?) I'm assuming i-g-t means intel graphics test? :)

-Kees

-- 
Kees Cook
Chrome OS Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

[Sergei Shtylyov]

On 15.03.2013 0:11, Laurent Pinchart wrote:


Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
and DU1 LVDS outputs will require information about the panels that will
be connected to those outputs.



Signed-off-by: Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com
---



   arch/arm/configs/marzen_defconfig |  2 ++
   arch/arm/mach-shmobile/board-marzen.c | 65 +
   2 files changed, 67 insertions(+)



diff --git a/arch/arm/mach-shmobile/board-marzen.c
b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c



[...]



@@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
.num_resources  = ARRAY_SIZE(hspi_resources),
   };

+/* DU */
+static struct resource rcar_du_resources[] = {
+   [0] = {
+   .name   = Display Unit,
+   .start  = 0xfff8,
+   .end= 0xfffb1007,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .start  = gic_spi(31),
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct rcar_du_platform_data rcar_du_pdata = {
+   .encoders = {
+   [0] = {
+   .encoder = RCAR_DU_ENCODER_VGA,
+   },
+   },
+};
+
+static struct platform_device rcar_du_device = {
+   .name   = rcar-du,
+   .num_resources  = ARRAY_SIZE(rcar_du_resources),
+   .resource   = rcar_du_resources,
+   .dev= {
+   .platform_data = rcar_du_pdata,
+   .coherent_dma_mask = ~0,
+   },
+};
+



Are we seeing again SoC device declared in the board file? That simply
doesn't scale...



The goal is obviously to move all that to DT, but there's no DT bindings for
the DU DRM driver yet.


   I don't see how it justifies dubious non-DT design. Let me tell/remind you 
about the LTSI-3.4 tree where all this stuff can be backported and which 
doesn't have DT support, AFAIR.


WBR, Sergei

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

Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Ben Widawsky]

On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
 In order to prevent a potential NULL deference with hostile userspace,
 we need to check whether the ioctl was passed an invalid args pointer.
 
 Reported-by: Tommi Rantala tt.rant...@gmail.com
 Link: 
 http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index 365e41a..9f5602e 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
   int ret, i;
  
 - if (args-buffer_count  1) {
 + if (args == NULL)
 + return -EINVAL;
 +
 + if (args-buffer_count  1 ||
 + args-buffer_count  INT_MAX / sizeof(*exec2_list)) {
   DRM_DEBUG(execbuf with %d buffers\n, args-buffer_count);
   return -EINVAL;
   }
 @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void 
 *data,
   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
   int ret;
  
 + if (args == NULL)
 + return -EINVAL;
 +
   if (args-buffer_count  1 ||
 - args-buffer_count  UINT_MAX / sizeof(*exec2_list)) {
 + args-buffer_count  INT_MAX / sizeof(*exec2_list)) {
   DRM_DEBUG(execbuf2 with %d buffers\n, args-buffer_count);
   return -EINVAL;
   }

Why did you change UINT_MAX to INT_MAX? TBH, I'm confused what we're
trying to achieve, and why we need anything other than:
if (!args-buffer_count)

I'm also not seeing how the NULL checks are needed since at least it
seems to be for execbuffer (IOW) we could never have NULL args.

if (cmd  (IOC_IN | IOC_OUT)) {
if (asize = sizeof(stack_kdata)) {
kdata = stack_kdata;
} else {
kdata = kmalloc(asize, GFP_KERNEL);
if (!kdata) {
retcode = -ENOMEM;
goto err_i1;
}
}
if (asize  usize)
memset(kdata + usize, 0, asize - usize);
}

Sorry if these are stupid questions.

-- 
Ben Widawsky, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

[Ben Widawsky]

On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
 In order to prevent a potential NULL deference with hostile userspace,
 we need to check whether the ioctl was passed an invalid args pointer.
 
 Reported-by: Tommi Rantala tt.rant...@gmail.com
 Link: 
 http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index 365e41a..9f5602e 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
   int ret, i;
  
 - if (args-buffer_count  1) {
 + if (args == NULL)
 + return -EINVAL;
 +
 + if (args-buffer_count  1 ||
 + args-buffer_count  INT_MAX / sizeof(*exec2_list)) {
   DRM_DEBUG(execbuf with %d buffers\n, args-buffer_count);
   return -EINVAL;
   }
 @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void 
 *data,
   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
   int ret;
  
 + if (args == NULL)
 + return -EINVAL;
 +
   if (args-buffer_count  1 ||
 - args-buffer_count  UINT_MAX / sizeof(*exec2_list)) {
 + args-buffer_count  INT_MAX / sizeof(*exec2_list)) {
   DRM_DEBUG(execbuf2 with %d buffers\n, args-buffer_count);
   return -EINVAL;
   }

Why did you change UINT_MAX to INT_MAX? TBH, I'm confused what we're
trying to achieve, and why we need anything other than:
if (!args-buffer_count)

I'm also not seeing how the NULL checks are needed since at least it
seems to be for execbuffer (IOW) we could never have NULL args.

if (cmd  (IOC_IN | IOC_OUT)) {
if (asize = sizeof(stack_kdata)) {
kdata = stack_kdata;
} else {
kdata = kmalloc(asize, GFP_KERNEL);
if (!kdata) {
retcode = -ENOMEM;
goto err_i1;
}
}
if (asize  usize)
memset(kdata + usize, 0, asize - usize);
}

Sorry if these are stupid questions.

-- 
Ben Widawsky, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 20211] Runing Kubrick game maximized freezes X and causes kernel panic

[bugzilla-daemon]

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

--- Comment #2 from chemtech patsev.an...@gmail.com ---
Jure Repinc,
Please attach full dmesg and output of lspci -vv
Please check the status of your issue.

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

[Bug 20129] Large texture object obscuring display with radeon driver in dxx-rebirth

[bugzilla-daemon]

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

--- Comment #14 from chemtech patsev.an...@gmail.com ---
jsado_...@comcast.net,
Please attach full dmesg and output of lspci -vv
Please check the status of your issue.

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

[Bug 20751] 2D acceleration on R6xx freezes my computer

[bugzilla-daemon]

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

--- Comment #3 from chemtech patsev.an...@gmail.com ---
Nicolas Bareil,
Please attach full dmesg and output of lspci -vv
Please check the status of your issue.

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

[Bug 21122] If DRI is enabled ,System will freeze after X quit

[bugzilla-daemon]

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

--- Comment #8 from chemtech patsev.an...@gmail.com ---
TeF,
Please attach full dmesg.
Please check the status of your issue.

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

[Bug 21284] [KMS] Radeon rv280 black screen with modeset=1

[bugzilla-daemon]

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

--- Comment #5 from chemtech patsev.an...@gmail.com ---
Andrew Randrianasulu,
Please attach full dmesg and output of lspci -vv
Please check the status of your issue.

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

[Bug 20537] piglit failures on ATI Mobility M6

[bugzilla-daemon]

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

--- Comment #9 from chemtech patsev.an...@gmail.com ---
jsado_...@comcast.net,
Do you still experience this issue with newer drivers ?
Please check the status of your issue.

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

[Bug 3493] r128: Entire X-windowing system hangs during normal 3D gaming

[bugzilla-daemon]

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

--- Comment #17 from chemtech patsev.an...@gmail.com ---
Alan Grimes,
Do you still experience this issue with newer drivers ?
Please check the status of your issue.

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

[Bug 8634] [r128] Driver does not support GLX_SGI_make_current_read

[bugzilla-daemon]

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

--- Comment #3 from chemtech patsev.an...@gmail.com ---
Ian Romanick,
Do you still experience this issue with newer drivers ?
Please check the status of your issue.

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