[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

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

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

--- Comment #34 from Andy Furniss  ---
(In reply to comment #30)
> Created attachment 74433 [details] [review]
> Kernel fix
> 
> This one apply against Linus master

Like Paul, I need the mesa patch as well to get rid of the junk at the bottom
of the screen.

I guess my screen was too small to show the issue this patch fixes, but I've
tried it and can't find anything that regresses.

-- 
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/20130208/247b475a/attachment.html>

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

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

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

--- Comment #33 from Paul Heldens  ---
i've seen no more dmesg errors

-- 
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/20130208/4477ce31/attachment.html>

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

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

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

Paul Heldens  changed:

   What|Removed |Added

  Attachment #74239|0   |1
is obsolete||
  Attachment #74306|0   |1
is obsolete||

--- Comment #32 from Paul Heldens  ---
Created attachment 74451
  --> https://bugs.freedesktop.org/attachment.cgi?id=74451=edit
xonotic with kernel without v2 patch 3.8-rc6

-- 
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/20130208/de0340d2/attachment.html>

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

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

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

--- Comment #31 from Paul Heldens  ---
3.8-rc6

your latest kernel patch applied well.



with fix v2 all corruption seems gone.  on ~10 startups




without fix v2 I still see dynamic corruption at the bottom of screen

-- 
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/20130208/77383e05/attachment.html>

[Bug 59521] [Serious Sam 3] Missing textures with R600g

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

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

--- Comment #3 from Laurent carlier  ---
Created attachment 74448
  --> https://bugs.freedesktop.org/attachment.cgi?id=74448=edit
apitrace that produce an error

That trace gives:

> apitrace retrace Sam3.1207.trim.trace 
1205: glDebugOutputCallback: High severity API error 0, GL_INVALID_OPERATION in
unsupported function called (unsupported extension or deprecated function?)
0 1205 glProgramUniform1i(program = 8, location = 65536, v0 = 0)
1205: warning: glGetError(glProgramUniform1i) = GL_INVALID_OPERATION
Rendered 0 frames in 0.0703531 secs, average of 0 fps

-- 
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/20130208/dc97b409/attachment.html>

[PATCH] drm/radeon: copy userspace cmd to local copy before processing it v3

[Alex Deucher]

On Fri, Feb 8, 2013 at 6:13 PM,   wrote:
> From: Jerome Glisse 
>
> In some rare case were packet is big enough to go over page boundary
> we might not have copied yet the userspace data into the local copy
> resulting in kernel reading garbage data.
>
> Without this patch kernel might submit unprocessed/unrelocated cmd
> to the GPU which might lead to GPU lockup.
>
> v2: Make sure we do copy all the page and don't forget some when
> the packet count dw is bigger than 1 page
> v3: Rebase patch against Linus master
>
> Signed-off-by: Jerome Glisse 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/radeon/evergreen_cs.c | 35 
> ++-
>  drivers/gpu/drm/radeon/r600_cs.c  | 19 ++-
>  2 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index 7a44566..51ad74a 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -1021,7 +1021,7 @@ static int evergreen_cs_packet_parse(struct 
> radeon_cs_parser *p,
>   unsigned idx)
>  {
> struct radeon_cs_chunk *ib_chunk = >chunks[p->chunk_ib_idx];
> -   uint32_t header;
> +   uint32_t header, i, npages;
>
> if (idx >= ib_chunk->length_dw) {
> DRM_ERROR("Can not parse packet at %d after CS end %d !\n",
> @@ -1052,6 +1052,11 @@ static int evergreen_cs_packet_parse(struct 
> radeon_cs_parser *p,
>   pkt->idx, pkt->type, pkt->count, 
> ib_chunk->length_dw);
> return -EINVAL;
> }
> +   /* make sure we copied packet fully from userspace */
> +   npages = ((idx + pkt->count + 1) >> 10) - (idx >> 10);
> +   for (i = 1; i <= npages; i++) {
> +   radeon_get_ib_value(p, (idx & 0xfc00) + i * 0x400);
> +   }
> return 0;
>  }
>
> @@ -2909,12 +2914,16 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
> return -EINVAL;
> }
> if (tiled) {
> +   /* make sure we copied packet fully from 
> userspace */
> +   radeon_get_ib_value(p, idx + 6);
> dst_offset = ib[idx+1];
> dst_offset <<= 8;
>
> ib[idx+1] += (u32)(dst_reloc->lobj.gpu_offset 
> >> 8);
> p->idx += count + 7;
> } else {
> +   /* make sure we copied packet fully from 
> userspace */
> +   radeon_get_ib_value(p, idx + 2);
> dst_offset = ib[idx+1];
> dst_offset |= ((u64)(ib[idx+2] & 0xff)) << 32;
>
> @@ -2945,6 +2954,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
> switch (misc) {
> case 0:
> /* L2T, frame to fields */
> +   /* make sure we copied packet 
> fully from userspace */
> +   radeon_get_ib_value(p, idx + 
> 9);
> if (idx_value & (1 << 31)) {
> DRM_ERROR("bad L2T, 
> frame to fields DMA_PACKET_COPY\n");
> return -EINVAL;
> @@ -2983,6 +2994,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
> break;
> case 1:
> /* L2T, T2L partial */
> +   /* make sure we copied packet 
> fully from userspace */
> +   radeon_get_ib_value(p, idx + 
> 11);
> if (p->family < CHIP_CAYMAN) {
> DRM_ERROR("L2T, T2L 
> Partial is cayman only !\n");
> return -EINVAL;
> @@ -3005,6 +3018,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
> break;
> case 3:
> /* L2T, broadcast */
> +   /* make sure we copied packet 
> fully from userspace */
> +   radeon_get_ib_value(p, idx + 
> 9);
> if (idx_value & (1 << 31)) {
> DRM_ERROR("bad L2T, 
> broadcast DMA_PACKET_COPY\n");
>

[PATCH] drm/radeon: copy userspace cmd to local copy before processing it v3

[j.gli...@gmail.com]

From: Jerome Glisse 

In some rare case were packet is big enough to go over page boundary
we might not have copied yet the userspace data into the local copy
resulting in kernel reading garbage data.

Without this patch kernel might submit unprocessed/unrelocated cmd
to the GPU which might lead to GPU lockup.

v2: Make sure we do copy all the page and don't forget some when
the packet count dw is bigger than 1 page
v3: Rebase patch against Linus master

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/evergreen_cs.c | 35 ++-
 drivers/gpu/drm/radeon/r600_cs.c  | 19 ++-
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 7a44566..51ad74a 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -1021,7 +1021,7 @@ static int evergreen_cs_packet_parse(struct 
radeon_cs_parser *p,
  unsigned idx)
 {
struct radeon_cs_chunk *ib_chunk = >chunks[p->chunk_ib_idx];
-   uint32_t header;
+   uint32_t header, i, npages;

if (idx >= ib_chunk->length_dw) {
DRM_ERROR("Can not parse packet at %d after CS end %d !\n",
@@ -1052,6 +1052,11 @@ static int evergreen_cs_packet_parse(struct 
radeon_cs_parser *p,
  pkt->idx, pkt->type, pkt->count, ib_chunk->length_dw);
return -EINVAL;
}
+   /* make sure we copied packet fully from userspace */
+   npages = ((idx + pkt->count + 1) >> 10) - (idx >> 10);
+   for (i = 1; i <= npages; i++) {
+   radeon_get_ib_value(p, (idx & 0xfc00) + i * 0x400);
+   }
return 0;
 }

@@ -2909,12 +2914,16 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
return -EINVAL;
}
if (tiled) {
+   /* make sure we copied packet fully from 
userspace */
+   radeon_get_ib_value(p, idx + 6);
dst_offset = ib[idx+1];
dst_offset <<= 8;

ib[idx+1] += (u32)(dst_reloc->lobj.gpu_offset 
>> 8);
p->idx += count + 7;
} else {
+   /* make sure we copied packet fully from 
userspace */
+   radeon_get_ib_value(p, idx + 2);
dst_offset = ib[idx+1];
dst_offset |= ((u64)(ib[idx+2] & 0xff)) << 32;

@@ -2945,6 +2954,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
switch (misc) {
case 0:
/* L2T, frame to fields */
+   /* make sure we copied packet 
fully from userspace */
+   radeon_get_ib_value(p, idx + 9);
if (idx_value & (1 << 31)) {
DRM_ERROR("bad L2T, 
frame to fields DMA_PACKET_COPY\n");
return -EINVAL;
@@ -2983,6 +2994,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
break;
case 1:
/* L2T, T2L partial */
+   /* make sure we copied packet 
fully from userspace */
+   radeon_get_ib_value(p, idx + 
11);
if (p->family < CHIP_CAYMAN) {
DRM_ERROR("L2T, T2L 
Partial is cayman only !\n");
return -EINVAL;
@@ -3005,6 +3018,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
break;
case 3:
/* L2T, broadcast */
+   /* make sure we copied packet 
fully from userspace */
+   radeon_get_ib_value(p, idx + 9);
if (idx_value & (1 << 31)) {
DRM_ERROR("bad L2T, 
broadcast DMA_PACKET_COPY\n");
return -EINVAL;
@@ -3043,6 +3058,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
break;
case 4:
  

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

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

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

--- Comment #11 from Lucas Kannebley Tavares  ---
Nevermind the question about the registers, just re-read your post, which I
should've done in the first place :)

Thanks

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

[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

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

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

--- Comment #10 from Lucas Kannebley Tavares  ---
Hi Jerome, thanks for the tips.

Well, I followed the next error
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing CC68 (len 72,
WS 0, PS 0) @ 0xCC97

Down to the test in 0x2f on 0xcc68.
command_table  cc68  #2c  (UpdateCRTC_DoubleBufferRegisters):
...
  0027: 5420b51b  CLEAR  reg[1bb5]  [...X]
  002b: 5420bd1b  CLEAR  reg[1bbd]  [...X]
  002f: 4a25b61b01TEST   reg[1bb6]  [...X]  <-  01

I have a question here: how do I determine what are these registers? I couldn't
match 1bb6 to anything on the radeon driver code, so I suppose that's somewhere
else... or is there some other way to read that?

Anyway, I backtracked that code back to this call on atombios_crtc.c:

static void atombios_lock_crtc(struct drm_crtc *crtc, int lock)
{
...
int index =
GetIndexIntoMasterTable(COMMAND, UpdateCRTC_DoubleBufferRegisters);
...
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *));
}

which could've come from either of these:
static void atombios_crtc_prepare(struct drm_crtc *crtc)
static void atombios_crtc_commit(struct drm_crtc *crtc)

Since those are callbacks registered as helper funcs, and I'm not sure of their
semantics, I ended up getting stuck :) 

static const struct drm_crtc_helper_funcs atombios_helper_funcs = {
.prepare = atombios_crtc_prepare,
.commit = atombios_crtc_commit,

Any ideas here?

Thanks! :)

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

[Bug 60503] New: [r300g] Unigine Heaven 3.0: all objects are black

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

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

  Priority: medium
Bug ID: 60503
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [r300g] Unigine Heaven 3.0: all objects are black
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pavel.ondracka at email.cz
   URL: http://unigine.com/products/heaven/download/
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r300
   Product: Mesa

All object in the 3.0 Heaven version are completely black... this seems to be
the cause:
r300 FP: Compiler Error:
Rewrite of inst 4 failed Can't allocate source for Inst 36 src_type=1
new_index=1 new_mask=4
Using a dummy shader instead.

Full RADEON_DEBUG=fp log attached.

This may be a hardware limitation, however Heaven 2.1 version works fine, so
maybe just a bug in the shader compiler.

GPU: RV530
Mesa: b681ed6ac970e061e9dbe7309bb69b3a947ae62d
Kernel: 3.6.11-1.fc17.i686

-- 
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/20130208/88058de9/attachment.html>

[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 15:28, Marcus Lorentzon wrote:

> When we do that we stop->setup->start during blanking. So our "DSS" is
> optimized to be able to do that without getting blocked. All DSI video
> mode panels (and DPI) products we have done so far have not had any
> issue with that (as long as DSI HS clock is set to continuous). I think
> this approach is less platform dependant, as long as there is no SoC
> that take more than a blanking period to reconfigure.

So do you stop, setup and start the link with CPU, and this has to be
happen during blanking? Isn't that prone to errors? Or did you mean that
the hardware handles that automatically?

In OMAP DSS there are so called shadow registers, that can be programmed
at any time. The you set a bit (GO bit), which tells the hardware to
take the new settings into use at the next vblank.

[Bug 35861] [r300g] Unigine Tropics: whiter triangle between center of the screen and horizon

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

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

Pavel Ondra?ka  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---
Summary|[r300g] Oilrush: whiter |[r300g] Unigine Tropics:
   |triangle between center of  |whiter triangle between
   |the screen and horizon  |center of the screen and
   ||horizon

--- Comment #7 from Pavel Ondra?ka  ---
(In reply to comment #6)
> Oilrush require at least ATI Radeon HD2600 so maybe this is the reason of
> this corruption?

I can reproduce this even with Unigine Tropics 1.3 which supports opengl 2.1
and hence also r500 cards, reopening.

-- 
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/20130208/32c34064/attachment.html>

[RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
> On 2013-02-08 15:28, Marcus Lorentzon wrote:
>
>> When we do that we stop->setup->start during blanking. So our "DSS" is
>> optimized to be able to do that without getting blocked. All DSI video
>> mode panels (and DPI) products we have done so far have not had any
>> issue with that (as long as DSI HS clock is set to continuous). I think
>> this approach is less platform dependant, as long as there is no SoC
>> that take more than a blanking period to reconfigure.
> So do you stop, setup and start the link with CPU, and this has to be
> happen during blanking? Isn't that prone to errors? Or did you mean that
> the hardware handles that automatically?
>
> In OMAP DSS there are so called shadow registers, that can be programmed
> at any time. The you set a bit (GO bit), which tells the hardware to
> take the new settings into use at the next vblank.
>
>  From DSI driver's perspective the link is never stopped when
> reconfiguring the video timings. However, many other settings have to be
> configured when the link is disabled.

Yeah, you lucky guys with the GO bit ;). No, we actually do CPU 
stop,setup,start. But since it is video mode, master is driving the sync 
so it is not a hard deadline. It is enough to restart before pixels 
start to degrade. On an LCD that is not so much time, but on an OLED it 
could be 10 secs :). Anyway, we have had several mass products with this 
soft solution and it has worked well.
> In OMAP you can configure the DSI pins quite freely. We have the
> following struct:
>
> struct omap_dsi_pin_config {
>   int num_pins;
>   /*
>* pin numbers in the following order:
>* clk+, clk-
>* data1+, data1-
>* data2+, data2-
>* ...
>*/
>   int pins[OMAP_DSS_MAX_DSI_PINS];
> };
>
>> I think it still is OMAP specifics and doesn't belong in the panel
>> drivers any longer. If you revisit this requirement in the CDF context
>> where DSI ifc parameters should describe how to interface with a panel
>> outside the SoC, there can't really be any dependencies on SoC internal
>> routing. As you say, this is inside pinmux, so how can that affect the
>> SoC external interface? I would suggest moving this to dispc-dsilink DT
>> settings that are activated on dsilink->enable/disable. At least that is
>> how I plan to solve similar STE SoC specific DSI config settings that
>> are not really CDF panel generic, like some DPhy trim settings. They do
>> depend on the panel and clock speed, but they are more product specific
>> than panel driver specific. Then if there are these type of settings
>> that every SoC have, then we could look at standardize those. But for
>> starters I would try to keep it in product/board-DT per DSI link. So we
>> should try to differentiate between DSI host and slave bus params and
>> keep slave params in panel driver.
> Ok, I think I was being a bit vague here. I explained the OMAP DSI
> routing not because I meant that this API is specific to that, but
> because it explains why this kind of routing info is needed, and a
> bitmask is not enough.
>
> If you look at the omap_dsi_pin_config struct, there's nothing OMAP
> specific there (except the names =). All it tells is that this device
> uses N DSI pins, and the device's clk+ function should be connected to
> pin X on the DSI master, clk- should be connected to pin Y, etc. X and Y
> are integers, and what they mean is specific to the DSI master.
>
> When the DSI master is OMAP's DSI, the OMAP DSI driver does the pin
> configuration as I explained. When the DSI master is something else,
> say, a DSI bridge, it does whatever it needs to do (which could be
> nothing) to assign a particular DSI function to a pin.
>
I understand, but removing the omap prefix doesn't mean it has to go in 
the panel slave port/bus settings. I still can't see why this should be 
configuration on the panel driver and not the DSI master driver. Number 
of pins might be useful since you might start with one lane and then 
activate the rest. But partial muxing (pre pinmux) doesn't seem to be 
something the panel should control or know anything about. Sounds like 
normal platform/DT data per product/board.

/BR
/Marcus

[PATCH 3/3] modetest: Add a command line parameter to select the driver

[Jani Nikula]

On Fri, 08 Feb 2013, Laurent Pinchart  
wrote:
> If the -M parameter is specific, modetest will use the requested device
> name instead of trying its builtin list of device names.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  tests/modetest/modetest.c | 34 +++---
>  1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 34457e2..b6298fc 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -908,6 +908,9 @@ void usage(char *name)
>   fprintf(stderr, "\t-s [@]:[@]\tset 
> a mode\n");
>   fprintf(stderr, "\t-v\ttest vsynced page flipping\n");
>  
> + fprintf(stderr, "\n Generic options:\n\n");
> + fprintf(stderr, "\t-M module\tuse the given driver\n");
> +
>   fprintf(stderr, "\n\tDefault is to dump all info.\n");
>   exit(0);
>  }
> @@ -935,7 +938,7 @@ static int page_flipping_supported(void)
>  #endif
>  }
>  
> -static char optstr[] = "cefmP:ps:v";
> +static char optstr[] = "cefM:mP:ps:v";
>  
>  int main(int argc, char **argv)
>  {
> @@ -943,6 +946,7 @@ int main(int argc, char **argv)
>   int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
> 0;
>   int test_vsync = 0;
>   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "omapdrm", 
> "exynos" };
> + char *module = NULL;
>   unsigned int i;
>   int count = 0, plane_count = 0;
>   struct connector con_args[2];
> @@ -960,6 +964,9 @@ int main(int argc, char **argv)
>   case 'f':
>   framebuffers = 1;
>   break;
> + case 'M':
> + module = optarg;
> + break;
>   case 'm':
>   modes = 1;
>   break;
> @@ -989,14 +996,27 @@ int main(int argc, char **argv)
>   if (argc == 1)
>   encoders = connectors = crtcs = planes = modes = framebuffers = 
> 1;
>  
> - for (i = 0; i < ARRAY_SIZE(modules); i++) {
> - printf("trying to load module %s...", modules[i]);
> + if (module) {
>   fd = drmOpen(modules[i], NULL);

If this worked for you, I presume you have some uncommitted changes in
your tree. ;) The compiler should cry about uninitialized use of i too.

fd = drmOpen(module, NULL); ?

>   if (fd < 0) {
> - printf("failed.\n");
> - } else {
> - printf("success.\n");
> - break;
> + printf("failed to open device '%s'.\n", module);
> + return 1;
> + }
> + } else {
> + for (i = 0; i < ARRAY_SIZE(modules); i++) {
> + printf("trying to open device '%s'...", modules[i]);
> + fd = drmOpen(modules[i], NULL);
> + if (fd < 0) {
> + printf("failed.\n");
> + } else {
> + printf("success.\n");
> + break;
> + }
> + }
> +
> + if (fd < 0) {
> + printf("no device found.\n", module);

Extra param to printf.


BR,
Jani.

> + return 1;
>   }
>   }
>  
> -- 
> 1.7.12.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60439] Suspend/resume broken for cayman since kernel >=3.7.0 (maybe rc too)

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

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

--- Comment #4 from Harald Judt  ---
I will bisect the week after the next, before I will not have access to that
machine. I'd rather avoid bisecting standby/resume problems too much because
that could possibly cause data loss, and it is not possible to do in a VM.

BTW: I do not have such issues on a laptop with a ATI RV620 [Mobility Radeon HD
3400 Series], so this only seems to affect cayman.

-- 
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/20130208/070e0215/attachment.html>

[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

On 2013-02-08 14:40, Marcus Lorentzon wrote:

> I agree, but I think it should be
> setup->enable->video_on->video_off->disable->setup->...
> I don't think there is any interface parameters that should be changed
> while link is enabled. And if there are, they should be identified and
> split out into a separate operation.

Hmm. At least on OMAP and DSI video mode, it is possible to change at
least timings on the fly. But yes, generally the link has to be disabled
first before changing any parameters.

>> In OMAP you can configure the DSI pins quite freely. We have the
>> following struct:
>>
>> struct omap_dsi_pin_config {
>> int num_pins;
>> /*
>>  * pin numbers in the following order:
>>  * clk+, clk-
>>  * data1+, data1-
>>  * data2+, data2-
>>  * ...
>>  */
>> int pins[OMAP_DSS_MAX_DSI_PINS];
>> };
>>
> Do you reroute after boot? Or is this just "board/product setup". We
> have some pinmuxing as well and DPhy sharing, but we have never used it
> after init/boot. If not runtime, I think this could be put in DT config
> for product instead of under dynamic control from panel.

The pin config with the struct above is done later, when the panel
driver configures the DSI bus. So in OMAP we have two distinct things
that need to be configured:

- The actual pin muxing, i.e. selecting the functions for pin N on the
OMAP package. The functions for a single pin could be for example GPIO
70, DSI DX0, UART1_CTS, etc. This is normally done once during board init.

- DSI pin configuration in the display subsystem. This is used to map
the pins to DSI functions. I.e. DSI DX0 pin is mapped to DATA1+. This is
done by the DSS driver, when the panel driver gives it the parameters.

So the first muxing basically assigns the pin to DSI in general, and
then DSI will internally route the pin to a an actual DSI function.

Whether the muxing needs to changed during runtime... I'm not sure. On
OMAP the DSI pin config also tells how many lanes are used. So if a DSI
panel would first want to use only one lane, and later change it to n
lanes, we'd need this kind of function.

I think it conceptually fits better if the pin config data is passed to
the panel via DT data, and the panel then gives the config to the DSI
master. It's just a part of the DSI bus parameters, like, say, clock
speed or whether to use HS or LP. That way the DT node for the panel
contains the information about the panel. (versus having pin config data
in the DSI master, in which case the DSI master's node contains data
about a specific DSI panel).

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130208/7f7cd046/attachment.pgp>

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

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

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

Jerome Glisse  changed:

   What|Removed |Added

  Attachment #74381|0   |1
is obsolete||

--- Comment #30 from Jerome Glisse  ---
Created attachment 74433
  --> https://bugs.freedesktop.org/attachment.cgi?id=74433=edit
Kernel fix

This one apply against Linus master

-- 
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/20130208/a4bdeeda/attachment.html>

[GMA500] Valid VCO frequency range on GMA500 platform?

["David Müller (ELSOFT AG)"]

Hello

I have a problem using a 1024x768 Eizo Monitor attached by DVI-D to a
system with GMA500 based graphics and running under Linux-3.7.

As soon as the GMA500 driver is taking over control, the refresh
rate raises to 64.5Hz and the monitor reports a "signal error".

For me i looks like the GMA500 driver is reprogramming the VCO to a too
high dot clock. If i lower the "I9XX_VCO_MIN" value to 130,
everything is fine.

Is the "I9XX_VCO_MIN" value used in the GMA500 driver correct?


Dave

[RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 02:04 PM, Tomi Valkeinen wrote:
> On 2013-02-08 14:40, Marcus Lorentzon wrote:
>
>> I agree, but I think it should be
>> setup->enable->video_on->video_off->disable->setup->...
>> I don't think there is any interface parameters that should be changed
>> while link is enabled. And if there are, they should be identified and
>> split out into a separate operation.
> Hmm. At least on OMAP and DSI video mode, it is possible to change at
> least timings on the fly. But yes, generally the link has to be disabled
> first before changing any parameters.

When we do that we stop->setup->start during blanking. So our "DSS" is 
optimized to be able to do that without getting blocked. All DSI video 
mode panels (and DPI) products we have done so far have not had any 
issue with that (as long as DSI HS clock is set to continuous). I think 
this approach is less platform dependant, as long as there is no SoC 
that take more than a blanking period to reconfigure.
>>> In OMAP you can configure the DSI pins quite freely. We have the
>>> following struct:
>>>
>>> struct omap_dsi_pin_config {
>>>  int num_pins;
>>>  /*
>>>   * pin numbers in the following order:
>>>   * clk+, clk-
>>>   * data1+, data1-
>>>   * data2+, data2-
>>>   * ...
>>>   */
>>>  int pins[OMAP_DSS_MAX_DSI_PINS];
>>> };
>>>
>> Do you reroute after boot? Or is this just "board/product setup". We
>> have some pinmuxing as well and DPhy sharing, but we have never used it
>> after init/boot. If not runtime, I think this could be put in DT config
>> for product instead of under dynamic control from panel.
> The pin config with the struct above is done later, when the panel
> driver configures the DSI bus. So in OMAP we have two distinct things
> that need to be configured:
>
> - The actual pin muxing, i.e. selecting the functions for pin N on the
> OMAP package. The functions for a single pin could be for example GPIO
> 70, DSI DX0, UART1_CTS, etc. This is normally done once during board init.
>
> - DSI pin configuration in the display subsystem. This is used to map
> the pins to DSI functions. I.e. DSI DX0 pin is mapped to DATA1+. This is
> done by the DSS driver, when the panel driver gives it the parameters.
>
> So the first muxing basically assigns the pin to DSI in general, and
> then DSI will internally route the pin to a an actual DSI function.
>
> Whether the muxing needs to changed during runtime... I'm not sure. On
> OMAP the DSI pin config also tells how many lanes are used. So if a DSI
> panel would first want to use only one lane, and later change it to n
> lanes, we'd need this kind of function.
>
> I think it conceptually fits better if the pin config data is passed to
> the panel via DT data, and the panel then gives the config to the DSI
> master. It's just a part of the DSI bus parameters, like, say, clock
> speed or whether to use HS or LP. That way the DT node for the panel
> contains the information about the panel. (versus having pin config data
> in the DSI master, in which case the DSI master's node contains data
> about a specific DSI panel).
>
I think it still is OMAP specifics and doesn't belong in the panel 
drivers any longer. If you revisit this requirement in the CDF context 
where DSI ifc parameters should describe how to interface with a panel 
outside the SoC, there can't really be any dependencies on SoC internal 
routing. As you say, this is inside pinmux, so how can that affect the 
SoC external interface? I would suggest moving this to dispc-dsilink DT 
settings that are activated on dsilink->enable/disable. At least that is 
how I plan to solve similar STE SoC specific DSI config settings that 
are not really CDF panel generic, like some DPhy trim settings. They do 
depend on the panel and clock speed, but they are more product specific 
than panel driver specific. Then if there are these type of settings 
that every SoC have, then we could look at standardize those. But for 
starters I would try to keep it in product/board-DT per DSI link. So we 
should try to differentiate between DSI host and slave bus params and 
keep slave params in panel driver.

/BR
/Marcus

[Bug 60439] Suspend/resume broken for cayman since kernel >=3.7.0 (maybe rc too)

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

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

--- Comment #3 from Michel D?nzer  ---
(In reply to comment #2)
> The following commits fall within that range (only one specific to cayman),
> I guess I can skip some of them:

Please don't. In the best case, you save a couple of tests, in the worst case
the bisection result is invalid and you have to start over again.

-- 
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/20130208/70848194/attachment.html>

[PATCH 3/3] modetest: Add a command line parameter to select the driver

[Laurent Pinchart]

If the -M parameter is specific, modetest will use the requested device
name instead of trying its builtin list of device names.

Signed-off-by: Laurent Pinchart 
---
 tests/modetest/modetest.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 34457e2..b6298fc 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -908,6 +908,9 @@ void usage(char *name)
fprintf(stderr, "\t-s [@]:[@]\tset 
a mode\n");
fprintf(stderr, "\t-v\ttest vsynced page flipping\n");

+   fprintf(stderr, "\n Generic options:\n\n");
+   fprintf(stderr, "\t-M module\tuse the given driver\n");
+
fprintf(stderr, "\n\tDefault is to dump all info.\n");
exit(0);
 }
@@ -935,7 +938,7 @@ static int page_flipping_supported(void)
 #endif
 }

-static char optstr[] = "cefmP:ps:v";
+static char optstr[] = "cefM:mP:ps:v";

 int main(int argc, char **argv)
 {
@@ -943,6 +946,7 @@ int main(int argc, char **argv)
int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
0;
int test_vsync = 0;
char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "omapdrm", 
"exynos" };
+   char *module = NULL;
unsigned int i;
int count = 0, plane_count = 0;
struct connector con_args[2];
@@ -960,6 +964,9 @@ int main(int argc, char **argv)
case 'f':
framebuffers = 1;
break;
+   case 'M':
+   module = optarg;
+   break;
case 'm':
modes = 1;
break;
@@ -989,14 +996,27 @@ int main(int argc, char **argv)
if (argc == 1)
encoders = connectors = crtcs = planes = modes = framebuffers = 
1;

-   for (i = 0; i < ARRAY_SIZE(modules); i++) {
-   printf("trying to load module %s...", modules[i]);
+   if (module) {
fd = drmOpen(modules[i], NULL);
if (fd < 0) {
-   printf("failed.\n");
-   } else {
-   printf("success.\n");
-   break;
+   printf("failed to open device '%s'.\n", module);
+   return 1;
+   }
+   } else {
+   for (i = 0; i < ARRAY_SIZE(modules); i++) {
+   printf("trying to open device '%s'...", modules[i]);
+   fd = drmOpen(modules[i], NULL);
+   if (fd < 0) {
+   printf("failed.\n");
+   } else {
+   printf("success.\n");
+   break;
+   }
+   }
+
+   if (fd < 0) {
+   printf("no device found.\n", module);
+   return 1;
}
}

-- 
1.7.12.4

[PATCH 1/3] modetest: Remove extern declarations of opt(arg|ind|err|opt)

[Laurent Pinchart]

Those variables are declared in unistd.h, there's no need to redeclare
them here.

Signed-off-by: Laurent Pinchart 
---
 tests/modetest/modetest.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c91bb9d..489918e 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -835,8 +835,6 @@ set_mode(struct connector *c, int count, struct plane *p, 
int plane_count,
kms_destroy();
 }

-extern char *optarg;
-extern int optind, opterr, optopt;
 static char optstr[] = "ecpmfs:P:v";

 #define min(a, b)  ((a) < (b) ? (a) : (b))
-- 
1.7.12.4

[PATCH 0/3] modetest: Allow selecting a driver manually

[Laurent Pinchart]

Hello,

Here's a small patch set that adds an argument to the modetest command line to
specify the driver name instead of using the builtin list of drivers. This is
particularly handy during development of new DRM/KMS drivers.

Laurent Pinchart (3):
  modetest: Remove extern declarations of opt(arg|ind|err|opt)
  modetest: Sort command line arguments
  modetest: Add a command line parameter to select the driver

 tests/modetest/modetest.c | 81 ++-
 1 file changed, 52 insertions(+), 29 deletions(-)

-- 
Regards,

Laurent Pinchart

[RFC v2 0/5] Common Display Framework

[Marcus Lorentzon]

On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:
> On 2013-02-04 12:05, Marcus Lorentzon wrote:
>
>> As discussed at FOSDEM I will give DSI bus with full feature set a
>> try.
> Please do, but as a reminder I want to raise the issues I see with a DSI
> bus:
>
> - A device can be a child of only one bus. So if DSI is used only for
> video, the device is a child of, say, i2c bus, and thus there's no DSI
> bus. How to configure and use DSI in this case?
>
> - If DSI is used for both control and video, we have two separate APIs
> for the bus. What I mean here is that for the video-only case above, we
> need a video-only-API for DSI. This API should contain all necessary
> methods to configure DSI. But we need similar methods for the control
> API also.
>
> So, I hope you come up with some solution for this, but as I see it,
> it's easily the most simple and clear option to have one video_source
> style entity for the DSI bus itself, which is used for both control and
> video.
>
>
Thanks, it is not that I'm totally against the video source stuff. And I 
share your concerns, none of the solutions are perfect. It just doesn't 
feel right to create this dummy source "device" without investigating 
the DSI bus route. But I will try to write up some history/problem 
description and ask Greg KH for guidance. If he has a strong opinion 
either way, there is not much more to discuss ;)

/BR
/Marcus

[RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 2013-02-03 21:17, Tomasz Figa wrote:
>> Hi Laurent,
>>
>> On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
>>> Hi Tomasz,
>>>
>>> Thank you for your RFC.
>>>
>>> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
 Changes done to Tomi's edition of CDF:
   - Replaced set_operation_mode, set_pixel_format and set_size video
   source>
 operations with get_params display entity operation, as it was
 originally in Laurent's version.
 
 We have discussed this matter on the mailing list and decided that
 it
 would be better to have the source ask the sink for its parameter
 structure and do whatever appropriate with it.
>>> Could you briefly outline the rationale behind this ?
>> Display interfaces may be described by an arbitrary number of parameters.
>> Some will require just video timings, others like DSI will require a
>> significant number of additional bus-specific ones.
>>
>> Separating all the parameters (all of which are usually set at the same
>> time) into a lot of ops setting single parameter will just add unnecessary
>> complexity.
> I have nothing against combining the parameters that way. I think the
> important thing here is just that we have to allow changing of the
> parameters, whenever the display device needs that. So the bus
> parameters cannot be a one time constant setting.

I agree, but I think it should be 
setup->enable->video_on->video_off->disable->setup->...
I don't think there is any interface parameters that should be changed 
while link is enabled. And if there are, they should be identified and 
split out into a separate operation.
>>> I'm wondering whether get_params could limit us if a device needs to
>>> modify parameters at runtime. For instance a panel might need to change
>>> clock frequencies or number of used data lane depending on various
>>> runtime conditions. I don't have a real use case here, so it might just
>>> be a bit of over-engineering.
>> Hmm, isn't it in the opposite direction (the user requests the display
>> interface to change, for example, video mode, which in turn reconfigures
>> the link and requests the panel to update its settings)?
> Well, now, that's the question.
>
> Let's consider a simplified case with DSI output from the SoC, and a DSI
> panel. If the panel is a rather simple one, you could well call a method
> in the API in the DSI output driver, which would do necessary
> configuration and inform the panel driver to do any configuration it
> needs to do, based on the parameters.
>
> However, in my experience display devices, DSI devices in particular,
> are often quite "interesting". If the control of the operation in
> question is in the DSI output side, we are limited about what kind of
> DSI panels we can use, as the DSI output driver has to know all the
> tricks needed to make the panels work.
>
> I'm having hard time trying to explain this, so let's try an example.
> Consider the initial powering up of the bus. If the DSI output driver is
> in control, something like the following probably happens:
>
> - output driver asks for the parameters from the panel driver
> - output driver programs the DSI output according to these parameters
> - output driver informs the panel that the bus is now up and running
>
> Then consider a totally invented case, but which perhaps describes the
> problem with the above approach: The DSI panel requires the DSI bus
> first to be started in HS mode, but with a certain predefined bus speed,
> and only one lane used. This predefined bus setup is used to send
> configuration commands to the panel hardware, and only after that can
> you reconfigure the bus with proper speed and lanes.
>
> That kind of thing is a bit difficult to manage with the DSI output
> driver is in control. However, if the DSI panel driver is in control,
> it's simple:
>
> - panel driver calls config methods in the DSI output driver, setting
> the predefined speed and one lane
> - panel driver sends configuration commands to the panel
> - panel driver calls config methods in the DSI output driver, setting
> the final bus config

We have similar use cases and so I agree (and have implemented) the 
latter approach where panel driver is in control. I think it is 
important to separate the panel calling dispc (which it should not) from 
panel calling bus/videosource ops. Compare to I2C, no one would expect 
panel to call dispc to do I2C ops, instead panel call bus ops directly 
in response to the CDF ops request panel is running.
 5. Mask of used data lanes (each bit represents single lane).
>>>  From my experience with MIPI CSI (Camera Serial Interface, similar to
>>> DSI) some transceivers can reroute data lanes internally. Is that true
>>> for DSI as well ? In that case we would need a list of data lanes, not
>>> just a mask.
>> Hmm, I don't remember at the moment, will have to look to 

[RFC PATCH 0/4] Common Display Framework-TF

[Tomi Valkeinen]

Hi,

On 2013-02-03 21:17, Tomasz Figa wrote:
> Hi Laurent,
> 
> On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
>> Hi Tomasz,
>>
>> Thank you for your RFC.
>>
>> On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:

>>> Changes done to Tomi's edition of CDF:
>>>  - Replaced set_operation_mode, set_pixel_format and set_size video
>>>  source>  
>>>operations with get_params display entity operation, as it was
>>>originally in Laurent's version.
>>>
>>>We have discussed this matter on the mailing list and decided that
>>>it
>>>would be better to have the source ask the sink for its parameter
>>>structure and do whatever appropriate with it.
>>
>> Could you briefly outline the rationale behind this ?
> 
> Display interfaces may be described by an arbitrary number of parameters. 
> Some will require just video timings, others like DSI will require a 
> significant number of additional bus-specific ones.
> 
> Separating all the parameters (all of which are usually set at the same 
> time) into a lot of ops setting single parameter will just add unnecessary 
> complexity.

I have nothing against combining the parameters that way. I think the
important thing here is just that we have to allow changing of the
parameters, whenever the display device needs that. So the bus
parameters cannot be a one time constant setting.

>> I'm wondering whether get_params could limit us if a device needs to
>> modify parameters at runtime. For instance a panel might need to change
>> clock frequencies or number of used data lane depending on various
>> runtime conditions. I don't have a real use case here, so it might just
>> be a bit of over-engineering.
> 
> Hmm, isn't it in the opposite direction (the user requests the display 
> interface to change, for example, video mode, which in turn reconfigures 
> the link and requests the panel to update its settings)?

Well, now, that's the question.

Let's consider a simplified case with DSI output from the SoC, and a DSI
panel. If the panel is a rather simple one, you could well call a method
in the API in the DSI output driver, which would do necessary
configuration and inform the panel driver to do any configuration it
needs to do, based on the parameters.

However, in my experience display devices, DSI devices in particular,
are often quite "interesting". If the control of the operation in
question is in the DSI output side, we are limited about what kind of
DSI panels we can use, as the DSI output driver has to know all the
tricks needed to make the panels work.

I'm having hard time trying to explain this, so let's try an example.
Consider the initial powering up of the bus. If the DSI output driver is
in control, something like the following probably happens:

- output driver asks for the parameters from the panel driver
- output driver programs the DSI output according to these parameters
- output driver informs the panel that the bus is now up and running

Then consider a totally invented case, but which perhaps describes the
problem with the above approach: The DSI panel requires the DSI bus
first to be started in HS mode, but with a certain predefined bus speed,
and only one lane used. This predefined bus setup is used to send
configuration commands to the panel hardware, and only after that can
you reconfigure the bus with proper speed and lanes.

That kind of thing is a bit difficult to manage with the DSI output
driver is in control. However, if the DSI panel driver is in control,
it's simple:

- panel driver calls config methods in the DSI output driver, setting
the predefined speed and one lane
- panel driver sends configuration commands to the panel
- panel driver calls config methods in the DSI output driver, setting
the final bus config

>>>5. Mask of used data lanes (each bit represents single lane).
>>
>> From my experience with MIPI CSI (Camera Serial Interface, similar to
>> DSI) some transceivers can reroute data lanes internally. Is that true
>> for DSI as well ? In that case we would need a list of data lanes, not
>> just a mask.
> 
> Hmm, I don't remember at the moment, will have to look to the 
> specification. Exynos DSI master doesn't support such feature.

In OMAP you can configure the DSI pins quite freely. We have the
following struct:

struct omap_dsi_pin_config {
int num_pins;
/*
 * pin numbers in the following order:
 * clk+, clk-
 * data1+, data1-
 * data2+, data2-
 * ...
 */
int pins[OMAP_DSS_MAX_DSI_PINS];
};

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130208/9ce90927/attachment.pgp>

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

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

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

--- Comment #29 from Paul Heldens  ---
3.8-rc6 Here neither, only chunk 1 with 25x lines fuz

-- 
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/20130208/f66152b2/attachment.html>

[Bug 30167] Heroes of Newerth: Setting shader quality to medium results in corrupt rendering

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

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

--- Comment #24 from Pavel Ondra?ka  ---
This seems to be fixed in the latest mesa git, however I didn't test all the
different settings mentioned in Comment 16. Sven can you confirm this is indeed
fixed?

-- 
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/20130208/a0e333e5/attachment-0001.html>

[RFC v2 0/5] Common Display Framework

[Tomi Valkeinen]

On 2013-02-04 12:05, Marcus Lorentzon wrote:

> As discussed at FOSDEM I will give DSI bus with full feature set a
> try.

Please do, but as a reminder I want to raise the issues I see with a DSI
bus:

- A device can be a child of only one bus. So if DSI is used only for
video, the device is a child of, say, i2c bus, and thus there's no DSI
bus. How to configure and use DSI in this case?

- If DSI is used for both control and video, we have two separate APIs
for the bus. What I mean here is that for the video-only case above, we
need a video-only-API for DSI. This API should contain all necessary
methods to configure DSI. But we need similar methods for the control
API also.

So, I hope you come up with some solution for this, but as I see it,
it's easily the most simple and clear option to have one video_source
style entity for the DSI bus itself, which is used for both control and
video.

 Tomi


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

[PATCH] drm: Use names of ioctls in debug traces

[Dave Airlie]

On Mon, Jan 28, 2013 at 10:39 PM, Chris Cummins
 wrote:
> The intention here is to make the output of dmesg with full verbosity a
> bit easier for a human to parse. This commit transforms:
>
I like this a lot, but I need a Signed-off-by on patches as per
Documentation/SubmittingPatches

Sorry it took me so long to read it :-)

Dave.

[Bug 46006] [r300g, bisected] piglit glsl-max-varyings fails

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

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

Pavel Ondra?ka  changed:

   What|Removed |Added

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

--- Comment #1 from Pavel Ondra?ka  ---
Fixed in latest mesa git.

-- 
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/20130208/b657b538/attachment-0001.html>

[Bug 60439] Suspend/resume broken for cayman since kernel >=3.7.0 (maybe rc too)

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

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

--- Comment #2 from Harald Judt  ---
Seems to have been introduced by a change between 3.7-rc1 and 3.7-rc2
(ddffeb8c4d0331..6f0c0580b7). Don't have time to track that further now.
Maybe it doesn't have to do with suspend/resume directly, but is caused by it
as some sort of side-effect?

The following commits fall within that range (only one specific to cayman), I
guess I can skip some of them:

bd6126b - drm: radeon: fix printk format warning (vor 4 Monaten)
8ad33cd - drm/radeon: fix spelling typos in debugging output
0829184 - drm/radeon: Don't destroy I2C Bus Rec in
radeon_ext_tmds_enc_destroy().
3691fee - drm/radeon: check if pcie gen 2 is already enabled (v2)
c1a7ca0 - drm/radeon/cayman: set VM max pfn at MC init
13e55c3 - drm/radeon: separate pt alloc from lru add
d72d43c - drm/radeon: don't add the IB pool to all VMs v2
90a51a3 - drm/radeon: allocate page tables on demand v4
23d4f1f - drm/radeon: update comments to clarify VM setup (v2)
29dbe3b - drm/radeon: allocate PPLLs from low to high
cd23492 - drm/radeon: fix compilation with backlight disabled
a187193 - drm/radeon: use %zu for formatting size_t

-- 
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/20130208/632ab95c/attachment.html>

radeon causing sleeping function called from invalid context

[Sergey Senozhatsky]

On (02/07/13 22:53), Andreas Bombe wrote:
> On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote:
> > On (01/12/13 20:27), Dave Jones wrote:
> > > BUG: sleeping function called from invalid context at mm/slub.c:925
> > > in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg
> > > INFO: lockdep is turned off.
> > > Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49
> > > Call Trace:
> > >  [] __might_sleep+0x141/0x200
> > >  [] kmem_cache_alloc_trace+0x4b/0x2a0
> > >  [] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm]
> > >  [] radeon_move_blit.isra.4+0xf8/0x160 [radeon]
> > >  [] radeon_bo_move+0xb0/0x1f0 [radeon]
> > >  [] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm]
> > >  [] ? get_parent_ip+0x11/0x50
> > >  [] ttm_bo_move_buffer+0x127/0x140 [ttm]
> > >  [] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm]
> > >  [] ttm_bo_validate+0xa2/0x120 [ttm]
> > >  [] radeon_bo_list_validate+0x75/0x90 [radeon]
> > >  [] radeon_cs_ioctl+0x582/0x950 [radeon]
> > >  [] drm_ioctl+0x4d3/0x580 [drm]
> > >  [] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon]
> > >  [] do_vfs_ioctl+0x99/0x5a0
> > >  [] ? file_has_perm+0x97/0xb0
> > >  [] ? rcu_eqs_exit+0x65/0xb0
> > >  [] sys_ioctl+0x91/0xb0
> > >  [] tracesys+0xdd/0xe2
> > > 
> > 
> > I see lots of these [mostly from page fault], the following one (quick and 
> > dirty) works for me.
> 
> Is that patch or any other fix being picked up? It's over three weeks
> now and I'm still seeing those BUGs with the latest 3.8-rc.
> 

None that I'm aware of.


-ss

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

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

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

--- Comment #28 from Andy Furniss  ---
(In reply to comment #27)
> Created attachment 74381 [details] [review]
> Kernel fix
> 
> Ok try this kernel patch without and with the mesa patch. This one should
> definitely fix the issue.

Won't apply against 3.8-rc6 or drm fixes for me.

-- 
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/20130208/479ebcf1/attachment.html>

radeon causing sleeping function called from invalid context

[Daniel Vetter]

On Fri, Feb 08, 2013 at 10:47:42AM +0300, Sergey Senozhatsky wrote:
> On (02/07/13 22:53), Andreas Bombe wrote:
> > On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote:
> > > On (01/12/13 20:27), Dave Jones wrote:
> > > > BUG: sleeping function called from invalid context at mm/slub.c:925
> > > > in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg
> > > > INFO: lockdep is turned off.
> > > > Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49
> > > > Call Trace:
> > > >  [] __might_sleep+0x141/0x200
> > > >  [] kmem_cache_alloc_trace+0x4b/0x2a0
> > > >  [] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm]
> > > >  [] radeon_move_blit.isra.4+0xf8/0x160 [radeon]
> > > >  [] radeon_bo_move+0xb0/0x1f0 [radeon]
> > > >  [] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm]
> > > >  [] ? get_parent_ip+0x11/0x50
> > > >  [] ttm_bo_move_buffer+0x127/0x140 [ttm]
> > > >  [] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm]
> > > >  [] ttm_bo_validate+0xa2/0x120 [ttm]
> > > >  [] radeon_bo_list_validate+0x75/0x90 [radeon]
> > > >  [] radeon_cs_ioctl+0x582/0x950 [radeon]
> > > >  [] drm_ioctl+0x4d3/0x580 [drm]
> > > >  [] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon]
> > > >  [] do_vfs_ioctl+0x99/0x5a0
> > > >  [] ? file_has_perm+0x97/0xb0
> > > >  [] ? rcu_eqs_exit+0x65/0xb0
> > > >  [] sys_ioctl+0x91/0xb0
> > > >  [] tracesys+0xdd/0xe2
> > > > 
> > > 
> > > I see lots of these [mostly from page fault], the following one (quick 
> > > and dirty) works for me.
> > 
> > Is that patch or any other fix being picked up? It's over three weeks
> > now and I'm still seeing those BUGs with the latest 3.8-rc.
> > 
> 
> None that I'm aware of.

Either this one

https://patchwork.kernel.org/patch/2094501/

or a bit an older approach here

https://patchwork.kernel.org/patch/1972071/

should fix this.

/me looks at Dave

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

[PATCHv5,RESEND 8/8] drm: tegra: Add gr2d device

[Thierry Reding]

fferent size [-Wint-to-pointer-c
> 
> The problem is that the fields are __u64's and can't be cast directly
> into 32-bit pointers.

Alright.

> >> That's the security firewall. It walks through each submit, and ensures
> >> that each register write that writes an address, goes through the host1x
> >> reloc mechanism. This way user space cannot ask 2D to write to arbitrary
> >> memory locations.
> > 
> > I see. Can this be made more generic? Perhaps adding a table of valid
> > registers to the device and use a generic function to iterate over that
> > instead of having to provide the same function for each client.
> 
> For which one does gcc generate more efficient code? I've thought a
> switch-case statement might get compiled into something more efficient
> than a table lookup.
> 
> But the rest of the code is generic - just the one function which
> compares against known address registers is specific to 2D.

Table lookup should be pretty fast. I wouldn't worry too much about
performance at this stage, though. Readability is more important in my
opinion. A lookup table is a lot more readable and reusable I think. If
it turns out that using a function is actually faster we can always
optimize later.

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/20130208/70802efe/attachment-0001.pgp>

[PATCHv5,RESEND 4/8] gpu: host1x: Add debug support

[Thierry Reding]

On Wed, Feb 06, 2013 at 12:58:19PM -0800, Terje Bergstr?m wrote:
> On 05.02.2013 01:15, Thierry Reding wrote:
> > On Mon, Feb 04, 2013 at 08:41:25PM -0800, Terje Bergstr?m wrote:
> >> This is used by debugfs code to direct to debugfs, and
> >> nvhost_debug_dump() to send via printk.
> > 
> > Yes, that was precisely my point. Why bother providing the same data via
> > several output methods. debugfs is good for showing large amounts of
> > data such as register dumps or a tabular representation of syncpoints
> > for instance.
> > 
> > If, however, you want to interactively show debug information using
> > printk the same format isn't very useful and something more reduced is
> > often better.
> 
> debugfs is there to be able to get a reliable dump of host1x state
> (f.ex. no lines intermixed with other output).
> 
> printk output is there because often we get just UART logs from failure
> cases, and having as much information as possible in the logs speeds up
> debugging.
> 
> Both of them need to output the values of sync points, and the channel
> state. Dumping all of that consists of a lot of code, and I wouldn't
> want to duplicate that for two output formats.

I'm still not convinced, but I think I could live with it. =)

> >> I have another suggestion. In downstream I removed the decoding part and
> >> I just print out a string of hex. That removes quite a bit bunch of code
> >> from kernel. It makes the debug output also more compact.
> > I don't know. I think if you use in-kernel debugging facilities such as
> > debugfs or printk, then the output should be self-explanatory. However I
> > do see the usefulness of having a binary dump that can be decoded in
> > userspace. But I think if we want to go that way we should make that a
> > separate interface. USB provides something like that, which can then be
> > fed to libpcap or wireshark to capture and analyze USB traffic. If done
> > properly you get replay functionality for free. I don't know what infra-
> > structure exists to help with implementing something similar.
> 
> It's not actually binary. I think I misrepresented the suggestion.
> 
> I'm suggesting that we'd display only the contents of command FIFO and
> contents of gathers (i.e. all opcodes) in hex format, not decoded. All
> other text would remain as is, so syncpt values, etc would be readable
> by a glance.
> 
> The user space tool can then take the streams and decode them if needed.
> 
> We've noticed that the decoded opcodes format can be very long and
> sometimes takes a minute to dump out via a slow console. The hex output
> is much more compact and faster to dump.
> 
> Actual tracing or wireshark kind of capability would come via decoding
> the ftrace log. When enabled, everything that is written to the channel,
> is also written to ftrace.

Okay, I'll have to take a closer look at ftrace since I've never used it
before. It sounds like extra infrastructure won't be necessary then.

> >>>> +static void show_channel_word(struct output *o, int *state, int *count,
> >>>> +u32 addr, u32 val, struct host1x_cdma *cdma)
> >>>> +{
> >>>> +static int start_count, dont_print;
> >>>
> >>> What if two processes read debug information at the same time?
> >>
> >> show_channels() acquires cdma.lock, so that shouldn't happen.
> > 
> > Okay. Another solution would be to pass around a debug context which
> > keeps track of the variables. But if we opt for a more involved dump
> > interface as discussed above this will no longer be relevant.
> 
> Actually, debugging process needs cdma.lock, because it goes through the
> cdma queue. Also command FIFO dumping is something that must be done by
> a single thread at a time.
> 
> > Okay. In the context of a channel dump interface this may not be
> > relevant anymore. Can you think of any issue that wouldn't be detectable
> > or debuggable by analyzing a binary dump of the data within a channel?
> > I'm asking because at that point we wouldn't be able to access any of
> > the in-kernel data structures but would have to rely on the data itself
> > for diagnostics. IOMMU virtual addresses won't be available and so on.
> 
> In many cases, looking at syncpt values, and channel state
> (active/waiting on a syncpt, etc) gives an indication on what is the
> current state of hardware. But, very often problems are ripple effects
> on something that happened earlier and the job that caused the problem
> has already been freed and is not visible in the dump.
> 
> To get a full history, we need often need the ftrace log.

So that's already covered. Great!

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/20130208/c70f6b2c/attachment.pgp>

[git pull] drm regression fix

[Dave Airlie]

Hi Linus,

this one fixes a sleep while locked regression that was introduced earlier 
in 3.8.

Dave.

The following changes since commit 6bacaa9ddacb71c691d32c678d37bc59ffc71fac:

  Merge tag 'sound-3.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2013-02-07 08:43:30 
+1100)

are available in the git repository at:


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

for you to fetch changes up to ff7c60c580d9722f820d85c9c58ca55ecc1ee7c4:

  drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try (2013-02-08 
10:44:31 +1000)


Daniel Vetter (1):
  drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try

 drivers/gpu/drm/ttm/ttm_bo_util.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

[Bug 60347] Htile support causes GPU lockup CP stall in Amnesia game

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

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

Alex Deucher  changed:

   What|Removed |Added

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

--- Comment #6 from Alex Deucher  ---


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

-- 
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/20130208/9e0099a4/attachment.html>

[Bug 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||anonymous at dodgeit.com

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

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

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

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

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

--- Comment #54 from Austin Lund  ---
This does seem to be fixed in 3.8 series kernels.  I just tested 3.8-rc6 and
booted fine into radeondrmfb.  I could get the vgaswitcheroo to move between
the integrated and discrete, but I couldn't get the intel console to work (will
have to check my config).

-- 
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/20130208/7f9b3050/attachment.html>

[Bug 60347] Htile support causes GPU lockup CP stall in Amnesia game

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

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

--- Comment #5 from Anonymous Helper  ---
This bug looks like to be a duplicate of 59592.

-- 
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/20130208/f8fee179/attachment.html>

[Bug 60439] Suspend/resume broken for cayman since kernel >=3.7.0 (maybe rc too)

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

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

--- Comment #1 from Alex Deucher  ---
Can you bisect?  I can't think of any commits in particular that would cause an
issue with suspend and resume.

-- 
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/20130208/fbba51de/attachment.html>

Re: radeon causing sleeping function called from invalid context

[Daniel Vetter]

On Fri, Feb 08, 2013 at 10:47:42AM +0300, Sergey Senozhatsky wrote:
 On (02/07/13 22:53), Andreas Bombe wrote:
  On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote:
   On (01/12/13 20:27), Dave Jones wrote:
BUG: sleeping function called from invalid context at mm/slub.c:925
in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg
INFO: lockdep is turned off.
Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49
Call Trace:
 [81087ad1] __might_sleep+0x141/0x200
 [8119eddb] kmem_cache_alloc_trace+0x4b/0x2a0
 [a0083fb3] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm]
 [a00c5418] radeon_move_blit.isra.4+0xf8/0x160 [radeon]
 [a00c5db0] radeon_bo_move+0xb0/0x1f0 [radeon]
 [a00820ed] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm]
 [8108dd51] ? get_parent_ip+0x11/0x50
 [a0083307] ttm_bo_move_buffer+0x127/0x140 [ttm]
 [a008717d] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm]
 [a00833c2] ttm_bo_validate+0xa2/0x120 [ttm]
 [a00c6f45] radeon_bo_list_validate+0x75/0x90 [radeon]
 [a00dca22] radeon_cs_ioctl+0x582/0x950 [radeon]
 [a002e573] drm_ioctl+0x4d3/0x580 [drm]
 [a00dc4a0] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon]
 [811c49f9] do_vfs_ioctl+0x99/0x5a0
 [812cd3d7] ? file_has_perm+0x97/0xb0
 [81103715] ? rcu_eqs_exit+0x65/0xb0
 [811c4f91] sys_ioctl+0x91/0xb0
 [81695ad4] tracesys+0xdd/0xe2

   
   I see lots of these [mostly from page fault], the following one (quick 
   and dirty) works for me.
  
  Is that patch or any other fix being picked up? It's over three weeks
  now and I'm still seeing those BUGs with the latest 3.8-rc.
  
 
 None that I'm aware of.

Either this one

https://patchwork.kernel.org/patch/2094501/

or a bit an older approach here

https://patchwork.kernel.org/patch/1972071/

should fix this.

/me looks at Dave

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeon causing sleeping function called from invalid context

[Andreas Bombe]

On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote:
 On (01/12/13 20:27), Dave Jones wrote:
  BUG: sleeping function called from invalid context at mm/slub.c:925
  in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg
  INFO: lockdep is turned off.
  Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49
  Call Trace:
   [81087ad1] __might_sleep+0x141/0x200
   [8119eddb] kmem_cache_alloc_trace+0x4b/0x2a0
   [a0083fb3] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm]
   [a00c5418] radeon_move_blit.isra.4+0xf8/0x160 [radeon]
   [a00c5db0] radeon_bo_move+0xb0/0x1f0 [radeon]
   [a00820ed] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm]
   [8108dd51] ? get_parent_ip+0x11/0x50
   [a0083307] ttm_bo_move_buffer+0x127/0x140 [ttm]
   [a008717d] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm]
   [a00833c2] ttm_bo_validate+0xa2/0x120 [ttm]
   [a00c6f45] radeon_bo_list_validate+0x75/0x90 [radeon]
   [a00dca22] radeon_cs_ioctl+0x582/0x950 [radeon]
   [a002e573] drm_ioctl+0x4d3/0x580 [drm]
   [a00dc4a0] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon]
   [811c49f9] do_vfs_ioctl+0x99/0x5a0
   [812cd3d7] ? file_has_perm+0x97/0xb0
   [81103715] ? rcu_eqs_exit+0x65/0xb0
   [811c4f91] sys_ioctl+0x91/0xb0
   [81695ad4] tracesys+0xdd/0xe2
  
 
 I see lots of these [mostly from page fault], the following one (quick and 
 dirty) works for me.

Is that patch or any other fix being picked up? It's over three weeks
now and I'm still seeing those BUGs with the latest 3.8-rc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Kuninori Morimoto]

Hi Laurent

   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/mach-shmobile/board-marzen.c | 65 ++
1 file changed, 65 insertions(+)
  
  It is very helpfull if this patch or additional patch has RCAR_DU defconfig
  for marzen
 
 Very good point. I will include that in the next version. Thank you.

Nice !
Thank you

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

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

[bugzilla-daemon]

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

--- Comment #28 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #27)
 Created attachment 74381 [details] [review]
 Kernel fix
 
 Ok try this kernel patch without and with the mesa patch. This one should
 definitely fix the issue.

Won't apply against 3.8-rc6 or drm fixes for me.

-- 
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 60439] Suspend/resume broken for cayman since kernel =3.7.0 (maybe rc too)

