date:20130328

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

--- Comment #44 from Alexandre Demers  ---
(In reply to comment #43)
> I do not know if this is relevant, but I recently purchased a radeon 6450
> and had similar issues - corruption when KMS is started and lockups when X
> starts. I did not get these issues in fglrx or the windows drivers.
> 
> I then happened to notice that the memory clock settings for the 'boot'
> power profile were incorrect, and were significantly higher than the card
> should support. The high & low power states appeared to be correct. Changing
> the boot values using the Radeon Bios editor
> (http://www.techpowerup.com/rbe/) fixed these problems for me.

While this is not related to the proposed attachment, it is quite interesting
to know you were able to fix your problem by tweaking your card's bios. Maybe
Kunal could tell us more about some similar observations.

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

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:

> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall  
> wrote:
> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
> >>
> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
> >> upstream fb patch is not accepted. If it is accepted we would not need
> >> this at all!
> >>
> >> > Then I guess there would be a similar rule for the false case?
> >>
> >> Nope, see that's the proactive strategy taken by the static inline and
> >> hence the patch. compat would have a static inline for both cases, and
> >> for the false case it'd be a no-op. If accepted upstream though then
> >> we would not need any changes for this collateral evolution. However
> >> *spotting* these collateral evolutions and giving you SmPL for them as
> >> a proactive strategy might be good given that if these type of patches
> >> are indeed welcomed upstream we'd then be able to address these as
> >> secondary steps. If they are not accepted then indeed we'd use them to
> >> backport that collateral evolution through both compat (adds the
> >> static inlines) and compat-drivers (the SmPL).
> >
> > Probably I am missing something, since I haven't looked at the code in
> > detail, bu wouldn't it be nicer to have a function call for the false
> > case, if there is a function call for the true case?
> 
> Yes, and indeed we have that, its the same function call, in the
> negative case its a no-op, in the newer kernels it wraps to modifying
> the element as in the original code.
> 
> > In looking at the
> > code, one could wonder why things are not done in a parallel way.
> 
> Not sure I get this.

I looked in today's linux-next, and there seems to be only one 
initialization of this field, to true, and one test of this field.  So 
perhaps the case for setting the field to false just isn't needed.

julia

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

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

--- Comment #8 from Thilo Cestonaro  ---
Finally I found some time do reinstall Ubuntu and compile the kernel with the
patch. Sadly it doesn't fix the issue. :(

Greetings
Thilo

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

[Bug 62882] Lockup after attempt to enable discrete Radeon GPU on Linux 3.9rc4

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

--- Comment #1 from Alex Deucher  ---
Your dGPU is not powering up for some reason.

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

[Bug 62882] New: Lockup after attempt to enable discrete Radeon GPU on Linux 3.9rc4

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

  Priority: medium
Bug ID: 62882
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Lockup after attempt to enable discrete Radeon GPU on
Linux 3.9rc4
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: runetmember at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 77173
  --> https://bugs.freedesktop.org/attachment.cgi?id=77173&action=edit
crash log

When I try to enable discrete GPU I get kernel module crash (please look into
attached log) and system lockup (few seconds later).

Software:
Kubuntu 13.04 x86_64 updated from Canonical X Staging PPA (there is just stable
X.Org Server 1.14, stable Mesa 9.1 and stable 7.1.0 radeon driver)
Linux 3.9rc4 
Mesa: 9.1
libdrm-radeon1: 2.4.43
xserver-xorg-video-radeon: 7.1.0
xserver-xorg-core: 1.14.0

Hardware:
Acer Aspire 7560G laptop,
AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO)
Discrete AMD Radeon HD 6650M (TURKS)

"xrandr --listproviders" output:
Providers: number : 2
Provider 0: id: 138 cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 2 outputs: 3 associated providers: 1 name:radeon
Provider 1: id: 85 cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 6 outputs: 0 associated providers: 1 name:radeon

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

[Bug 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

--- Comment #5 from Alexander von Gluck  ---
If I disable ColorTiling, Gnome doesn't load completely only showing the
desktop wallpaper Errors about unable to find displaybuffer (or something like
that... not sure of exact error)

While the display is corrupt.. I *can* tell that acceleration is working due to
the speed of the GUI compared to llvmpipe.

-- 
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 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

--- Comment #4 from Alexander von Gluck  ---
Created attachment 77183
  --> https://bugs.freedesktop.org/attachment.cgi?id=77183&action=edit
Example of corruption

-- 
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 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

--- Comment #3 from Alexander von Gluck  ---
Created attachment 77182
  --> https://bugs.freedesktop.org/attachment.cgi?id=77182&action=edit
dmesg  wcolortile  stable software version

-- 
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 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

--- Comment #2 from Alexander von Gluck  ---
Created attachment 77181
  --> https://bugs.freedesktop.org/attachment.cgi?id=77181&action=edit
xorgconf  wcolortile  stable software version

-- 
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 62889] ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

--- Comment #1 from Alexander von Gluck  ---
Created attachment 77180
  --> https://bugs.freedesktop.org/attachment.cgi?id=77180&action=edit
xorglog  wcolortile  stable software version

-- 
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 62889] New: ColorTiling results in glitches on Radeon HD 7970 + Glamor

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

  Priority: medium
Bug ID: 62889
  Assignee: dri-devel@lists.freedesktop.org
   Summary: ColorTiling results in glitches on Radeon HD 7970 +
Glamor
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: kallis...@unixzen.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Versions tried
Stable:
LLVM 3.2  + Mesa 9.1.1 + kernel 3.8.4

Mainline
LLVM 3.3-devel + mesa 9.2-devel + kernel 3.8.4


Gnome Desktop.


Attempting to use Glamor on the Radeon HD 7970 results in odd screen artifacts.
 Cursor is not effected however.

worked with agd5f in irc without any luck

-- 
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 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #20 from Alexandre Demers  ---
I'm reopening this bug for two reasons:
 -It is still happening with kernel 3.9.0-rc4 because attachment 64759 from bug
42373 seems to never have been pushed
 -It is not a duplicate of bug 42373 since attachment 64759 fixes current bug
but not 42373

It would be nice to have a revised version of attachment 64759 that applies
correctly on latest kernel, then to have it tested and pushed to kernel's git.

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

Re: [Nouveau] [PATCH v2] drm/nouveau: wait for vblank on page flipping

2013-03-28 Thread Ben Skeggs

On Fri, Mar 29, 2013 at 7:33 AM, Peter Hurley  wrote:
> On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> Oops, fixed to apply this time..
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
>> b/drivers/gpu/drm/nouveau/nouveau_display.c
>> index 4610c3a..020542e 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
>> @@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
>> drm_framebuffer *fb,
>>
>>   /* Emit a page flip */
>>   if (nv_device(drm->device)->card_type >= NV_50) {
>> - ret = nv50_display_flip_next(crtc, fb, chan, 0);
>> + ret = nv50_display_flip_next(crtc, fb, chan, 1);
>
> Why would this work?
Because, when I added the code to support all this I kept it in mind
and added a switch to use it.

Now.  The reason I never switched this on is that (as I *already*
mentioned in #nouveau to Maarten about another patch to enable vblank
unconditionally in the DDX...) we already have huge problems with
memory bandwidth due to our cards usually starting up at low clock
speeds.  When I added page flipping support it made a huge difference
to some games etc that were barely playable before.

So, it'd be really nice to be able to do this, yes.  But, before I'll
accept the patches a few things need to happen.  I'd have done it
before, but, I've always had higher priority things in the way (like,
fixing the reclocking issue...)..

1. Fix the X server so that the page flipping path (dri2.c, line 1125)
will be called even if theres no swap_interval set, this will allow
page flipping to be used even in the absence of a sync-to-vblank
request too.
2. Remove the GLXVBlank option from the nouveau ddx completely,
default it to on.  The application/user can now control it via other
means anyway (drawable swap_interval).
3. Fix the DRM page flip ioctl to take a flag to request a non-vsync'd
flip, and hook that bit up to the nv50_display_flip_next() call

I think that's everything... This will let us support both the speed
improvements from flipping, and sync-to-vblank as the user chooses.

Ben.

