date:20111114

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

--- Comment #17 from Marek Ol??k  2011-11-14 15:28:23 PST 
---
(In reply to comment #16)
> So, I bisected mesa tree (7.11 branch)
> 
> Result:
> 
> 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit
> commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3
> Author: Marek Olk 
> Date:   Sun Dec 26 04:30:51 2010 +0100
> 
> st/mesa: set vertex arrays state only when necessary

I guess the bisection failed in this case, because that commit contains a bug
that was fixed later.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> +struct drm_mode_fb_cmd2 {
> + __u32 fb_id;
> + __u32 width, height;
> + __u32 pixel_format; /* fourcc code from videodev2.h */
> +
> + /*
> +  * In case of planar formats, this ioctl allows up to 4
> +  * buffer objects with offets and pitches per plane.
> +  * The pitch and offset order is dictated by the fourcc,
> +  * e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
> +  *
> +  *   YUV 4:2:0 image with a plane of 8 bit Y samples
> +  *   followed by an interleaved U/V plane containing
> +  *   8 bit 2x2 subsampled colour difference samples.
> +  *
> +  * So it would consist of Y as offset[0] and UV as
> +  * offeset[1].  Note that offset[0] will generally
> +  * be 0.
> +  */
> + __u32 handles[4];
> + __u32 pitches[4]; /* pitch for each plane */
> + __u32 offsets[4]; /* offset of each plane */
> +};

Hey, what about those interlaced buffers? We talked privately about
adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
drm_mode_set_plane.

We could stick something like these to those flags:
fb_cmd2.flags:
#define DRM_MODE_FB_INTERLACED 0x1

set_plane.flags:
#define DRM_MODE_PRESENT_TOP_FIELD 0x1
#define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2

-- 
Ville Syrj?l?
Intel OTC

[Bug 34969] [nouveau] Card lockup on openarena

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

--- Comment #16 from Andrew Randrianasulu  2011-11-14 
15:16:55 PST ---
So, I bisected mesa tree (7.11 branch)

Result:

2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit
commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3
Author: Marek Olk 
Date:   Sun Dec 26 04:30:51 2010 +0100

st/mesa: set vertex arrays state only when necessary

The vertex arrays state should be set only when (_NEW_ARRAY | _NEW_PROGRAM)
is dirty. This assumes user buffer content is mutable, which will be
sorted out in the next commit. The following usage case should be much
faster
now:

for (i = 0; i < 1000; i++) {
   glDrawElements(...);
}

Or even:

for (i = 0; i < 1000; i++) {
   glSomeStateChangeOtherThanArraysOrProgram(...);
   glDrawElements(...);
}

The performance increase from this may be significant in some apps and
negligible in others. It is especially noticable in the Torcs game (r300g):
Before: 15.4 fps
After: 20 fps

Also less looping over attribs in st_draw_vbo yields slight speed-up
in apps with lots of glDraw* calls.

:04 04 45e5630d445206ce8c7eab6ac6bfe144901695bb
927efd20e354ecae459227bd464dbb6001cb448e M  src


guest at slax:~/botva/src/src/mesa$ git bisect log
git bisect start
# good: [0f7325b89038937bd428f7c89ed9859189a0ab0b] i965: Emit texel offsets in
sampler messages.
git bisect good 0f7325b89038937bd428f7c89ed9859189a0ab0b
# bad: [8767fe2437094f33db140a6b92f25116de4fc371] mesa: Sort extensions in
extension string by year.
git bisect bad 8767fe2437094f33db140a6b92f25116de4fc371
# bad: [fbd681f1a03f6ad62432107dc94e02674f6de7bf] i915g: Use dump function in
sw winsys
git bisect bad fbd681f1a03f6ad62432107dc94e02674f6de7bf
# good: [1f5b67416810f7331fe71db0f767418473083701] egl_dri2: add nouveau
support.
git bisect good 1f5b67416810f7331fe71db0f767418473083701
# bad: [e0481cac7d57757d75a39763a1dd36b915979bb4] svga: Disable surface cache
for textures
git bisect bad e0481cac7d57757d75a39763a1dd36b915979bb4
# bad: [fc5ab1b19780ef97c5e7f6257a2d91121503bd53] mesa: use gl_format type
instead of GLuint
git bisect bad fc5ab1b19780ef97c5e7f6257a2d91121503bd53
# bad: [56029ce52bafbc51b5b6660383767257b7770cd7] r300g: inline some of the
pipe_buffer_map/unmap calls
git bisect bad 56029ce52bafbc51b5b6660383767257b7770cd7
# good: [9e96ea0652dda64f8eb311d7dfc9c50519ad02f0] r600g: add alignment cases
for linear aligned
git bisect good 9e96ea0652dda64f8eb311d7dfc9c50519ad02f0
# bad: [588fa884d212eba5ffbc69fda75db37d7c77214c] gallium: notify drivers about
possible changes in user buffer contents
git bisect bad 588fa884d212eba5ffbc69fda75db37d7c77214c
# good: [cfaf217135d8a8e903b3fbf380f18170df018f0c] vbo: bind arrays only when
necessary
git bisect good cfaf217135d8a8e903b3fbf380f18170df018f0c
# good: [cdca3c58aa2d9549f5188910e2a77b438516714f] gallium: remove
pipe_vertex_buffer::max_index
git bisect good cdca3c58aa2d9549f5188910e2a77b438516714f
# bad: [2a904fd6a0cb80eec6dec2bae07fd8778b04caf3] st/mesa: set vertex arrays
state only when necessary
git bisect bad 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) << 8) | \
> +   ((u32)(c) << 16) | ((u32)(d) << 24))
> +
> +/* RGB codes */
> +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
> +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
> +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
> +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
> +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
> +
> +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
> +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')

I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
formats, so why do we need the RGB/BGR32 variants? If the difference
is in the alpha channel, I'd like to document that fact in the name.

Could we call them ARGB, XRGB, XRGB1555 etc.?

Also the channel and byte order should be documented clearly.

And one other thing. I probably wouldn't call these fourccs
since they don't actually match the official fourccs. Not that
there is anything sensible defined for RGB formats in the
official list anyway. In fact, I'm not sure what we gain by
cooking our own fourccs when we know most of them won't match
the official list. AFAICS a simple running number would do
just as well as the format identifier.

-- 
Ville Syrj?l?
Intel OTC

[Bug 27184] Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably

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

--- Comment #18 from Oliver Winker  2011-11-14 
14:01:30 PST ---
(In reply to comment #17)
> DPMS standby, suspend, and off states are all treated the same from the
> driver's perspective.  The driver really only deals with 2 DPMS states on and
> off.

Ok, interesting to know. Now somehow the way using "xset dpms 240 0 0"
(stand-by) quite surely made a difference for me at the time (<3.1) - but I
can't prove and explain in detail.

Now currently I'm using "xset dpms 0 240 0" (suspend) with 3.1 and until now it
wakes up quite reliable. Which would be in inline with your info, that the
driver operates on the same two states, as with stand-by. 

Maybe I'll also retest again the KDE power mgmt setting way, where I originally
observed the wake-up problem. Maybe it's some screwed side effect in the end. 

> > 
> > Anyway, I will also retry a bit and do some testing using "suspend" on a 
> > 3.1,
> > to see if something changed.
> 
> When you say suspend, are you talking about the DPMS display state, or suspend
> and resume of the entire laptop?  The two are very different.

No, no - I'm really talking about pure display suspend/resume, on a desktop
with an Asus screen. Only the display is suspended and should nicely wakeup
again, when I tick the mouse ;).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DRM KMS Modesetting

2011-11-14 Thread David Herrmann

On Mon, Nov 14, 2011 at 9:38 PM, Jesse Barnes  
wrote:
> On Mon, 14 Nov 2011 21:25:56 +0100
> David Herrmann  wrote:
>
>> Hi
>>
>> I thought it's better to ask this question here again as it is easier
>> to comment via mail.
>>
>> I tried writing a simple kms modesetting program. I have written it similar 
>> to:
>> http://virtuousgeek.org/blog/index.php/jbarnes?blog=2=writing_stanalone_programs_with_egl_and_
>> and wayland compositor-drm.c
>> and modetest.c in libdrm/tests
>>
>> My problem is, the program compiles and runs fine, however, the
>> framebuffer is only displayed on the left quarter of the screen. The
>> vertical size is perfect but the horizontal size is just the left
>> quarter. I've double checked all the drm parameters and they are equal
>> to the ones in modetest.c and compositor-drm.c.
>>
>> ./modetest runs fine and also reports only a single mode and encoder
>> for my connector so I cannot choose the wrong mode, either.
>>
>> The code is here:
>> https://gist.github.com/1364994
>> It should compile fine with:
>> gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`
>>
>> I would be glad if someone could run this or look over the code.
>
> Hm I get a full white screen with a gray triangle in the lower right
> hand corner.

Yes, thats what should be displayed.

> I had to modify the resolution the test was searching for
> to 1920x1200 instead of 1024x600 since I tested on a DP attached
> monitor, and fix the connector id, but other than that it seemed to
> work fine.

Thanks for testing. At least my code seems right now, but I still
cannot get it to work on my machine. The output of modetest is:
https://gist.github.com/1365083

There is only one connected connector+encoder+mode so I don't know
where the problem exactly is. Are there any debug options? Is it
possible to query the EGLImage for width/height?

> --
> Jesse Barnes, Intel Open Source Technology Center
>

Cheers
David

[Bug 41265] KMS does not work on Radeon HD6700M

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

--- Comment #7 from nover  2011-11-14 13:26:42 PST ---
I did some further testing on the matter of the ATI card in the PMD.

In windows, it's actually possible to have two screens connected via HDMI - one
to the ATI card in the PMD, which is then "promoted" to be the primary graphics
adapter, and one in the intel card.

So i guess this suggests that the ATI card is simply "another graphics card"
connected to the computer? Only twist is that it's conneted via
LightPeak/Thunderbolt...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

DRM KMS Modesetting

2011-11-14 Thread David Herrmann

Hi

I thought it's better to ask this question here again as it is easier
to comment via mail.

I tried writing a simple kms modesetting program. I have written it similar to:
http://virtuousgeek.org/blog/index.php/jbarnes?blog=2=writing_stanalone_programs_with_egl_and_
and wayland compositor-drm.c
and modetest.c in libdrm/tests

My problem is, the program compiles and runs fine, however, the
framebuffer is only displayed on the left quarter of the screen. The
vertical size is perfect but the horizontal size is just the left
quarter. I've double checked all the drm parameters and they are equal
to the ones in modetest.c and compositor-drm.c.

./modetest runs fine and also reports only a single mode and encoder
for my connector so I cannot choose the wrong mode, either.

The code is here:
https://gist.github.com/1364994
It should compile fine with:
gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`

I would be glad if someone could run this or look over the code.

Regards
David

[Bug 42514] [r300g] EVE online: some shaders are failing

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

Pavel Ondra?ka  changed:

   What|Removed |Added

 Depends on||42930

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

On 11/14/2011 07:54 PM, Jerome Glisse wrote:
> On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote:
>
>> On 11/14/2011 05:02 PM, Jerome Glisse wrote:
>>  
>>> On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom 
>>>   wrote:
>>>
 On 11/11/2011 11:47 PM, j.glisse at gmail.com wrote:
  
> So attached is updated serie of patch with fixes for swaping issue
> that also impacted memory accounting.
>
 Jerome,
 Out of interest, what was the swapping issue?

 /Thomas


  
>>> The page list was NULL and some access ended up freaking the kernel
>>> and oom kicked in for some reason i still don't understand. Bottom
>>> line things were going south in a split second leaving me with no log
>>> or access, i thought it was accounting not working as it was what i
>>> tested at the time. I should have tested accouting without the
>>> patchset
>>>
>>> Cheers,
>>> Jerome
>>>
>> Still, I think you have a point in the fact that *when* finally the
>> OOM killer kicks in,
>> it probably doesn't have a way to associate user-space created bos
>> with processes
>> and kill the right process.
>>
>> /Thomas
>>
>>  
> Btw can you review patch 14 as it touch vmwgfx, i am pretty sure
> i got it right.
>
> Cheers,
> Jerome
>
Yes I will do a more thorough review tomorrow of all unreviewed stuff.

/Thomas

[PATCH] drm_edid: support CEA video modes

2011-11-14 Thread Paul Menzel

Am Sonntag, den 13.11.2011, 23:16 +0100 schrieb alanwww1:
> This is awesome ! A LOT of HTPC fans are waiting for this! Is there a
> chance that this lands in 3.2 ?

Have you tested this? Adding a Tested-by line would surely help getting
it included.


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/51878d8e/attachment.pgp>

[PATCH] drm_edid: support CEA video modes

On Sun, 2011-11-13 at 01:31 +0100, Christian Schmidt wrote:
> TFT/plasma televisions and projectors have become commonplace, and so
> has the use of PCs to drive them. Add the video modes specified by an
> EDID's CEA extension to the mode database for a connector.

Thanks for finishing this up.  The mode list was indeed mechanically
generated (pdf2text on the spec and then some python to bash it all
together).  It's probably worth noting in the comment that it's from
CEA-861-D, as I suspect subsequent revisions have added more timings (I
haven't bought it yet to check).

Reviewed-by: Adam Jackson 

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/f19c737a/attachment.pgp>

[PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

On Sun, 2011-11-13 at 09:57 +0100, Christian Schmidt wrote:
> The current logic misunderstands the spec about CEA 18byte descriptors.
> First, the spec doesn't state "detailed timing descriptors" but "18 byte
> descriptors", so any data record could be stored, mixed timings and
> other data, just as in the standard EDID.

I don't think the code misinterprets this.  But I also don't think your
patch changes this interpretation, so that's fine.

> Second, the lower four bit of byte 3 of the CEA record do not contain
> the number of descriptors, but "the total number of DTDs defining native
> formats in the whole EDID [...], starting with the first DTD in the DTD
> list (which starts in the base EDID block)." A device can of course
> support non-native formats.
> 
> As such the number can't be used to determine n, and the existing code
> will filter non-timing 18byte descriptors anyway.

Good catch, thanks.

Reviewed-by: Adam Jackson 

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/3e0f1ec0/attachment.pgp>

[PATCH] drm/radeon/kms: fix segfault in pm rework

2011-11-14 Thread alexdeuc...@gmail.com

From: Alex Deucher 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/radeon_atombios.c |   20 +---
 1 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 6b5fbc9..0e9ad6f 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2017,14 +2017,14 @@ static int radeon_atombios_parse_power_table_1_3(struct 
radeon_device *rdev)
return state_index;
/* last mode is usually default, array is low to high */
for (i = 0; i < num_modes; i++) {
+   rdev->pm.power_state[state_index].clock_info =
+   kzalloc(sizeof(struct radeon_pm_clock_info) * 1, 
GFP_KERNEL);
+   if (!rdev->pm.power_state[state_index].clock_info)
+   return state_index;
+   rdev->pm.power_state[state_index].num_clock_modes = 1;
rdev->pm.power_state[state_index].clock_info[0].voltage.type = 
VOLTAGE_NONE;
switch (frev) {
case 1:
-   rdev->pm.power_state[state_index].clock_info =
-   kzalloc(sizeof(struct radeon_pm_clock_info) * 
1, GFP_KERNEL);
-   if (!rdev->pm.power_state[state_index].clock_info)
-   return state_index;
-   rdev->pm.power_state[state_index].num_clock_modes = 1;
rdev->pm.power_state[state_index].clock_info[0].mclk =

le16_to_cpu(power_info->info.asPowerPlayInfo[i].usMemoryClock);
rdev->pm.power_state[state_index].clock_info[0].sclk =
@@ -2060,11 +2060,6 @@ static int radeon_atombios_parse_power_table_1_3(struct 
radeon_device *rdev)
state_index++;
break;
case 2:
-   rdev->pm.power_state[state_index].clock_info =
-   kzalloc(sizeof(struct radeon_pm_clock_info) * 
1, GFP_KERNEL);
-   if (!rdev->pm.power_state[state_index].clock_info)
-   return state_index;
-   rdev->pm.power_state[state_index].num_clock_modes = 1;
rdev->pm.power_state[state_index].clock_info[0].mclk =

le32_to_cpu(power_info->info_2.asPowerPlayInfo[i].ulMemoryClock);
rdev->pm.power_state[state_index].clock_info[0].sclk =
@@ -2101,11 +2096,6 @@ static int radeon_atombios_parse_power_table_1_3(struct 
radeon_device *rdev)
state_index++;
break;
case 3:
-   rdev->pm.power_state[state_index].clock_info =
-   kzalloc(sizeof(struct radeon_pm_clock_info) * 
1, GFP_KERNEL);
-   if (!rdev->pm.power_state[state_index].clock_info)
-   return state_index;
-   rdev->pm.power_state[state_index].num_clock_modes = 1;
rdev->pm.power_state[state_index].clock_info[0].mclk =

le32_to_cpu(power_info->info_3.asPowerPlayInfo[i].ulMemoryClock);
rdev->pm.power_state[state_index].clock_info[0].sclk =
-- 
1.7.3.4

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

On 11/14/2011 05:02 PM, Jerome Glisse wrote:
> On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom  
> wrote:
>
>> On 11/11/2011 11:47 PM, j.glisse at gmail.com wrote:
>>  
>>> So attached is updated serie of patch with fixes for swaping issue
>>> that also impacted memory accounting.
>>>
>> Jerome,
>> Out of interest, what was the swapping issue?
>>
>> /Thomas
>>
>>
>>  
> The page list was NULL and some access ended up freaking the kernel
> and oom kicked in for some reason i still don't understand. Bottom
> line things were going south in a split second leaving me with no log
> or access, i thought it was accounting not working as it was what i
> tested at the time. I should have tested accouting without the
> patchset
>
> Cheers,
> Jerome
>

Still, I think you have a point in the fact that *when* finally the OOM 
killer kicks in,
it probably doesn't have a way to associate user-space created bos with 
processes
and kill the right process.

/Thomas

[PATCH 00/23] kill drm cruft with fire

2011-11-14 Thread James Simmons


> > Should I test this set of patches for the VIA driver or wait until you 
> > have a second version of this patch?
> 
> Testing this on via would be awesome! Iirc I haven't changed anything in
> the via specific patches, but if it's more convenient you can also
> directly test my branch:
> 
> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire

Okay I tried the patches and it locked up the openchrome X server. I'm 
going to try your branch tonight to see if it makes any difference. If it 
still fails I will have to track down what the problem is.

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

On 11/11/2011 11:47 PM, j.glisse at gmail.com wrote:
> So attached is updated serie of patch with fixes for swaping issue
> that also impacted memory accounting.

Jerome,
Out of interest, what was the swapping issue?

/Thomas



>   Last patch fix memory accounting
> for radeon&  nouveau. I think it's ready to go into drm-next, patchset
> is against linus tree as there is thing there not in next that conflict.
> (in radeon iirc)
>
> Cheers,
> Jerome
>
>

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

2011-11-14 Thread Rob Clark

On Mon, Nov 14, 2011 at 3:16 PM, Ville Syrj?l?
 wrote:
> On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
>> +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) << 8) | \
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ((u32)(c) << 16) | ((u32)(d) << 24))
>> +
>> +/* RGB codes */
>> +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
>> +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
>> +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
>> +#define DRM_FOURCC_RGB24 ?fourcc_code('R','G','B','3')
>> +#define DRM_FOURCC_RGB32 ?fourcc_code('R','G','B','4')
>> +
>> +#define DRM_FOURCC_BGR24 ?fourcc_code('B','G','R','3')
>> +#define DRM_FOURCC_BGR32 ?fourcc_code('B','G','R','4')
>
> I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
> formats, so why do we need the RGB/BGR32 variants? If the difference
> is in the alpha channel, I'd like to document that fact in the name.
>
> Could we call them ARGB, XRGB, XRGB1555 etc.?
>
> Also the channel and byte order should be documented clearly.
>
> And one other thing. I probably wouldn't call these fourccs
> since they don't actually match the official fourccs. Not that
> there is anything sensible defined for RGB formats in the
> official list anyway. In fact, I'm not sure what we gain by
> cooking our own fourccs when we know most of them won't match
> the official list. AFAICS a simple running number would do
> just as well as the format identifier.

I expect that v4l just made up their own fourcc values for some of the
RGB formats..  which isn't a horrible idea, and seems worthwhile to be
aligned with names/values that v4l already picked.  At least then we
don't have two different sets of more or less arbitrary rgb fourcc
names..

BR,
-R

> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

DRM KMS Modesetting

On Mon, 14 Nov 2011 21:47:09 +0100
David Herrmann  wrote:
> > I had to modify the resolution the test was searching for
> > to 1920x1200 instead of 1024x600 since I tested on a DP attached
> > monitor, and fix the connector id, but other than that it seemed to
> > work fine.
> 
> Thanks for testing. At least my code seems right now, but I still
> cannot get it to work on my machine. The output of modetest is:
> https://gist.github.com/1365083
> 
> There is only one connected connector+encoder+mode so I don't know
> where the problem exactly is. Are there any debug options? Is it
> possible to query the EGLImage for width/height?

Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
width/stride correctly somewhere then.  You'd have to walk through the
gbm_dri2.c and egl_dri2.c code and see where the width is going off
into the weeds.

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/f1c2bf50/attachment.pgp>

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, 15 Nov 2011 00:37:47 +0200
Ville Syrj?l?  wrote:

> On Mon, Nov 14, 2011 at 01:35:57PM -0800, Jesse Barnes wrote:
> > On Mon, 14 Nov 2011 23:24:55 +0200
> > Ville Syrj?l?  wrote:
> > 
> > > On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> > > > +struct drm_mode_fb_cmd2 {
> > > > +   __u32 fb_id;
> > > > +   __u32 width, height;
> > > > +   __u32 pixel_format; /* fourcc code from videodev2.h */
> > > > +
> > > > +   /*
> > > > +* In case of planar formats, this ioctl allows up to 4
> > > > +* buffer objects with offets and pitches per plane.
> > > > +* The pitch and offset order is dictated by the fourcc,
> > > > +* e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
> > > > +*
> > > > +*   YUV 4:2:0 image with a plane of 8 bit Y samples
> > > > +*   followed by an interleaved U/V plane containing
> > > > +*   8 bit 2x2 subsampled colour difference samples.
> > > > +*
> > > > +* So it would consist of Y as offset[0] and UV as
> > > > +* offeset[1].  Note that offset[0] will generally
> > > > +* be 0.
> > > > +*/
> > > > +   __u32 handles[4];
> > > > +   __u32 pitches[4]; /* pitch for each plane */
> > > > +   __u32 offsets[4]; /* offset of each plane */
> > > > +};
> > > 
> > > Hey, what about those interlaced buffers? We talked privately about
> > > adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
> > > drm_mode_set_plane.
> > > 
> > > We could stick something like these to those flags:
> > > fb_cmd2.flags:
> > > #define DRM_MODE_FB_INTERLACED 0x1
> > > 
> > > set_plane.flags:
> > > #define DRM_MODE_PRESENT_TOP_FIELD 0x1
> > > #define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2
> > 
> > Oh sorry I lost track of the internal discussion.
> > 
> > Are those attributes of the fb or of each object?  E.g. could you mix
> > interlaced and non-interlaced buffers in a planar format?
> 
> I suppose it might be possible that you'd want to treat luma as
> interlaced and chroma as progressive under some circumstances.
> But I can't see why simply defining another flag for that wouldn't
> be enough.
> 
> > Maybe I need to rename this ioctl to addfb_swissarmyknife :)
> 
> Now I'm just waiting for someone to jump in and say that they 
> want independent buffers for each interlaced field :)
> 
> Me? I'll be happy with just those two flags members... for now at least ;)