[bugzilla-daemon]

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

--- Comment #2 from Harald Judt h.j...@gmx.at ---
Seems to have been introduced by a change between 3.7-rc1 and 3.7-rc2
(ddffeb8c4d0331..6f0c0580b7). Don't have time to track that further now.
Maybe it doesn't have to do with suspend/resume directly, but is caused by it
as some sort of side-effect?

The following commits fall within that range (only one specific to cayman), I
guess I can skip some of them:

bd6126b - drm: radeon: fix printk format warning (vor 4 Monaten)
8ad33cd - drm/radeon: fix spelling typos in debugging output
0829184 - drm/radeon: Don't destroy I2C Bus Rec in
radeon_ext_tmds_enc_destroy().
3691fee - drm/radeon: check if pcie gen 2 is already enabled (v2)
c1a7ca0 - drm/radeon/cayman: set VM max pfn at MC init
13e55c3 - drm/radeon: separate pt alloc from lru add
d72d43c - drm/radeon: don't add the IB pool to all VMs v2
90a51a3 - drm/radeon: allocate page tables on demand v4
23d4f1f - drm/radeon: update comments to clarify VM setup (v2)
29dbe3b - drm/radeon: allocate PPLLs from low to high
cd23492 - drm/radeon: fix compilation with backlight disabledAlex Deucher
a187193 - drm/radeon: use %zu for formatting size_t