>
>>   if (ret) {
>>   mutex_unlock(&chan->cli->mutex);
>>   goto fail_unreserve;
>
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

--- Comment #43 from Jonathan Hamilton  ---
I do not know if this is relevant, but I recently purchased a radeon 6450 and
had similar issues - corruption when KMS is started and lockups when X starts.
I did not get these issues in fglrx or the windows drivers.

I then happened to notice that the memory clock settings for the 'boot' power
profile were incorrect, and were significantly higher than the card should
support. The high & low power states appeared to be correct. Changing the boot
values using the Radeon Bios editor (http://www.techpowerup.com/rbe/) fixed
these problems for me.

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

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch



On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:

> On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall  wrote:
> > On Thu, 28 Mar 2013, Jesse Barnes wrote:
> >> > -  info->skip_vt_switch = true;
> >> > +  fb_enable_skip_vt_switch(info);
> >> >
> >> > So we'd then have to just add this static inline change for each new 
> >> > driver...
> >> > There may be a way to get SmPL to do this for us...
> >
> > @@
> > type of info  *info;
> > @@
> >
> > -  info->skip_vt_switch = true;
> > +  fb_enable_skip_vt_switch(info);
> >
> > for whatever the type of info is.
>
> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
> upstream fb patch is not accepted. If it is accepted we would not need
> this at all!
>
> > Then I guess there would be a similar rule for the false case?
>
> Nope, see that's the proactive strategy taken by the static inline and
> hence the patch. compat would have a static inline for both cases, and
> for the false case it'd be a no-op. If accepted upstream though then
> we would not need any changes for this collateral evolution. However
> *spotting* these collateral evolutions and giving you SmPL for them as
> a proactive strategy might be good given that if these type of patches
> are indeed welcomed upstream we'd then be able to address these as
> secondary steps. If they are not accepted then indeed we'd use them to
> backport that collateral evolution through both compat (adds the
> static inlines) and compat-drivers (the SmPL).

Probably I am missing something, since I haven't looked at the code in
detail, bu wouldn't it be nicer to have a function call for the false
case, if there is a function call for the true case?  In looking at the
code, one could wonder why things are not done in a parallel way.

julia

drm/tilcdc: LCD panels clocks initialization and earlier backlight initialization

2013-03-28 Thread Michal Bachraty

Hi,

I'm trying to use tilcdc driver for KWH050TG08 LCD panel connected to AM335x 
processor (3.9 rc1 kernel). I have prepared DT bindings for that (listed 
bellow). I see fb0 device but I have no clocks going from cpu to LCD.  My 
clocks for LCD seems not properly to be set ...

virt_2500_ck   1   12500  
sys_clkin_ck8   19   2500  
   dpll_disp_ck 0   12500  
  dpll_disp_m2_ck   0   12500  
 lcd_gclk   0   12500   

and tilcdc_crtc is not called. I also set lcd_gclk to 300MHz, but I got same 
result. The question is there any way how to properly set clocks for LCD?

There is also one issue with backlight panel driver initialization in tilcdc 
driver. This problem seems to depend on DT and I2c driver deferried 
initialization and then also tps65217-bl driver.  Therefore tilcdc is 
initialized earlier than backlight driver. The question is: is there any way 
to switch order for loading drivers and how can be that done?

My short dmesg listing is as follows:
...
[3.330046] pinctrl-single 44e10800.pinmux: request pin 41 (44e108a4) for 
lcd_panel.15
[3.338390] pinctrl-single 44e10800.pinmux: request pin 40 (44e108a0) for 
lcd_panel.15
[3.346707] pinctrl-single 44e10800.pinmux: enabling pinmux_lcd_pins 
function6
[3.354387] panel lcd_panel.15: obtain a copy of previously claimed pinctrl
[3.368248] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[3.375202] [drm] No driver support for vblank timestamp query.
[3.386253] tilcdc 4830e000.fb: fb0:  frame buffer device
[3.392015] tilcdc 4830e000.fb: registered panic notifier
[3.397781] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0
[3.405347] pinctrl core: add 1 pinmux maps
[3.409879] pinctrl-single 44e10800.pinmux: found group selector 7 for 
pinmux_i2c1_pins
[3.418347] pinctrl-single 44e10800.pinmux: request pin 98 (44e10988) for 
44e0b000.i2c
[3.426662] pinctrl-single 44e10800.pinmux: request pin 99 (44e1098c) for 
44e0b000.i2c
[3.435014] pinctrl-single 44e10800.pinmux: enabling pinmux_i2c1_pins 
function7
[3.442900] omap_i2c 44e0b000.i2c: obtain a copy of previously claimed 
pinctrl
[3.453107] omap_i2c 44e0b000.i2c: bus 1 rev0.11 at 400 kHz
[3.462980] tps65217-pmic tps65217-pmic: no of_node; not parsing pinctrl DT
[3.473866] DCDC1: 925 <--> 1800 mV at 1800 mV 
[3.480899] vdd_mpu: 925 <--> 1325 mV at 1100 mV 
[3.487935] vdd_core: 925 <--> 1150 mV at 1100 mV 
[3.494958] LDO1: 1000 <--> 3300 mV at 1800 mV 
[3.501814] LDO2: 900 <--> 3300 mV at 3300 mV 
[3.508447] LDO3: 1800 <--> 3300 mV at 3300 mV 
[3.515238] LDO4: 1800 <--> 3300 mV at 3300 mV 
[3.521270] tps65217-bl tps65217-bl: no of_node; not parsing pinctrl DT
[3.531348] tps65217 1-0024: TPS65217 ID 0xf version 1.1


With older version of kernel (3.7 ) I uses to use da8xx driver (with some 
patches for DT support and hack for proper clock setup)  and this  
configuration works fine. 


Best regards,

Michal Bachraty

device tree:
am3358_pinmux: pinmux at 44e10800 {

lcdc_pins: pinmux_lcd_pins {
pinctrl-single,pins = < /*  pin-name -> function
  (name)*/
0xec  0x00  /* lcd_ac_bias_en 
->lcd_ac_bias_en (LCD_EN)- out */
0xe4  0x00  /* lcd_hsync -> 
lcd_hsync (LCD_HSYNC) -out */
0xe0  0x00  /* lcd_vsync -> 
lcd_vsync (LCD_VSYNC) -out */
0xe8  0x00  /* lcd_pclk -> lcd_pclk 
(LCD_PCLK) -out */
0xdc  0x00  /* lcd_data15 -> 
lcd_data15 (LCD_DATA15) -out */
0xd8  0x00  /* lcd_data14 -> 
lcd_data14 (LCD_DATA14) -out */
0xd4  0x00  /* lcd_data13 -> 
lcd_data13 (LCD_DATA13) -out */
0xd0  0x00  /* lcd_data12 -> 
lcd_data12 (LCD_DATA12) -out */
0xcc  0x00  /* lcd_data11 -> 
lcd_data11 (LCD_DATA11) -out */
0xc8  0x00  /* lcd_data10 -> 
lcd_data10 (LCD_DATA10) -out */
0xc4  0x00  /* lcd_data9 -> 
lcd_data9 (LCD_DATA9) -out */
0xc0  0x00  /* lcd_data8 -> 
lcd_data8 (LCD_DATA8) -out */
0xbc  0x00  /* lcd_data7 -> 
lcd_data7 (LCD_DATA7) -out */
0xb8  0x00  /* lcd_data6 -> 
lcd_data6 (LCD_DATA6) -out */
0xb4  0x00  /* lcd_data5 -> 
lcd_data5 (LCD_DATA5) -out */
0xb0  0x00  /* lcd_d

[Nouveau] [PATCH v2] drm/nouveau: wait for vblank on page flipping

2013-03-28 Thread Peter Hurley

On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
> Oops, fixed to apply this time..
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 4610c3a..020542e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
> drm_framebuffer *fb,
>  
>   /* Emit a page flip */
>   if (nv_device(drm->device)->card_type >= NV_50) {
> - ret = nv50_display_flip_next(crtc, fb, chan, 0);
> + ret = nv50_display_flip_next(crtc, fb, chan, 1);

Why would this work?

>   if (ret) {
>   mutex_unlock(&chan->cli->mutex);
>   goto fail_unreserve;

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, 28 Mar 2013, Jesse Barnes wrote:

> On Thu, 28 Mar 2013 05:04:26 -0700
> "Luis R. Rodriguez"  wrote:
>
> > The new commit by Jesse that extended the fb_info with a skip_vt_switch
> > element is the simplest example of a data structure expansion. We'd backport
> > this by adding a static inline to compat so that new kernels muck with the
> > new element and for older kernels this would be a no-op. This reduces the
> > size of the backport and unclutters the required patch with #idefs, and
> > insteads leaves only a replacement of the usage of the new elements with
> > a static inline, this however would still be required on our end:
> >
> > -  info->skip_vt_switch = true;
> > +  fb_enable_skip_vt_switch(info);
> >
> > So we'd then have to just add this static inline change for each new 
> > driver...
> > There may be a way to get SmPL to do this for us...

@@
type of info  *info;
@@

-  info->skip_vt_switch = true;
+  fb_enable_skip_vt_switch(info);

for whatever the type of info is.

Then I guess there would be a similar rule for the false case?

julia


>
> Yeah I'm not attached to the direct structure reference; a couple of
> inlines are just as easy to read.  So no argument from me.
>
> Thanks,
> --
> Jesse Barnes, Intel Open Source Technology Center
>

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

--- Comment #44 from Alexandre Demers  ---
(In reply to comment #43)
> I do not know if this is relevant, but I recently purchased a radeon 6450
> and had similar issues - corruption when KMS is started and lockups when X
> starts. I did not get these issues in fglrx or the windows drivers.
> 
> I then happened to notice that the memory clock settings for the 'boot'
> power profile were incorrect, and were significantly higher than the card
> should support. The high & low power states appeared to be correct. Changing
> the boot values using the Radeon Bios editor
> (http://www.techpowerup.com/rbe/) fixed these problems for me.

While this is not related to the proposed attachment, it is quite interesting
to know you were able to fix your problem by tweaking your card's bios. Maybe
Kunal could tell us more about some similar observations.

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

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall  wrote:
> On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>
>> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall  
>> wrote:
>> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>> >>
>> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
>> >> upstream fb patch is not accepted. If it is accepted we would not need
>> >> this at all!
>> >>
>> >> > Then I guess there would be a similar rule for the false case?
>> >>
>> >> Nope, see that's the proactive strategy taken by the static inline and
>> >> hence the patch. compat would have a static inline for both cases, and
>> >> for the false case it'd be a no-op. If accepted upstream though then
>> >> we would not need any changes for this collateral evolution. However
>> >> *spotting* these collateral evolutions and giving you SmPL for them as
>> >> a proactive strategy might be good given that if these type of patches
>> >> are indeed welcomed upstream we'd then be able to address these as
>> >> secondary steps. If they are not accepted then indeed we'd use them to
>> >> backport that collateral evolution through both compat (adds the
>> >> static inlines) and compat-drivers (the SmPL).
>> >
>> > Probably I am missing something, since I haven't looked at the code in
>> > detail, bu wouldn't it be nicer to have a function call for the false
>> > case, if there is a function call for the true case?
>>
>> Yes, and indeed we have that, its the same function call, in the
>> negative case its a no-op, in the newer kernels it wraps to modifying
>> the element as in the original code.
>>
>> > In looking at the
>> > code, one could wonder why things are not done in a parallel way.
>>
>> Not sure I get this.
>
> I looked in today's linux-next, and there seems to be only one
> initialization of this field, to true, and one test of this field.  So
> perhaps the case for setting the field to false just isn't needed.

Oh sorry now I get what you mean! I thought about this -- and yes I
decided to not add a bool false setting for the structure field given
that the assumption is this would not be something dynamic, and data
structure would be kzalloc()'d so by default they are 0.

  Luis

[PATCH v2] drm/nouveau: wait for vblank on page flipping

Signed-off-by: Maarten Lankhorst 
---
Oops, fixed to apply this time..

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 4610c3a..020542e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,

/* Emit a page flip */
if (nv_device(drm->device)->card_type >= NV_50) {
-   ret = nv50_display_flip_next(crtc, fb, chan, 0);
+   ret = nv50_display_flip_next(crtc, fb, chan, 1);
if (ret) {
mutex_unlock(&chan->cli->mutex);
goto fail_unreserve;

[PATCH 0/2] Miscellaneous mode set and page flip fixes

On Thursday 23 August 2012 12:05:27 Laurent Pinchart wrote:
> On Thursday 19 July 2012 13:55:37 Laurent Pinchart wrote:
> > On Thursday 31 May 2012 18:26:14 Laurent Pinchart wrote:
> > > Hi everybody,
> > > 
> > > Here are two small fixes that disallow format changes in page flip
> > > operations, and perform a full mode set instead of a mode set base in
> > > the
> > > CRTC helper set config handler if the pixel format changed.
> > 
> > Ping ? Can those two patches be applied ?
> 
> Ping again ?

And again ? :-)

> > > Laurent Pinchart (2):
> > >   drm: Don't allow page flip to change pixel format
> > >   drm: Perform a full mode set when the pixel format changed
> > >  
> > >  drivers/gpu/drm/drm_crtc.c|8 
> > >  drivers/gpu/drm/drm_crtc_helper.c |3 +++
> > >  2 files changed, 11 insertions(+), 0 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 0/2] GEM CMA DMA-BUF support

Hello,

On Thursday 14 March 2013 15:05:29 Laurent Pinchart wrote:
> On Tuesday 12 March 2013 15:45:36 Laurent Pinchart wrote:
> > Hello,
> > 
> > This two patches add support for GEM CMA objects import and export as
> > dma-buf file handles.
> > 
> > There's not much to be added about the patches themselves, they're pretty
> > self-explicit. The code is based on the Exynos DRM DMA-BUF implementation.
> > 
> > The exporter role has been successfully tested with the Renesas R-Car DU
> > driver.
> > 
> > Laurent Pinchart (2):
> >   drm: GEM CMA: Split object creation into object alloc and DMA memory
> > alloc
> >   drm: GEM CMA: Add DRM PRIME support
> >  
> >  drivers/gpu/drm/drm_gem_cma_helper.c | 376 +++---
> >  include/drm/drm_gem_cma_helper.h |   9 +
> >  2 files changed, 356 insertions(+), 29 deletions(-)
> 
> Oops, the CC list was missing from the original post, sorry about that. It's
> fixed now.

No comment about these patches ? I'd like to get them in v3.10 if possible.

-- 
Regards,

Laurent Pinchart

[PATCH] drm/shmobile: Fix race condition between page flip request and handler

Hi Dave,

Could you please pick this patch for v3.10 ?

On Tuesday 12 March 2013 15:38:43 Laurent Pinchart wrote:
> The page flip handler stores the page flip event pointer and then calls
> drm_vblank_get() to enable the vblank interrupt. Due to the vblank off
> delay, the vblank interrupt can be enabled in the hardware at that
> point, even if the vblank reference count is equal to 0. If a vblank
> interrupt is triggered between storing the event pointer and calling
> drm_vblank_get(), the page flip completion handler will process the
> event and call drm_vblank_put() with a reference count equal to 0. This
> will result in a BUG_ON.
> 
> Fix the race condition by calling drm_vblank_get() before storing the
> event pointer.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c index d917a41..7dff49e 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> @@ -494,10 +494,10 @@ static int shmob_drm_crtc_page_flip(struct drm_crtc
> *crtc,
> 
>   if (event) {
>   event->pipe = 0;
> + drm_vblank_get(dev, 0);
>   spin_lock_irqsave(&dev->event_lock, flags);
>   scrtc->event = event;
>   spin_unlock_irqrestore(&dev->event_lock, flags);
> - drm_vblank_get(dev, 0);
>   }
> 
>   return 0;

-- 
Regards,

Laurent Pinchart

[Bug 43276] Resume fails after suspending Toshiba Satellite C675D-S7109 laptop

2013-03-28 Thread bugzilla-dae...@bugzilla.kernel.org

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


Lan Tianyu  changed:

   What|Removed |Added

  Component|Power-Sleep-Wake|Video(DRI - non Intel)
 AssignedTo|tianyu.lan at intel.com|drivers_video-dri at 
kernel-bu
   ||gs.osdl.org
Product|ACPI|Drivers




--- Comment #11 from Lan Tianyu   2013-03-28 15:53:28 
---
> Yes, I can ssh in after resume. 
This means pm core works well. Screen not resume is Graphic driver issume.
So assign to Graphic driver module. There will be Graphic expert.

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

[PATCH] drm/nouveau: wait for vblank on page flipping

AGHHhhh!

Signed-off-by: Maarten Lankhorst 

---
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 6d01e0f..f56bd56 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,

/* Emit a page flip */
if (nv_device(drm->device)->card_type >= NV_50) {
-   ret = nv50_display_flip_next(crtc, fb, chan, 0);
+   ret = nv50_display_flip_next(crtc, fb, chan, 1);
if (ret) {
mutex_unlock(&chan->cli->mutex);
goto fail_unreserve;

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

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

--- Comment #8 from Thilo Cestonaro  ---
Finally I found some time do reinstall Ubuntu and compile the kernel with the
patch. Sadly it doesn't fix the issue. :(

Greetings
Thilo

-- 
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 62882] Lockup after attempt to enable discrete Radeon GPU on Linux 3.9rc4

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

--- Comment #1 from Alex Deucher  ---
Your dGPU is not powering up for some reason.

-- 
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 62882] New: Lockup after attempt to enable discrete Radeon GPU on Linux 3.9rc4

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

  Priority: medium
Bug ID: 62882
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Lockup after attempt to enable discrete Radeon GPU on
Linux 3.9rc4
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: runetmem...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

Created attachment 77173
  --> https://bugs.freedesktop.org/attachment.cgi?id=77173&action=edit
crash log

When I try to enable discrete GPU I get kernel module crash (please look into
attached log) and system lockup (few seconds later).

Software:
Kubuntu 13.04 x86_64 updated from Canonical X Staging PPA (there is just stable
X.Org Server 1.14, stable Mesa 9.1 and stable 7.1.0 radeon driver)
Linux 3.9rc4 
Mesa: 9.1
libdrm-radeon1: 2.4.43
xserver-xorg-video-radeon: 7.1.0
xserver-xorg-core: 1.14.0

Hardware:
Acer Aspire 7560G laptop,
AMD APU A8-3500M with integrated Radeon HD 6620G (SUMO)
Discrete AMD Radeon HD 6650M (TURKS)

"xrandr --listproviders" output:
Providers: number : 2
Provider 0: id: 138 cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 2 outputs: 3 associated providers: 1 name:radeon
Provider 1: id: 85 cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 6 outputs: 0 associated providers: 1 name:radeon

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

[PATCH] drm: Fix error message in drmWaitVBlank

2013-03-28 Thread Daniel Kurtz

If clock_gettime did fail, it would return -1 and set errno.
What we really want to strerror() is the errno.

Signed-off-by: Daniel Kurtz 
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 2a74c80..4791a05 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -1946,7 +1946,7 @@ int drmWaitVBlank(int fd, drmVBlankPtr vbl)

 ret = clock_gettime(CLOCK_MONOTONIC, &timeout);
 if (ret < 0) {
-   fprintf(stderr, "clock_gettime failed: %s\n", strerror(ret));
+   fprintf(stderr, "clock_gettime failed: %s\n", strerror(errno));
goto out;
 }
 timeout.tv_sec++;
-- 
1.8.1.3

[PATCH v4 08/21] modetest: Add a command line parameter to set properties

On Tuesday 19 March 2013 15:55:49 Laurent Pinchart wrote:
> The -w parameter can be used to set a property value from the command
> line, using the target object ID and the property name.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  tests/modetest/modetest.c | 108 ++-
>  1 file changed, 106 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index f58c01d..7153a40 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c

[snip]

> @@ -1122,6 +1210,19 @@ int main(int argc, char **argv)
>   case 'v':
>   test_vsync = 1;
>   break;
> + case 'w':
> + prop_args = realloc(prop_args,
> +(prop_count + 1) * sizeof 
> *prop_args);
> + if (con_args == NULL) {

This should obviously be prop_args. I'll fix it in v5.

> + fprintf(stderr, "memory allocation failed\n");
> + return 1;
> + }
> +
> + if (parse_property(&prop_args[prop_count], optarg) < 0)
> + usage(argv[0]);
> +
> + prop_count++;
> + break;
>   default:
>   usage(argv[0]);
>   break;

-- 
Regards,

Laurent Pinchart

[PATCH v4 09/21] modetest: Allow specifying plane position

On Thu, Mar 28, 2013 at 01:16:09AM +0100, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Wednesday 27 March 2013 19:15:31 Ville Syrj?l? wrote:
> > On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrj?l? wrote:
> > > On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > > > Extend the -P option to allow specifying the plane x and y offsets. The
> > > > position is optional, if not specified the plane will be positioned at
> > > > the center of the screen as before.
> > > > 
> > > > Signed-off-by: Laurent Pinchart 
> > > > ---
> > > > 
> > > >  tests/modetest/modetest.c | 72 ++--
> > > >  1 file changed, 57 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > > > index 7153a40..f95efe6 100644
> > > > --- a/tests/modetest/modetest.c
> > > > +++ b/tests/modetest/modetest.c
> > > > @@ -645,6 +645,7 @@ struct connector_arg {
> > > > 
> > > >  struct plane_arg {
> > > >  
> > > > uint32_t con_id;  /* the id of connector to bind to */
> > > > 
> > > > +   uint32_t x, y;
> > > 
> > > I'd like the coordinates to allow negative values too.
> > 
> > Tested it and it actually works w/ negative values thanks to the way
> > strtoul() works :) The only real obstacle is the magic '-1' handling.
> > I guess you should just give up on magic values and add some flag to
> > indicate whether the user provided the coords or not.
> > 
> > Also I must say that I don't like the syntax you used for specifying the
> > coords. '(' and ')' need to be escaped or the shell eats them.
> 
> You're not the first one to complain, I don't mind changing the syntax 
> (although escaping is not mandatory, you can just enclose the whole argument 
> in quotes).
> 
> > I've been using the x11 -geometry syntax whenever I have to deal with the
> > x/y/w/h combination. It's a reasonably well known syntax and doesn't have
> > these shell issues. Maybe you could use it here as well.
> 
> The issue with the geometry syntax is that you can't put the top-left corner 
> at negative coordinates, as -XOFF places the right edge of the plane XOFF 
> pixels from the right edge of the screen, and similarly for -YOFF. Should we 
> deviate from that spec and consider -XOFF to mean XOFF pixels on the left 
> side 
> of the left edge (outside of the screen) ?

I forgot that there's this kind of magic change of origin in the
specification. I guess it's been too long since I've used negative
geometry coordinates under X.

I've just been using it so that the origin is always the top left
corner. That's how I chose to interpret things in my
drm_rect_debug_print() function for example. But since it's a bit
contrary to the X geometry spec, maybe it's not the best syntax
either. If anyone has a better idea in mind, I'm open to suggestions.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm: don't unlock in the addfb error paths

On Wed, Mar 27, 2013 at 09:45:35PM +0100, Daniel Vetter wrote:
> We don't grab the modeset locks any more since
> 
> commit 468174f748603497e73dba9b5c6d1d9f71121486
> Author: Daniel Vetter 
> Date:   Tue Dec 11 00:09:12 2012 +0100
> 
> drm: push modeset_lock_all into ->fb_create driver callbacks
> 
> Reported-by: Ray Strode 
> Cc: Ray Strode 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Ville Syrj?l? 

> ---
>  drivers/gpu/drm/drm_crtc.c |2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 792c3e3..dd64a06 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2326,7 +2326,6 @@ int drm_mode_addfb(struct drm_device *dev,
>   fb = dev->mode_config.funcs->fb_create(dev, file_priv, &r);
>   if (IS_ERR(fb)) {
>   DRM_DEBUG_KMS("could not create framebuffer\n");
> - drm_modeset_unlock_all(dev);
>   return PTR_ERR(fb);
>   }
>  
> @@ -2506,7 +2505,6 @@ int drm_mode_addfb2(struct drm_device *dev,
>   fb = dev->mode_config.funcs->fb_create(dev, file_priv, r);
>   if (IS_ERR(fb)) {
>   DRM_DEBUG_KMS("could not create framebuffer\n");
> - drm_modeset_unlock_all(dev);
>   return PTR_ERR(fb);
>   }
>  
> -- 
> 1.7.10.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

--- Comment #43 from Jonathan Hamilton  ---
I do not know if this is relevant, but I recently purchased a radeon 6450 and
had similar issues - corruption when KMS is started and lockups when X starts.
I did not get these issues in fglrx or the windows drivers.

I then happened to notice that the memory clock settings for the 'boot' power
profile were incorrect, and were significantly higher than the card should
support. The high & low power states appeared to be correct. Changing the boot
values using the Radeon Bios editor (http://www.techpowerup.com/rbe/) fixed
these problems for me.

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

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall  wrote:
> On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>>
>> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
>> upstream fb patch is not accepted. If it is accepted we would not need
>> this at all!
>>
>> > Then I guess there would be a similar rule for the false case?
>>
>> Nope, see that's the proactive strategy taken by the static inline and
>> hence the patch. compat would have a static inline for both cases, and
>> for the false case it'd be a no-op. If accepted upstream though then
>> we would not need any changes for this collateral evolution. However
>> *spotting* these collateral evolutions and giving you SmPL for them as
>> a proactive strategy might be good given that if these type of patches
>> are indeed welcomed upstream we'd then be able to address these as
>> secondary steps. If they are not accepted then indeed we'd use them to
>> backport that collateral evolution through both compat (adds the
>> static inlines) and compat-drivers (the SmPL).
>
> Probably I am missing something, since I haven't looked at the code in
> detail, bu wouldn't it be nicer to have a function call for the false
> case, if there is a function call for the true case?

Yes, and indeed we have that, its the same function call, in the
negative case its a no-op, in the newer kernels it wraps to modifying
the element as in the original code.

> In looking at the
> code, one could wonder why things are not done in a parallel way.

Not sure I get this.

  Luis

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall  wrote:
> On Thu, 28 Mar 2013, Jesse Barnes wrote:
>> > -  info->skip_vt_switch = true;
>> > +  fb_enable_skip_vt_switch(info);
>> >
>> > So we'd then have to just add this static inline change for each new 
>> > driver...
>> > There may be a way to get SmPL to do this for us...
>
> @@
> type of info  *info;
> @@
>
> -  info->skip_vt_switch = true;
> +  fb_enable_skip_vt_switch(info);
>
> for whatever the type of info is.

Thanks Julia! I'll be sure to try to add this to compat-drivers if the
upstream fb patch is not accepted. If it is accepted we would not need
this at all!

> Then I guess there would be a similar rule for the false case?

Nope, see that's the proactive strategy taken by the static inline and
hence the patch. compat would have a static inline for both cases, and
for the false case it'd be a no-op. If accepted upstream though then
we would not need any changes for this collateral evolution. However
*spotting* these collateral evolutions and giving you SmPL for them as
a proactive strategy might be good given that if these type of patches
are indeed welcomed upstream we'd then be able to address these as
secondary steps. If they are not accepted then indeed we'd use them to
backport that collateral evolution through both compat (adds the
static inlines) and compat-drivers (the SmPL).

  Luis

[pull] drm-intel-fixes

2013-03-28 Thread Daniel Vetter

Hi Dave,

I've figured I'll flush my -fixes queue before I head off to an extended
w/e. All just really small stuff: 3 small regression fixes plus a build
fix for especially dense gcc versions.

Cheers, Daniel

The following changes since commit b1289371fcd580b4c412e6d05c4cb8ac8d277239:

  Revert "drm/i915: write backlight harder" (2013-03-24 13:23:20 +0100)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 8abbbaf6adb46157b6bd416f7616b555cc6a332f:

  drm: don't unlock in the addfb error paths (2013-03-27 21:47:32 +0100)


Adam Jackson (1):
  drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)

Daniel Vetter (2):
  drm/i915: duct-tape locking when eDP init fails
  drm: don't unlock in the addfb error paths

Lauri Kasanen (1):
  drm/i915: Fix build failure

 drivers/gpu/drm/drm_crtc.c |2 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
 drivers/gpu/drm/i915/intel_crt.c   |   40 
 drivers/gpu/drm/i915/intel_dp.c|3 +++
 4 files changed, 21 insertions(+), 26 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, 28 Mar 2013, Jesse Barnes wrote:

> On Thu, 28 Mar 2013 05:04:26 -0700
> "Luis R. Rodriguez"  wrote:
>
> > The new commit by Jesse that extended the fb_info with a skip_vt_switch
> > element is the simplest example of a data structure expansion. We'd backport
> > this by adding a static inline to compat so that new kernels muck with the
> > new element and for older kernels this would be a no-op. This reduces the
> > size of the backport and unclutters the required patch with #idefs, and
> > insteads leaves only a replacement of the usage of the new elements with
> > a static inline, this however would still be required on our end:
> >
> > -  info->skip_vt_switch = true;
> > +  fb_enable_skip_vt_switch(info);
> >
> > So we'd then have to just add this static inline change for each new 
> > driver...
> > There may be a way to get SmPL to do this for us...

@@
type of info  *info;
@@

-  info->skip_vt_switch = true;
+  fb_enable_skip_vt_switch(info);

for whatever the type of info is.

Then I guess there would be a similar rule for the false case?

julia


>
> Yeah I'm not attached to the direct structure reference; a couple of
> inlines are just as easy to read.  So no argument from me.
>
> Thanks,
> --
> Jesse Barnes, Intel Open Source Technology Center
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, 28 Mar 2013 05:04:26 -0700
"Luis R. Rodriguez"  wrote:

> The new commit by Jesse that extended the fb_info with a skip_vt_switch
> element is the simplest example of a data structure expansion. We'd backport
> this by adding a static inline to compat so that new kernels muck with the
> new element and for older kernels this would be a no-op. This reduces the
> size of the backport and unclutters the required patch with #idefs, and
> insteads leaves only a replacement of the usage of the new elements with
> a static inline, this however would still be required on our end:
> 
>   -  info->skip_vt_switch = true;
>   +  fb_enable_skip_vt_switch(info);
> 
> So we'd then have to just add this static inline change for each new driver...
> There may be a way to get SmPL to do this for us...

Yeah I'm not attached to the direct structure reference; a couple of
inlines are just as easy to read.  So no argument from me.

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

[Bug 43276] Resume fails after suspending Toshiba Satellite C675D-S7109 laptop

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


Lan Tianyu  changed:

   What|Removed |Added

  Component|Power-Sleep-Wake|Video(DRI - non Intel)
 AssignedTo|tianyu@intel.com|drivers_video-dri@kernel-bu
   ||gs.osdl.org
Product|ACPI|Drivers




--- Comment #11 from Lan Tianyu   2013-03-28 15:53:28 ---
> Yes, I can ssh in after resume. 
This means pm core works well. Screen not resume is Graphic driver issume.
So assign to Graphic driver module. There will be Graphic expert.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

On Thu, 28 Mar 2013 05:04:26 -0700
"Luis R. Rodriguez"  wrote:

> The new commit by Jesse that extended the fb_info with a skip_vt_switch
> element is the simplest example of a data structure expansion. We'd backport
> this by adding a static inline to compat so that new kernels muck with the
> new element and for older kernels this would be a no-op. This reduces the
> size of the backport and unclutters the required patch with #idefs, and
> insteads leaves only a replacement of the usage of the new elements with
> a static inline, this however would still be required on our end:
> 
>   -  info->skip_vt_switch = true;
>   +  fb_enable_skip_vt_switch(info);
> 
> So we'd then have to just add this static inline change for each new driver...
> There may be a way to get SmPL to do this for us...

Yeah I'm not attached to the direct structure reference; a couple of
inlines are just as easy to read.  So no argument from me.

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

Re: [PATCH] drm: Fix error message in drmWaitVBlank

On Thu, 28 Mar 2013 14:05:40 +0800
Daniel Kurtz  wrote:

> If clock_gettime did fail, it would return -1 and set errno.
> What we really want to strerror() is the errno.
> 
> Signed-off-by: Daniel Kurtz 
> ---
>  xf86drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index 2a74c80..4791a05 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -1946,7 +1946,7 @@ int drmWaitVBlank(int fd, drmVBlankPtr vbl)
>  
>  ret = clock_gettime(CLOCK_MONOTONIC, &timeout);
>  if (ret < 0) {
> - fprintf(stderr, "clock_gettime failed: %s\n", strerror(ret));
> + fprintf(stderr, "clock_gettime failed: %s\n", strerror(errno));
>   goto out;
>  }
>  timeout.tv_sec++;

Applied, thanks.

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

[PATCH] drm: Fix error message in drmWaitVBlank

On Thu, 28 Mar 2013 14:05:40 +0800
Daniel Kurtz  wrote:

> If clock_gettime did fail, it would return -1 and set errno.
> What we really want to strerror() is the errno.
> 
> Signed-off-by: Daniel Kurtz 
> ---
>  xf86drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index 2a74c80..4791a05 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -1946,7 +1946,7 @@ int drmWaitVBlank(int fd, drmVBlankPtr vbl)
>  
>  ret = clock_gettime(CLOCK_MONOTONIC, &timeout);
>  if (ret < 0) {
> - fprintf(stderr, "clock_gettime failed: %s\n", strerror(ret));
> + fprintf(stderr, "clock_gettime failed: %s\n", strerror(errno));
>   goto out;
>  }
>  timeout.tv_sec++;

Applied, thanks.

-- 
Jesse Barnes, Intel Open Source Technology Center

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

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

Miroslav ?ustek  changed:

   What|Removed |Added

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

--- Comment #22 from Miroslav ?ustek  ---
Guys, thank you for all your work here. I also spent good times hacking r128
drivers.
Unfortunately, I gave the video card away four years ago, so I can't
participate on this bug anymore.
Closing. *** drying nostalgic tear ***

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

[PATCH v2] drm/nouveau: wait for vblank on page flipping

Signed-off-by: Maarten Lankhorst 
---
Oops, fixed to apply this time..

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 4610c3a..020542e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
 
/* Emit a page flip */
if (nv_device(drm->device)->card_type >= NV_50) {
-   ret = nv50_display_flip_next(crtc, fb, chan, 0);
+   ret = nv50_display_flip_next(crtc, fb, chan, 1);
if (ret) {
mutex_unlock(&chan->cli->mutex);
goto fail_unreserve;

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

Re: [PATCH 0/2] Miscellaneous mode set and page flip fixes

On Thursday 23 August 2012 12:05:27 Laurent Pinchart wrote:
> On Thursday 19 July 2012 13:55:37 Laurent Pinchart wrote:
> > On Thursday 31 May 2012 18:26:14 Laurent Pinchart wrote:
> > > Hi everybody,
> > > 
> > > Here are two small fixes that disallow format changes in page flip
> > > operations, and perform a full mode set instead of a mode set base in
> > > the
> > > CRTC helper set config handler if the pixel format changed.
> > 
> > Ping ? Can those two patches be applied ?
> 
> Ping again ?

And again ? :-)

> > > Laurent Pinchart (2):
> > >   drm: Don't allow page flip to change pixel format
> > >   drm: Perform a full mode set when the pixel format changed
> > >  
> > >  drivers/gpu/drm/drm_crtc.c|8 
> > >  drivers/gpu/drm/drm_crtc_helper.c |3 +++
> > >  2 files changed, 11 insertions(+), 0 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 0/2] GEM CMA DMA-BUF support

Hello,

On Thursday 14 March 2013 15:05:29 Laurent Pinchart wrote:
> On Tuesday 12 March 2013 15:45:36 Laurent Pinchart wrote:
> > Hello,
> > 
> > This two patches add support for GEM CMA objects import and export as
> > dma-buf file handles.
> > 
> > There's not much to be added about the patches themselves, they're pretty
> > self-explicit. The code is based on the Exynos DRM DMA-BUF implementation.
> > 
> > The exporter role has been successfully tested with the Renesas R-Car DU
> > driver.
> > 
> > Laurent Pinchart (2):
> >   drm: GEM CMA: Split object creation into object alloc and DMA memory
> > alloc
> >   drm: GEM CMA: Add DRM PRIME support
> >  
> >  drivers/gpu/drm/drm_gem_cma_helper.c | 376 +++---
> >  include/drm/drm_gem_cma_helper.h |   9 +
> >  2 files changed, 356 insertions(+), 29 deletions(-)
> 
> Oops, the CC list was missing from the original post, sorry about that. It's
> fixed now.

No comment about these patches ? I'd like to get them in v3.10 if possible.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/shmobile: Fix race condition between page flip request and handler

Hi Dave,

Could you please pick this patch for v3.10 ?

On Tuesday 12 March 2013 15:38:43 Laurent Pinchart wrote:
> The page flip handler stores the page flip event pointer and then calls
> drm_vblank_get() to enable the vblank interrupt. Due to the vblank off
> delay, the vblank interrupt can be enabled in the hardware at that
> point, even if the vblank reference count is equal to 0. If a vblank
> interrupt is triggered between storing the event pointer and calling
> drm_vblank_get(), the page flip completion handler will process the
> event and call drm_vblank_put() with a reference count equal to 0. This
> will result in a BUG_ON.
> 
> Fix the race condition by calling drm_vblank_get() before storing the
> event pointer.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c index d917a41..7dff49e 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> @@ -494,10 +494,10 @@ static int shmob_drm_crtc_page_flip(struct drm_crtc
> *crtc,
> 
>   if (event) {
>   event->pipe = 0;
> + drm_vblank_get(dev, 0);
>   spin_lock_irqsave(&dev->event_lock, flags);
>   scrtc->event = event;
>   spin_unlock_irqrestore(&dev->event_lock, flags);
> - drm_vblank_get(dev, 0);
>   }
> 
>   return 0;

-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/nouveau: wait for vblank on page flipping

AGHHhhh!

Signed-off-by: Maarten Lankhorst 

---
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 6d01e0f..f56bd56 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -593,7 +597,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
 
/* Emit a page flip */
if (nv_device(drm->device)->card_type >= NV_50) {
-   ret = nv50_display_flip_next(crtc, fb, chan, 0);
+   ret = nv50_display_flip_next(crtc, fb, chan, 1);
if (ret) {
mutex_unlock(&chan->cli->mutex);
goto fail_unreserve;

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

Re: [PATCH v4 08/21] modetest: Add a command line parameter to set properties

On Tuesday 19 March 2013 15:55:49 Laurent Pinchart wrote:
> The -w parameter can be used to set a property value from the command
> line, using the target object ID and the property name.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  tests/modetest/modetest.c | 108 ++-
>  1 file changed, 106 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index f58c01d..7153a40 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c

[snip]

> @@ -1122,6 +1210,19 @@ int main(int argc, char **argv)
>   case 'v':
>   test_vsync = 1;
>   break;
> + case 'w':
> + prop_args = realloc(prop_args,
> +(prop_count + 1) * sizeof 
> *prop_args);
> + if (con_args == NULL) {

This should obviously be prop_args. I'll fix it in v5.

> + fprintf(stderr, "memory allocation failed\n");
> + return 1;
> + }
> +
> + if (parse_property(&prop_args[prop_count], optarg) < 0)
> + usage(argv[0]);
> +
> + prop_count++;
> + break;
>   default:
>   usage(argv[0]);
>   break;

-- 
Regards,

Laurent Pinchart

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

[PATCH 4/4] fb: add helpers to enable and test for the skip_vt_switch

From: "Luis R. Rodriguez" 

This adds helpers to enable and test for the skip_vt_switch.
This gets us two things:

1) It allows us to require less collateral evolutions
   should we need changes on the fb_info data structure
   later (perhaps a bitmap flag).

2) Allows this feature to be backported with 0 delta
   required on the upstream drivers, we'd just require
   the static inline to do a no-op.

1) may be worth while considering, 2) is a new consideration
I'm trying to get others to evaluate to help with automatically
backporting the Linux kernel. This is the first time I am
aware someone argues for it.

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/gpu/drm/i915/intel_fb.c |2 +-
 drivers/video/fbmem.c   |2 +-
 include/linux/fb.h  |   10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8d81c929..c0f306c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -151,7 +151,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->screen_size = size;
 
/* This driver doesn't need a VT switch to restore the mode on resume */
-   info->skip_vt_switch = true;
+   fb_enable_skip_vt_switch(info);
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, 
sizes->fb_height);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index ccd44b0..daffadc 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1645,7 +1645,7 @@ static int do_register_framebuffer(struct fb_info 
*fb_info)
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(&fb_info->modelist);
 
-   if (fb_info->skip_vt_switch)
+   if (fb_skip_vt_switch_isset(fb_info))
pm_vt_switch_required(fb_info->dev, false);
else
pm_vt_switch_required(fb_info->dev, true);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..d534966 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -505,6 +505,16 @@ struct fb_info {
bool skip_vt_switch; /* no VT switch on suspend/resume required */
 };
 
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info->skip_vt_switch = true;
+}
+
+static inline bool fb_skip_vt_switch_isset(struct fb_info *info)
+{
+   return info->skip_vt_switch;
+}
+
 static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
+ max_num * sizeof(struct aperture), GFP_KERNEL);
-- 
1.7.10.4

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

[PATCH 3/4] compat-drivers: simplify backport fb_info->skip_vt_switch CE

From: "Luis R. Rodriguez" 

The collateral evolution (CE) on the fb_info data structure
that added the skip_vt_switch element can be simplified
further by replacing the #ifdef hell with a static inline.

Furthermore, if the static inline is added upstream it'd mean
we can get rid of all these static inline replacements for
this data structure element CE.

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 .../drm/0001-fb-info-vt_switch.patch   |   25 
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
index cdced87..39b13d1 100644
--- a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -8,23 +8,7 @@ pm_vt_switch_unregister() would not have been made.
 This patch cannot be broken down further so I'm pegging
 this as the first one with 4 digits under the DRM folder
 for collateral evolutions. This reflects its as atomic as
-is possible. As we'll see on the next commit, these type
-of collateral evolutions can best be backported not by
-keeping ifdef's as below but instead by using a wrapper
-caller, to help reduce with the amount of lines of code
-we need. If a static inline is added upstream for these
-changes, then no code is required for backporting, at all,
-we'd just implement the static inline later upstream as
-a no-op.
-
-The tradeoffs to consider for this is if we can live with
-these practices upstream, we may be able to support full
-subsystems only with a compat module, and no need for
-patches. This also means less code and likely less bugs
-on the distribution front when backporting is required.
-At least IMHO this may be worthy to consider at least to
-support kernels listed as supported on kernel.org. We could
-just leave the ifdef hell to older unsupported kernels.
+is possible.
 
 Relevant commits below, starting with the first one that
 added this new collateral evolution.
@@ -60,14 +44,13 @@ Date:   Tue Mar 26 09:25:45 2013 -0700
 
 --- a/drivers/gpu/drm/i915/intel_fb.c
 +++ b/drivers/gpu/drm/i915/intel_fb.c
-@@ -150,8 +150,10 @@ static int intelfb_create(struct drm_fb_
+@@ -150,8 +150,8 @@ static int intelfb_create(struct drm_fb_
}
info->screen_size = size;
  
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,10,0))
/* This driver doesn't need a VT switch to restore the mode on resume */
-   info->skip_vt_switch = true;
-+#endif
+-  info->skip_vt_switch = true;
++  fb_enable_skip_vt_switch(info);
  
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, 
sizes->fb_height);
-- 
1.7.10.4

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

[PATCH 2/4] compat: backport fb_info->skip_vt_switch using a static inline

From: "Luis R. Rodriguez" 

Commit 3cf2667 as of next-20130301 extended the struct fb_info
with a skip_vt_switch to allow drivers to skip the VT switch
at suspend/resume time. For older kernels we can skip this
as all this switch does is call pm_vt_switch_required() with true
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

compat-drivers was backporting this using #ifdef's but by
integrating a static inline we'd reduce the number of lines
to backport to just 1 line replacement. This would be something
like:

  -   info->skip_vt_switch = true;
  +   fb_enable_skip_vt_switch(info);

For kernels >= 3.10 we'd set the attribute as we do upstream,
for older kernels this would be a no-op.

If this static inline would have been added upstream it would
have meant this collateral evolution would require just adding
a no-op static inline to backport, and no changes as the above
example hunk for every driver that requires the change.

If this static inline ends up upstream *now* it means we do *not*
require the type of hunk above for every driver that requires
the change.

All the code would be left intact !

This is a linux-next 'data structure element collateral evolution'.

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 include/linux/compat-3.10.h |   41 +
 1 file changed, 41 insertions(+)

diff --git a/include/linux/compat-3.10.h b/include/linux/compat-3.10.h
index 69ddc11..9abfc4b 100644
--- a/include/linux/compat-3.10.h
+++ b/include/linux/compat-3.10.h
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 
 #define sg_page_iter_page LINUX_BACKPORT(sg_page_iter_page)
 /**
@@ -29,6 +30,46 @@ static inline dma_addr_t sg_page_iter_dma_address(struct 
sg_page_iter *piter)
return sg_dma_address(piter->sg) + (piter->sg_pgoffset << PAGE_SHIFT);
 }
 
+/*
+ * This is a linux-next data structure element collateral evolution,
+ * we use a wrapper to avoid #ifdef hell to backport it. This allows
+ * us to use a simple fb_info_skip_vt_switch() replacement for when
+ * the new data structure element is used. If coccinelle SmPL grammar
+ * could be used to express the transformation for us on compat-drivers
+ * it means we'd need to express it only once. If the structure element
+ * collateral evolution were to be used *at development* time and we'd
+ * have a way to express the inverse through SmPL we'd be able to
+ * backport this collateral evolution automatically for any new driver
+ * that used it. We'd use coccinelle to look for it and do the
+ * transformations for us based on the original commit (maybe SmPL
+ * would be listed on the commit log.
+ *
+ * We may need the LINUX_BACKPORT() call that adds the backport_
+ * prefix for older kernels than 3.10 if distros decide to
+ * add this same static inline themselves (although unlikely).
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+}
+
+#else /* kernel is >= 3.10 */
+/*
+ * We'd delete this upstream ever got this, we use our
+ * backport_ prefix with LINUX_BACKPORT() so that if this
+ * does get upstream we would not have to add another ifdef
+ * here for the kernels in between v3.10.. up to the point
+ * the routine would have gotten added, we'd just delete this
+ * #else condition completely. If we didn't have this and
+ * say 3.12 added the static inline upstream, we'd have a
+ * clash on the backport for 3.12 as the routine would
+ * already be defined *but* we'd need it for 3.11.
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info->skip_vt_switch = true;
+}
 #endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(3,10,0)) */
 
 #endif /* LINUX_3_10_COMPAT_H */
-- 
1.7.10.4

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

[PATCH 1/4] compat-drivers: backport fb_info->skip_vt_switch using ifdefs

From: "Luis R. Rodriguez" 

Commit 3cf2667 as of next-20130301 extended the struct fb_info
with a skip_vt_switch to allow drivers to skip the VT switch
at suspend/resume time. For older kernels we can skip this
as all this switch does is call pm_vt_switch_required() with true
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

This patch cannot be broken down further so I'm pegging
this as the first one with 4 digits under the DRM folder
for collateral evolutions. This reflects its as atomic as
is possible. As we'll see on the next commit, these type
of collateral evolutions can best be backported not by
keeping ifdef's as below but instead by using a wrapper
caller, to help reduce with the amount of lines of code
we need. If a static inline is added upstream for these
changes, then no code is required for backporting, at all,
we'd just implement the static inline later upstream as
a no-op.

The tradeoffs to consider for this is if we can live with
these practices upstream, we may be able to support full
subsystems only with a compat module, and no need for
patches. This also means less code and likely less bugs
on the distribution front when backporting is required.
At least IMHO this may be worthy to consider at least to
support kernels listed as supported on kernel.org. We could
just leave the ifdef hell to older unsupported kernels.

Relevant commits below, starting with the first one that
added this new collateral evolution.

commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
Author: Jesse Barnes 
Date:   Mon Feb 4 13:37:21 2013 +

fb: add support for drivers not needing VT switch at suspend/resume time

Use the new PM routines to indicate whether we need to VT switch at suspend
and resume time.  When a new driver is bound, set its flag accordingly,
and when unbound, remove it from the PM's console tracking list.

Signed-off-by: Jesse Barnes 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Daniel Vetter 

commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
Author: Jesse Barnes 
Date:   Tue Mar 26 09:25:45 2013 -0700

drm/i915: enable VT switchless resume v3

With the other bits in place, we can do this safely.

v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)

Signed-off-by: Jesse Barnes 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 

Cc: co...@systeme.lip6.fr
Cc: backpo...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 .../drm/0001-fb-info-vt_switch.patch   |   73 
 1 file changed, 73 insertions(+)
 create mode 100644 
patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
new file mode 100644
index 000..cdced87
--- /dev/null
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -0,0 +1,73 @@
+Commit 3cf2667 as of next-20130301 extended the struct fb_info
+with a skip_vt_switch to allow drivers to skip the VT switch
+at suspend/resume time. For older kernels we can skip this
+as all this switch does is call pm_vt_switch_required() with true
+or false depending on this new flag and later
+pm_vt_switch_unregister() would not have been made.
+
+This patch cannot be broken down further so I'm pegging
+this as the first one with 4 digits under the DRM folder
+for collateral evolutions. This reflects its as atomic as
+is possible. As we'll see on the next commit, these type
+of collateral evolutions can best be backported not by
+keeping ifdef's as below but instead by using a wrapper
+caller, to help reduce with the amount of lines of code
+we need. If a static inline is added upstream for these
+changes, then no code is required for backporting, at all,
+we'd just implement the static inline later upstream as
+a no-op.
+
+The tradeoffs to consider for this is if we can live with
+these practices upstream, we may be able to support full
+subsystems only with a compat module, and no need for
+patches. This also means less code and likely less bugs
+on the distribution front when backporting is required.
+At least IMHO this may be worthy to consider at least to
+support kernels listed as supported on kernel.org. We could
+just leave the ifdef hell to older unsupported kernels.
+
+Relevant commits below, starting with the first one that
+added this new collateral evolution.
+
+commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
+Author: Jesse Barnes 
+Date:   Mon Feb 4 13:37:21 2013 +
+
+fb: add support for drivers not needing VT switch at suspend/resume time
+
+Use the new PM routines to indicate whether we need to VT switch at suspend
+and resume time.  When a new driver i

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

From: "Luis R. Rodriguez" 

I maintain the the compat-drivers project [0] which aims at backporting the
Linux kernel drivers down to older kernels, automatically [1]. Thanks to
Ozan Caglayan as a GSoC project we now backport DRM drivers.

The initial framework we had set up to help with the automatic juice was
simply quilt refresh to help with hunk offsets, later it consisted of
writing cleaner diffs, then compartamentalizing shared differences into a
compat backport module [2].

Recently I looked into Coccinelle SmPL to help push for collateral evolutions
on the Linux kernel to be written when possible with SmPL [3] given that, as
discussed with Julia, the very inverse of the grammar may allow us to backport
that collateral evolution on older kernels. I'm still experimenting with that,
but another benefit of studying INRIA's Coccinelle work is that the concept
of collateral evolutions is now formalized and as I've studied their work
I'm realizing we have different categories for collateral evolutions. From
what I've experienced through the backport work, data structure changes are
the more difficult collateral evolutions to backport. Instead of updates on
our compat module these require manual diffs... One strategy to simplify
backporting these data structure changes however was to replace the uses of
the new elements on the data structure with static inlines and requiring
the heavy changes to be implementd on a helper. That is, we actually simplfied
the backport by changing the form of the collateral evolution.

The new commit by Jesse that extended the fb_info with a skip_vt_switch
element is the simplest example of a data structure expansion. We'd backport
this by adding a static inline to compat so that new kernels muck with the
new element and for older kernels this would be a no-op. This reduces the
size of the backport and unclutters the required patch with #idefs, and
insteads leaves only a replacement of the usage of the new elements with
a static inline, this however would still be required on our end:

-  info->skip_vt_switch = true;
+  fb_enable_skip_vt_switch(info);

So we'd then have to just add this static inline change for each new driver...
There may be a way to get SmPL to do this for us...

However... if the static inline makes it upstream it means 0 changes are
required for *any* driver!

I've been reluctant to request a change upstream because of these side
backport benefits but due to this case's simplcity I figured I'd shoot
this out for review now.

A more elaborate example would be the netdev_attach_ops() which is not
yet upstream. This exands to this simple inline for new kernels:

static inline void netdev_attach_ops(struct net_device *dev,
   const struct net_device_ops *ops)
{   
dev->netdev_ops = ops;  
} 

For older kernels this expands to:

void netdev_attach_ops(struct net_device *dev,  
   const struct net_device_ops *ops)
{   
dev->open = ops->ndo_open;  
dev->init = ops->ndo_init;  
dev->stop = ops->ndo_stop;  
dev->hard_start_xmit = ops->ndo_start_xmit; 
dev->change_rx_flags = ops->ndo_change_rx_flags;
dev->set_multicast_list = ops->ndo_set_multicast_list;  
dev->validate_addr = ops->ndo_validate_addr;
dev->do_ioctl = ops->ndo_do_ioctl;  
dev->set_config = ops->ndo_set_config;  
dev->change_mtu = ops->ndo_change_mtu;  
dev->set_mac_address = ops->ndo_set_mac_address;
dev->tx_timeout = ops->ndo_tx_timeout;  
if (ops->ndo_get_stats) 
dev->get_stats = ops->ndo_get_stats;
dev->vlan_rx_register = ops->ndo_vlan_rx_register;  
dev->vlan_rx_add_vid = ops->ndo_vlan_rx_add_vid;
dev->vlan_rx_kill_vid = ops->ndo_vlan_rx_kill_vid;  
#ifdef CONFIG_NET_POLL_CONTROLLER   
dev->poll_controller = ops->ndo_poll_controller;
#endif  

#if (LINUX_

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

2013-03-28 Thread Danny Baumann

Hi,

Well, the ACPI spec says this (section B.5.2):

"
The OEM may define the number 0 as "Zero brightness" that can mean
to turn off the lighting (e.g. LCD panel backlight) in the device.
This may be useful in the case of an output device that can still be
viewed using only ambient light, for example, a transflective LCD.
"

My interpretation of this is that the value 0 is supposed to still
be visible. I'm pretty sure I saw a statement that 0 is supposed to
mean "barely visible" somewhere, but can't find it at the moment.
I'll search for the source of it.

BTW, I found the source for that statement: [1], section
System.Client.BrightnessControls.SmoothBrightness. While formally it's
not part of the ACPI spec, I'm pretty sure most vendors (except Apple,
obviously) will follow it as if it were, if not more strictly.

OK, I see. And there is user space depending on that behaviour? And again -
how is user space supposed to know about the behavioral differences? Is it
something like 'if type is raw, don't expect anything'?
The reason for my question is that I want to determine what a) the correct
place to fix this and b) the correct fix is. As Xrandr abstracts away the
used backlight interface, I see no way for user space using Xrandr (e.g.
KDE) to meaningfully handle this.

In practice does it really matter? As a user if you set the
brightness really low and you either can't see the screen or can
barely make it out does it matter if the screen is off or just really,
really dim? The 0 brightness setting is probably not practically
usable regardless of what it does.

That's right. I'm not intending to use the laptop with that low
brightness, though, I'd just like to distinguish between my laptop being
turned off / suspended or just its display being dimmed down by the
desktop environment to conserve power. In order to do the latter, KDE
sets brightness to 0 ([2]), which worked fine for me as long as
acpi_video was working on this laptop. This isn't the case at present,
which is why I'm using intel_backlight at the moment. As you may have
noticed, things aren't working as expected with it, which in turn is
what brought me over here ;) I'm fine with sending a patch to KDE if
that's the correct thing to do, but I'm not yet sure what the correct
thing to do is.

Thanks,

Danny

[1] http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx
[2]
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/actions/bundled/dimdisplay.cpp#L53

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

[PATCH 4/4] fb: add helpers to enable and test for the skip_vt_switch

From: "Luis R. Rodriguez" 

This adds helpers to enable and test for the skip_vt_switch.
This gets us two things:

1) It allows us to require less collateral evolutions
   should we need changes on the fb_info data structure
   later (perhaps a bitmap flag).

2) Allows this feature to be backported with 0 delta
   required on the upstream drivers, we'd just require
   the static inline to do a no-op.