Ok, added, see the latest patchset.

Dave, please pound the gavel on this now and declare it sold before
someone asks me to add braille support. :)

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/f8ca6895/attachment.pgp>

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v5

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)

Signed-off-by: Ville Syrj?l? 
Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_crtc.c|  111 +++--
 drivers/gpu/drm/drm_crtc_helper.c |   51 -
 drivers/gpu/drm/drm_drv.c |1 +
 drivers/gpu/drm/i915/intel_display.c  |   39 ++-
 drivers/gpu/drm/i915/intel_drv.h  |2 +-
 drivers/gpu/drm/i915/intel_fb.c   |   11 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c |6 +-
 drivers/gpu/drm/nouveau/nouveau_fb.h  |2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |   13 ++--
 drivers/gpu/drm/radeon/radeon_display.c   |8 +-
 drivers/gpu/drm/radeon/radeon_fb.c|   18 +++--
 drivers/gpu/drm/radeon/radeon_mode.h  |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   22 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |1 +
 drivers/staging/gma500/framebuffer.c  |2 +-
 include/drm/drm.h |1 +
 include/drm/drm_crtc.h|9 ++-
 include/drm/drm_crtc_helper.h |4 +-
 include/drm/drm_fourcc.h  |   63 
 include/drm/drm_mode.h|   27 +++
 20 files changed, 327 insertions(+), 66 deletions(-)
 create mode 100644 include/drm/drm_fourcc.h

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 804ef12..30a70a4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -35,6 +35,7 @@
 #include "drmP.h"
 #include "drm_crtc.h"
 #include "drm_edid.h"
+#include "drm_fourcc.h"

 struct drm_prop_enum_list {
int type;
@@ -563,7 +564,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
return -ENOMEM;
}

-   memcpy(plane->format_types, formats, format_count);
+   memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;

@@ -1910,6 +1911,42 @@ out:
return ret;
 }

+/* Original addfb only supported RGB formats, so figure out which one */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+   uint32_t fmt;
+
+   switch (bpp) {
+   case 8:
+   fmt = DRM_FOURCC_RGB332;
+   break;
+   case 16:
+   if (depth == 15)
+   fmt = DRM_FOURCC_RGB555;
+   else
+   fmt = DRM_FOURCC_RGB565;
+   break;
+   case 24:
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   case 32:
+   if (depth == 24)
+   fmt = DRM_FOURCC_RGB24;
+   else if (depth == 30)
+   fmt = DRM_INTEL_RGB30;
+   else
+   fmt = DRM_FOURCC_RGB32;
+   break;
+   default:
+   DRM_ERROR("bad bpp, assuming RGB24 pixel format\n");
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   }
+
+   return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
 /**
  * drm_mode_addfb - add an FB to the graphics configuration
  * @inode: inode from the ioctl
@@ -1930,7 +1967,74 @@ out:
 int drm_mode_addfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
-   struct drm_mode_fb_cmd *r = data;
+   struct drm_mode_fb_cmd *or = data;
+   struct drm_mode_fb_cmd2 r = {};
+   struct drm_mode_config *config = >mode_config;
+   struct drm_framebuffer *fb;
+   int ret = 0;
+
+   /* Use new struct with format internally */
+   r.fb_id = or->fb_id;
+   r.width = or->width;
+   r.height = or->height;
+   r.pitches[0] = or->pitch;
+   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
+   r.handles[0] = or->handle;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if ((config->min_width > r.width) || (r.width > config->max_width)) {
+   DRM_ERROR("mode new framebuffer width not within limits\n");
+   return -EINVAL;
+   }
+   if

[PATCH 1/2] drm: add plane support v3

Planes are a bit like half-CRTCs.  They have a location and fb, but
don't drive outputs directly.  Add support for handling them to the core
KMS code.

v2: fix ABI of get_plane - move format_type_ptr to the end
v3: add 'flags' field for interlaced support (from Ville)

Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_crtc.c |  257 +++-
 drivers/gpu/drm/drm_drv.c  |3 +
 include/drm/drm.h  |3 +
 include/drm/drm_crtc.h |   75 +-
 include/drm/drm_mode.h |   37 +++
 5 files changed, 372 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..804ef12 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
struct drm_crtc *crtc;
+   struct drm_plane *plane;
struct drm_mode_set set;
int ret;

@@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}

+   list_for_each_entry(plane, >mode_config.plane_list, head) {
+   if (plane->fb == fb) {
+   /* should turn off the crtc */
+   ret = plane->funcs->disable_plane(plane);
+   if (ret)
+   DRM_ERROR("failed to disable plane with busy 
fb\n");
+   }
+   }
+
drm_mode_object_put(dev, >base);
list_del(>head);
dev->mode_config.num_fb--;
@@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
 }
 EXPORT_SYMBOL(drm_encoder_cleanup);

+int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+  unsigned long possible_crtcs,
+  const struct drm_plane_funcs *funcs,
+  uint32_t *formats, uint32_t format_count)
+{
+   mutex_lock(>mode_config.mutex);
+
+   plane->dev = dev;
+   drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
+   plane->funcs = funcs;
+   plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+   if (!plane->format_types) {
+   DRM_DEBUG_KMS("out of memory when allocating plane\n");
+   drm_mode_object_put(dev, >base);
+   return -ENOMEM;
+   }
+
+   memcpy(plane->format_types, formats, format_count);
+   plane->format_count = format_count;
+   plane->possible_crtcs = possible_crtcs;
+
+   list_add_tail(>head, >mode_config.plane_list);
+   dev->mode_config.num_plane++;
+
+   mutex_unlock(>mode_config.mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+   struct drm_device *dev = plane->dev;
+
+   mutex_lock(>mode_config.mutex);
+   kfree(plane->format_types);
+   drm_mode_object_put(dev, >base);
+   list_del(>head);
+   dev->mode_config.num_plane--;
+   mutex_unlock(>mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
 /**
  * drm_mode_create - create a new display mode
  * @dev: DRM device
@@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(>mode_config.encoder_list);
INIT_LIST_HEAD(>mode_config.property_list);
INIT_LIST_HEAD(>mode_config.property_blob_list);
+   INIT_LIST_HEAD(>mode_config.plane_list);
idr_init(>mode_config.crtc_idr);

mutex_lock(>mode_config.mutex);
@@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_encoder *encoder, *enct;
struct drm_framebuffer *fb, *fbt;
struct drm_property *property, *pt;
+   struct drm_plane *plane, *plt;

list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
 head) {
@@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
crtc->funcs->destroy(crtc);
}

+   list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
+head) {
+   plane->funcs->destroy(plane);
+   }
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);

@@ -1466,6 +1526,197 @@ out:
 }

 /**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_mode_get_plane_res *plane_resp = data;
+   struct drm_mode_config *config;
+   struct drm_plane *plane;
+   uint32_t __user *plane_ptr;
+   int copied = 0, ret = 0;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+

[PATCH] drm/radeon/kms: fix up gpio i2c mask bits for r4xx

2011-11-14 Thread alexdeuc...@gmail.com

From: Alex Deucher 

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
Cc: Jean Delvare 
---
 drivers/gpu/drm/radeon/radeon_atombios.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index bcb88f1..6b5fbc9 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -89,6 +89,18 @@ static struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_device *rd
for (i = 0; i < num_indices; i++) {
gpio = _info->asGPIO_Info[i];

+   /* r4xx mask is technically not used by the hw, so 
patch in the legacy mask bits */
+   if ((rdev->family == CHIP_R420) ||
+   (rdev->family == CHIP_R423) ||
+   (rdev->family == CHIP_RV410)) {
+   if ((le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0018) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x0019) ||
+   (le16_to_cpu(gpio->usClkMaskRegisterIndex) 
== 0x001a)) {
+   gpio->ucClkMaskShift = 0x19;
+   gpio->ucDataMaskShift = 0x18;
+   }
+   }
+
/* some evergreen boards have bad data for this entry */
if (ASIC_IS_DCE4(rdev)) {
if ((i == 7) &&
-- 
1.7.3.4

Strange effect with i915 backlight controller

At Mon, 14 Nov 2011 13:03:46 +0100,
Daniel Mack wrote:
> 
> On 11/14/2011 11:39 AM, Takashi Iwai wrote:
> > [Added Chris to Cc]
> > 
> > At Sun, 13 Nov 2011 17:24:09 +0100,
> > Daniel Mack wrote:
> >>
> >> Hi Takashi,
> >>
> >> On 11/10/2011 04:39 PM, Takashi Iwai wrote:
> >>> At Thu, 10 Nov 2011 16:11:29 +0100,
> >>> Daniel Mack wrote:
> 
>  On 11/08/2011 01:57 AM, Daniel Mack wrote:
> > Didn't get any response yet, hence copying LKML for a broader audience.
> 
>  Nobody, really?
> 
>  This is a rather annoying regression, as touching the brightness keys
>  appearantly switches off the whole machine. I'm sure this is trivial to
>  fix, I just don't have the insight of this driver and the chipset.
> >>>
> >>> I vaguely remember that the bit 0 is invalid on some old chips.
> >>> Maybe 915GM is one of them, as it's gen3?  If so, the patch like below
> >>> may work.
> >>
> >> Thank you for looking into this.
> >>
> >>> ---
> >>> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> >>> b/drivers/gpu/drm/i915/intel_panel.c
> >>> index 499d4c0..be952d1 100644
> >>> --- a/drivers/gpu/drm/i915/intel_panel.c
> >>> +++ b/drivers/gpu/drm/i915/intel_panel.c
> >>> @@ -249,8 +249,11 @@ static void 
> >>> intel_panel_actually_set_backlight(struct drm_device *dev, u32 level
> >>>   if (IS_PINEVIEW(dev)) {
> >>>   tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
> >>>   level <<= 1;
> >>> - } else
> >>> + } else {
> >>>   tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
> >>> + if (INTEL_INFO(dev)->gen < 4)
> >>> + tmp &= ~1;
> >>> + }
> >>>   I915_WRITE(BLC_PWM_CTL, tmp | level);
> >>>  }
> >>>  
> >>
> >> This seems to be the right intention, but the value you want to modify
> >> under this condition is 'level', not 'tmp'.
> > 
> > Ah, of course.  Sorry for that.
> > 
> >> With this amendment of your
> >> patch, things work perfectly fine here.
> > 
> > OK, then perhaps a better fix is to change the check to be equivalent
> > with pineview, as you mentioned in the original post.  The handling of
> > bit 0 for old chips was lost during the refactoring of backlight code
> > since 2.6.37.
> > 
> > Does the patch below work for you?
> 
> Will test, but I only have occasional access to the machine, so this
> will have to wait for some days.

It's an old bug over a year, so no need to hurry.


Takashi

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote:
> On 11/14/2011 05:02 PM, Jerome Glisse wrote:
> >On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom  
> >wrote:
> >>On 11/11/2011 11:47 PM, j.glisse at gmail.com wrote:
> >>>So attached is updated serie of patch with fixes for swaping issue
> >>>that also impacted memory accounting.
> >>Jerome,
> >>Out of interest, what was the swapping issue?
> >>
> >>/Thomas
> >>
> >>
> >The page list was NULL and some access ended up freaking the kernel
> >and oom kicked in for some reason i still don't understand. Bottom
> >line things were going south in a split second leaving me with no log
> >or access, i thought it was accounting not working as it was what i
> >tested at the time. I should have tested accouting without the
> >patchset
> >
> >Cheers,
> >Jerome
> 
> Still, I think you have a point in the fact that *when* finally the
> OOM killer kicks in,
> it probably doesn't have a way to associate user-space created bos
> with processes
> and kill the right process.
> 
> /Thomas
> 

Btw can you review patch 14 as it touch vmwgfx, i am pretty sure
i got it right.

Cheers,
Jerome

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, 14 Nov 2011 23:24:55 +0200
Ville Syrj?l?  wrote:

> On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> > +struct drm_mode_fb_cmd2 {
> > +   __u32 fb_id;
> > +   __u32 width, height;
> > +   __u32 pixel_format; /* fourcc code from videodev2.h */
> > +
> > +   /*
> > +* In case of planar formats, this ioctl allows up to 4
> > +* buffer objects with offets and pitches per plane.
> > +* The pitch and offset order is dictated by the fourcc,
> > +* e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
> > +*
> > +*   YUV 4:2:0 image with a plane of 8 bit Y samples
> > +*   followed by an interleaved U/V plane containing
> > +*   8 bit 2x2 subsampled colour difference samples.
> > +*
> > +* So it would consist of Y as offset[0] and UV as
> > +* offeset[1].  Note that offset[0] will generally
> > +* be 0.
> > +*/
> > +   __u32 handles[4];
> > +   __u32 pitches[4]; /* pitch for each plane */
> > +   __u32 offsets[4]; /* offset of each plane */
> > +};
> 
> Hey, what about those interlaced buffers? We talked privately about
> adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
> drm_mode_set_plane.
> 
> We could stick something like these to those flags:
> fb_cmd2.flags:
> #define DRM_MODE_FB_INTERLACED 0x1
> 
> set_plane.flags:
> #define DRM_MODE_PRESENT_TOP_FIELD 0x1
> #define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2

Oh sorry I lost track of the internal discussion.

Are those attributes of the fb or of each object?  E.g. could you mix
interlaced and non-interlaced buffers in a planar format?

Maybe I need to rename this ioctl to addfb_swissarmyknife :)

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/702ddef2/attachment.pgp>

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, 14 Nov 2011 23:16:44 +0200
Ville Syrj?l?  wrote:

> On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> > +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) << 8) | \
> > + ((u32)(c) << 16) | ((u32)(d) << 24))
> > +
> > +/* RGB codes */
> > +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
> > +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
> > +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
> > +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
> > +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
> > +
> > +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
> > +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')
> 
> I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
> formats, so why do we need the RGB/BGR32 variants? If the difference
> is in the alpha channel, I'd like to document that fact in the name.
> 
> Could we call them ARGB, XRGB, XRGB1555 etc.?