-- 
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 46006] [r300g, bisected] piglit glsl-max-varyings fails

[bugzilla-daemon]

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

Pavel Ondračka pavel.ondra...@email.cz changed:

   What|Removed |Added

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

--- Comment #1 from Pavel Ondračka pavel.ondra...@email.cz ---
Fixed in latest mesa git.

-- 
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

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 12:40 PM, Tomi Valkeinen wrote:

Hi,

On 2013-02-03 21:17, Tomasz Figa wrote:

Hi Laurent,

On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:

Hi Tomasz,

Thank you for your RFC.

On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:

Changes done to Tomi's edition of CDF:
  - Replaced set_operation_mode, set_pixel_format and set_size video
  source
operations with get_params display entity operation, as it was
originally in Laurent's version.

We have discussed this matter on the mailing list and decided that

it
would be better to have the source ask the sink for its parameter
structure and do whatever appropriate with it.

Could you briefly outline the rationale behind this ?

Display interfaces may be described by an arbitrary number of parameters.
Some will require just video timings, others like DSI will require a
significant number of additional bus-specific ones.

Separating all the parameters (all of which are usually set at the same
time) into a lot of ops setting single parameter will just add unnecessary
complexity.

I have nothing against combining the parameters that way. I think the
important thing here is just that we have to allow changing of the
parameters, whenever the display device needs that. So the bus
parameters cannot be a one time constant setting.


