[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]

[Jiri Kosina]

On Thu, 21 Mar 2013, Daniel Vetter wrote:

> Indeed, this is pretty useful and allowed me to quickly reproduce that
> phantom irq on my gm45. Thanks to module reloading we can even reset the
> kernel's irq disabling logic and so test different tricks quickly without
> rebooting. Really useful.

Daniel,

out of curiosity, have you been able to make some sense of the phantom 
legacy IRQs on GM45 systems, or are we just staying with my original 
bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect?

Thanks,

-- 
Jiri Kosina
SUSE Labs

[Bug 62967] New: Game Dungeon Defenders crash my whole system.

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

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

  Priority: medium
Bug ID: 62967
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Game Dungeon Defenders crash my whole system.
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: lvella at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 77255
  --> https://bugs.freedesktop.org/attachment.cgi?id=77255=edit
glxinfo output

When I run Dungeon Defenders, the game window pops up and the first intro
animation runs very slowly (a red logo building in front of a white backgroud),
then at the second animation, a seeming magic circle with purple fire, my
computer halts and freezes completely, and I have to reboot.

-- 
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/20130331/fe760cee/attachment.html>

[PATCH] gma500: Make VGA and HDMI connector hotpluggable

[Kero]

From: Kero van Gelder 

Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
This patch will cause output to be shown on either when plugged in.
For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.

Signed-off-by: Kero van Gelder 
---
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 8c17534..7b8386f 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -276,6 +276,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
goto failed_connector;

connector = _intel_connector->base;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_init(dev, connector,
_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);

diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c 
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index e223b50..464153d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -319,6 +319,7 @@ void cdv_hdmi_init(struct drm_device *dev,
goto err_priv;

connector = _intel_connector->base;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
encoder = _intel_encoder->base;
drm_connector_init(dev, connector,
   _hdmi_connector_funcs,

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

[Michal Hocko]

On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> This looks a bit like a hack and it doesn't look right,
> conceptually. If the call fails, it should restore things as if
> nothing has ever happened and overwriting old_mapping is not going to
> do the trick.

OK, I thought this is what the patch does as it falls back to
>i_data which is the default mapping for all inodes or it uses
what used to be in device mapping.

I am obviously not familiar with the drm code but it feels a bit strange
that the device mapping can be different than inode's resp. file's one
and even more confusing that inode and file are saved separately.

> I think the right way to fix it would be to separately store the
> original mapping for filp->f_mapping and inode->i_mapping and restore
> it from their respective temporary variables if drm_open_helper or
> drm_setup fail. Attached is a quick patch to show you
[...]
> @@ -137,6 +139,8 @@ int drm_open(struct inode *inode, struct file *filp)
>   if (!dev->open_count++)
>   need_setup = 1;
>   mutex_lock(>struct_mutex);
> + old_fmapping = filp->f_mapping;
> + old_imapping = inode->i_mapping;

How can file and inode mappings be different?

>   old_mapping = dev->dev_mapping;
>   if (old_mapping == NULL)
>   dev->dev_mapping = >i_data;
> @@ -159,8 +163,8 @@ int drm_open(struct inode *inode, struct file *filp)
>  
>  err_undo:
>   mutex_lock(>struct_mutex);
> - filp->f_mapping = old_mapping;
> - inode->i_mapping = old_mapping;
> + filp->f_mapping = old_fmapping;
> + inode->i_mapping = old_imapping;
>   iput(container_of(dev->dev_mapping, struct inode, i_data));
>   dev->dev_mapping = old_mapping;
>   mutex_unlock(>struct_mutex);
-- 
1.8.1.5

-- 
Michal Hocko
SUSE Labs

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #2 from Alexandre Demers  ---
Nevermind, I've found out how to run a single glsl test.

Running /home/dema1701/projects/display/piglit/framework/../bin/shader_runner
tests/spec/glsl-1.10/execution/variable-indexing/fs-temp-array-mat4-col-row-wr.shader_test
works fine.

Could it be the following test that crashes the system? If so, how can I know
which test is next on the list?

-- 
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/20130331/c6dc70b6/attachment.html>

[Bug 61182] r600g causes KWin crashes with kernel 3.8

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

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

--- Comment #20 from Chris Fong  ---
(In reply to comment #16)
> No gnome-shell crashes since I've upgraded to Mesa 9.1.1. Will post an
> update in a few days whether it remains stable or I was just lucky today.

Observed the same gnome-shell crash problem with Mesa 9.1.1 with kernel
3.8.4-202 also.  The way how I reproduce this is to have dual monitors.  The
left one with resolution 1680x1050 (rotated counterclockwise) and the right
with 1920x1200.  With this setup, gnome-shell will always crash at initial
login.  If I don't rotate the left monitor, gnome-shell will not crash.

-- 
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/20130331/e7befd87/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

--- Comment #1 from Alexandre Demers  ---
I'd appreciate if someone could tell me how to test a single glsl test (or
batch or version) at a time.

-- 
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/20130331/d4284ccb/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

Alexandre Demers  changed:

   What|Removed |Added

   Hardware|Other   |All

-- 
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/20130331/df6f1576/attachment-0001.html>

[Bug 62959] New: r600g (HD 6950 Cayman) fails piglit tests and hangs system

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

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

  Priority: medium
Bug ID: 62959
  Assignee: dri-devel at lists.freedesktop.org
   Summary: r600g (HD 6950 Cayman) fails piglit tests and hangs
system
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: alexandre.f.demers at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Using mesa 0967c362bf378b7415c30ca6d9523d3b2a3a7f5d (and for a long time),
piglit tests fail and hangs the system (ssh session won't respond). Using an HD
6950 (Cayman).

Running "python2 piglit-run.py --no-concurrency tests/r600.tests
results/r600.results/", it fails everytime. According to the "main" file, the
last log info is:

"spec/glsl-1.30/execution/built-in-functions/fs-greaterThan-uvec4-uvec4": {
"info": "Returncode: 0\n\nErrors:\n\n\nOutput:\n", 
"returncode": 0, 
"command":
"/home/dema1701/projects/display/piglit/framework/../bin/shader_runner
tests/../generated_tests/spec/glsl-1.30/execution/built-in-functions/fs-greaterThan-uvec4-uvec4.shader_test
-auto", 
"result": "pass", 
"time": 0.10875105857849121
},

"spec/glsl-1.10/execution/variable-indexing/fs-temp-array-mat4-col-row-wr": {
"info": "Returncode: 0\n\nErrors:\n\n\nOutput:\n", 
"returncode": 0, 



Mesa's build options:
baseExec="./autogen.sh --prefix=/usr \
--enable-debug \
--enable-shared \
--enable-osmesa \
--enable-gbm \
--enable-xvmc \
--enable-vdpau \
--enable-gles1 \
--enable-gles2 \
--enable-openvg \
--enable-xorg \
--enable-xa \
--enable-egl \
--enable-gallium-egl \
--enable-glx-tls \
--enable-texture-float \
--enable-wgl \
--with-gallium-drivers=r600,swrast,svga \
--with-egl-platforms=x11,drm"
"$baseExec  --enable-64-bit --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --libdir=/usr/lib/x86_64-linux-gnu
--includedir=/usr/include/x86_64-linux-gnu"

-- 
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/20130331/d429a955/attachment.html>

[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state

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

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

--- Comment #24 from Alexandre Demers  ---
62444b7462a2b98bc78d68736c03a7c4e66ba7e2 is the first bad commit
commit 62444b7462a2b98bc78d68736c03a7c4e66ba7e2
Author: Alex Deucher 
Date:   Wed Aug 15 17:18:42 2012 -0400

drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)

- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access

This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.

v2: fix crtc enabled check noticed by Luca Tettamanti

Signed-off-by: Alex Deucher 

:04 04 3e0d33c9b4eda29ced814fe9a863efe63e53f14c
4932561607b160734ec1eade927a9fe18c9f3f1b Mdrivers




So in other words, your explanation Alex seems to be right. I'll be waiting if
anything has to be tested.

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

Re: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

[Michal Hocko]

On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
 This looks a bit like a hack and it doesn't look right,
 conceptually. If the call fails, it should restore things as if
 nothing has ever happened and overwriting old_mapping is not going to
 do the trick.

OK, I thought this is what the patch does as it falls back to
inode-i_data which is the default mapping for all inodes or it uses
what used to be in device mapping.

I am obviously not familiar with the drm code but it feels a bit strange
that the device mapping can be different than inode's resp. file's one
and even more confusing that inode and file are saved separately.

 I think the right way to fix it would be to separately store the
 original mapping for filp-f_mapping and inode-i_mapping and restore
 it from their respective temporary variables if drm_open_helper or
 drm_setup fail. Attached is a quick patch to show you
[...]
 @@ -137,6 +139,8 @@ int drm_open(struct inode *inode, struct file *filp)
   if (!dev-open_count++)
   need_setup = 1;
   mutex_lock(dev-struct_mutex);
 + old_fmapping = filp-f_mapping;
 + old_imapping = inode-i_mapping;

How can file and inode mappings be different?

   old_mapping = dev-dev_mapping;
   if (old_mapping == NULL)
   dev-dev_mapping = inode-i_data;
 @@ -159,8 +163,8 @@ int drm_open(struct inode *inode, struct file *filp)
  
  err_undo:
   mutex_lock(dev-struct_mutex);
 - filp-f_mapping = old_mapping;
 - inode-i_mapping = old_mapping;
 + filp-f_mapping = old_fmapping;
 + inode-i_mapping = old_imapping;
   iput(container_of(dev-dev_mapping, struct inode, i_data));
   dev-dev_mapping = old_mapping;
   mutex_unlock(dev-struct_mutex);
-- 
1.8.1.5

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

[Bug 62967] New: Game Dungeon Defenders crash my whole system.

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 62967
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Game Dungeon Defenders crash my whole system.
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: lve...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 77255
  -- https://bugs.freedesktop.org/attachment.cgi?id=77255action=edit
glxinfo output

When I run Dungeon Defenders, the game window pops up and the first intro
animation runs very slowly (a red logo building in front of a white backgroud),
then at the second animation, a seeming magic circle with purple fire, my
computer halts and freezes completely, and I have to reboot.

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

Re: [PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r

[Jiri Kosina]

On Thu, 21 Mar 2013, Daniel Vetter wrote:

 Indeed, this is pretty useful and allowed me to quickly reproduce that
 phantom irq on my gm45. Thanks to module reloading we can even reset the
 kernel's irq disabling logic and so test different tricks quickly without
 rebooting. Really useful.

Daniel,

out of curiosity, have you been able to make some sense of the phantom 
legacy IRQs on GM45 systems, or are we just staying with my original 
bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect?

Thanks,

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

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

[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@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_data4 - 
lcd_data4 (LCD_DATA4) 

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

[Luis R. Rodriguez]

On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall julia.law...@lip6.fr 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
___
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

[Julia Lawall]

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

 On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall julia.law...@lip6.fr 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
___
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

[Luis R. Rodriguez]

On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall julia.law...@lip6.fr 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
___
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

[Peter Hurley]

On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 ---
 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;


___
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

[Julia Lawall]

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

 On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall julia.law...@lip6.fr 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
___
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

[Luis R. Rodriguez]

On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall julia.law...@lip6.fr wrote:
 On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:

 On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall julia.law...@lip6.fr 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
___
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

[Julia Lawall]

  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.

What do you do about the test, though?

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

[Luis R. Rodriguez]

On Thu, Mar 28, 2013 at 11:21 PM, Julia Lawall julia.law...@lip6.fr wrote:
  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.

 What do you do about the test, though?

Return the value.

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

[PATCH] gma500: Make VGA and HDMI connector hotpluggable

[Kero]

From: Kero van Gelder k...@chello.nl

Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
This patch will cause output to be shown on either when plugged in.
For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.

Signed-off-by: Kero van Gelder k...@chello.nl
---
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 8c17534..7b8386f 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -276,6 +276,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
goto failed_connector;
 
connector = psb_intel_connector-base;
+   connector-polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_init(dev, connector,
cdv_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
 
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c 
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index e223b50..464153d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -319,6 +319,7 @@ void cdv_hdmi_init(struct drm_device *dev,
goto err_priv;
 
connector = psb_intel_connector-base;
+   connector-polled = DRM_CONNECTOR_POLL_HPD;
encoder = psb_intel_encoder-base;
drm_connector_init(dev, connector,
   cdv_hdmi_connector_funcs,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43276] Screen black after suspending/resuming Toshiba Satellite C675D-S7109 laptop

[bugzilla-daemon]

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


Dan Furlani dan.furl...@earthling.net changed:

   What|Removed |Added

 Kernel Version|3.4.0-030400rc6-generic |3.9.0-rc4
Summary|Resume fails after  |Screen black after
   |suspending Toshiba  |suspending/resuming Toshiba
   |Satellite C675D-S7109   |Satellite C675D-S7109
   |laptop  |laptop




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

[Bug 56031] New: Enabling radeon HDMI audio causes video corruption in unsupported hardware

[bugzilla-daemon]

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

   Summary: Enabling radeon HDMI audio causes video corruption in
unsupported hardware
   Product: Drivers
   Version: 2.5
Kernel Version: 3.8
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: low
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: dark...@gmail.com
Regression: Yes


I changed laptops from an r600 to an aruba, and accidentally left
radeon.audio=1 in my kernel parameters.  This caused the external screen to be
shifted right a bit and a pink stripe on the left.  This is due to change
f92e70cae880e3540d0c1dddc64825b70f963703 which does not filter out DCE6 (since
it is currently unsupported for HDMI) as it should.  The patch I have attached
adds this restriction, but it might be better if somewhere early in the device
initialization radeon_audio were just set to 0 if unsupported.

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

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

[bugzilla-daemon]

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

runetmem...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from runetmem...@gmail.com ---
Tested with proprietary driver - issues reproducible (GPU not power-up without
reboot) so probably problems with hardware or maybe BIOS.

-- 
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 56041] New: Disabling LCD on ARUBA causes hotplug loop

[bugzilla-daemon]

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

   Summary: Disabling LCD on ARUBA causes hotplug loop
   Product: Drivers
   Version: 2.5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: dark...@gmail.com
Regression: No


My hardware:  a Gateway/Acer laptop with Radeon HD 7640G.  Disabling the LCD
(xrandr --output eDP --off) while the external display is being used causes
some sort of hotplug event loop.  100% of one CPU's worth of CPU time is
consumed, and X freezes every few seconds.  For now, I have worked around by
commenting out queue_hotplug = true in evergreen.c (case 0).

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

[Bug 45641] Screen goes black randomly

[bugzilla-daemon]

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

--- Comment #18 from John john.etted...@gmail.com ---
I tried the patch today but got another black screen already.
I have an 4670 by the way, not sure if the patch was made for that one or
not...

Thanks

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

[Bug 62976] New: UEFI + SUMO [6550D] freeze after loading radeon

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 62976
  Assignee: dri-devel@lists.freedesktop.org
   Summary: UEFI + SUMO [6550D] freeze after loading radeon
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: d.ok...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

HW: Motheboard asus f1a75-v pro, cpu a3870k.

Kernel 3.8.5, direct boot from BIOS.

EFI framebuffer OK.

radeon DRM - nothing displayed, only some strong garbage in center (100% width,
2/3 height).

EFI fb + radeon DRM: some messages, freeze on takeover from EFI

-- 
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 62976] UEFI + SUMO [6550D] freeze after loading radeon

[bugzilla-daemon]

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

--- Comment #1 from okias d.ok...@gmail.com ---
Created attachment 77262
  -- https://bugs.freedesktop.org/attachment.cgi?id=77262action=edit
dmesg_with_EFI_FB.txt

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