1) may be worth while considering, 2) is a new consideration
I'm trying to get others to evaluate to help with automatically
backporting the Linux kernel. This is the first time I am
aware someone argues for it.

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/gpu/drm/i915/intel_fb.c |2 +-
 drivers/video/fbmem.c   |2 +-
 include/linux/fb.h  |   10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8d81c929..c0f306c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -151,7 +151,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->screen_size = size;

/* This driver doesn't need a VT switch to restore the mode on resume */
-   info->skip_vt_switch = true;
+   fb_enable_skip_vt_switch(info);

drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, 
sizes->fb_height);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index ccd44b0..daffadc 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1645,7 +1645,7 @@ static int do_register_framebuffer(struct fb_info 
*fb_info)
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(&fb_info->modelist);

-   if (fb_info->skip_vt_switch)
+   if (fb_skip_vt_switch_isset(fb_info))
pm_vt_switch_required(fb_info->dev, false);
else
pm_vt_switch_required(fb_info->dev, true);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..d534966 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -505,6 +505,16 @@ struct fb_info {
bool skip_vt_switch; /* no VT switch on suspend/resume required */
 };

+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info->skip_vt_switch = true;
+}
+
+static inline bool fb_skip_vt_switch_isset(struct fb_info *info)
+{
+   return info->skip_vt_switch;
+}
+
 static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