I agree, but I think it should be 
setup-enable-video_on-video_off-disable-setup-...
I don't think there is any interface parameters that should be changed 
while link is enabled. And if there are, they should be identified and 
split out into a separate operation.

I'm wondering whether get_params could limit us if a device needs to
modify parameters at runtime. For instance a panel might need to change
clock frequencies or number of used data lane depending on various
runtime conditions. I don't have a real use case here, so it might just
be a bit of over-engineering.

Hmm, isn't it in the opposite direction (the user requests the display
interface to change, for example, video mode, which in turn reconfigures
the link and requests the panel to update its settings)?

Well, now, that's the question.

Let's consider a simplified case with DSI output from the SoC, and a DSI
panel. If the panel is a rather simple one, you could well call a method
in the API in the DSI output driver, which would do necessary
configuration and inform the panel driver to do any configuration it
needs to do, based on the parameters.

However, in my experience display devices, DSI devices in particular,
are often quite interesting. If the control of the operation in
question is in the DSI output side, we are limited about what kind of
DSI panels we can use, as the DSI output driver has to know all the
tricks needed to make the panels work.

I'm having hard time trying to explain this, so let's try an example.
Consider the initial powering up of the bus. If the DSI output driver is
in control, something like the following probably happens:

- output driver asks for the parameters from the panel driver
- output driver programs the DSI output according to these parameters
- output driver informs the panel that the bus is now up and running