Yeah, the fourcc naming isn't very good, I'd have no problem changing
the names to something more descriptive for 24 and 32.  fourcc.org
itself seems ambiguous about the 24 bit format

> Also the channel and byte order should be documented clearly.

Supposedly the fourcc code is supposed to provide that?

> And one other thing. I probably wouldn't call these fourccs
> since they don't actually match the official fourccs. Not that
> there is anything sensible defined for RGB formats in the
> official list anyway. In fact, I'm not sure what we gain by
> cooking our own fourccs when we know most of them won't match
> the official list. AFAICS a simple running number would do
> just as well as the format identifier.

They seem to match what's at fourcc.org, though I don't see the upper
byte documented, and also share values with the v4l stuff, which I was
assuming had the right fourcc codes.

If we don't match, we should strive to.  I'm just using what I find at
fourcc.org and in the v4l code to check...

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/6477813f/attachment.pgp>

Strange effect with i915 backlight controller

2011-11-14 Thread Daniel Mack

On 11/14/2011 11:39 AM, Takashi Iwai wrote:
> [Added Chris to Cc]
> 
> At Sun, 13 Nov 2011 17:24:09 +0100,
> Daniel Mack wrote:
>>
>> Hi Takashi,
>>
>> On 11/10/2011 04:39 PM, Takashi Iwai wrote:
>>> At Thu, 10 Nov 2011 16:11:29 +0100,
>>> Daniel Mack wrote:

 On 11/08/2011 01:57 AM, Daniel Mack wrote:
> Didn't get any response yet, hence copying LKML for a broader audience.

 Nobody, really?

 This is a rather annoying regression, as touching the brightness keys
 appearantly switches off the whole machine. I'm sure this is trivial to
 fix, I just don't have the insight of this driver and the chipset.
>>>
>>> I vaguely remember that the bit 0 is invalid on some old chips.
>>> Maybe 915GM is one of them, as it's gen3?  If so, the patch like below
>>> may work.
>>
>> Thank you for looking into this.
>>
>>> ---
>>> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
>>> b/drivers/gpu/drm/i915/intel_panel.c
>>> index 499d4c0..be952d1 100644
>>> --- a/drivers/gpu/drm/i915/intel_panel.c
>>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>>> @@ -249,8 +249,11 @@ static void intel_panel_actually_set_backlight(struct 
>>> drm_device *dev, u32 level
>>> if (IS_PINEVIEW(dev)) {
>>> tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
>>> level <<= 1;
>>> -   } else
>>> +   } else {
>>> tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
>>> +   if (INTEL_INFO(dev)->gen < 4)
>>> +   tmp &= ~1;
>>> +   }
>>> I915_WRITE(BLC_PWM_CTL, tmp | level);
>>>  }
>>>  
>>
>> This seems to be the right intention, but the value you want to modify
>> under this condition is 'level', not 'tmp'.
> 
> Ah, of course.  Sorry for that.
> 
>> With this amendment of your
>> patch, things work perfectly fine here.
> 
> OK, then perhaps a better fix is to change the check to be equivalent
> with pineview, as you mentioned in the original post.  The handling of
> bit 0 for old chips was lost during the refactoring of backlight code
> since 2.6.37.
> 
> Does the patch below work for you?

Will test, but I only have occasional access to the machine, so this
will have to wait for some days.

> The only concern by this fix is that it changes the max value.  If
> apps expect some certain (e.g. recorded) value, it may screw up.  But
> I don't expect this would happen with sane apps.

I don't think so either.


Thanks,
Daniel

DRM KMS Modesetting

On Mon, 14 Nov 2011 21:25:56 +0100
David Herrmann  wrote:

> Hi
> 
> I thought it's better to ask this question here again as it is easier
> to comment via mail.
> 
> I tried writing a simple kms modesetting program. I have written it similar 
> to:
> http://virtuousgeek.org/blog/index.php/jbarnes?blog=2=writing_stanalone_programs_with_egl_and_
> and wayland compositor-drm.c
> and modetest.c in libdrm/tests
> 
> My problem is, the program compiles and runs fine, however, the
> framebuffer is only displayed on the left quarter of the screen. The
> vertical size is perfect but the horizontal size is just the left
> quarter. I've double checked all the drm parameters and they are equal
> to the ones in modetest.c and compositor-drm.c.
> 
> ./modetest runs fine and also reports only a single mode and encoder
> for my connector so I cannot choose the wrong mode, either.
> 
> The code is here:
> https://gist.github.com/1364994
> It should compile fine with:
> gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`
> 
> I would be glad if someone could run this or look over the code.

Hm I get a full white screen with a gray triangle in the lower right
hand corner.  I had to modify the resolution the test was searching for
to 1920x1200 instead of 1024x600 since I tested on a DP attached
monitor, and fix the connector id, but other than that it seemed to
work fine.

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/a68fc87c/attachment.pgp>

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb

Signed-off-by: Ville Syrj?l? 
Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_crtc.c|  111 +++--
 drivers/gpu/drm/drm_crtc_helper.c |   51 -
 drivers/gpu/drm/drm_drv.c |1 +
 drivers/gpu/drm/i915/intel_display.c  |   39 ++-
 drivers/gpu/drm/i915/intel_drv.h  |2 +-
 drivers/gpu/drm/i915/intel_fb.c   |   11 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c |6 +-
 drivers/gpu/drm/nouveau/nouveau_fb.h  |2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |   13 ++--
 drivers/gpu/drm/radeon/radeon_display.c   |8 +-
 drivers/gpu/drm/radeon/radeon_fb.c|   18 +++--
 drivers/gpu/drm/radeon/radeon_mode.h  |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   22 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |1 +
 drivers/staging/gma500/framebuffer.c  |2 +-
 include/drm/drm.h |1 +
 include/drm/drm_crtc.h|9 ++-
 include/drm/drm_crtc_helper.h |4 +-
 include/drm/drm_fourcc.h  |   63 
 include/drm/drm_mode.h|   24 ++
 20 files changed, 324 insertions(+), 66 deletions(-)
 create mode 100644 include/drm/drm_fourcc.h

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 804ef12..30a70a4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -35,6 +35,7 @@
 #include "drmP.h"
 #include "drm_crtc.h"
 #include "drm_edid.h"
+#include "drm_fourcc.h"

 struct drm_prop_enum_list {
int type;
@@ -563,7 +564,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
return -ENOMEM;
}

-   memcpy(plane->format_types, formats, format_count);
+   memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;

@@ -1910,6 +1911,42 @@ out:
return ret;
 }

+/* Original addfb only supported RGB formats, so figure out which one */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+   uint32_t fmt;
+
+   switch (bpp) {
+   case 8:
+   fmt = DRM_FOURCC_RGB332;
+   break;
+   case 16:
+   if (depth == 15)
+   fmt = DRM_FOURCC_RGB555;
+   else
+   fmt = DRM_FOURCC_RGB565;
+   break;
+   case 24:
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   case 32:
+   if (depth == 24)
+   fmt = DRM_FOURCC_RGB24;
+   else if (depth == 30)
+   fmt = DRM_INTEL_RGB30;
+   else
+   fmt = DRM_FOURCC_RGB32;
+   break;
+   default:
+   DRM_ERROR("bad bpp, assuming RGB24 pixel format\n");
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   }
+
+   return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
 /**
  * drm_mode_addfb - add an FB to the graphics configuration
  * @inode: inode from the ioctl
@@ -1930,7 +1967,74 @@ out:
 int drm_mode_addfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
-   struct drm_mode_fb_cmd *r = data;
+   struct drm_mode_fb_cmd *or = data;
+   struct drm_mode_fb_cmd2 r = {};
+   struct drm_mode_config *config = >mode_config;
+   struct drm_framebuffer *fb;
+   int ret = 0;
+
+   /* Use new struct with format internally */
+   r.fb_id = or->fb_id;
+   r.width = or->width;
+   r.height = or->height;
+   r.pitches[0] = or->pitch;
+   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
+   r.handles[0] = or->handle;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if ((config->min_width > r.width) || (r.width > config->max_width)) {
+   DRM_ERROR("mode new framebuffer width not within limits\n");
+   return -EINVAL;
+   }
+   if ((config->min_height > r.height) || (r.height > config->max_height)) 
{
+

[PATCH 1/2] drm: add plane support v2

Planes are a bit like half-CRTCs.  They have a location and fb, but
don't drive outputs directly.  Add support for handling them to the core
KMS code.

v2: fix ABI of get_plane - move format_type_ptr to the end

Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_crtc.c |  257 +++-
 drivers/gpu/drm/drm_drv.c  |3 +
 include/drm/drm.h  |3 +
 include/drm/drm_crtc.h |   75 +-
 include/drm/drm_mode.h |   33 ++
 5 files changed, 368 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..804ef12 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
struct drm_crtc *crtc;
+   struct drm_plane *plane;
struct drm_mode_set set;
int ret;

@@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}

+   list_for_each_entry(plane, >mode_config.plane_list, head) {
+   if (plane->fb == fb) {
+   /* should turn off the crtc */
+   ret = plane->funcs->disable_plane(plane);
+   if (ret)
+   DRM_ERROR("failed to disable plane with busy 
fb\n");
+   }
+   }
+
drm_mode_object_put(dev, >base);
list_del(>head);
dev->mode_config.num_fb--;
@@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
 }
 EXPORT_SYMBOL(drm_encoder_cleanup);

+int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+  unsigned long possible_crtcs,
+  const struct drm_plane_funcs *funcs,
+  uint32_t *formats, uint32_t format_count)
+{
+   mutex_lock(>mode_config.mutex);
+
+   plane->dev = dev;
+   drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
+   plane->funcs = funcs;
+   plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+   if (!plane->format_types) {
+   DRM_DEBUG_KMS("out of memory when allocating plane\n");
+   drm_mode_object_put(dev, >base);
+   return -ENOMEM;
+   }
+
+   memcpy(plane->format_types, formats, format_count);
+   plane->format_count = format_count;
+   plane->possible_crtcs = possible_crtcs;
+
+   list_add_tail(>head, >mode_config.plane_list);
+   dev->mode_config.num_plane++;
+
+   mutex_unlock(>mode_config.mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+   struct drm_device *dev = plane->dev;
+
+   mutex_lock(>mode_config.mutex);
+   kfree(plane->format_types);
+   drm_mode_object_put(dev, >base);
+   list_del(>head);
+   dev->mode_config.num_plane--;
+   mutex_unlock(>mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
 /**
  * drm_mode_create - create a new display mode
  * @dev: DRM device
@@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(>mode_config.encoder_list);
INIT_LIST_HEAD(>mode_config.property_list);
INIT_LIST_HEAD(>mode_config.property_blob_list);
+   INIT_LIST_HEAD(>mode_config.plane_list);
idr_init(>mode_config.crtc_idr);

mutex_lock(>mode_config.mutex);
@@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_encoder *encoder, *enct;
struct drm_framebuffer *fb, *fbt;
struct drm_property *property, *pt;
+   struct drm_plane *plane, *plt;

list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
 head) {
@@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
crtc->funcs->destroy(crtc);
}

+   list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
+head) {
+   plane->funcs->destroy(plane);
+   }
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);

@@ -1466,6 +1526,197 @@ out:
 }

 /**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_mode_get_plane_res *plane_resp = data;
+   struct drm_mode_config *config;
+   struct drm_plane *plane;
+   uint32_t __user *plane_ptr;
+   int copied = 0, ret = 0;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(>mode_config.mutex);
+   config = >mode_config;
+
+   /*
+

[PATCH] intel-dri: Fix initialization if startup happens in interlaced mode [v2]

2011-11-14 Thread Christian Schmidt

My EFI BIOS starts the graphics card up in my projector's preferred EDID
mode, 1080 at 60i. The Intel driver does not clear the interlaced bit:

#define   PIPECONF_PROGRESSIVE  (0 << 21)
#define   PIPECONF_INTERLACE_W_FIELD_INDICATION (6 << 21)
#define   PIPECONF_INTERLACE_FIELD_0_ONLY   (7 << 21)

This patch introduces a new PIPECONF_INTERLACE_MASK define and uses it
to restore progressive mode.

Signed-of-by: Christian Schmidt 

-- next part --
A non-text attachment was scrubbed...
Name: fix_startup_in_interlaced_mode.patch
Type: text/x-patch
Size: 1241 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/6bfece8d/attachment.bin>

[PATCH 1/2] drm: add plane support v2

On Mon, 14 Nov 2011 11:47:06 -0800
Jesse Barnes  wrote:

> Planes are a bit like half-CRTCs.  They have a location and fb, but
> don't drive outputs directly.  Add support for handling them to the core
> KMS code.
> 
> v2: fix ABI of get_plane - move format_type_ptr to the end

Ok ignore these two; I botched the rebase and accidentally left in some
v4l stuff.

Since I had to re-post I confirmed with Rob about the multi-object API;
apparently a simple handle array will be enough, so that's included in
the next version.

I'll re-post one more time, this time with feeling.

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/c20e537c/attachment.pgp>

[Bug 42913] New: r600g: glx-swap-pixmap causes screen corruption

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

 Bug #: 42913
   Summary: r600g: glx-swap-pixmap causes screen corruption
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: debian at carbon-project.org


First: I don't think this is bug 40610 because I don't see a crash but screen
corruption and (sometimes) the following lines in dmesg:
> radeon :01:00.0: r600_check_texture_resource:1346 texture invalid format 0
> [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

But I'm no Mesa/Piglit expert, so my assumption might be wrong.

The Piglit test itself fails, the output is:
> Probe at (0,0)
>  Expected: 0.00 1.00 0.00 0.00
>  Observed: 0.00 0.00 1.00 1.00

Used stack:
Mesa: Git/9ae10e9c
libdrm: 2.4.27-1
Kernel: 3.1.1
X.org: 1.11.1.902-1

Let me know, if you need more information.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v2

On Mon, 14 Nov 2011 11:47:07 -0800
Jesse Barnes  wrote:

> To properly support the various plane formats supported by different
> hardware, the kernel must know the pixel format of a framebuffer object.
> So add a new ioctl taking a format argument corresponding to a fourcc
> name from videodev2.h.  Implement the fb creation hooks in terms of the
> new mode_fb_cmd2 using helpers where the old bpp/depth values are
> needed.
> 
> v2: create DRM specific fourcc header file for sharing with libdrm etc

These now contradict one another, can you fix the text up when you
apply?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2014/4397006a/attachment.pgp>

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v2

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.  Implement the fb creation hooks in terms of the
new mode_fb_cmd2 using helpers where the old bpp/depth values are
needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc

Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_crtc.c|  109 +++-
 drivers/gpu/drm/drm_crtc_helper.c |   51 -
 drivers/gpu/drm/drm_drv.c |1 +
 drivers/gpu/drm/i915/intel_display.c  |   36 +-
 drivers/gpu/drm/i915/intel_drv.h  |2 +-
 drivers/gpu/drm/i915/intel_fb.c   |   11 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c |4 +-
 drivers/gpu/drm/nouveau/nouveau_fb.h  |2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |   13 ++--
 drivers/gpu/drm/radeon/radeon_display.c   |4 +-
 drivers/gpu/drm/radeon/radeon_fb.c|   18 +++--
 drivers/gpu/drm/radeon/radeon_mode.h  |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   22 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |1 +
 drivers/staging/gma500/framebuffer.c  |2 +-
 include/drm/drm.h |1 +
 include/drm/drm_crtc.h|9 ++-
 include/drm/drm_crtc_helper.h |4 +-
 include/drm/drm_fourcc.h  |   63 +
 include/drm/drm_mode.h|   24 ++
 20 files changed, 318 insertions(+), 61 deletions(-)
 create mode 100644 include/drm/drm_fourcc.h

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 804ef12..f3be623 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -35,6 +35,7 @@
 #include "drmP.h"
 #include "drm_crtc.h"
 #include "drm_edid.h"
+#include "drm_fourcc.h"

 struct drm_prop_enum_list {
int type;
@@ -1910,6 +1911,42 @@ out:
return ret;
 }

+/* Original addfb only supported RGB formats, so figure out which one */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+   uint32_t fmt;
+
+   switch (bpp) {
+   case 8:
+   fmt = DRM_FOURCC_RGB332;
+   break;
+   case 16:
+   if (depth == 15)
+   fmt = DRM_FOURCC_RGB555;
+   else
+   fmt = DRM_FOURCC_RGB565;
+   break;
+   case 24:
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   case 32:
+   if (depth == 24)
+   fmt = DRM_FOURCC_RGB24;
+   else if (depth == 30)
+   fmt = DRM_INTEL_RGB30;
+   else
+   fmt = DRM_FOURCC_RGB32;
+   break;
+   default:
+   DRM_ERROR("bad bpp, assuming RGB24 pixel format\n");
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   }
+
+   return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
 /**
  * drm_mode_addfb - add an FB to the graphics configuration
  * @inode: inode from the ioctl
@@ -1930,7 +1967,74 @@ out:
 int drm_mode_addfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
-   struct drm_mode_fb_cmd *r = data;
+   struct drm_mode_fb_cmd *or = data;
+   struct drm_mode_fb_cmd2 r;
+   struct drm_mode_config *config = >mode_config;
+   struct drm_framebuffer *fb;
+   int ret = 0;
+
+   /* Use new struct with format internally */
+   r.fb_id = or->fb_id;
+   r.width = or->width;
+   r.height = or->height;
+   r.pitches[0] = or->pitch;
+   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
+   r.handle = or->handle;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if ((config->min_width > r.width) || (r.width > config->max_width)) {
+   DRM_ERROR("mode new framebuffer width not within limits\n");
+   return -EINVAL;
+   }
+   if ((config->min_height > r.height) || (r.height > config->max_height)) 
{
+   DRM_ERROR("mode new framebuffer height not within limits\n");
+   return -EINVAL;
+   }
+
+   mutex_lock(>mode_config.mutex);
+
+   /* TODO check buffer is sufficiently large */
+   /* TODO setup destructor callback */
+
+   fb = dev->mode_config.funcs->fb_create(dev, file_priv, );
+   if (IS_ERR(fb)) {
+   DRM_ERROR("could not create framebuffer\n");
+   ret = PTR_ERR(fb);
+   goto out;
+   }
+
+   or->fb_id = fb->base.id;
+   list_add(>filp_head, _priv->fbs);
+   DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
+
+out:
+   mutex_unlock(>mode_config.mutex);
+   return ret;
+}
+
+/**
+ * drm_mode_addfb2 -

[PATCH 1/2] drm: add plane support v2

Planes are a bit like half-CRTCs.  They have a location and fb, but
don't drive outputs directly.  Add support for handling them to the core
KMS code.

v2: fix ABI of get_plane - move format_type_ptr to the end

Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/drm_crtc.c |  257 +++-
 drivers/gpu/drm/drm_drv.c  |3 +
 include/drm/drm.h  |3 +
 include/drm/drm_crtc.h |   75 +-
 include/drm/drm_mode.h |   33 ++
 5 files changed, 368 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..804ef12 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
struct drm_crtc *crtc;
+   struct drm_plane *plane;
struct drm_mode_set set;
int ret;

@@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}

+   list_for_each_entry(plane, >mode_config.plane_list, head) {
+   if (plane->fb == fb) {
+   /* should turn off the crtc */
+   ret = plane->funcs->disable_plane(plane);
+   if (ret)
+   DRM_ERROR("failed to disable plane with busy 
fb\n");
+   }
+   }
+
drm_mode_object_put(dev, >base);
list_del(>head);
dev->mode_config.num_fb--;
@@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
 }
 EXPORT_SYMBOL(drm_encoder_cleanup);

+int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+  unsigned long possible_crtcs,
+  const struct drm_plane_funcs *funcs,
+  uint32_t *formats, uint32_t format_count)
+{
+   mutex_lock(>mode_config.mutex);
+
+   plane->dev = dev;
+   drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
+   plane->funcs = funcs;
+   plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+   if (!plane->format_types) {
+   DRM_DEBUG_KMS("out of memory when allocating plane\n");
+   drm_mode_object_put(dev, >base);
+   return -ENOMEM;
+   }
+
+   memcpy(plane->format_types, formats, format_count);
+   plane->format_count = format_count;
+   plane->possible_crtcs = possible_crtcs;
+
+   list_add_tail(>head, >mode_config.plane_list);
+   dev->mode_config.num_plane++;
+
+   mutex_unlock(>mode_config.mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+   struct drm_device *dev = plane->dev;
+
+   mutex_lock(>mode_config.mutex);
+   kfree(plane->format_types);
+   drm_mode_object_put(dev, >base);
+   list_del(>head);
+   dev->mode_config.num_plane--;
+   mutex_unlock(>mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
 /**
  * drm_mode_create - create a new display mode
  * @dev: DRM device
@@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(>mode_config.encoder_list);
INIT_LIST_HEAD(>mode_config.property_list);
INIT_LIST_HEAD(>mode_config.property_blob_list);
+   INIT_LIST_HEAD(>mode_config.plane_list);
idr_init(>mode_config.crtc_idr);

mutex_lock(>mode_config.mutex);
@@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_encoder *encoder, *enct;
struct drm_framebuffer *fb, *fbt;
struct drm_property *property, *pt;
+   struct drm_plane *plane, *plt;

list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
 head) {
@@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
crtc->funcs->destroy(crtc);
}

+   list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
+head) {
+   plane->funcs->destroy(plane);
+   }
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);

@@ -1466,6 +1526,197 @@ out:
 }

 /**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_mode_get_plane_res *plane_resp = data;
+   struct drm_mode_config *config;
+   struct drm_plane *plane;
+   uint32_t __user *plane_ptr;
+   int copied = 0, ret = 0;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(>mode_config.mutex);
+   config = >mode_config;
+
+   /*
+

Strange effect with i915 backlight controller

[Added Chris to Cc]

At Sun, 13 Nov 2011 17:24:09 +0100,
Daniel Mack wrote:
> 
> Hi Takashi,
> 
> On 11/10/2011 04:39 PM, Takashi Iwai wrote:
> > At Thu, 10 Nov 2011 16:11:29 +0100,
> > Daniel Mack wrote:
> >>
> >> On 11/08/2011 01:57 AM, Daniel Mack wrote:
> >>> Didn't get any response yet, hence copying LKML for a broader audience.
> >>
> >> Nobody, really?
> >>
> >> This is a rather annoying regression, as touching the brightness keys
> >> appearantly switches off the whole machine. I'm sure this is trivial to
> >> fix, I just don't have the insight of this driver and the chipset.
> > 
> > I vaguely remember that the bit 0 is invalid on some old chips.
> > Maybe 915GM is one of them, as it's gen3?  If so, the patch like below
> > may work.
> 
> Thank you for looking into this.
> 
> > ---
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index 499d4c0..be952d1 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -249,8 +249,11 @@ static void intel_panel_actually_set_backlight(struct 
> > drm_device *dev, u32 level
> > if (IS_PINEVIEW(dev)) {
> > tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
> > level <<= 1;
> > -   } else
> > +   } else {
> > tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
> > +   if (INTEL_INFO(dev)->gen < 4)
> > +   tmp &= ~1;
> > +   }
> > I915_WRITE(BLC_PWM_CTL, tmp | level);
> >  }
> >  
> 
> This seems to be the right intention, but the value you want to modify
> under this condition is 'level', not 'tmp'.

Ah, of course.  Sorry for that.

> With this amendment of your
> patch, things work perfectly fine here.

OK, then perhaps a better fix is to change the check to be equivalent
with pineview, as you mentioned in the original post.  The handling of
bit 0 for old chips was lost during the refactoring of backlight code
since 2.6.37.

Does the patch below work for you?

The only concern by this fix is that it changes the max value.  If
apps expect some certain (e.g. recorded) value, it may screw up.  But
I don't expect this would happen with sane apps.


thanks,

Takashi

===
From: Takashi Iwai 
Subject: drm/i915: Fix invalid backpanel values for GEN3 or older chips

While refactoring of backlight control code in commit [a95735569:
drm/i915: Refactor panel backlight controls], the handling of the bit
0 of duty-cycle was gone except for pineview.  This resulted in invalid
register values for old chips like 915GM.  When the bit 0 is set, the
backlight is turned off suddenly.

This patch changes the bit-0 check by replacing with the condition of
gen < 4 (pineview is included in this condition, too).

Reported-by: Daniel Mack 
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/intel_panel.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 499d4c0..737d00f 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -178,12 +178,10 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
max >>= 16;
} else {
-   if (IS_PINEVIEW(dev)) {
+   if (INTEL_INFO(dev)->gen < 4) {
max >>= 17;
} else {
max >>= 16;
-   if (INTEL_INFO(dev)->gen < 4)
-   max &= ~1;
}

if (is_backlight_combination_mode(dev))
@@ -203,7 +201,7 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CPU_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
} else {
val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
-   if (IS_PINEVIEW(dev))
+   if (INTEL_INFO(dev)->gen < 4)
val >>= 1;

if (is_backlight_combination_mode(dev)) {
@@ -246,7 +244,7 @@ static void intel_panel_actually_set_backlight(struct 
drm_device *dev, u32 level
}

tmp = I915_READ(BLC_PWM_CTL);
-   if (IS_PINEVIEW(dev)) {
+   if (INTEL_INFO(dev)->gen < 4) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level <<= 1;
} else
-- 
1.7.7

[Bug 42908] r600g: glx-shader-sharing causes segfault

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

Kai  changed:

   What|Removed |Added

   Platform|Other   |x86-64 (AMD64)
 OS/Version|All |Linux (All)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 42908] New: r600g: glx-shader-sharing causes segfault

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

 Bug #: 42908
   Summary: r600g: glx-shader-sharing causes segfault
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: debian at carbon-project.org


Created attachment 53511
  --> https://bugs.freedesktop.org/attachment.cgi?id=53511
GDB ouput for the crash

I'm currently trying to find the Piglit test (it's one of the GLX tests run by
r600.tests), that causes screen corruption. In the process I hit a segfault in
r600_dri.so, which I can cause repeatedly with glx-shader-sharing.

Used stack:
Mesa: Git/9ae10e9c
libdrm: 2.4.27-1
Kernel: 3.1.1
X.org: 1.11.1.902-1

The attachment shows a backtrace and a register dump. Let me know, if you need
more.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] intel-dri: Fix initialization if startup happens in interlaced mode [v2]

On Mon, 14 Nov 2011 12:21:35 +0100, Christian Schmidt  
wrote:
> My EFI BIOS starts the graphics card up in my projector's preferred EDID
> mode, 1080 at 60i. The Intel driver does not clear the interlaced bit:
> 
> #define   PIPECONF_PROGRESSIVE  (0 << 21)
> #define   PIPECONF_INTERLACE_W_FIELD_INDICATION (6 << 21)
> #define   PIPECONF_INTERLACE_FIELD_0_ONLY   (7 << 21)
> 
> This patch introduces a new PIPECONF_INTERLACE_MASK define and uses it
> to restore progressive mode.
> 
> Signed-of-by: Christian Schmidt 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: add some caps for userspace to discover more info for dumb KMS driver (v2)

2011-11-14 Thread Dave Airlie

From: Dave Airlie 

For the simple KMS driver case we need some more info about what the preferred
depth and if a shadow framebuffer is preferred.

I've only added this for intel/radeon which support the dumb ioctls so far.

If you need something really fancy you should be writing a real X.org driver.

v2: drop cursor information, just return an error from the cursor ioctls
and we can make userspace fallback to sw cursor in that case, cursor 
info was getting too messy, best to start smaller.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_ioctl.c |6 ++
 drivers/gpu/drm/i915/intel_display.c|3 +++
 drivers/gpu/drm/radeon/radeon_display.c |3 +++
 include/drm/drm.h   |2 ++
 include/drm/drm_crtc.h  |3 +++
 5 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 904d7e9..56911d1 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -283,6 +283,12 @@ int drm_getcap(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
case DRM_CAP_VBLANK_HIGH_CRTC:
req->value = 1;
break;
+   case DRM_CAP_DUMB_PREFERRED_DEPTH:
+   req->value = dev->mode_config.preferred_depth;
+   break;
+   case DRM_CAP_DUMB_PREFER_SHADOW:
+   req->value = dev->mode_config.prefer_shadow;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 04411ad..557cb21 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8397,6 +8397,9 @@ void intel_modeset_init(struct drm_device *dev)
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;

+   dev->mode_config.preferred_depth = 24;
+   dev->mode_config.prefer_shadow = 1;
+
dev->mode_config.funcs = (void *)_mode_funcs;

intel_init_quirks(dev);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 6adb3e5..53eb487 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1310,6 +1310,9 @@ int radeon_modeset_init(struct radeon_device *rdev)
rdev->ddev->mode_config.max_height = 4096;
}

+   rdev->ddev->mode_config.preferred_depth = 24;
+   rdev->ddev->mode_config.prefer_shadow = 1;
+
rdev->ddev->mode_config.fb_base = rdev->mc.aper_base;

ret = radeon_modeset_create_props(rdev);
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 4be33b4..e57f185 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -757,6 +757,8 @@ struct drm_event_vblank {

 #define DRM_CAP_DUMB_BUFFER 0x1
 #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+#define DRM_CAP_DUMB_PREFER_SHADOW 0x4

 /* typedef area */
 #ifndef __KERNEL__
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 44335e5..aec4ae7 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -623,6 +623,9 @@ struct drm_mode_config {
struct drm_property *scaling_mode_property;
struct drm_property *dithering_mode_property;
struct drm_property *dirty_info_property;
+
+   /* dumb ioctl parameters */
+   uint32_t preferred_depth, prefer_shadow;
 };

 #define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
-- 
1.7.6

[PATCH 00/14] update exynos drm driver.

2011-11-14 Thread Kyungmin Park

Hi,

Also you can find relevant patches at git
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/samsung-drm

To Mr. Dae.
Can you rebase the latest drm-next tree or mainline to merge easily?

Thank you,
Kyungmin Park

On 11/12/11, Inki Dae  wrote:
> Hello, Dave. sorry but please, ignor previous patch sets posted
> by Seung-Woo Kim. I am seding patch sets again.
>
> this patch sets are as the following.
> - add kms poll to handle hdp event.
> - fix converting between display mode and timing.
> - fix connector and crtc callbacks to call proper display driver.
> - fix vblank bug that manager->pipe could be -1 at vsync interrupt handler.
> - add exynos_drm_gem_init() that is used commonly.
> - change buffer structure to support IOMMU in the future.
> - add comments and code clean.
>
> this patch is based on git repository below:
> git://people.freedesktop.org/~airlied/linux.git
> branch name: drm-fixes
> commit-id: 8f3f1c9a22a6420e28c2d3eff59b832893bc8efc
>
> Inki Dae (7):
>   drm/exynos: added manager object to connector
>   drm/exynos: changed exynos_drm_display to exynos_drm_display_ops
>   drm/exynos: use gem create function generically
>   drm/exynos: removed unnecessary variable.
>   drm/exynos: changed buffer structure.
>   drm/exynos: fix vblank bug.
>   drm/exynos: include linux/module.h
>
> Joonyoung Shim (2):
>   drm/exynos: restored kernel_fb_list when reiniting fb_helper
>   drm/exynos: added crtc dpms for disable crtc
>
> Seung-Woo Kim (5):
>   drm/exynos: added kms poll for handling hpd event
>   drm/exynos: fixed connector flag with hpd and interlace scan for hdmi
>   drm/exynos: fixed converting between display mode and timing
>   drm/exynos: removed meaningless parameter from fbdev update
>   drm/exynos: checked for null pointer
>
>  drivers/gpu/drm/exynos/exynos_drm_buf.c   |   62 +
>  drivers/gpu/drm/exynos/exynos_drm_buf.h   |   21 +-
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |   78 +++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   76 ++--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   25 +++
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |5 ++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |   11 ++--
>  drivers/gpu/drm/exynos/exynos_drm_encoder.c   |   65 ++---
>  drivers/gpu/drm/exynos/exynos_drm_encoder.h   |1 +
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|   66 ++---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   44 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   62 -
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |   94
> +++--
>  drivers/gpu/drm/exynos/exynos_drm_gem.h   |   28 ++--
>  include/drm/exynos_drm.h  |9 +--
>  15 files changed, 416 insertions(+), 231 deletions(-)
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V5

On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom  
wrote:
> On 11/11/2011 11:47 PM, j.glisse at gmail.com wrote:
>>
>> So attached is updated serie of patch with fixes for swaping issue
>> that also impacted memory accounting.
>
> Jerome,
> Out of interest, what was the swapping issue?
>
> /Thomas
>
>

The page list was NULL and some access ended up freaking the kernel
and oom kicked in for some reason i still don't understand. Bottom
line things were going south in a split second leaving me with no log
or access, i thought it was accounting not working as it was what i
tested at the time. I should have tested accouting without the
patchset

Cheers,
Jerome

[BUG] WARNING: at drivers/gpu/drm/i915/intel_display.c:901 assert_panel_unlocked

2011-11-14 Thread Tom Gundersen

Hi guys,

I have been experiencing problems with suspend/resume on my ThinkPad
x60 for some time (sorry for being vague, I forget when it started).
With 3.1 it seems to behave much better (no crashes).

The problems I'm still seeing is that sometimes the computer does not
suspend when closing the lid, but manually using "pm-suspend" always
works. Opening the lid again after a failed suspend causes it to
flicker briefly and then continue working as before.

I receive the following warning in dmesg (after both successful and
unsuccessful suspends):

[24395.487631] [ cut here ]
[24395.487659] WARNING: at drivers/gpu/drm/i915/intel_display.c:901
assert_panel_unlocked.isra.22+0x242/0x280 [i915]()
[24395.487664] Hardware name: 1706GMG
[24395.487667] panel assertion failure, pipe B regs locked
[24395.487671] Modules linked in: ext2 msr cpufreq_stats ext4 mbcache
jbd2 microcode sbs sbshc max6650 coretemp kvm_intel kvm acpi_cpufreq
freq_table mperf i915 drm_kms_helper cryptd drm aes_x86_64 iTCO_wdt
aes_generic ecb iTCO_vendor_support btusb bluetooth crc16 mmc_block
e1000e thinkpad_acpi uhci_hcd firewire_ohci firewire_core intel_agp
pata_acpi i2c_algo_bit arc4 sdhci_pci sdhci snd_hda_codec_analog
ata_generic intel_gtt snd_hda_intel snd_hda_codec iwl3945 iwl_legacy
i2c_i801 snd_hwdep snd_pcm ehci_hcd snd_timer mac80211 snd psmouse
mmc_core i2c_core processor video nvram ata_piix usbcore thermal ac
button battery evdev soundcore cfg80211 snd_page_alloc serio_raw
crc_itu_t rfkill autofs4 btrfs zlib_deflate crc32c libcrc32c sd_mod
ahci libahci libata scsi_mod
[24395.487772] Pid: 7975, comm: kworker/u:5 Tainted: GW
3.1.1-1-ARCH #1
[24395.48] Call Trace:
[24395.487791]  [] warn_slowpath_common+0x7f/0xc0
[24395.487798]  [] warn_slowpath_fmt+0x46/0x50
[24395.487814]  []
assert_panel_unlocked.isra.22+0x242/0x280 [i915]
[24395.487830]  [] i9xx_crtc_enable+0xa6/0x4c0 [i915]
[24395.487838]  [] ? snprintf+0x34/0x40
[24395.487852]  [] i9xx_crtc_commit+0xe/0x10 [i915]
[24395.487861]  []
drm_crtc_helper_set_mode+0x3b9/0x4f0 [drm_kms_helper]
[24395.487873]  []
drm_helper_resume_force_mode+0x73/0x160 [drm_kms_helper]
[24395.487887]  [] ? drm_irq_install+0x153/0x260 [drm]
[24395.487899]  [] i915_drm_thaw+0xca/0x110 [i915]
[24395.487909]  [] i915_resume+0x4e/0x80 [i915]
[24395.487927]  [] i915_pm_resume+0x16/0x20 [i915]
[24395.487931]  [] pci_pm_resume+0x76/0xd0
[24395.487936]  [] pm_op+0xe7/0x1c0
[24395.487939]  [] device_resume+0x9f/0x140
[24395.487943]  [] ? async_schedule+0x20/0x20
[24395.487946]  [] async_resume+0x21/0x50
[24395.487949]  [] async_run_entry_fn+0x7f/0x180
[24395.487953]  [] process_one_work+0x116/0x4d0
[24395.487956]  [] worker_thread+0x15e/0x350
[24395.487959]  [] ? manage_workers.isra.29+0x230/0x230
[24395.487962]  [] kthread+0x8c/0xa0
[24395.487966]  [] kernel_thread_helper+0x4/0x10
[24395.487969]  [] ? kthread_worker_fn+0x190/0x190
[24395.487972]  [] ? gs_change+0x13/0x13
[24395.487974] ---[ end trace 1d476bd6e1af4e33 ]---

The kernel is mostly unpatched, but the few patches it has (as well as
its .config) can be found here:
.

Please let me know if you require more information.

Thanks for your time,

Tom

[Bug 42808] Xserver fails to start with NI Seymour XT

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

--- Comment #6 from samit vats  2011-11-14 02:17:05 PST 
---
(In reply to comment #5)
> Then it sounds like your laptop is muxless, i.e. the Radeon GPU physically
> isn't connected to any display outputs. I'm afraid this won't be supported for
> a long time, as it requires a lot of infrastructural work to happen first. In
> the meantime, you'll have to use the integrated GPU with the intel drivers.


"In SBIOS the switchable Graphics is set to Muxed instead of Muxless. The
message, "Unable to find connected outputs - setting 1024x768
initial framebuffer" appears as warning and startx fails with segmentation
fault."

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] intel-dri: Fix initialization if startup happens in interlaced mode

On Sun, 13 Nov 2011 22:08:41 +0100, Christian Schmidt  
wrote:
> My EFI BIOS starts the graphics card up in my projector's preferred EDID
> mode, 1080 at 60i. The Intel driver does not clear the interlaced bit:
> 
> #define   PIPECONF_PROGRESSIVE  (0 << 21)
> #define   PIPECONF_INTERLACE_W_FIELD_INDICATION (6 << 21)
> #define   PIPECONF_INTERLACE_FIELD_0_ONLY   (7 << 21)
> 
> Likewise, I suppose that this bit is not set for interlaced modes
> either, however interlaced modes are discarded anyway.

The patch is correct, we do need to clear all 3 bits to restore
progressive mode. However it would be better to add a new
#define PIPECONF_INTERLACE_MASK (7 << 21)
so that we do not confuse clearing all interlace bits with unsetting a
particular mode.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 24475] clutter applications are unusable with radeon/radeonhd

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

--- Comment #5 from Marco Albanese  2011-11-14 09:52:59 
UTC ---
I've noticed a particular condition: I can see the windows's content if I
maximize them.

Could be helpful?

Again, I'm talking about an rv100 chip ( R100 ), should I fill a new bug or is
it related to this one?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon: add some missing FireMV pci ids

2011-11-14 Thread alexdeuc...@gmail.com

From: Alex Deucher 

Noticed by Egbert.

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

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index a13e1d8..82fbcf5 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -4,6 +4,7 @@
 */
 #define radeon_PCI_IDS \
{0x1002, 0x3150, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY}, \
+   {0x1002, 0x3151, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x3152, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x3154, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x3155, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -55,6 +56,7 @@
{0x1002, 0x4C64, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV250|RADEON_IS_MOBILITY}, \
{0x1002, 0x4C66, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV250|RADEON_IS_MOBILITY}, \
{0x1002, 0x4C67, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV250|RADEON_IS_MOBILITY}, \
+   {0x1002, 0x4C6E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV280|RADEON_IS_MOBILITY}, \
{0x1002, 0x4E44, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
{0x1002, 0x4E45, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
{0x1002, 0x4E46, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
-- 
1.7.3.4

[Bug 41971] [kms] Muxless radeon takes 20 seconds to fetch rom

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

Mike Lothian  changed:

   What|Removed |Added

 CC||mike at fireburn.co.uk

--- Comment #14 from Mike Lothian  2011-11-13 19:38:21 
PST ---
I just thought I'd add I've now compiled radeon as a module and it only takes 2
seconds to load the BIOS when modprobed after everything else is loaded

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: [PATCH] intel-dri: Fix initialization if startup happens in interlaced mode

On Sun, 13 Nov 2011 22:08:41 +0100, Christian Schmidt schm...@digadd.de wrote:
 My EFI BIOS starts the graphics card up in my projector's preferred EDID
 mode, 1080@60i. The Intel driver does not clear the interlaced bit:
 
 #define   PIPECONF_PROGRESSIVE  (0  21)
 #define   PIPECONF_INTERLACE_W_FIELD_INDICATION (6  21)
 #define   PIPECONF_INTERLACE_FIELD_0_ONLY   (7  21)
 
 Likewise, I suppose that this bit is not set for interlaced modes
 either, however interlaced modes are discarded anyway.

The patch is correct, we do need to clear all 3 bits to restore
progressive mode. However it would be better to add a new
#define PIPECONF_INTERLACE_MASK (7  21)
so that we do not confuse clearing all interlace bits with unsetting a
particular mode.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42808] Xserver fails to start with NI Seymour XT

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

--- Comment #6 from samit vats hysv...@gmail.com 2011-11-14 02:17:05 PST ---
(In reply to comment #5)
 Then it sounds like your laptop is muxless, i.e. the Radeon GPU physically
 isn't connected to any display outputs. I'm afraid this won't be supported for
 a long time, as it requires a lot of infrastructural work to happen first. In
 the meantime, you'll have to use the integrated GPU with the intel drivers.


In SBIOS the switchable Graphics is set to Muxed instead of Muxless. The
message, Unable to find connected outputs - setting 1024x768
initial framebuffer appears as warning and startx fails with segmentation
fault.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: Strange effect with i915 backlight controller

[Added Chris to Cc]

At Sun, 13 Nov 2011 17:24:09 +0100,
Daniel Mack wrote:
 
 Hi Takashi,
 
 On 11/10/2011 04:39 PM, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 16:11:29 +0100,
  Daniel Mack wrote:
 
  On 11/08/2011 01:57 AM, Daniel Mack wrote:
  Didn't get any response yet, hence copying LKML for a broader audience.
 
  Nobody, really?
 
  This is a rather annoying regression, as touching the brightness keys
  appearantly switches off the whole machine. I'm sure this is trivial to
  fix, I just don't have the insight of this driver and the chipset.
  
  I vaguely remember that the bit 0 is invalid on some old chips.
  Maybe 915GM is one of them, as it's gen3?  If so, the patch like below
  may work.
 
 Thank you for looking into this.
 
  ---
  diff --git a/drivers/gpu/drm/i915/intel_panel.c 
  b/drivers/gpu/drm/i915/intel_panel.c
  index 499d4c0..be952d1 100644
  --- a/drivers/gpu/drm/i915/intel_panel.c
  +++ b/drivers/gpu/drm/i915/intel_panel.c
  @@ -249,8 +249,11 @@ static void intel_panel_actually_set_backlight(struct 
  drm_device *dev, u32 level
  if (IS_PINEVIEW(dev)) {
  tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
  level = 1;
  -   } else
  +   } else {
  tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
  +   if (INTEL_INFO(dev)-gen  4)
  +   tmp = ~1;
  +   }
  I915_WRITE(BLC_PWM_CTL, tmp | level);
   }
   
 
 This seems to be the right intention, but the value you want to modify
 under this condition is 'level', not 'tmp'.

Ah, of course.  Sorry for that.

 With this amendment of your
 patch, things work perfectly fine here.

OK, then perhaps a better fix is to change the check to be equivalent
with pineview, as you mentioned in the original post.  The handling of
bit 0 for old chips was lost during the refactoring of backlight code
since 2.6.37.

Does the patch below work for you?

The only concern by this fix is that it changes the max value.  If
apps expect some certain (e.g. recorded) value, it may screw up.  But
I don't expect this would happen with sane apps.


thanks,

Takashi

===
From: Takashi Iwai ti...@suse.de
Subject: drm/i915: Fix invalid backpanel values for GEN3 or older chips

While refactoring of backlight control code in commit [a95735569:
drm/i915: Refactor panel backlight controls], the handling of the bit
0 of duty-cycle was gone except for pineview.  This resulted in invalid
register values for old chips like 915GM.  When the bit 0 is set, the
backlight is turned off suddenly.

This patch changes the bit-0 check by replacing with the condition of
gen  4 (pineview is included in this condition, too).

Reported-by: Daniel Mack zon...@gmail.com
Signed-off-by: Takashi Iwai ti...@suse.de
---
 drivers/gpu/drm/i915/intel_panel.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 499d4c0..737d00f 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -178,12 +178,10 @@ u32 intel_panel_get_max_backlight(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
max = 16;
} else {
-   if (IS_PINEVIEW(dev)) {
+   if (INTEL_INFO(dev)-gen  4) {
max = 17;
} else {
max = 16;
-   if (INTEL_INFO(dev)-gen  4)
-   max = ~1;
}
 
if (is_backlight_combination_mode(dev))
@@ -203,7 +201,7 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CPU_CTL)  BACKLIGHT_DUTY_CYCLE_MASK;
} else {
val = I915_READ(BLC_PWM_CTL)  BACKLIGHT_DUTY_CYCLE_MASK;
-   if (IS_PINEVIEW(dev))
+   if (INTEL_INFO(dev)-gen  4)
val = 1;
 
if (is_backlight_combination_mode(dev)) {
@@ -246,7 +244,7 @@ static void intel_panel_actually_set_backlight(struct 
drm_device *dev, u32 level
}
 
tmp = I915_READ(BLC_PWM_CTL);
-   if (IS_PINEVIEW(dev)) {
+   if (INTEL_INFO(dev)-gen  4) {
tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level = 1;
} else
-- 
1.7.7

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

[PATCH] drm: add some caps for userspace to discover more info for dumb KMS driver (v2)

2011-11-14 Thread Dave Airlie

From: Dave Airlie airl...@redhat.com

For the simple KMS driver case we need some more info about what the preferred
depth and if a shadow framebuffer is preferred.

I've only added this for intel/radeon which support the dumb ioctls so far.

If you need something really fancy you should be writing a real X.org driver.

v2: drop cursor information, just return an error from the cursor ioctls
and we can make userspace fallback to sw cursor in that case, cursor 
info was getting too messy, best to start smaller.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_ioctl.c |6 ++
 drivers/gpu/drm/i915/intel_display.c|3 +++
 drivers/gpu/drm/radeon/radeon_display.c |3 +++
 include/drm/drm.h   |2 ++
 include/drm/drm_crtc.h  |3 +++
 5 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 904d7e9..56911d1 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -283,6 +283,12 @@ int drm_getcap(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
case DRM_CAP_VBLANK_HIGH_CRTC:
req-value = 1;
break;
+   case DRM_CAP_DUMB_PREFERRED_DEPTH:
+   req-value = dev-mode_config.preferred_depth;
+   break;
+   case DRM_CAP_DUMB_PREFER_SHADOW:
+   req-value = dev-mode_config.prefer_shadow;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 04411ad..557cb21 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8397,6 +8397,9 @@ void intel_modeset_init(struct drm_device *dev)
dev-mode_config.min_width = 0;
dev-mode_config.min_height = 0;
 
+   dev-mode_config.preferred_depth = 24;
+   dev-mode_config.prefer_shadow = 1;
+
dev-mode_config.funcs = (void *)intel_mode_funcs;
 
intel_init_quirks(dev);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 6adb3e5..53eb487 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1310,6 +1310,9 @@ int radeon_modeset_init(struct radeon_device *rdev)
rdev-ddev-mode_config.max_height = 4096;
}
 
+   rdev-ddev-mode_config.preferred_depth = 24;
+   rdev-ddev-mode_config.prefer_shadow = 1;
+
rdev-ddev-mode_config.fb_base = rdev-mc.aper_base;
 
ret = radeon_modeset_create_props(rdev);
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 4be33b4..e57f185 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -757,6 +757,8 @@ struct drm_event_vblank {
 
 #define DRM_CAP_DUMB_BUFFER 0x1
 #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
+#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
 
 /* typedef area */
 #ifndef __KERNEL__
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 44335e5..aec4ae7 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -623,6 +623,9 @@ struct drm_mode_config {
struct drm_property *scaling_mode_property;
struct drm_property *dithering_mode_property;
struct drm_property *dirty_info_property;
+
+   /* dumb ioctl parameters */
+   uint32_t preferred_depth, prefer_shadow;
 };
 
 #define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
-- 
1.7.6

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

Re: [PATCH] intel-dri: Fix initialization if startup happens in interlaced mode [v2]

On Mon, 14 Nov 2011 12:21:35 +0100, Christian Schmidt schm...@digadd.de wrote:
 My EFI BIOS starts the graphics card up in my projector's preferred EDID
 mode, 1080@60i. The Intel driver does not clear the interlaced bit:
 
 #define   PIPECONF_PROGRESSIVE  (0  21)
 #define   PIPECONF_INTERLACE_W_FIELD_INDICATION (6  21)
 #define   PIPECONF_INTERLACE_FIELD_0_ONLY   (7  21)
 
 This patch introduces a new PIPECONF_INTERLACE_MASK define and uses it
 to restore progressive mode.
 
 Signed-of-by: Christian Schmidt schm...@digadd.de
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42908] New: r600g: glx-shader-sharing causes segfault

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

 Bug #: 42908
   Summary: r600g: glx-shader-sharing causes segfault
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: deb...@carbon-project.org


Created attachment 53511
  -- https://bugs.freedesktop.org/attachment.cgi?id=53511
GDB ouput for the crash

I'm currently trying to find the Piglit test (it's one of the GLX tests run by
r600.tests), that causes screen corruption. In the process I hit a segfault in
r600_dri.so, which I can cause repeatedly with glx-shader-sharing.

Used stack:
Mesa: Git/9ae10e9c
libdrm: 2.4.27-1
Kernel: 3.1.1
X.org: 1.11.1.902-1

The attachment shows a backtrace and a register dump. Let me know, if you need
more.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 42908] r600g: glx-shader-sharing causes segfault

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

Kai deb...@carbon-project.org changed:

   What|Removed |Added

   Platform|Other   |x86-64 (AMD64)
 OS/Version|All |Linux (All)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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: Strange effect with i915 backlight controller

2011-11-14 Thread Daniel Mack

On 11/14/2011 11:39 AM, Takashi Iwai wrote:
 [Added Chris to Cc]
 
 At Sun, 13 Nov 2011 17:24:09 +0100,
 Daniel Mack wrote:

 Hi Takashi,

 On 11/10/2011 04:39 PM, Takashi Iwai wrote:
 At Thu, 10 Nov 2011 16:11:29 +0100,
 Daniel Mack wrote:

 On 11/08/2011 01:57 AM, Daniel Mack wrote:
 Didn't get any response yet, hence copying LKML for a broader audience.

 Nobody, really?

 This is a rather annoying regression, as touching the brightness keys
 appearantly switches off the whole machine. I'm sure this is trivial to
 fix, I just don't have the insight of this driver and the chipset.

 I vaguely remember that the bit 0 is invalid on some old chips.
 Maybe 915GM is one of them, as it's gen3?  If so, the patch like below
 may work.

 Thank you for looking into this.

 ---
 diff --git a/drivers/gpu/drm/i915/intel_panel.c 
 b/drivers/gpu/drm/i915/intel_panel.c
 index 499d4c0..be952d1 100644
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@ -249,8 +249,11 @@ static void intel_panel_actually_set_backlight(struct 
 drm_device *dev, u32 level
 if (IS_PINEVIEW(dev)) {
 tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
 level = 1;
 -   } else
 +   } else {
 tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
 +   if (INTEL_INFO(dev)-gen  4)
 +   tmp = ~1;
 +   }
 I915_WRITE(BLC_PWM_CTL, tmp | level);
  }
  

 This seems to be the right intention, but the value you want to modify
 under this condition is 'level', not 'tmp'.
 
 Ah, of course.  Sorry for that.
 
 With this amendment of your
 patch, things work perfectly fine here.
 
 OK, then perhaps a better fix is to change the check to be equivalent
 with pineview, as you mentioned in the original post.  The handling of
 bit 0 for old chips was lost during the refactoring of backlight code
 since 2.6.37.
 
 Does the patch below work for you?

Will test, but I only have occasional access to the machine, so this
will have to wait for some days.

 The only concern by this fix is that it changes the max value.  If
 apps expect some certain (e.g. recorded) value, it may screw up.  But
 I don't expect this would happen with sane apps.

I don't think so either.


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

Re: Strange effect with i915 backlight controller

At Mon, 14 Nov 2011 13:03:46 +0100,
Daniel Mack wrote:
 
 On 11/14/2011 11:39 AM, Takashi Iwai wrote:
  [Added Chris to Cc]
  
  At Sun, 13 Nov 2011 17:24:09 +0100,
  Daniel Mack wrote:
 
  Hi Takashi,
 
  On 11/10/2011 04:39 PM, Takashi Iwai wrote:
  At Thu, 10 Nov 2011 16:11:29 +0100,
  Daniel Mack wrote:
 
  On 11/08/2011 01:57 AM, Daniel Mack wrote:
  Didn't get any response yet, hence copying LKML for a broader audience.
 
  Nobody, really?
 
  This is a rather annoying regression, as touching the brightness keys
  appearantly switches off the whole machine. I'm sure this is trivial to
  fix, I just don't have the insight of this driver and the chipset.
 
  I vaguely remember that the bit 0 is invalid on some old chips.
  Maybe 915GM is one of them, as it's gen3?  If so, the patch like below
  may work.
 
  Thank you for looking into this.
 
  ---
  diff --git a/drivers/gpu/drm/i915/intel_panel.c 
  b/drivers/gpu/drm/i915/intel_panel.c
  index 499d4c0..be952d1 100644
  --- a/drivers/gpu/drm/i915/intel_panel.c
  +++ b/drivers/gpu/drm/i915/intel_panel.c
  @@ -249,8 +249,11 @@ static void 
  intel_panel_actually_set_backlight(struct drm_device *dev, u32 level
if (IS_PINEVIEW(dev)) {
tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level = 1;
  - } else
  + } else {
tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
  + if (INTEL_INFO(dev)-gen  4)
  + tmp = ~1;
  + }
I915_WRITE(BLC_PWM_CTL, tmp | level);
   }
   
 
  This seems to be the right intention, but the value you want to modify
  under this condition is 'level', not 'tmp'.
  
  Ah, of course.  Sorry for that.
  
  With this amendment of your
  patch, things work perfectly fine here.
  
  OK, then perhaps a better fix is to change the check to be equivalent
  with pineview, as you mentioned in the original post.  The handling of
  bit 0 for old chips was lost during the refactoring of backlight code
  since 2.6.37.
  
  Does the patch below work for you?
 
 Will test, but I only have occasional access to the machine, so this
 will have to wait for some days.

It's an old bug over a year, so no need to hurry.


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

[PATCH] drm/radeon: add some missing FireMV pci ids

2011-11-14 Thread alexdeucher

From: Alex Deucher alexander.deuc...@amd.com

Noticed by Egbert.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@kernel.org
Cc: Egbert Eich e...@suse.de
---
 include/drm/drm_pciids.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index a13e1d8..82fbcf5 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -4,6 +4,7 @@
 */
 #define radeon_PCI_IDS \
{0x1002, 0x3150, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY}, \
+   {0x1002, 0x3151, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x3152, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x3154, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x3155, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV380|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -55,6 +56,7 @@
{0x1002, 0x4C64, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV250|RADEON_IS_MOBILITY}, \
{0x1002, 0x4C66, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV250|RADEON_IS_MOBILITY}, \
{0x1002, 0x4C67, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV250|RADEON_IS_MOBILITY}, \
+   {0x1002, 0x4C6E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
CHIP_RV280|RADEON_IS_MOBILITY}, \
{0x1002, 0x4E44, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
{0x1002, 0x4E45, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
{0x1002, 0x4E46, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_R300}, \
-- 
1.7.3.4

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

Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V5


On 11/11/2011 11:47 PM, j.gli...@gmail.com wrote:

So attached is updated serie of patch with fixes for swaping issue
that also impacted memory accounting.


Jerome,
Out of interest, what was the swapping issue?

/Thomas




  Last patch fix memory accounting
for radeon  nouveau. I think it's ready to go into drm-next, patchset
is against linus tree as there is thing there not in next that conflict.
(in radeon iirc)

Cheers,
Jerome

   


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

[PATCH] intel-dri: Fix initialization if startup happens in interlaced mode [v2]

2011-11-14 Thread Christian Schmidt

My EFI BIOS starts the graphics card up in my projector's preferred EDID
mode, 1080@60i. The Intel driver does not clear the interlaced bit:

#define   PIPECONF_PROGRESSIVE  (0  21)
#define   PIPECONF_INTERLACE_W_FIELD_INDICATION (6  21)
#define   PIPECONF_INTERLACE_FIELD_0_ONLY   (7  21)

This patch introduces a new PIPECONF_INTERLACE_MASK define and uses it
to restore progressive mode.

Signed-of-by: Christian Schmidt schm...@digadd.de

diff -ur linux-3.2-rc1.orig/drivers/gpu/drm/i915/i915_reg.h linux-3.2-rc1/drivers/gpu/drm/i915/i915_reg.h
--- linux-3.2-rc1.orig/drivers/gpu/drm/i915/i915_reg.h	2011-11-14 12:16:42.811994538 +0100
+++ linux-3.2-rc1/drivers/gpu/drm/i915/i915_reg.h	2011-11-14 12:17:05.124715590 +0100
@@ -2312,6 +2312,7 @@
 #define   PIPECONF_PROGRESSIVE	(0  21)
 #define   PIPECONF_INTERLACE_W_FIELD_INDICATION	(6  21)
 #define   PIPECONF_INTERLACE_FIELD_0_ONLY		(7  21)
+#define   PIPECONF_INTERLACE_MASK	(7  21)
 #define   PIPECONF_CXSR_DOWNCLOCK	(116)
 #define   PIPECONF_BPP_MASK	(0x00e0)
 #define   PIPECONF_BPP_8	(05)
diff -ur linux-3.2-rc1.orig/drivers/gpu/drm/i915/intel_display.c linux-3.2-rc1/drivers/gpu/drm/i915/intel_display.c
--- linux-3.2-rc1.orig/drivers/gpu/drm/i915/intel_display.c	2011-11-08 01:16:02.0 +0100
+++ linux-3.2-rc1/drivers/gpu/drm/i915/intel_display.c	2011-11-14 12:15:59.373537593 +0100
@@ -5136,7 +5136,7 @@
 		adjusted_mode-crtc_vsync_end -= 1;
 		adjusted_mode-crtc_vsync_start -= 1;
 	} else
-		pipeconf = ~PIPECONF_INTERLACE_W_FIELD_INDICATION; /* progressive */
+		pipeconf = ~PIPECONF_INTERLACE_MASK; /* progressive */
 
 	I915_WRITE(HTOTAL(pipe),
 		   (adjusted_mode-crtc_hdisplay - 1) |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V5

On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom thellst...@vmware.com wrote:
 On 11/11/2011 11:47 PM, j.gli...@gmail.com wrote:

 So attached is updated serie of patch with fixes for swaping issue
 that also impacted memory accounting.

 Jerome,
 Out of interest, what was the swapping issue?

 /Thomas



The page list was NULL and some access ended up freaking the kernel
and oom kicked in for some reason i still don't understand. Bottom
line things were going south in a split second leaving me with no log
or access, i thought it was accounting not working as it was what i
tested at the time. I should have tested accouting without the
patchset

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

Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V5


On 11/14/2011 05:02 PM, Jerome Glisse wrote:

On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstromthellst...@vmware.com  wrote:
   

On 11/11/2011 11:47 PM, j.gli...@gmail.com wrote:
 

So attached is updated serie of patch with fixes for swaping issue
that also impacted memory accounting.
   

Jerome,
Out of interest, what was the swapping issue?

/Thomas


 

The page list was NULL and some access ended up freaking the kernel
and oom kicked in for some reason i still don't understand. Bottom
line things were going south in a split second leaving me with no log
or access, i thought it was accounting not working as it was what i
tested at the time. I should have tested accouting without the
patchset

Cheers,
Jerome
   


Still, I think you have a point in the fact that *when* finally the OOM 
killer kicks in,
it probably doesn't have a way to associate user-space created bos with 
processes

and kill the right process.

/Thomas

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

Re: [PATCH 00/23] kill drm cruft with fire

2011-11-14 Thread James Simmons


  Should I test this set of patches for the VIA driver or wait until you 
  have a second version of this patch?
 
 Testing this on via would be awesome! Iirc I haven't changed anything in
 the via specific patches, but if it's more convenient you can also
 directly test my branch:
 
 http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire

Okay I tried the patches and it locked up the openchrome X server. I'm 
going to try your branch tonight to see if it makes any difference. If it 
still fails I will have to track down what the problem is.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 24475] clutter applications are unusable with radeon/radeonhd

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

--- Comment #5 from Marco Albanese deli...@gmail.com 2011-11-14 09:52:59 UTC 
---
I've noticed a particular condition: I can see the windows's content if I
maximize them.

Could be helpful?

Again, I'm talking about an rv100 chip ( R100 ), should I fill a new bug or is
it related to this one?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] drm_edid: support CEA video modes

2011-11-14 Thread Paul Menzel

Am Sonntag, den 13.11.2011, 23:16 +0100 schrieb alanwww1:
 This is awesome ! A LOT of HTPC fans are waiting for this! Is there a
 chance that this lands in 3.2 ?

Have you tested this? Adding a Tested-by line would surely help getting
it included.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V5

On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote:
 On 11/14/2011 05:02 PM, Jerome Glisse wrote:
 On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstromthellst...@vmware.com  
 wrote:
 On 11/11/2011 11:47 PM, j.gli...@gmail.com wrote:
 So attached is updated serie of patch with fixes for swaping issue
 that also impacted memory accounting.
 Jerome,
 Out of interest, what was the swapping issue?
 
 /Thomas
 
 
 The page list was NULL and some access ended up freaking the kernel
 and oom kicked in for some reason i still don't understand. Bottom
 line things were going south in a split second leaving me with no log
 or access, i thought it was accounting not working as it was what i
 tested at the time. I should have tested accouting without the
 patchset
 
 Cheers,
 Jerome
 
 Still, I think you have a point in the fact that *when* finally the
 OOM killer kicks in,
 it probably doesn't have a way to associate user-space created bos
 with processes
 and kill the right process.
 
 /Thomas
 

Btw can you review patch 14 as it touch vmwgfx, i am pretty sure
i got it right.

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

[PATCH] drm/radeon/kms: fix up gpio i2c mask bits for r4xx

2011-11-14 Thread alexdeucher

From: Alex Deucher alexander.deuc...@amd.com

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
---
 drivers/gpu/drm/radeon/radeon_atombios.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index bcb88f1..6b5fbc9 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -89,6 +89,18 @@ static struct radeon_i2c_bus_rec 
radeon_lookup_i2c_gpio(struct radeon_device *rd
for (i = 0; i  num_indices; i++) {
gpio = i2c_info-asGPIO_Info[i];
 
+   /* r4xx mask is technically not used by the hw, so 
patch in the legacy mask bits */
+   if ((rdev-family == CHIP_R420) ||
+   (rdev-family == CHIP_R423) ||
+   (rdev-family == CHIP_RV410)) {
+   if ((le16_to_cpu(gpio-usClkMaskRegisterIndex) 
== 0x0018) ||
+   (le16_to_cpu(gpio-usClkMaskRegisterIndex) 
== 0x0019) ||
+   (le16_to_cpu(gpio-usClkMaskRegisterIndex) 
== 0x001a)) {
+   gpio-ucClkMaskShift = 0x19;
+   gpio-ucDataMaskShift = 0x18;
+   }
+   }
+
/* some evergreen boards have bad data for this entry */
if (ASIC_IS_DCE4(rdev)) {
if ((i == 7) 
-- 
1.7.3.4

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

Re: ttm: merge ttm_backend ttm_tt, introduce ttm dma allocator V5


On 11/14/2011 07:54 PM, Jerome Glisse wrote:

On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote:
   

On 11/14/2011 05:02 PM, Jerome Glisse wrote:
 

On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstromthellst...@vmware.com   
wrote:
   

On 11/11/2011 11:47 PM, j.gli...@gmail.com wrote:
 

So attached is updated serie of patch with fixes for swaping issue
that also impacted memory accounting.
   

Jerome,
Out of interest, what was the swapping issue?

/Thomas


 

The page list was NULL and some access ended up freaking the kernel
and oom kicked in for some reason i still don't understand. Bottom
line things were going south in a split second leaving me with no log
or access, i thought it was accounting not working as it was what i
tested at the time. I should have tested accouting without the
patchset

Cheers,
Jerome
   

Still, I think you have a point in the fact that *when* finally the
OOM killer kicks in,
it probably doesn't have a way to associate user-space created bos
with processes
and kill the right process.

/Thomas

 

Btw can you review patch 14 as it touch vmwgfx, i am pretty sure
i got it right.

Cheers,
Jerome
   

Yes I will do a more thorough review tomorrow of all unreviewed stuff.

/Thomas






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

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v2

On Mon, 14 Nov 2011 11:47:07 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:

 To properly support the various plane formats supported by different
 hardware, the kernel must know the pixel format of a framebuffer object.
 So add a new ioctl taking a format argument corresponding to a fourcc
 name from videodev2.h.  Implement the fb creation hooks in terms of the
 new mode_fb_cmd2 using helpers where the old bpp/depth values are
 needed.
 
 v2: create DRM specific fourcc header file for sharing with libdrm etc

These now contradict one another, can you fix the text up when you
apply?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [PATCH 1/2] drm: add plane support v2

On Mon, 14 Nov 2011 11:47:06 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:

 Planes are a bit like half-CRTCs.  They have a location and fb, but
 don't drive outputs directly.  Add support for handling them to the core
 KMS code.
 
 v2: fix ABI of get_plane - move format_type_ptr to the end

Ok ignore these two; I botched the rebase and accidentally left in some
v4l stuff.

Since I had to re-post I confirmed with Rob about the multi-object API;
apparently a simple handle array will be enough, so that's included in
the next version.

I'll re-post one more time, this time with feeling.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Acked-by: Alan Cox a...@lxorguk.ukuu.org.uk
Reviewed-by: Rob Clark rob.cl...@linaro.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/drm_crtc.c|  111 +++--
 drivers/gpu/drm/drm_crtc_helper.c |   51 -
 drivers/gpu/drm/drm_drv.c |1 +
 drivers/gpu/drm/i915/intel_display.c  |   39 ++-
 drivers/gpu/drm/i915/intel_drv.h  |2 +-
 drivers/gpu/drm/i915/intel_fb.c   |   11 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c |6 +-
 drivers/gpu/drm/nouveau/nouveau_fb.h  |2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |   13 ++--
 drivers/gpu/drm/radeon/radeon_display.c   |8 +-
 drivers/gpu/drm/radeon/radeon_fb.c|   18 +++--
 drivers/gpu/drm/radeon/radeon_mode.h  |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   22 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |1 +
 drivers/staging/gma500/framebuffer.c  |2 +-
 include/drm/drm.h |1 +
 include/drm/drm_crtc.h|9 ++-
 include/drm/drm_crtc_helper.h |4 +-
 include/drm/drm_fourcc.h  |   63 
 include/drm/drm_mode.h|   24 ++
 20 files changed, 324 insertions(+), 66 deletions(-)
 create mode 100644 include/drm/drm_fourcc.h

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 804ef12..30a70a4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -35,6 +35,7 @@
 #include drmP.h
 #include drm_crtc.h
 #include drm_edid.h
+#include drm_fourcc.h
 
 struct drm_prop_enum_list {
int type;
@@ -563,7 +564,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
return -ENOMEM;
}
 
-   memcpy(plane-format_types, formats, format_count);
+   memcpy(plane-format_types, formats, format_count * sizeof(uint32_t));
plane-format_count = format_count;
plane-possible_crtcs = possible_crtcs;
 
@@ -1910,6 +1911,42 @@ out:
return ret;
 }
 
+/* Original addfb only supported RGB formats, so figure out which one */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+   uint32_t fmt;
+
+   switch (bpp) {
+   case 8:
+   fmt = DRM_FOURCC_RGB332;
+   break;
+   case 16:
+   if (depth == 15)
+   fmt = DRM_FOURCC_RGB555;
+   else
+   fmt = DRM_FOURCC_RGB565;
+   break;
+   case 24:
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   case 32:
+   if (depth == 24)
+   fmt = DRM_FOURCC_RGB24;
+   else if (depth == 30)
+   fmt = DRM_INTEL_RGB30;
+   else
+   fmt = DRM_FOURCC_RGB32;
+   break;
+   default:
+   DRM_ERROR(bad bpp, assuming RGB24 pixel format\n);
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   }
+
+   return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
 /**
  * drm_mode_addfb - add an FB to the graphics configuration
  * @inode: inode from the ioctl
@@ -1930,7 +1967,74 @@ out:
 int drm_mode_addfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
-   struct drm_mode_fb_cmd *r = data;
+   struct drm_mode_fb_cmd *or = data;
+   struct drm_mode_fb_cmd2 r = {};
+   struct drm_mode_config *config = dev-mode_config;
+   struct drm_framebuffer *fb;
+   int ret = 0;
+
+   /* Use new struct with format internally */
+   r.fb_id = or-fb_id;
+   r.width = or-width;
+   r.height = or-height;
+   r.pitches[0] = or-pitch;
+   r.pixel_format = drm_mode_legacy_fb_format(or-bpp, or-depth);
+   r.handles[0] = or-handle;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if ((config-min_width  r.width) || (r.width  config-max_width)) {
+   DRM_ERROR(mode new framebuffer width not within limits\n);
+   return -EINVAL;
+   }
+

Re: DRM KMS Modesetting

On Mon, 14 Nov 2011 21:25:56 +0100
David Herrmann dh.herrm...@googlemail.com wrote:

I thought it's better to ask this question here again as it is easier
to comment via mail.

I tried writing a simple kms modesetting program. I have written it similar
to:
http://virtuousgeek.org/blog/index.php/jbarnes?blog=2title=writing_stanalone_programs_with_egl_and_
and wayland compositor-drm.c
and modetest.c in libdrm/tests

My problem is, the program compiles and runs fine, however, the
framebuffer is only displayed on the left quarter of the screen. The
vertical size is perfect but the horizontal size is just the left
quarter. I've double checked all the drm parameters and they are equal
to the ones in modetest.c and compositor-drm.c.

./modetest runs fine and also reports only a single mode and encoder
for my connector so I cannot choose the wrong mode, either.

The code is here:
https://gist.github.com/1364994
It should compile fine with:
gcc -o bin file.c `pkg-config --cflags --libs egl gbm gl`

I would be glad if someone could run this or look over the code.

Hm I get a full white screen with a gray triangle in the lower right
hand corner. I had to modify the resolution the test was searching for
to 1920x1200 instead of 1024x600 since I tested on a DP attached
monitor, and fix the connector id, but other than that it seemed to
work fine.

--
Jesse Barnes, Intel Open Source Technology Center

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

[Bug 42514] [r300g] EVE online: some shaders are failing

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

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

   What|Removed |Added

 Depends on||42930

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
 +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b)  8) | \
 +   ((u32)(c)  16) | ((u32)(d)  24))
 +
 +/* RGB codes */
 +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
 +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
 +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
 +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
 +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
 +
 +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
 +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')

I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
formats, so why do we need the RGB/BGR32 variants? If the difference
is in the alpha channel, I'd like to document that fact in the name.

Could we call them ARGB, XRGB, XRGB1555 etc.?

Also the channel and byte order should be documented clearly.

And one other thing. I probably wouldn't call these fourccs
since they don't actually match the official fourccs. Not that
there is anything sensible defined for RGB formats in the
official list anyway. In fact, I'm not sure what we gain by
cooking our own fourccs when we know most of them won't match
the official list. AFAICS a simple running number would do
just as well as the format identifier.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, 14 Nov 2011 23:16:44 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:

 On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
  +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b)  8) | \
  + ((u32)(c)  16) | ((u32)(d)  24))
  +
  +/* RGB codes */
  +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
  +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
  +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
  +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
  +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
  +
  +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
  +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')
 
 I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
 formats, so why do we need the RGB/BGR32 variants? If the difference
 is in the alpha channel, I'd like to document that fact in the name.
 
 Could we call them ARGB, XRGB, XRGB1555 etc.?

Yeah, the fourcc naming isn't very good, I'd have no problem changing
the names to something more descriptive for 24 and 32.  fourcc.org
itself seems ambiguous about the 24 bit format

 Also the channel and byte order should be documented clearly.

Supposedly the fourcc code is supposed to provide that?

 And one other thing. I probably wouldn't call these fourccs
 since they don't actually match the official fourccs. Not that
 there is anything sensible defined for RGB formats in the
 official list anyway. In fact, I'm not sure what we gain by
 cooking our own fourccs when we know most of them won't match
 the official list. AFAICS a simple running number would do
 just as well as the format identifier.

They seem to match what's at fourcc.org, though I don't see the upper
byte documented, and also share values with the v4l stuff, which I was
assuming had the right fourcc codes.

If we don't match, we should strive to.  I'm just using what I find at
fourcc.org and in the v4l code to check...

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
 +struct drm_mode_fb_cmd2 {
 + __u32 fb_id;
 + __u32 width, height;
 + __u32 pixel_format; /* fourcc code from videodev2.h */
 +
 + /*
 +  * In case of planar formats, this ioctl allows up to 4
 +  * buffer objects with offets and pitches per plane.
 +  * The pitch and offset order is dictated by the fourcc,
 +  * e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
 +  *
 +  *   YUV 4:2:0 image with a plane of 8 bit Y samples
 +  *   followed by an interleaved U/V plane containing
 +  *   8 bit 2x2 subsampled colour difference samples.
 +  *
 +  * So it would consist of Y as offset[0] and UV as
 +  * offeset[1].  Note that offset[0] will generally
 +  * be 0.
 +  */
 + __u32 handles[4];
 + __u32 pitches[4]; /* pitch for each plane */
 + __u32 offsets[4]; /* offset of each plane */
 +};

Hey, what about those interlaced buffers? We talked privately about
adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
drm_mode_set_plane.

We could stick something like these to those flags:
fb_cmd2.flags:
#define DRM_MODE_FB_INTERLACED 0x1

set_plane.flags:
#define DRM_MODE_PRESENT_TOP_FIELD 0x1
#define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, 14 Nov 2011 23:24:55 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:

 On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
  +struct drm_mode_fb_cmd2 {
  +   __u32 fb_id;
  +   __u32 width, height;
  +   __u32 pixel_format; /* fourcc code from videodev2.h */
  +
  +   /*
  +* In case of planar formats, this ioctl allows up to 4
  +* buffer objects with offets and pitches per plane.
  +* The pitch and offset order is dictated by the fourcc,
  +* e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
  +*
  +*   YUV 4:2:0 image with a plane of 8 bit Y samples
  +*   followed by an interleaved U/V plane containing
  +*   8 bit 2x2 subsampled colour difference samples.
  +*
  +* So it would consist of Y as offset[0] and UV as
  +* offeset[1].  Note that offset[0] will generally
  +* be 0.
  +*/
  +   __u32 handles[4];
  +   __u32 pitches[4]; /* pitch for each plane */
  +   __u32 offsets[4]; /* offset of each plane */
  +};
 
 Hey, what about those interlaced buffers? We talked privately about
 adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
 drm_mode_set_plane.
 
 We could stick something like these to those flags:
 fb_cmd2.flags:
 #define DRM_MODE_FB_INTERLACED 0x1
 
 set_plane.flags:
 #define DRM_MODE_PRESENT_TOP_FIELD 0x1
 #define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2

Oh sorry I lost track of the internal discussion.

Are those attributes of the fb or of each object?  E.g. could you mix
interlaced and non-interlaced buffers in a planar format?

Maybe I need to rename this ioctl to addfb_swissarmyknife :)

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

2011-11-14 Thread Rob Clark

On Mon, Nov 14, 2011 at 3:16 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
 On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
 +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b)  8) | \
 +                           ((u32)(c)  16) | ((u32)(d)  24))
 +
 +/* RGB codes */
 +#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
 +#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
 +#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
 +#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
 +#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
 +
 +#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
 +#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')

 I'm confused by these. The code suggests RGB/BGR24 are in fact 32bpp
 formats, so why do we need the RGB/BGR32 variants? If the difference
 is in the alpha channel, I'd like to document that fact in the name.

 Could we call them ARGB, XRGB, XRGB1555 etc.?

 Also the channel and byte order should be documented clearly.

 And one other thing. I probably wouldn't call these fourccs
 since they don't actually match the official fourccs. Not that
 there is anything sensible defined for RGB formats in the
 official list anyway. In fact, I'm not sure what we gain by
 cooking our own fourccs when we know most of them won't match
 the official list. AFAICS a simple running number would do
 just as well as the format identifier.

I expect that v4l just made up their own fourcc values for some of the
RGB formats..  which isn't a horrible idea, and seems worthwhile to be
aligned with names/values that v4l already picked.  At least then we
don't have two different sets of more or less arbitrary rgb fourcc
names..

BR,
-R

 --
 Ville Syrjälä
 Intel OTC
 ___
 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

[Bug 27184] Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably

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

--- Comment #18 from Oliver Winker oliver...@oli1170.net 2011-11-14 14:01:30 
PST ---
(In reply to comment #17)
 DPMS standby, suspend, and off states are all treated the same from the
 driver's perspective.  The driver really only deals with 2 DPMS states on and
 off.

Ok, interesting to know. Now somehow the way using xset dpms 240 0 0
(stand-by) quite surely made a difference for me at the time (3.1) - but I
can't prove and explain in detail.

Now currently I'm using xset dpms 0 240 0 (suspend) with 3.1 and until now it
wakes up quite reliable. Which would be in inline with your info, that the
driver operates on the same two states, as with stand-by. 

Maybe I'll also retest again the KDE power mgmt setting way, where I originally
observed the wake-up problem. Maybe it's some screwed side effect in the end. 

  
  Anyway, I will also retry a bit and do some testing using suspend on a 
  3.1,
  to see if something changed.
 
 When you say suspend, are you talking about the DPMS display state, or suspend
 and resume of the entire laptop?  The two are very different.

No, no - I'm really talking about pure display suspend/resume, on a desktop
with an Asus screen. Only the display is suspended and should nicely wakeup
again, when I tick the mouse ;).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Mon, Nov 14, 2011 at 01:35:57PM -0800, Jesse Barnes wrote:
 On Mon, 14 Nov 2011 23:24:55 +0200
 Ville Syrjälä ville.syrj...@linux.intel.com wrote:
 
  On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
   +struct drm_mode_fb_cmd2 {
   + __u32 fb_id;
   + __u32 width, height;
   + __u32 pixel_format; /* fourcc code from videodev2.h */
   +
   + /*
   +  * In case of planar formats, this ioctl allows up to 4
   +  * buffer objects with offets and pitches per plane.
   +  * The pitch and offset order is dictated by the fourcc,
   +  * e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
   +  *
   +  *   YUV 4:2:0 image with a plane of 8 bit Y samples
   +  *   followed by an interleaved U/V plane containing
   +  *   8 bit 2x2 subsampled colour difference samples.
   +  *
   +  * So it would consist of Y as offset[0] and UV as
   +  * offeset[1].  Note that offset[0] will generally
   +  * be 0.
   +  */
   + __u32 handles[4];
   + __u32 pitches[4]; /* pitch for each plane */
   + __u32 offsets[4]; /* offset of each plane */
   +};
  
  Hey, what about those interlaced buffers? We talked privately about
  adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
  drm_mode_set_plane.
  
  We could stick something like these to those flags:
  fb_cmd2.flags:
  #define DRM_MODE_FB_INTERLACED 0x1
  
  set_plane.flags:
  #define DRM_MODE_PRESENT_TOP_FIELD 0x1
  #define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2
 
 Oh sorry I lost track of the internal discussion.
 
 Are those attributes of the fb or of each object?  E.g. could you mix
 interlaced and non-interlaced buffers in a planar format?

I suppose it might be possible that you'd want to treat luma as
interlaced and chroma as progressive under some circumstances.
But I can't see why simply defining another flag for that wouldn't
be enough.

 Maybe I need to rename this ioctl to addfb_swissarmyknife :)

Now I'm just waiting for someone to jump in and say that they 
want independent buffers for each interlaced field :)

Me? I'll be happy with just those two flags members... for now at least ;)

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: add plane support v3

Planes are a bit like half-CRTCs.  They have a location and fb, but
don't drive outputs directly.  Add support for handling them to the core
KMS code.

v2: fix ABI of get_plane - move format_type_ptr to the end
v3: add 'flags' field for interlaced support (from Ville)

Acked-by: Alan Cox a...@lxorguk.ukuu.org.uk
Reviewed-by: Rob Clark rob.cl...@linaro.org
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/drm_crtc.c |  257 +++-
 drivers/gpu/drm/drm_drv.c  |3 +
 include/drm/drm.h  |3 +
 include/drm/drm_crtc.h |   75 +-
 include/drm/drm_mode.h |   37 +++
 5 files changed, 372 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..804ef12 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb-dev;
struct drm_crtc *crtc;
+   struct drm_plane *plane;
struct drm_mode_set set;
int ret;
 
@@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}
 
+   list_for_each_entry(plane, dev-mode_config.plane_list, head) {
+   if (plane-fb == fb) {
+   /* should turn off the crtc */
+   ret = plane-funcs-disable_plane(plane);
+   if (ret)
+   DRM_ERROR(failed to disable plane with busy 
fb\n);
+   }
+   }
+
drm_mode_object_put(dev, fb-base);
list_del(fb-head);
dev-mode_config.num_fb--;
@@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
 }
 EXPORT_SYMBOL(drm_encoder_cleanup);
 
+int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+  unsigned long possible_crtcs,
+  const struct drm_plane_funcs *funcs,
+  uint32_t *formats, uint32_t format_count)
+{
+   mutex_lock(dev-mode_config.mutex);
+
+   plane-dev = dev;
+   drm_mode_object_get(dev, plane-base, DRM_MODE_OBJECT_PLANE);
+   plane-funcs = funcs;
+   plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+   if (!plane-format_types) {
+   DRM_DEBUG_KMS(out of memory when allocating plane\n);
+   drm_mode_object_put(dev, plane-base);
+   return -ENOMEM;
+   }
+
+   memcpy(plane-format_types, formats, format_count);
+   plane-format_count = format_count;
+   plane-possible_crtcs = possible_crtcs;
+
+   list_add_tail(plane-head, dev-mode_config.plane_list);
+   dev-mode_config.num_plane++;
+
+   mutex_unlock(dev-mode_config.mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+   struct drm_device *dev = plane-dev;
+
+   mutex_lock(dev-mode_config.mutex);
+   kfree(plane-format_types);
+   drm_mode_object_put(dev, plane-base);
+   list_del(plane-head);
+   dev-mode_config.num_plane--;
+   mutex_unlock(dev-mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
 /**
  * drm_mode_create - create a new display mode
  * @dev: DRM device
@@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(dev-mode_config.encoder_list);
INIT_LIST_HEAD(dev-mode_config.property_list);
INIT_LIST_HEAD(dev-mode_config.property_blob_list);
+   INIT_LIST_HEAD(dev-mode_config.plane_list);
idr_init(dev-mode_config.crtc_idr);
 
mutex_lock(dev-mode_config.mutex);
@@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_encoder *encoder, *enct;
struct drm_framebuffer *fb, *fbt;
struct drm_property *property, *pt;
+   struct drm_plane *plane, *plt;
 
list_for_each_entry_safe(encoder, enct, dev-mode_config.encoder_list,
 head) {
@@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
crtc-funcs-destroy(crtc);
}
 
+   list_for_each_entry_safe(plane, plt, dev-mode_config.plane_list,
+head) {
+   plane-funcs-destroy(plane);
+   }
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);
 
@@ -1466,6 +1526,197 @@ out:
 }
 
 /**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_mode_get_plane_res *plane_resp = data;
+   struct drm_mode_config *config;
+   struct drm_plane *plane;
+   uint32_t __user *plane_ptr;
+   int

[PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v5

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Acked-by: Alan Cox a...@lxorguk.ukuu.org.uk
Reviewed-by: Rob Clark rob.cl...@linaro.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
 drivers/gpu/drm/drm_crtc.c|  111 +++--
 drivers/gpu/drm/drm_crtc_helper.c |   51 -
 drivers/gpu/drm/drm_drv.c |1 +
 drivers/gpu/drm/i915/intel_display.c  |   39 ++-
 drivers/gpu/drm/i915/intel_drv.h  |2 +-
 drivers/gpu/drm/i915/intel_fb.c   |   11 ++--
 drivers/gpu/drm/nouveau/nouveau_display.c |6 +-
 drivers/gpu/drm/nouveau/nouveau_fb.h  |2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |   13 ++--
 drivers/gpu/drm/radeon/radeon_display.c   |8 +-
 drivers/gpu/drm/radeon/radeon_fb.c|   18 +++--
 drivers/gpu/drm/radeon/radeon_mode.h  |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   22 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |1 +
 drivers/staging/gma500/framebuffer.c  |2 +-
 include/drm/drm.h |1 +
 include/drm/drm_crtc.h|9 ++-
 include/drm/drm_crtc_helper.h |4 +-
 include/drm/drm_fourcc.h  |   63 
 include/drm/drm_mode.h|   27 +++
 20 files changed, 327 insertions(+), 66 deletions(-)
 create mode 100644 include/drm/drm_fourcc.h

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 804ef12..30a70a4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -35,6 +35,7 @@
 #include drmP.h
 #include drm_crtc.h
 #include drm_edid.h
+#include drm_fourcc.h
 
 struct drm_prop_enum_list {
int type;
@@ -563,7 +564,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
return -ENOMEM;
}
 
-   memcpy(plane-format_types, formats, format_count);
+   memcpy(plane-format_types, formats, format_count * sizeof(uint32_t));
plane-format_count = format_count;
plane-possible_crtcs = possible_crtcs;
 
@@ -1910,6 +1911,42 @@ out:
return ret;
 }
 
+/* Original addfb only supported RGB formats, so figure out which one */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+   uint32_t fmt;
+
+   switch (bpp) {
+   case 8:
+   fmt = DRM_FOURCC_RGB332;
+   break;
+   case 16:
+   if (depth == 15)
+   fmt = DRM_FOURCC_RGB555;
+   else
+   fmt = DRM_FOURCC_RGB565;
+   break;
+   case 24:
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   case 32:
+   if (depth == 24)
+   fmt = DRM_FOURCC_RGB24;
+   else if (depth == 30)
+   fmt = DRM_INTEL_RGB30;
+   else
+   fmt = DRM_FOURCC_RGB32;
+   break;
+   default:
+   DRM_ERROR(bad bpp, assuming RGB24 pixel format\n);
+   fmt = DRM_FOURCC_RGB24;
+   break;
+   }
+
+   return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
 /**
  * drm_mode_addfb - add an FB to the graphics configuration
  * @inode: inode from the ioctl
@@ -1930,7 +1967,74 @@ out:
 int drm_mode_addfb(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
-   struct drm_mode_fb_cmd *r = data;
+   struct drm_mode_fb_cmd *or = data;
+   struct drm_mode_fb_cmd2 r = {};
+   struct drm_mode_config *config = dev-mode_config;
+   struct drm_framebuffer *fb;
+   int ret = 0;
+
+   /* Use new struct with format internally */
+   r.fb_id = or-fb_id;
+   r.width = or-width;
+   r.height = or-height;
+   r.pitches[0] = or-pitch;
+   r.pixel_format = drm_mode_legacy_fb_format(or-bpp, or-depth);
+   r.handles[0] = or-handle;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if ((config-min_width  r.width) || (r.width  config-max_width)) {
+   DRM_ERROR(mode new framebuffer width not within

Re: [PATCH 2/2] drm: add an fb creation ioctl that takes a pixel format v4

On Tue, 15 Nov 2011 00:37:47 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:

 On Mon, Nov 14, 2011 at 01:35:57PM -0800, Jesse Barnes wrote:
  On Mon, 14 Nov 2011 23:24:55 +0200
  Ville Syrjälä ville.syrj...@linux.intel.com wrote:
  
   On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
+struct drm_mode_fb_cmd2 {
+   __u32 fb_id;
+   __u32 width, height;
+   __u32 pixel_format; /* fourcc code from videodev2.h */
+
+   /*
+* In case of planar formats, this ioctl allows up to 4
+* buffer objects with offets and pitches per plane.
+* The pitch and offset order is dictated by the fourcc,
+* e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
+*
+*   YUV 4:2:0 image with a plane of 8 bit Y samples
+*   followed by an interleaved U/V plane containing
+*   8 bit 2x2 subsampled colour difference samples.
+*
+* So it would consist of Y as offset[0] and UV as
+* offeset[1].  Note that offset[0] will generally
+* be 0.
+*/
+   __u32 handles[4];
+   __u32 pitches[4]; /* pitch for each plane */
+   __u32 offsets[4]; /* offset of each plane */
+};
   
   Hey, what about those interlaced buffers? We talked privately about
   adding a '__u32 flags' member to both drm_mode_fb_cmd2 and
   drm_mode_set_plane.
   
   We could stick something like these to those flags:
   fb_cmd2.flags:
   #define DRM_MODE_FB_INTERLACED 0x1
   
   set_plane.flags:
   #define DRM_MODE_PRESENT_TOP_FIELD 0x1
   #define DRM_MODE_PRESENT_BOTTOM_FIELD 0x2
  
  Oh sorry I lost track of the internal discussion.
  
  Are those attributes of the fb or of each object?  E.g. could you mix
  interlaced and non-interlaced buffers in a planar format?
 
 I suppose it might be possible that you'd want to treat luma as
 interlaced and chroma as progressive under some circumstances.
 But I can't see why simply defining another flag for that wouldn't
 be enough.
 
  Maybe I need to rename this ioctl to addfb_swissarmyknife :)
 
 Now I'm just waiting for someone to jump in and say that they 
 want independent buffers for each interlaced field :)
 
 Me? I'll be happy with just those two flags members... for now at least ;)

Ok, added, see the latest patchset.

Dave, please pound the gavel on this now and declare it sold before
someone asks me to add braille support. :)

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [PATCH] Fix wrong assumptions in cea_for_each_detailed_block v2

On Sun, 2011-11-13 at 09:57 +0100, Christian Schmidt wrote:
 The current logic misunderstands the spec about CEA 18byte descriptors.
 First, the spec doesn't state detailed timing descriptors but 18 byte
 descriptors, so any data record could be stored, mixed timings and
 other data, just as in the standard EDID.

I don't think the code misinterprets this.  But I also don't think your
patch changes this interpretation, so that's fine.

 Second, the lower four bit of byte 3 of the CEA record do not contain
 the number of descriptors, but the total number of DTDs defining native
 formats in the whole EDID [...], starting with the first DTD in the DTD
 list (which starts in the base EDID block). A device can of course
 support non-native formats.
 
 As such the number can't be used to determine n, and the existing code
 will filter non-timing 18byte descriptors anyway.

Good catch, thanks.

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM KMS Modesetting

On Mon, 14 Nov 2011 21:47:09 +0100
David Herrmann dh.herrm...@googlemail.com wrote:
  I had to modify the resolution the test was searching for
  to 1920x1200 instead of 1024x600 since I tested on a DP attached
  monitor, and fix the connector id, but other than that it seemed to
  work fine.
 
 Thanks for testing. At least my code seems right now, but I still
 cannot get it to work on my machine. The output of modetest is:
 https://gist.github.com/1365083
 
 There is only one connected connector+encoder+mode so I don't know
 where the problem exactly is. Are there any debug options? Is it
 possible to query the EGLImage for width/height?

Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
width/stride correctly somewhere then.  You'd have to walk through the
gbm_dri2.c and egl_dri2.c code and see where the width is going off
into the weeds.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [PATCH] drm_edid: support CEA video modes

On Sun, 2011-11-13 at 01:31 +0100, Christian Schmidt wrote:
 TFT/plasma televisions and projectors have become commonplace, and so
 has the use of PCs to drive them. Add the video modes specified by an
 EDID's CEA extension to the mode database for a connector.

Thanks for finishing this up.  The mode list was indeed mechanically
generated (pdf2text on the spec and then some python to bash it all
together).  It's probably worth noting in the comment that it's from
CEA-861-D, as I suspect subsequent revisions have added more timings (I
haven't bought it yet to check).

Reviewed-by: Adam Jackson a...@redhat.com

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34969] [nouveau] Card lockup on openarena

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

--- Comment #16 from Andrew Randrianasulu rand...@mail.ru 2011-11-14 15:16:55 
PST ---
So, I bisected mesa tree (7.11 branch)

Result:

2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit
commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3
Author: Marek OlЕЎГЎk mar...@gmail.com
Date:   Sun Dec 26 04:30:51 2010 +0100

st/mesa: set vertex arrays state only when necessary

The vertex arrays state should be set only when (_NEW_ARRAY | _NEW_PROGRAM)
is dirty. This assumes user buffer content is mutable, which will be
sorted out in the next commit. The following usage case should be much
faster
now:

for (i = 0; i  1000; i++) {
   glDrawElements(...);
}

Or even:

for (i = 0; i  1000; i++) {
   glSomeStateChangeOtherThanArraysOrProgram(...);
   glDrawElements(...);
}

The performance increase from this may be significant in some apps and
negligible in others. It is especially noticable in the Torcs game (r300g):
Before: 15.4 fps
After: 20 fps

Also less looping over attribs in st_draw_vbo yields slight speed-up
in apps with lots of glDraw* calls.

:04 04 45e5630d445206ce8c7eab6ac6bfe144901695bb
927efd20e354ecae459227bd464dbb6001cb448e M  src


guest@slax:~/botva/src/src/mesa$ git bisect log
git bisect start
# good: [0f7325b89038937bd428f7c89ed9859189a0ab0b] i965: Emit texel offsets in
sampler messages.
git bisect good 0f7325b89038937bd428f7c89ed9859189a0ab0b
# bad: [8767fe2437094f33db140a6b92f25116de4fc371] mesa: Sort extensions in
extension string by year.
git bisect bad 8767fe2437094f33db140a6b92f25116de4fc371
# bad: [fbd681f1a03f6ad62432107dc94e02674f6de7bf] i915g: Use dump function in
sw winsys
git bisect bad fbd681f1a03f6ad62432107dc94e02674f6de7bf
# good: [1f5b67416810f7331fe71db0f767418473083701] egl_dri2: add nouveau
support.
git bisect good 1f5b67416810f7331fe71db0f767418473083701
# bad: [e0481cac7d57757d75a39763a1dd36b915979bb4] svga: Disable surface cache
for textures
git bisect bad e0481cac7d57757d75a39763a1dd36b915979bb4
# bad: [fc5ab1b19780ef97c5e7f6257a2d91121503bd53] mesa: use gl_format type
instead of GLuint
git bisect bad fc5ab1b19780ef97c5e7f6257a2d91121503bd53
# bad: [56029ce52bafbc51b5b6660383767257b7770cd7] r300g: inline some of the
pipe_buffer_map/unmap calls
git bisect bad 56029ce52bafbc51b5b6660383767257b7770cd7
# good: [9e96ea0652dda64f8eb311d7dfc9c50519ad02f0] r600g: add alignment cases
for linear aligned
git bisect good 9e96ea0652dda64f8eb311d7dfc9c50519ad02f0
# bad: [588fa884d212eba5ffbc69fda75db37d7c77214c] gallium: notify drivers about
possible changes in user buffer contents
git bisect bad 588fa884d212eba5ffbc69fda75db37d7c77214c
# good: [cfaf217135d8a8e903b3fbf380f18170df018f0c] vbo: bind arrays only when
necessary
git bisect good cfaf217135d8a8e903b3fbf380f18170df018f0c
# good: [cdca3c58aa2d9549f5188910e2a77b438516714f] gallium: remove
pipe_vertex_buffer::max_index
git bisect good cdca3c58aa2d9549f5188910e2a77b438516714f
# bad: [2a904fd6a0cb80eec6dec2bae07fd8778b04caf3] st/mesa: set vertex arrays
state only when necessary
git bisect bad 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 34969] [nouveau] Card lockup on openarena

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

--- Comment #17 from Marek Olšák mar...@gmail.com 2011-11-14 15:28:23 PST ---
(In reply to comment #16)
 So, I bisected mesa tree (7.11 branch)
 
 Result:
 
 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit
 commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3
 Author: Marek OlЕЎГЎk mar...@gmail.com
 Date:   Sun Dec 26 04:30:51 2010 +0100
 
 st/mesa: set vertex arrays state only when necessary

I guess the bisection failed in this case, because that commit contains a bug
that was fixed later.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 34969] [nouveau] Card lockup on openarena

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

--- Comment #18 from Andrew Randrianasulu rand...@mail.ru 2011-11-14 16:06:19 
PST ---
(In reply to comment #17)
 (In reply to comment #16)
  So, I bisected mesa tree (7.11 branch)
  
  Result:
  
  2a904fd6a0cb80eec6dec2bae07fd8778b04caf3 is the first bad commit
  commit 2a904fd6a0cb80eec6dec2bae07fd8778b04caf3
  Author: Marek OlЕЎГЎk mar...@gmail.com
  Date:   Sun Dec 26 04:30:51 2010 +0100
  
  st/mesa: set vertex arrays state only when necessary
 
 I guess the bisection failed in this case, because that commit contains a bug
 that was fixed later.

gallium: notify drivers about possible changes in user buffer contents ? It was
well-masked for Q3 arena until extension sorting exposed it there, but I run my
./vertexrate (reduced) test, and you can see whole bisect log... May be nvfx
played too much with mesa/gallium internals.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 34969] [nouveau] Card lockup on openarena

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

--- Comment #19 from Andrew Randrianasulu rand...@mail.ru 2011-11-14 16:36:06 
PST ---
Created attachment 53562
  -- https://bugs.freedesktop.org/attachment.cgi?id=53562
hand-typed log

While trying some self-made liveCD based on slackware-current, I found
Slackware's Mesa works fine for both Celestia, and Q3 timedemo demo002.
Slackware currently uses Mesa 7.10.2/libdrm 2.4.24/ and some nouveau DDX from
march, 2011. I've compiled 7.11 branch , and discovered it hang videocard like
7.12 does on my main system. Then I just set good commit at last one from Luca.
And even if i keep all other components the same
(libdrm-2.4.27/xf86-video-nouveau few comments behind git/kernel 3.2.0-rc1
mainline) freeze go on and off with just mesa versions.My bisect compilation
was without any llvm stuff (normal compilation has llvm 2.9). nice mistery, and
thanfully  whole machine not locked up hard, only videocard, it seems.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] drm_edid: support CEA video modes

2011-11-14 Thread alanwww1

I ran a test with the CEA patch, on my Sandy Bridge system with a Samsung
HDTV hooked up with an Onkyo TX-SR-607 AV-receiver.
The patch works like charm. The so wanted missing modelines are there, both
in the kernel log and in the Xorg.log and I can now use them in any Media
Center application,

Dmesg before:

[   10.496714] [drm:drm_mode_debug_printmodeline], Modeline
18:1920x1080 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48
0x5
[   10.496717] [drm:drm_mode_debug_printmodeline], Modeline
20:1280x720 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[   10.496719] [drm:drm_mode_debug_printmodeline], Modeline
19:1280x720 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[   10.496722] [drm:drm_mode_debug_printmodeline], Modeline
21:640x480 60 25200 640 656 752 800 480 490 492 525 0x40 0xa


Dmesg After:

[   10.777130] [drm:drm_mode_prune_invalid], Not using 1920x1080 mode 7
[   10.777132] [drm:drm_mode_debug_printmodeline], Modeline
26:1920x1080 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40
0x15
[   10.777134] [drm:drm_mode_prune_invalid], Not using 1920x1080 mode 7
[   10.777136] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:14:HDMI-A-2] probed modes :
[   10.777138] [drm:drm_mode_debug_printmodeline], Modeline
22:1920x1080 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48
0x5
[   10.777140] [drm:drm_mode_debug_printmodeline], Modeline
23:1920x1080 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40
0x5
[   10.777143] [drm:drm_mode_debug_printmodeline], Modeline
32:1920x1080 30 74250 1920 2008 2052 2200 1080 1084 1089 1125 0x40
0x5
[   10.777145] [drm:drm_mode_debug_printmodeline], Modeline
31:1920x1080 25 74250 1920 2448 2492 2640 1080 1084 1089 1125 0x40
0x5
[   10.777147] [drm:drm_mode_debug_printmodeline], Modeline
30:1920x1080 24 74250 1920 2558 2602 2750 1080 1084 1089 1125 0x40
0x5
[   10.777149] [drm:drm_mode_debug_printmodeline], Modeline
36:2880x576 50 108000 2880 2928 3184 3456 576 581 586 625 0x40 0xa
[   10.777151] [drm:drm_mode_debug_printmodeline], Modeline
35:2880x480 60 108000 2880 2944 3192 3432 480 489 495 525 0x40 0xa
[   10.777153] [drm:drm_mode_debug_printmodeline], Modeline
25:1280x720 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[   10.777155] [drm:drm_mode_debug_printmodeline], Modeline
24:1280x720 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[   10.777158] [drm:drm_mode_debug_printmodeline], Modeline
34:1440x576 50 54000 1440 1464 1592 1728 576 581 586 625 0x40 0xa
[   10.777160] [drm:drm_mode_debug_printmodeline], Modeline
33:1440x480 60 54000 1440 1472 1596 1716 480 489 495 525 0x40 0xa
[   10.777162] [drm:drm_mode_debug_printmodeline], Modeline
29:720x576 50 27000 720 732 796 864 576 581 586 625 0x40 0xa
[   10.777164] [drm:drm_mode_debug_printmodeline], Modeline
28:720x480 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
[   10.777166] [drm:drm_mode_debug_printmodeline], Modeline
21:640x480 60 25200 640 656 752 800 480 490 492 525 0x40 0xa

Xorg before:

[11.924] (II) intel(0): Printing probed modes for output HDMI2
[11.924] (II) intel(0): Modeline 1920x1080x60.0  148.50  1920
2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz)
[11.924] (II) intel(0): Modeline 1280x720x50.0   74.25  1280
1720 1760 1980  720 725 730 750 +hsync +vsync (37.5 kHz)
[11.924] (II) intel(0): Modeline 1280x720x60.0   74.25  1280
1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz)
[11.924] (II) intel(0): Modeline 640x480x60.0   25.20  640 656
752 800  480 490 492 525 -hsync -vsync (31.5 kHz)

Xorg after:

[   324.852] (II) intel(0): Printing probed modes for output HDMI2
[   324.852] (II) intel(0): Modeline 1920x1080x60.0  148.50  1920
2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz)
[   324.852] (II) intel(0): Modeline 1920x1080x50.0  148.50  1920
2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz)
[   324.852] (II) intel(0): Modeline 1920x1080x30.0   74.25  1920
2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (33.8 kHz)
[   324.852] (II) intel(0): Modeline 1920x1080x25.0   74.25  1920
2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (28.1 kHz)
[   324.852] (II) intel(0): Modeline 1920x1080x24.0   74.25  1920
2558 2602 2750  1080 1084 1089 1125 +hsync +vsync (27.0 kHz)
[   324.852] (II) intel(0): Modeline 2880x576x50.0  108.00  2880
2928 3184 3456  576 581 586 625 -hsync -vsync (31.2 kHz)
[   324.852] (II) intel(0): Modeline 2880x480x59.9  108.00  2880
2944 3192 3432  480 489 495 525 -hsync -vsync (31.5 kHz)
[   324.852] (II) intel(0): Modeline 1280x720x50.0   74.25  1280
1720 1760 1980  720 725 730 750 +hsync +vsync (37.5 kHz)
[   324.852] (II) intel(0): Modeline 1280x720x60.0   74.25  1280
1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz)
[   324.852] (II) intel(0): Modeline 1440x576x50.0   54.00  1440
1464 1592 1728  576 581 586 625 -hsync -vsync (31.2 kHz)
[   324.852] (II) intel(0): Modeline 1440x480x59.9   54.00  1440
1472 1596 1716  480 489 495 525 -hsync -vsync

Re: [PATCH 1/2] drm: add plane support v2

2011-11-14 Thread Ben Skeggs

On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
 Planes are a bit like half-CRTCs.  They have a location and fb, but
 don't drive outputs directly.  Add support for handling them to the core
 KMS code.
Out of curiosity, lets say you have a *really* stupid hardware overlay
that can't do scaling (or even, has limited scaling capabilities),
should we provide some way to expose this to userspace?

I've recently looked at the hardware overlay on recent NVIDIA GPUs with
the intention of implementing this API in nouveau.  However, while there
is indeed an overlay, it only accepts a couple of RGB formats and does
simple clipping - and *no* scaling that I've found so far.

From traces of VDPAU, NVIDIA themselves appear to do CSC and scaling via
some other method before passing the frame off to the overlay.

Rather disappointing, and seemingly not of too much use.  But, I'd like
to expose what functionality there is in any case.

Ben.

 
 v2: fix ABI of get_plane - move format_type_ptr to the end
 
 Acked-by: Alan Cox a...@lxorguk.ukuu.org.uk
 Reviewed-by: Rob Clark rob.cl...@linaro.org
 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/drm_crtc.c |  257 
 +++-
  drivers/gpu/drm/drm_drv.c  |3 +
  include/drm/drm.h  |3 +
  include/drm/drm_crtc.h |   75 +-
  include/drm/drm_mode.h |   33 ++
  5 files changed, 368 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index fe738f0..804ef12 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
  {
   struct drm_device *dev = fb-dev;
   struct drm_crtc *crtc;
 + struct drm_plane *plane;
   struct drm_mode_set set;
   int ret;
  
 @@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
   }
   }
  
 + list_for_each_entry(plane, dev-mode_config.plane_list, head) {
 + if (plane-fb == fb) {
 + /* should turn off the crtc */
 + ret = plane-funcs-disable_plane(plane);
 + if (ret)
 + DRM_ERROR(failed to disable plane with busy 
 fb\n);
 + }
 + }
 +
   drm_mode_object_put(dev, fb-base);
   list_del(fb-head);
   dev-mode_config.num_fb--;
 @@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
  }
  EXPORT_SYMBOL(drm_encoder_cleanup);
  
 +int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
 +unsigned long possible_crtcs,
 +const struct drm_plane_funcs *funcs,
 +uint32_t *formats, uint32_t format_count)
 +{
 + mutex_lock(dev-mode_config.mutex);
 +
 + plane-dev = dev;
 + drm_mode_object_get(dev, plane-base, DRM_MODE_OBJECT_PLANE);
 + plane-funcs = funcs;
 + plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
 +   GFP_KERNEL);
 + if (!plane-format_types) {
 + DRM_DEBUG_KMS(out of memory when allocating plane\n);
 + drm_mode_object_put(dev, plane-base);
 + return -ENOMEM;
 + }
 +
 + memcpy(plane-format_types, formats, format_count);
 + plane-format_count = format_count;
 + plane-possible_crtcs = possible_crtcs;
 +
 + list_add_tail(plane-head, dev-mode_config.plane_list);
 + dev-mode_config.num_plane++;
 +
 + mutex_unlock(dev-mode_config.mutex);
 +
 + return 0;
 +}
 +EXPORT_SYMBOL(drm_plane_init);
 +
 +void drm_plane_cleanup(struct drm_plane *plane)
 +{
 + struct drm_device *dev = plane-dev;
 +
 + mutex_lock(dev-mode_config.mutex);
 + kfree(plane-format_types);
 + drm_mode_object_put(dev, plane-base);
 + list_del(plane-head);
 + dev-mode_config.num_plane--;
 + mutex_unlock(dev-mode_config.mutex);
 +}
 +EXPORT_SYMBOL(drm_plane_cleanup);
 +
  /**
   * drm_mode_create - create a new display mode
   * @dev: DRM device
 @@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
   INIT_LIST_HEAD(dev-mode_config.encoder_list);
   INIT_LIST_HEAD(dev-mode_config.property_list);
   INIT_LIST_HEAD(dev-mode_config.property_blob_list);
 + INIT_LIST_HEAD(dev-mode_config.plane_list);
   idr_init(dev-mode_config.crtc_idr);
  
   mutex_lock(dev-mode_config.mutex);
 @@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
   struct drm_encoder *encoder, *enct;
   struct drm_framebuffer *fb, *fbt;
   struct drm_property *property, *pt;
 + struct drm_plane *plane, *plt;
  
   list_for_each_entry_safe(encoder, enct, dev-mode_config.encoder_list,
head) {
 @@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
   crtc-funcs-destroy(crtc);

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)