+ max_num * sizeof(struct aperture), GFP_KERNEL);
-- 
1.7.10.4

[PATCH 3/4] compat-drivers: simplify backport fb_info->skip_vt_switch CE

From: "Luis R. Rodriguez" 

The collateral evolution (CE) on the fb_info data structure
that added the skip_vt_switch element can be simplified
further by replacing the #ifdef hell with a static inline.

Furthermore, if the static inline is added upstream it'd mean
we can get rid of all these static inline replacements for
this data structure element CE.

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 .../drm/0001-fb-info-vt_switch.patch   |   25 
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
index cdced87..39b13d1 100644
--- a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -8,23 +8,7 @@ pm_vt_switch_unregister() would not have been made.
 This patch cannot be broken down further so I'm pegging
 this as the first one with 4 digits under the DRM folder
 for collateral evolutions. This reflects its as atomic as
-is possible. As we'll see on the next commit, these type
-of collateral evolutions can best be backported not by
-keeping ifdef's as below but instead by using a wrapper
-caller, to help reduce with the amount of lines of code
-we need. If a static inline is added upstream for these
-changes, then no code is required for backporting, at all,
-we'd just implement the static inline later upstream as
-a no-op.
-
-The tradeoffs to consider for this is if we can live with
-these practices upstream, we may be able to support full
-subsystems only with a compat module, and no need for
-patches. This also means less code and likely less bugs
-on the distribution front when backporting is required.
-At least IMHO this may be worthy to consider at least to
-support kernels listed as supported on kernel.org. We could
-just leave the ifdef hell to older unsupported kernels.
+is possible.

 Relevant commits below, starting with the first one that
 added this new collateral evolution.