Then consider a totally invented case, but which perhaps describes the
problem with the above approach: The DSI panel requires the DSI bus
first to be started in HS mode, but with a certain predefined bus speed,
and only one lane used. This predefined bus setup is used to send
configuration commands to the panel hardware, and only after that can
you reconfigure the bus with proper speed and lanes.

That kind of thing is a bit difficult to manage with the DSI output
driver is in control. However, if the DSI panel driver is in control,
it's simple:

- panel driver calls config methods in the DSI output driver, setting
the predefined speed and one lane
- panel driver sends configuration commands to the panel
- panel driver calls config methods in the DSI output driver, setting
the final bus config


We have similar use cases and so I agree (and have implemented) the 
latter approach where panel driver is in control. I think it is 
important to separate the panel calling dispc (which it should not) from 
panel calling bus/videosource ops. Compare to I2C, no one would expect 
panel to call dispc to do I2C ops, instead panel call bus ops directly 
in response to the CDF ops request panel is running.

5. Mask of used data lanes (each bit represents single lane).

 From my experience with MIPI CSI (Camera Serial Interface, similar to
DSI) some transceivers can reroute data lanes internally. Is that true
for DSI as well ? In that case we would need a list of data lanes, not
just a mask.

Hmm, I don't remember at the moment, will have to look to the
specification. Exynos DSI master doesn't support such feature.