@@ -60,14 +44,13 @@ Date:   Tue Mar 26 09:25:45 2013 -0700

 --- a/drivers/gpu/drm/i915/intel_fb.c
 +++ b/drivers/gpu/drm/i915/intel_fb.c
-@@ -150,8 +150,10 @@ static int intelfb_create(struct drm_fb_
+@@ -150,8 +150,8 @@ static int intelfb_create(struct drm_fb_
}
info->screen_size = size;

-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,10,0))
/* This driver doesn't need a VT switch to restore the mode on resume */
-   info->skip_vt_switch = true;
-+#endif
+-  info->skip_vt_switch = true;
++  fb_enable_skip_vt_switch(info);

drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, 
sizes->fb_height);
-- 
1.7.10.4

[PATCH 2/4] compat: backport fb_info->skip_vt_switch using a static inline

From: "Luis R. Rodriguez" 

Commit 3cf2667 as of next-20130301 extended the struct fb_info
with a skip_vt_switch to allow drivers to skip the VT switch
at suspend/resume time. For older kernels we can skip this
as all this switch does is call pm_vt_switch_required() with true
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

compat-drivers was backporting this using #ifdef's but by
integrating a static inline we'd reduce the number of lines
to backport to just 1 line replacement. This would be something
like:

  -   info->skip_vt_switch = true;
  +   fb_enable_skip_vt_switch(info);

For kernels >= 3.10 we'd set the attribute as we do upstream,
for older kernels this would be a no-op.

If this static inline would have been added upstream it would
have meant this collateral evolution would require just adding
a no-op static inline to backport, and no changes as the above
example hunk for every driver that requires the change.

If this static inline ends up upstream *now* it means we do *not*
require the type of hunk above for every driver that requires
the change.

All the code would be left intact !

This is a linux-next 'data structure element collateral evolution'.

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 include/linux/compat-3.10.h |   41 +
 1 file changed, 41 insertions(+)

diff --git a/include/linux/compat-3.10.h b/include/linux/compat-3.10.h
index 69ddc11..9abfc4b 100644
--- a/include/linux/compat-3.10.h
+++ b/include/linux/compat-3.10.h
@@ -7,6 +7,7 @@

 #include 
 #include 
+#include 

 #define sg_page_iter_page LINUX_BACKPORT(sg_page_iter_page)
 /**
@@ -29,6 +30,46 @@ static inline dma_addr_t sg_page_iter_dma_address(struct 
sg_page_iter *piter)
return sg_dma_address(piter->sg) + (piter->sg_pgoffset << PAGE_SHIFT);
 }

+/*
+ * This is a linux-next data structure element collateral evolution,
+ * we use a wrapper to avoid #ifdef hell to backport it. This allows
+ * us to use a simple fb_info_skip_vt_switch() replacement for when
+ * the new data structure element is used. If coccinelle SmPL grammar
+ * could be used to express the transformation for us on compat-drivers
+ * it means we'd need to express it only once. If the structure element
+ * collateral evolution were to be used *at development* time and we'd
+ * have a way to express the inverse through SmPL we'd be able to
+ * backport this collateral evolution automatically for any new driver
+ * that used it. We'd use coccinelle to look for it and do the
+ * transformations for us based on the original commit (maybe SmPL
+ * would be listed on the commit log.
+ *
+ * We may need the LINUX_BACKPORT() call that adds the backport_
+ * prefix for older kernels than 3.10 if distros decide to
+ * add this same static inline themselves (although unlikely).
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+}
+
+#else /* kernel is >= 3.10 */
+/*
+ * We'd delete this upstream ever got this, we use our
+ * backport_ prefix with LINUX_BACKPORT() so that if this
+ * does get upstream we would not have to add another ifdef
+ * here for the kernels in between v3.10.. up to the point
+ * the routine would have gotten added, we'd just delete this
+ * #else condition completely. If we didn't have this and
+ * say 3.12 added the static inline upstream, we'd have a
+ * clash on the backport for 3.12 as the routine would
+ * already be defined *but* we'd need it for 3.11.
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+   info->skip_vt_switch = true;
+}
 #endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(3,10,0)) */

 #endif /* LINUX_3_10_COMPAT_H */