In OMAP you can configure the DSI pins quite freely. We have the
following struct:

struct omap_dsi_pin_config {
int num_pins;
/*
 * pin 

Re: [RFC v2 0/5] Common Display Framework

[Marcus Lorentzon]

On 02/08/2013 11:51 AM, Tomi Valkeinen wrote:

On 2013-02-04 12:05, Marcus Lorentzon wrote:


As discussed at FOSDEM I will give DSI bus with full feature set a
try.

Please do, but as a reminder I want to raise the issues I see with a DSI
bus:

- A device can be a child of only one bus. So if DSI is used only for
video, the device is a child of, say, i2c bus, and thus there's no DSI
bus. How to configure and use DSI in this case?

- If DSI is used for both control and video, we have two separate APIs
for the bus. What I mean here is that for the video-only case above, we
need a video-only-API for DSI. This API should contain all necessary
methods to configure DSI. But we need similar methods for the control
API also.

So, I hope you come up with some solution for this, but as I see it,
it's easily the most simple and clear option to have one video_source
style entity for the DSI bus itself, which is used for both control and
video.


Thanks, it is not that I'm totally against the video source stuff. And I 
share your concerns, none of the solutions are perfect. It just doesn't 
feel right to create this dummy source device without investigating 
the DSI bus route. But I will try to write up some history/problem 
description and ask Greg KH for guidance. If he has a strong opinion 
either way, there is not much more to discuss ;)


/BR
/Marcus

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

[PATCH 1/3] modetest: Remove extern declarations of opt(arg|ind|err|opt)

[Laurent Pinchart]

Those variables are declared in unistd.h, there's no need to redeclare
them here.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 tests/modetest/modetest.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c91bb9d..489918e 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -835,8 +835,6 @@ set_mode(struct connector *c, int count, struct plane *p, 
int plane_count,
kms_destroy(kms);
 }
 
-extern char *optarg;
-extern int optind, opterr, optopt;
 static char optstr[] = ecpmfs:P:v;
 
 #define min(a, b)  ((a)  (b) ? (a) : (b))
-- 
1.7.12.4

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

[PATCH 0/3] modetest: Allow selecting a driver manually

[Laurent Pinchart]

Hello,

Here's a small patch set that adds an argument to the modetest command line to
specify the driver name instead of using the builtin list of drivers. This is
particularly handy during development of new DRM/KMS drivers.

Laurent Pinchart (3):
  modetest: Remove extern declarations of opt(arg|ind|err|opt)
  modetest: Sort command line arguments
  modetest: Add a command line parameter to select the driver

 tests/modetest/modetest.c | 81 ++-
 1 file changed, 52 insertions(+), 29 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH 2/3] modetest: Sort command line arguments

[Laurent Pinchart]

The current mostly random sort order hinders code readability. Sort the
options alphabetically in the code, and by group in the help message.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 tests/modetest/modetest.c | 49 ++-
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 489918e..34457e2 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -835,8 +835,6 @@ set_mode(struct connector *c, int count, struct plane *p, 
int plane_count,
kms_destroy(kms);
 }
 
-static char optstr[] = ecpmfs:P:v;
-
 #define min(a, b)  ((a)  (b) ? (a) : (b))
 
 static int parse_connector(struct connector *c, const char *arg)
@@ -896,15 +894,20 @@ static int parse_plane(struct plane *p, const char *arg)
 
 void usage(char *name)
 {
-   fprintf(stderr, usage: %s [-ecpmf]\n, name);
-   fprintf(stderr, \t-e\tlist encoders\n);
+   fprintf(stderr, usage: %s [-cefmPpsv]\n, name);
+
+   fprintf(stderr, \n Query options:\n\n);
fprintf(stderr, \t-c\tlist connectors\n);
-   fprintf(stderr, \t-p\tlist CRTCs and planes (pipes)\n);
-   fprintf(stderr, \t-m\tlist modes\n);
+   fprintf(stderr, \t-e\tlist encoders\n);
fprintf(stderr, \t-f\tlist framebuffers\n);
-   fprintf(stderr, \t-v\ttest vsynced page flipping\n);
-   fprintf(stderr, \t-s connector_id[@crtc_id]:mode[@format]\tset 
a mode\n);
+   fprintf(stderr, \t-m\tlist modes\n);
+
+   fprintf(stderr, \n Test options:\n\n);
+   fprintf(stderr, \t-p\tlist CRTCs and planes (pipes)\n);
fprintf(stderr, \t-P connector_id:wxh[@format]\tset a 
plane\n);
+   fprintf(stderr, \t-s connector_id[@crtc_id]:mode[@format]\tset 
a mode\n);
+   fprintf(stderr, \t-v\ttest vsynced page flipping\n);
+
fprintf(stderr, \n\tDefault is to dump all info.\n);
exit(0);
 }
@@ -932,6 +935,8 @@ static int page_flipping_supported(void)
 #endif
 }
 
+static char optstr[] = cefmP:ps:v;
+
 int main(int argc, char **argv)
 {
int c;
@@ -946,34 +951,34 @@ int main(int argc, char **argv)
opterr = 0;
while ((c = getopt(argc, argv, optstr)) != -1) {
switch (c) {
-   case 'e':
-   encoders = 1;
-   break;
case 'c':
connectors = 1;
break;
-   case 'p':
-   crtcs = 1;
-   planes = 1;
+   case 'e':
+   encoders = 1;
+   break;
+   case 'f':
+   framebuffers = 1;
break;
case 'm':
modes = 1;
break;
-   case 'f':
-   framebuffers = 1;
+   case 'P':
+   if (parse_plane(plane_args[plane_count], optarg)  0)
+   usage(argv[0]);
+   plane_count++;
break;
-   case 'v':
-   test_vsync = 1;
+   case 'p':
+   crtcs = 1;
+   planes = 1;
break;
case 's':
if (parse_connector(con_args[count], optarg)  0)
usage(argv[0]);
count++;  
break;
-   case 'P':
-   if (parse_plane(plane_args[plane_count], optarg)  0)
-   usage(argv[0]);
-   plane_count++;
+   case 'v':
+   test_vsync = 1;
break;
default:
usage(argv[0]);
-- 
1.7.12.4

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

[PATCH 3/3] modetest: Add a command line parameter to select the driver

[Laurent Pinchart]

If the -M parameter is specific, modetest will use the requested device
name instead of trying its builtin list of device names.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 tests/modetest/modetest.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 34457e2..b6298fc 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -908,6 +908,9 @@ void usage(char *name)
fprintf(stderr, \t-s connector_id[@crtc_id]:mode[@format]\tset 
a mode\n);
fprintf(stderr, \t-v\ttest vsynced page flipping\n);
 
+   fprintf(stderr, \n Generic options:\n\n);
+   fprintf(stderr, \t-M module\tuse the given driver\n);
+
fprintf(stderr, \n\tDefault is to dump all info.\n);
exit(0);
 }
@@ -935,7 +938,7 @@ static int page_flipping_supported(void)
 #endif
 }
 
-static char optstr[] = cefmP:ps:v;
+static char optstr[] = cefM:mP:ps:v;
 
 int main(int argc, char **argv)
 {
@@ -943,6 +946,7 @@ int main(int argc, char **argv)
int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
0;
int test_vsync = 0;
char *modules[] = { i915, radeon, nouveau, vmwgfx, omapdrm, 
exynos };
+   char *module = NULL;
unsigned int i;
int count = 0, plane_count = 0;
struct connector con_args[2];
@@ -960,6 +964,9 @@ int main(int argc, char **argv)
case 'f':
framebuffers = 1;
break;
+   case 'M':
+   module = optarg;
+   break;
case 'm':
modes = 1;
break;
@@ -989,14 +996,27 @@ int main(int argc, char **argv)
if (argc == 1)
encoders = connectors = crtcs = planes = modes = framebuffers = 
1;
 
-   for (i = 0; i  ARRAY_SIZE(modules); i++) {
-   printf(trying to load module %s..., modules[i]);
+   if (module) {
fd = drmOpen(modules[i], NULL);
if (fd  0) {
-   printf(failed.\n);
-   } else {
-   printf(success.\n);
-   break;
+   printf(failed to open device '%s'.\n, module);
+   return 1;
+   }
+   } else {
+   for (i = 0; i  ARRAY_SIZE(modules); i++) {
+   printf(trying to open device '%s'..., modules[i]);
+   fd = drmOpen(modules[i], NULL);
+   if (fd  0) {
+   printf(failed.\n);
+   } else {
+   printf(success.\n);
+   break;
+   }
+   }
+
+   if (fd  0) {
+   printf(no device found.\n, module);
+   return 1;
}
}
 
-- 
1.7.12.4

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

[Bug 30167] Heroes of Newerth: Setting shader quality to medium results in corrupt rendering

[bugzilla-daemon]

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

--- Comment #24 from Pavel Ondračka pavel.ondra...@email.cz ---
This seems to be fixed in the latest mesa git, however I didn't test all the
different settings mentioned in Comment 16. Sven can you confirm this is indeed
fixed?

-- 
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 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

[bugzilla-daemon]

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

--- Comment #29 from Paul Heldens pheld...@ziggo.nl ---
3.8-rc6 Here neither, only chunk 1 with 25x lines fuz

-- 
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

Re: [PATCH 3/3] modetest: Add a command line parameter to select the driver

[Jani Nikula]

On Fri, 08 Feb 2013, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
 If the -M parameter is specific, modetest will use the requested device
 name instead of trying its builtin list of device names.

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  tests/modetest/modetest.c | 34 +++---
  1 file changed, 27 insertions(+), 7 deletions(-)

 diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
 index 34457e2..b6298fc 100644
 --- a/tests/modetest/modetest.c
 +++ b/tests/modetest/modetest.c
 @@ -908,6 +908,9 @@ void usage(char *name)
   fprintf(stderr, \t-s connector_id[@crtc_id]:mode[@format]\tset 
 a mode\n);
   fprintf(stderr, \t-v\ttest vsynced page flipping\n);
  
 + fprintf(stderr, \n Generic options:\n\n);
 + fprintf(stderr, \t-M module\tuse the given driver\n);
 +
   fprintf(stderr, \n\tDefault is to dump all info.\n);
   exit(0);
  }
 @@ -935,7 +938,7 @@ static int page_flipping_supported(void)
  #endif
  }
  
 -static char optstr[] = cefmP:ps:v;
 +static char optstr[] = cefM:mP:ps:v;
  
  int main(int argc, char **argv)
  {
 @@ -943,6 +946,7 @@ int main(int argc, char **argv)
   int encoders = 0, connectors = 0, crtcs = 0, planes = 0, framebuffers = 
 0;
   int test_vsync = 0;
   char *modules[] = { i915, radeon, nouveau, vmwgfx, omapdrm, 
 exynos };
 + char *module = NULL;
   unsigned int i;
   int count = 0, plane_count = 0;
   struct connector con_args[2];
 @@ -960,6 +964,9 @@ int main(int argc, char **argv)
   case 'f':
   framebuffers = 1;
   break;
 + case 'M':
 + module = optarg;
 + break;
   case 'm':
   modes = 1;
   break;
 @@ -989,14 +996,27 @@ int main(int argc, char **argv)
   if (argc == 1)
   encoders = connectors = crtcs = planes = modes = framebuffers = 
 1;
  
 - for (i = 0; i  ARRAY_SIZE(modules); i++) {
 - printf(trying to load module %s..., modules[i]);
 + if (module) {
   fd = drmOpen(modules[i], NULL);

If this worked for you, I presume you have some uncommitted changes in
your tree. ;) The compiler should cry about uninitialized use of i too.

fd = drmOpen(module, NULL); ?

   if (fd  0) {
 - printf(failed.\n);
 - } else {
 - printf(success.\n);
 - break;
 + printf(failed to open device '%s'.\n, module);
 + return 1;
 + }
 + } else {
 + for (i = 0; i  ARRAY_SIZE(modules); i++) {
 + printf(trying to open device '%s'..., modules[i]);
 + fd = drmOpen(modules[i], NULL);
 + if (fd  0) {
 + printf(failed.\n);
 + } else {
 + printf(success.\n);
 + break;
 + }
 + }
 +
 + if (fd  0) {
 + printf(no device found.\n, module);

Extra param to printf.


BR,
Jani.

 + return 1;
   }
   }
  
 -- 
 1.7.12.4

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

[GMA500] Valid VCO frequency range on GMA500 platform?

[David Müller (ELSOFT AG)]

Hello

I have a problem using a 1024x768 Eizo Monitor attached by DVI-D to a
system with GMA500 based graphics and running under Linux-3.7.

As soon as the GMA500 driver is taking over control, the refresh
rate raises to 64.5Hz and the monitor reports a signal error.

For me i looks like the GMA500 driver is reprogramming the VCO to a too
high dot clock. If i lower the I9XX_VCO_MIN value to 130,
everything is fine.

Is the I9XX_VCO_MIN value used in the GMA500 driver correct?


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

[Bug 60439] Suspend/resume broken for cayman since kernel =3.7.0 (maybe rc too)

[bugzilla-daemon]

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

--- Comment #3 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #2)
 The following commits fall within that range (only one specific to cayman),
 I guess I can skip some of them:

Please don't. In the best case, you save a couple of tests, in the worst case
the bisection result is invalid and you have to start over again.

-- 
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

Re: [RFC PATCH 0/4] Common Display Framework-TF

[Marcus Lorentzon]

On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:

On 2013-02-08 15:28, Marcus Lorentzon wrote:


When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had any
issue with that (as long as DSI HS clock is set to continuous). I think
this approach is less platform dependant, as long as there is no SoC
that take more than a blanking period to reconfigure.

So do you stop, setup and start the link with CPU, and this has to be
happen during blanking? Isn't that prone to errors? Or did you mean that
the hardware handles that automatically?

In OMAP DSS there are so called shadow registers, that can be programmed
at any time. The you set a bit (GO bit), which tells the hardware to
take the new settings into use at the next vblank.

 From DSI driver's perspective the link is never stopped when
reconfiguring the video timings. However, many other settings have to be
configured when the link is disabled.


Yeah, you lucky guys with the GO bit ;). No, we actually do CPU 
stop,setup,start. But since it is video mode, master is driving the sync 
so it is not a hard deadline. It is enough to restart before pixels 
start to degrade. On an LCD that is not so much time, but on an OLED it 
could be 10 secs :). Anyway, we have had several mass products with this 
soft solution and it has worked well.

In OMAP you can configure the DSI pins quite freely. We have the
following struct:

struct omap_dsi_pin_config {
  int num_pins;
  /*
   * pin numbers in the following order:
   * clk+, clk-
   * data1+, data1-
   * data2+, data2-
   * ...
   */
  int pins[OMAP_DSS_MAX_DSI_PINS];
};


I think it still is OMAP specifics and doesn't belong in the panel
drivers any longer. If you revisit this requirement in the CDF context
where DSI ifc parameters should describe how to interface with a panel
outside the SoC, there can't really be any dependencies on SoC internal
routing. As you say, this is inside pinmux, so how can that affect the
SoC external interface? I would suggest moving this to dispc-dsilink DT
settings that are activated on dsilink-enable/disable. At least that is
how I plan to solve similar STE SoC specific DSI config settings that
are not really CDF panel generic, like some DPhy trim settings. They do
depend on the panel and clock speed, but they are more product specific
than panel driver specific. Then if there are these type of settings
that every SoC have, then we could look at standardize those. But for
starters I would try to keep it in product/board-DT per DSI link. So we
should try to differentiate between DSI host and slave bus params and
keep slave params in panel driver.

Ok, I think I was being a bit vague here. I explained the OMAP DSI
routing not because I meant that this API is specific to that, but
because it explains why this kind of routing info is needed, and a
bitmask is not enough.

If you look at the omap_dsi_pin_config struct, there's nothing OMAP
specific there (except the names =). All it tells is that this device
uses N DSI pins, and the device's clk+ function should be connected to
pin X on the DSI master, clk- should be connected to pin Y, etc. X and Y
are integers, and what they mean is specific to the DSI master.

When the DSI master is OMAP's DSI, the OMAP DSI driver does the pin
configuration as I explained. When the DSI master is something else,
say, a DSI bridge, it does whatever it needs to do (which could be
nothing) to assign a particular DSI function to a pin.

I understand, but removing the omap prefix doesn't mean it has to go in 
the panel slave port/bus settings. I still can't see why this should be 
configuration on the panel driver and not the DSI master driver. Number 
of pins might be useful since you might start with one lane and then 
activate the rest. But partial muxing (pre pinmux) doesn't seem to be 
something the panel should control or know anything about. Sounds like 
normal platform/DT data per product/board.


/BR
/Marcus

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

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

[bugzilla-daemon]

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

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

  Attachment #74381|0   |1
is obsolete||

--- Comment #30 from Jerome Glisse gli...@freedesktop.org ---
Created attachment 74433
  -- https://bugs.freedesktop.org/attachment.cgi?id=74433action=edit
Kernel fix

This one apply against Linus master

-- 
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 60439] Suspend/resume broken for cayman since kernel =3.7.0 (maybe rc too)

[bugzilla-daemon]

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

--- Comment #4 from Harald Judt h.j...@gmx.at ---
I will bisect the week after the next, before I will not have access to that
machine. I'd rather avoid bisecting standby/resume problems too much because
that could possibly cause data loss, and it is not possible to do in a VM.

BTW: I do not have such issues on a laptop with a ATI RV620 [Mobility Radeon HD
3400 Series], so this only seems to affect cayman.

-- 
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 35861] [r300g] Unigine Tropics: whiter triangle between center of the screen and horizon

[bugzilla-daemon]

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

Pavel Ondračka pavel.ondra...@email.cz changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---
Summary|[r300g] Oilrush: whiter |[r300g] Unigine Tropics:
   |triangle between center of  |whiter triangle between
   |the screen and horizon  |center of the screen and
   ||horizon

--- Comment #7 from Pavel Ondračka pavel.ondra...@email.cz ---
(In reply to comment #6)
 Oilrush require at least ATI Radeon HD2600 so maybe this is the reason of
 this corruption?

I can reproduce this even with Unigine Tropics 1.3 which supports opengl 2.1
and hence also r500 cards, reopening.

-- 
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 60503] New: [r300g] Unigine Heaven 3.0: all objects are black

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 60503
  Assignee: dri-devel@lists.freedesktop.org
   Summary: [r300g] Unigine Heaven 3.0: all objects are black
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pavel.ondra...@email.cz
   URL: http://unigine.com/products/heaven/download/
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r300
   Product: Mesa

All object in the 3.0 Heaven version are completely black... this seems to be
the cause:
r300 FP: Compiler Error:
Rewrite of inst 4 failed Can't allocate source for Inst 36 src_type=1
new_index=1 new_mask=4
Using a dummy shader instead.

Full RADEON_DEBUG=fp log attached.

This may be a hardware limitation, however Heaven 2.1 version works fine, so
maybe just a bug in the shader compiler.

GPU: RV530
Mesa: b681ed6ac970e061e9dbe7309bb69b3a947ae62d
Kernel: 3.6.11-1.fc17.i686

-- 
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 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

[bugzilla-daemon]

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

--- Comment #10 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
Hi Jerome, thanks for the tips.

Well, I followed the next error
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing CC68 (len 72,
WS 0, PS 0) @ 0xCC97

Down to the test in 0x2f on 0xcc68.
command_table  cc68  #2c  (UpdateCRTC_DoubleBufferRegisters):
...
  0027: 5420b51b  CLEAR  reg[1bb5]  [...X]
  002b: 5420bd1b  CLEAR  reg[1bbd]  [...X]
  002f: 4a25b61b01TEST   reg[1bb6]  [...X]  -  01

I have a question here: how do I determine what are these registers? I couldn't
match 1bb6 to anything on the radeon driver code, so I suppose that's somewhere
else... or is there some other way to read that?

Anyway, I backtracked that code back to this call on atombios_crtc.c:

static void atombios_lock_crtc(struct drm_crtc *crtc, int lock)
{
...
int index =
GetIndexIntoMasterTable(COMMAND, UpdateCRTC_DoubleBufferRegisters);
...
atom_execute_table(rdev-mode_info.atom_context, index, (uint32_t *)args);
}

which could've come from either of these:
static void atombios_crtc_prepare(struct drm_crtc *crtc)
static void atombios_crtc_commit(struct drm_crtc *crtc)

Since those are callbacks registered as helper funcs, and I'm not sure of their
semantics, I ended up getting stuck :) 

static const struct drm_crtc_helper_funcs atombios_helper_funcs = {
.prepare = atombios_crtc_prepare,
.commit = atombios_crtc_commit,

Any ideas here?

Thanks! :)

-- 
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 59982] Radeon: evergreen Atombios in loop during initialization on ppc64

[bugzilla-daemon]

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

--- Comment #11 from Lucas Kannebley Tavares luca...@linux.vnet.ibm.com ---
Nevermind the question about the registers, just re-read your post, which I
should've done in the first place :)

Thanks

-- 
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 59521] [Serious Sam 3] Missing textures with R600g

[bugzilla-daemon]

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

--- Comment #3 from Laurent carlier lordhea...@gmail.com ---
Created attachment 74448
  -- https://bugs.freedesktop.org/attachment.cgi?id=74448action=edit
apitrace that produce an error

That trace gives:

 apitrace retrace Sam3.1207.trim.trace 
1205: glDebugOutputCallback: High severity API error 0, GL_INVALID_OPERATION in
unsupported function called (unsupported extension or deprecated function?)
0 1205 glProgramUniform1i(program = 8, location = 65536, v0 = 0)
1205: warning: glGetError(glProgramUniform1i) = GL_INVALID_OPERATION
Rendered 0 frames in 0.0703531 secs, average of 0 fps

-- 
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 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

[bugzilla-daemon]

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

--- Comment #31 from Paul Heldens pheld...@ziggo.nl ---
3.8-rc6

your latest kernel patch applied well.



with fix v2 all corruption seems gone.  on ~10 startups




without fix v2 I still see dynamic corruption at the bottom of screen

-- 
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 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

[bugzilla-daemon]

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

Paul Heldens pheld...@ziggo.nl changed:

   What|Removed |Added

  Attachment #74239|0   |1
is obsolete||
  Attachment #74306|0   |1
is obsolete||

--- Comment #32 from Paul Heldens pheld...@ziggo.nl ---
Created attachment 74451
  -- https://bugs.freedesktop.org/attachment.cgi?id=74451action=edit
xonotic with kernel without v2 patch 3.8-rc6

-- 
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 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

[bugzilla-daemon]

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

--- Comment #33 from Paul Heldens pheld...@ziggo.nl ---
i've seen no more dmesg errors

-- 
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] drm/radeon: copy userspace cmd to local copy before processing it v3

[j . glisse]

From: Jerome Glisse jgli...@redhat.com

In some rare case were packet is big enough to go over page boundary
we might not have copied yet the userspace data into the local copy
resulting in kernel reading garbage data.

Without this patch kernel might submit unprocessed/unrelocated cmd
to the GPU which might lead to GPU lockup.

v2: Make sure we do copy all the page and don't forget some when
the packet count dw is bigger than 1 page
v3: Rebase patch against Linus master

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/evergreen_cs.c | 35 ++-
 drivers/gpu/drm/radeon/r600_cs.c  | 19 ++-
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 7a44566..51ad74a 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -1021,7 +1021,7 @@ static int evergreen_cs_packet_parse(struct 
radeon_cs_parser *p,
  unsigned idx)
 {
struct radeon_cs_chunk *ib_chunk = p-chunks[p-chunk_ib_idx];
-   uint32_t header;
+   uint32_t header, i, npages;
 
if (idx = ib_chunk-length_dw) {
DRM_ERROR(Can not parse packet at %d after CS end %d !\n,
@@ -1052,6 +1052,11 @@ static int evergreen_cs_packet_parse(struct 
radeon_cs_parser *p,
  pkt-idx, pkt-type, pkt-count, ib_chunk-length_dw);
return -EINVAL;
}
+   /* make sure we copied packet fully from userspace */
+   npages = ((idx + pkt-count + 1)  10) - (idx  10);
+   for (i = 1; i = npages; i++) {
+   radeon_get_ib_value(p, (idx  0xfc00) + i * 0x400);
+   }
return 0;
 }
 
@@ -2909,12 +2914,16 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
return -EINVAL;
}
if (tiled) {
+   /* make sure we copied packet fully from 
userspace */
+   radeon_get_ib_value(p, idx + 6);
dst_offset = ib[idx+1];
dst_offset = 8;
 
ib[idx+1] += (u32)(dst_reloc-lobj.gpu_offset 
 8);
p-idx += count + 7;
} else {
+   /* make sure we copied packet fully from 
userspace */
+   radeon_get_ib_value(p, idx + 2);
dst_offset = ib[idx+1];
dst_offset |= ((u64)(ib[idx+2]  0xff))  32;
 
@@ -2945,6 +2954,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
switch (misc) {
case 0:
/* L2T, frame to fields */
+   /* make sure we copied packet 
fully from userspace */
+   radeon_get_ib_value(p, idx + 9);
if (idx_value  (1  31)) {
DRM_ERROR(bad L2T, 
frame to fields DMA_PACKET_COPY\n);
return -EINVAL;
@@ -2983,6 +2994,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
break;
case 1:
/* L2T, T2L partial */
+   /* make sure we copied packet 
fully from userspace */
+   radeon_get_ib_value(p, idx + 
11);
if (p-family  CHIP_CAYMAN) {
DRM_ERROR(L2T, T2L 
Partial is cayman only !\n);
return -EINVAL;
@@ -3005,6 +3018,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
break;
case 3:
/* L2T, broadcast */
+   /* make sure we copied packet 
fully from userspace */
+   radeon_get_ib_value(p, idx + 9);
if (idx_value  (1  31)) {
DRM_ERROR(bad L2T, 
broadcast DMA_PACKET_COPY\n);
return -EINVAL;
@@ -3043,6 +3058,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
break;
case 4:
/* 

Re: [PATCH] drm/radeon: copy userspace cmd to local copy before processing it v3

[Alex Deucher]

On Fri, Feb 8, 2013 at 6:13 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 In some rare case were packet is big enough to go over page boundary
 we might not have copied yet the userspace data into the local copy
 resulting in kernel reading garbage data.

 Without this patch kernel might submit unprocessed/unrelocated cmd
 to the GPU which might lead to GPU lockup.

 v2: Make sure we do copy all the page and don't forget some when
 the packet count dw is bigger than 1 page
 v3: Rebase patch against Linus master

 Signed-off-by: Jerome Glisse jgli...@redhat.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/radeon/evergreen_cs.c | 35 
 ++-
  drivers/gpu/drm/radeon/r600_cs.c  | 19 ++-
  2 files changed, 52 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
 b/drivers/gpu/drm/radeon/evergreen_cs.c
 index 7a44566..51ad74a 100644
 --- a/drivers/gpu/drm/radeon/evergreen_cs.c
 +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
 @@ -1021,7 +1021,7 @@ static int evergreen_cs_packet_parse(struct 
 radeon_cs_parser *p,
   unsigned idx)
  {
 struct radeon_cs_chunk *ib_chunk = p-chunks[p-chunk_ib_idx];
 -   uint32_t header;
 +   uint32_t header, i, npages;

 if (idx = ib_chunk-length_dw) {
 DRM_ERROR(Can not parse packet at %d after CS end %d !\n,
 @@ -1052,6 +1052,11 @@ static int evergreen_cs_packet_parse(struct 
 radeon_cs_parser *p,
   pkt-idx, pkt-type, pkt-count, 
 ib_chunk-length_dw);
 return -EINVAL;
 }
 +   /* make sure we copied packet fully from userspace */
 +   npages = ((idx + pkt-count + 1)  10) - (idx  10);
 +   for (i = 1; i = npages; i++) {
 +   radeon_get_ib_value(p, (idx  0xfc00) + i * 0x400);
 +   }
 return 0;
  }

 @@ -2909,12 +2914,16 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
 return -EINVAL;
 }
 if (tiled) {
 +   /* make sure we copied packet fully from 
 userspace */
 +   radeon_get_ib_value(p, idx + 6);
 dst_offset = ib[idx+1];
 dst_offset = 8;

 ib[idx+1] += (u32)(dst_reloc-lobj.gpu_offset 
  8);
 p-idx += count + 7;
 } else {
 +   /* make sure we copied packet fully from 
 userspace */
 +   radeon_get_ib_value(p, idx + 2);
 dst_offset = ib[idx+1];
 dst_offset |= ((u64)(ib[idx+2]  0xff))  32;

 @@ -2945,6 +2954,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
 switch (misc) {
 case 0:
 /* L2T, frame to fields */
 +   /* make sure we copied packet 
 fully from userspace */
 +   radeon_get_ib_value(p, idx + 
 9);
 if (idx_value  (1  31)) {
 DRM_ERROR(bad L2T, 
 frame to fields DMA_PACKET_COPY\n);
 return -EINVAL;
 @@ -2983,6 +2994,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
 break;
 case 1:
 /* L2T, T2L partial */
 +   /* make sure we copied packet 
 fully from userspace */
 +   radeon_get_ib_value(p, idx + 
 11);
 if (p-family  CHIP_CAYMAN) {
 DRM_ERROR(L2T, T2L 
 Partial is cayman only !\n);
 return -EINVAL;
 @@ -3005,6 +3018,8 @@ int evergreen_dma_cs_parse(struct radeon_cs_parser *p)
 break;
 case 3:
 /* L2T, broadcast */
 +   /* make sure we copied packet 
 fully from userspace */
 +   radeon_get_ib_value(p, idx + 
 9);
 if (idx_value  (1  31)) {
 DRM_ERROR(bad L2T, 
 broadcast DMA_PACKET_COPY\n);
 return -EINVAL;
 @@ -3043,6 +3058,8 @@ 

[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc

[bugzilla-daemon]

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

--- Comment #34 from Andy Furniss li...@andyfurniss.entadsl.com ---
(In reply to comment #30)
 Created attachment 74433 [details] [review]
 Kernel fix
 
 This one apply against Linus master

Like Paul, I need the mesa patch as well to get rid of the junk at the bottom
of the screen.

I guess my screen was too small to show the issue this patch fixes, but I've
tried it and can't find anything that regresses.

-- 
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 60182] X.Org Server terminate when I close video player

[bugzilla-daemon]

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

--- Comment #11 from runetmem...@gmail.com ---
Created attachment 74462
  -- https://bugs.freedesktop.org/attachment.cgi?id=74462action=edit
lightdm.log after crash

-- 
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 60182] X.Org Server terminate when I close video player

[bugzilla-daemon]

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

--- Comment #12 from runetmem...@gmail.com ---
Created attachment 74464
  -- https://bugs.freedesktop.org/attachment.cgi?id=74464action=edit
x-0.log LightDM log after crash

LightDM logs in right-after-crash state attached.

-- 
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