-- 
1.7.10.4

[PATCH 1/4] compat-drivers: backport fb_info->skip_vt_switch using ifdefs

From: "Luis R. Rodriguez" 

Commit 3cf2667 as of next-20130301 extended the struct fb_info
with a skip_vt_switch to allow drivers to skip the VT switch
at suspend/resume time. For older kernels we can skip this
as all this switch does is call pm_vt_switch_required() with true
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.

This patch cannot be broken down further so I'm pegging
this as the first one with 4 digits under the DRM folder
for collateral evolutions. This reflects its as atomic as
is possible. As we'll see on the next commit, these type
of collateral evolutions can best be backported not by
keeping ifdef's as below but instead by using a wrapper
caller, to help reduce with the amount of lines of code
we need. If a static inline is added upstream for these
changes, then no code is required for backporting, at all,
we'd just implement the static inline later upstream as
a no-op.

The tradeoffs to consider for this is if we can live with
these practices upstream, we may be able to support full
subsystems only with a compat module, and no need for
patches. This also means less code and likely less bugs
on the distribution front when backporting is required.
At least IMHO this may be worthy to consider at least to
support kernels listed as supported on kernel.org. We could
just leave the ifdef hell to older unsupported kernels.

Relevant commits below, starting with the first one that
added this new collateral evolution.

commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
Author: Jesse Barnes 
Date:   Mon Feb 4 13:37:21 2013 +

fb: add support for drivers not needing VT switch at suspend/resume time

Use the new PM routines to indicate whether we need to VT switch at suspend
and resume time.  When a new driver is bound, set its flag accordingly,
and when unbound, remove it from the PM's console tracking list.

Signed-off-by: Jesse Barnes 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Daniel Vetter 

commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
Author: Jesse Barnes 
Date:   Tue Mar 26 09:25:45 2013 -0700

drm/i915: enable VT switchless resume v3

With the other bits in place, we can do this safely.

v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)

Signed-off-by: Jesse Barnes 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 

Cc: cocci at systeme.lip6.fr
Cc: backports at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: Julia Lawall 
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: Rafael J. Wysocki 
Signed-off-by: Luis R. Rodriguez 
---
 .../drm/0001-fb-info-vt_switch.patch   |   73 
 1 file changed, 73 insertions(+)
 create mode 100644 
patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch

diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch 
b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
new file mode 100644
index 000..cdced87
--- /dev/null
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -0,0 +1,73 @@
+Commit 3cf2667 as of next-20130301 extended the struct fb_info
+with a skip_vt_switch to allow drivers to skip the VT switch
+at suspend/resume time. For older kernels we can skip this
+as all this switch does is call pm_vt_switch_required() with true
+or false depending on this new flag and later
+pm_vt_switch_unregister() would not have been made.
+
+This patch cannot be broken down further so I'm pegging
+this as the first one with 4 digits under the DRM folder
+for collateral evolutions. This reflects its as atomic as
+is possible. As we'll see on the next commit, these type
+of collateral evolutions can best be backported not by
+keeping ifdef's as below but instead by using a wrapper
+caller, to help reduce with the amount of lines of code
+we need. If a static inline is added upstream for these
+changes, then no code is required for backporting, at all,
+we'd just implement the static inline later upstream as
+a no-op.
+
+The tradeoffs to consider for this is if we can live with
+these practices upstream, we may be able to support full
+subsystems only with a compat module, and no need for
+patches. This also means less code and likely less bugs
+on the distribution front when backporting is required.
+At least IMHO this may be worthy to consider at least to
+support kernels listed as supported on kernel.org. We could
+just leave the ifdef hell to older unsupported kernels.
+
+Relevant commits below, starting with the first one that
+added this new collateral evolution.
+
+commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
+Author: Jesse Barnes 
+Date:   Mon Feb 4 13:37:21 2013 +
+
+fb: add support for drivers not needing VT switch at suspend/resume time
+
+Use the new PM routines to indicate whether we need to VT switch at suspend
+and resume time.  When a new

[PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

From: "Luis R. Rodriguez" 

I maintain the the compat-drivers project [0] which aims at backporting the
Linux kernel drivers down to older kernels, automatically [1]. Thanks to
Ozan Caglayan as a GSoC project we now backport DRM drivers.

The initial framework we had set up to help with the automatic juice was
simply quilt refresh to help with hunk offsets, later it consisted of
writing cleaner diffs, then compartamentalizing shared differences into a
compat backport module [2].

Recently I looked into Coccinelle SmPL to help push for collateral evolutions
on the Linux kernel to be written when possible with SmPL [3] given that, as
discussed with Julia, the very inverse of the grammar may allow us to backport
that collateral evolution on older kernels. I'm still experimenting with that,
but another benefit of studying INRIA's Coccinelle work is that the concept
of collateral evolutions is now formalized and as I've studied their work
I'm realizing we have different categories for collateral evolutions. From
what I've experienced through the backport work, data structure changes are
the more difficult collateral evolutions to backport. Instead of updates on
our compat module these require manual diffs... One strategy to simplify
backporting these data structure changes however was to replace the uses of
the new elements on the data structure with static inlines and requiring
the heavy changes to be implementd on a helper. That is, we actually simplfied
the backport by changing the form of the collateral evolution.

The new commit by Jesse that extended the fb_info with a skip_vt_switch
element is the simplest example of a data structure expansion. We'd backport
this by adding a static inline to compat so that new kernels muck with the
new element and for older kernels this would be a no-op. This reduces the
size of the backport and unclutters the required patch with #idefs, and
insteads leaves only a replacement of the usage of the new elements with
a static inline, this however would still be required on our end:

-  info->skip_vt_switch = true;
+  fb_enable_skip_vt_switch(info);

So we'd then have to just add this static inline change for each new driver...
There may be a way to get SmPL to do this for us...

However... if the static inline makes it upstream it means 0 changes are
required for *any* driver!

I've been reluctant to request a change upstream because of these side
backport benefits but due to this case's simplcity I figured I'd shoot
this out for review now.

A more elaborate example would be the netdev_attach_ops() which is not
yet upstream. This exands to this simple inline for new kernels:

static inline void netdev_attach_ops(struct net_device *dev,
   const struct net_device_ops *ops)
{   
dev->netdev_ops = ops;  
} 

For older kernels this expands to:

void netdev_attach_ops(struct net_device *dev,  
   const struct net_device_ops *ops)
{   
dev->open = ops->ndo_open;  
dev->init = ops->ndo_init;  
dev->stop = ops->ndo_stop;  
dev->hard_start_xmit = ops->ndo_start_xmit; 
dev->change_rx_flags = ops->ndo_change_rx_flags;
dev->set_multicast_list = ops->ndo_set_multicast_list;  
dev->validate_addr = ops->ndo_validate_addr;
dev->do_ioctl = ops->ndo_do_ioctl;  
dev->set_config = ops->ndo_set_config;  
dev->change_mtu = ops->ndo_change_mtu;  
dev->set_mac_address = ops->ndo_set_mac_address;
dev->tx_timeout = ops->ndo_tx_timeout;  
if (ops->ndo_get_stats) 
dev->get_stats = ops->ndo_get_stats;
dev->vlan_rx_register = ops->ndo_vlan_rx_register;  
dev->vlan_rx_add_vid = ops->ndo_vlan_rx_add_vid;
dev->vlan_rx_kill_vid = ops->ndo_vlan_rx_kill_vid;  
#ifdef CONFIG_NET_POLL_CONTROLLER   
dev->poll_controller = ops->ndo_poll_controller;
#endif  

#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,27))  
de

Re: [PATCH v4 09/21] modetest: Allow specifying plane position

On Thu, Mar 28, 2013 at 01:16:09AM +0100, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Wednesday 27 March 2013 19:15:31 Ville Syrjälä wrote:
> > On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > > > Extend the -P option to allow specifying the plane x and y offsets. The
> > > > position is optional, if not specified the plane will be positioned at
> > > > the center of the screen as before.
> > > > 
> > > > Signed-off-by: Laurent Pinchart 
> > > > ---
> > > > 
> > > >  tests/modetest/modetest.c | 72 ++--
> > > >  1 file changed, 57 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > > > index 7153a40..f95efe6 100644
> > > > --- a/tests/modetest/modetest.c
> > > > +++ b/tests/modetest/modetest.c
> > > > @@ -645,6 +645,7 @@ struct connector_arg {
> > > > 
> > > >  struct plane_arg {
> > > >  
> > > > uint32_t con_id;  /* the id of connector to bind to */
> > > > 
> > > > +   uint32_t x, y;
> > > 
> > > I'd like the coordinates to allow negative values too.
> > 
> > Tested it and it actually works w/ negative values thanks to the way
> > strtoul() works :) The only real obstacle is the magic '-1' handling.
> > I guess you should just give up on magic values and add some flag to
> > indicate whether the user provided the coords or not.
> > 
> > Also I must say that I don't like the syntax you used for specifying the
> > coords. '(' and ')' need to be escaped or the shell eats them.
> 
> You're not the first one to complain, I don't mind changing the syntax 
> (although escaping is not mandatory, you can just enclose the whole argument 
> in quotes).
> 
> > I've been using the x11 -geometry syntax whenever I have to deal with the
> > x/y/w/h combination. It's a reasonably well known syntax and doesn't have
> > these shell issues. Maybe you could use it here as well.
> 
> The issue with the geometry syntax is that you can't put the top-left corner 
> at negative coordinates, as -XOFF places the right edge of the plane XOFF 
> pixels from the right edge of the screen, and similarly for -YOFF. Should we 
> deviate from that spec and consider -XOFF to mean XOFF pixels on the left 
> side 
> of the left edge (outside of the screen) ?

I forgot that there's this kind of magic change of origin in the
specification. I guess it's been too long since I've used negative
geometry coordinates under X.

I've just been using it so that the origin is always the top left
corner. That's how I chose to interpret things in my
drm_rect_debug_print() function for example. But since it's a bit
contrary to the X geometry spec, maybe it's not the best syntax
either. If anyone has a better idea in mind, I'm open to suggestions.

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

Re: [PATCH] drm: don't unlock in the addfb error paths

On Wed, Mar 27, 2013 at 09:45:35PM +0100, Daniel Vetter wrote:
> We don't grab the modeset locks any more since
> 
> commit 468174f748603497e73dba9b5c6d1d9f71121486
> Author: Daniel Vetter 
> Date:   Tue Dec 11 00:09:12 2012 +0100
> 
> drm: push modeset_lock_all into ->fb_create driver callbacks
> 
> Reported-by: Ray Strode 
> Cc: Ray Strode 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_crtc.c |2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 792c3e3..dd64a06 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2326,7 +2326,6 @@ int drm_mode_addfb(struct drm_device *dev,
>   fb = dev->mode_config.funcs->fb_create(dev, file_priv, &r);
>   if (IS_ERR(fb)) {
>   DRM_DEBUG_KMS("could not create framebuffer\n");
> - drm_modeset_unlock_all(dev);
>   return PTR_ERR(fb);
>   }
>  
> @@ -2506,7 +2505,6 @@ int drm_mode_addfb2(struct drm_device *dev,
>   fb = dev->mode_config.funcs->fb_create(dev, file_priv, r);
>   if (IS_ERR(fb)) {
>   DRM_DEBUG_KMS("could not create framebuffer\n");
> - drm_modeset_unlock_all(dev);
>   return PTR_ERR(fb);
>   }
>  
> -- 
> 1.7.10.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[pull] drm-intel-fixes

2013-03-28 Thread Daniel Vetter

Hi Dave,

I've figured I'll flush my -fixes queue before I head off to an extended
w/e. All just really small stuff: 3 small regression fixes plus a build
fix for especially dense gcc versions.

Cheers, Daniel

The following changes since commit b1289371fcd580b4c412e6d05c4cb8ac8d277239:

  Revert "drm/i915: write backlight harder" (2013-03-24 13:23:20 +0100)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 8abbbaf6adb46157b6bd416f7616b555cc6a332f:

  drm: don't unlock in the addfb error paths (2013-03-27 21:47:32 +0100)


Adam Jackson (1):
  drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)

Daniel Vetter (2):
  drm/i915: duct-tape locking when eDP init fails
  drm: don't unlock in the addfb error paths

Lauri Kasanen (1):
  drm/i915: Fix build failure

 drivers/gpu/drm/drm_crtc.c |2 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
 drivers/gpu/drm/i915/intel_crt.c   |   40 
 drivers/gpu/drm/i915/intel_dp.c|3 +++
 4 files changed, 21 insertions(+), 26 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot

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

--- Comment #42 from Alexandre Demers  ---
Was attachment 64759 ever applied to kernel's git? While I don't know if the
current bug is still happening for radeon HD 6450 cards, it was fixing bug
43655  (which was considered as a duplicate, but it was not as explained in the
last comment of that bug because it works for HD 6950).

If not, please let me know because I'm still experiencing bug 43655 with kernel
3.9.0-rc4 and attachment 64759 can't be applied on kernel's current git version
(was applying on 3.7, not sure about 3.8, definitively not on 3.9).

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

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

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

Miroslav Šustek  changed:

   What|Removed |Added

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

--- Comment #22 from Miroslav Šustek  ---
Guys, thank you for all your work here. I also spent good times hacking r128
drivers.
Unfortunately, I gave the video card away four years ago, so I can't
participate on this bug anymore.
Closing. *** drying nostalgic tear ***

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

[PATCH v4 09/21] modetest: Allow specifying plane position

Hi Ville,

On Wednesday 27 March 2013 17:57:20 Ville Syrj?l? wrote:
> On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > Extend the -P option to allow specifying the plane x and y offsets. The
> > position is optional, if not specified the plane will be positioned at
> > the center of the screen as before.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  tests/modetest/modetest.c | 72 --
> >  1 file changed, 57 insertions(+), 15 deletions(-)
> > 
> > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > index 7153a40..f95efe6 100644
> > --- a/tests/modetest/modetest.c
> > +++ b/tests/modetest/modetest.c
> > @@ -645,6 +645,7 @@ struct connector_arg {
> > 
> >  struct plane_arg {
> > uint32_t con_id;  /* the id of connector to bind to */
> > +   uint32_t x, y;
> 
> I'd like the coordinates to allow negative values too. I just posted my
> latest version of the plane clipping patches. The main feature there is
> to allow coordinates to be partially/fully offscreen and the driver will
> clip then the plane to the screen dimensions. Hence negative coordinates
> become somewhat useful.
> 
> And if you're looking into plane stuff in general, maybe you can review
> my patches? The drm_rect utility functions should be useful for all
> drivers that have to deal with movable or scalable planes.

I'll try to, but I'm very busy nowadays with pinctrl patches :-/

> Now I'll see about trying this stuff out with my latest patches.

-- 
Regards,

Laurent Pinchart

[PATCH v4 09/21] modetest: Allow specifying plane position

Hi Ville,

On Wednesday 27 March 2013 19:15:31 Ville Syrj?l? wrote:
> On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrj?l? wrote:
> > On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote:
> > > Extend the -P option to allow specifying the plane x and y offsets. The
> > > position is optional, if not specified the plane will be positioned at
> > > the center of the screen as before.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > 
> > >  tests/modetest/modetest.c | 72 ++--
> > >  1 file changed, 57 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> > > index 7153a40..f95efe6 100644
> > > --- a/tests/modetest/modetest.c
> > > +++ b/tests/modetest/modetest.c
> > > @@ -645,6 +645,7 @@ struct connector_arg {
> > > 
> > >  struct plane_arg {
> > >  
> > >   uint32_t con_id;  /* the id of connector to bind to */
> > > 
> > > + uint32_t x, y;
> > 
> > I'd like the coordinates to allow negative values too.
> 
> Tested it and it actually works w/ negative values thanks to the way
> strtoul() works :) The only real obstacle is the magic '-1' handling.
> I guess you should just give up on magic values and add some flag to
> indicate whether the user provided the coords or not.
> 
> Also I must say that I don't like the syntax you used for specifying the
> coords. '(' and ')' need to be escaped or the shell eats them.

You're not the first one to complain, I don't mind changing the syntax 
(although escaping is not mandatory, you can just enclose the whole argument 
in quotes).

> I've been using the x11 -geometry syntax whenever I have to deal with the
> x/y/w/h combination. It's a reasonably well known syntax and doesn't have
> these shell issues. Maybe you could use it here as well.

The issue with the geometry syntax is that you can't put the top-left corner 
at negative coordinates, as -XOFF places the right edge of the plane XOFF 
pixels from the right edge of the screen, and similarly for -YOFF. Should we 
deviate from that spec and consider -XOFF to mean XOFF pixels on the left side 
of the left edge (outside of the screen) ?

-- 
Regards,

Laurent Pinchart

[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot