date:20110525

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

--- Comment #1 from Rene Peinthor  2011-05-25 22:50:13 
PDT ---
Same problem here on HD4850 and 5770, will try to disable llvm when I'm back
home.

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

[PULL] drm-intel-next

2011-05-25 Thread Keith Packard


This fixes a simple typo in the Ivybridge code -- an extra semicolon.

The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0:

  drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge 
(2011-05-18 15:14:39 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git 
drm-intel-next

Dan Carpenter (1):
  drm/i915: fix if statement in ivybridge irq handler

 drivers/gpu/drm/i915/i915_irq.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/a6753734/attachment.pgp>

[PATCH] drm/radeon/kms: fix thermal sensor reading on juniper

Uses a different method than other evergreen asics.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c  |   48 ---
 drivers/gpu/drm/radeon/evergreend.h |8 +-
 2 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 7c37638..5f0c345 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -88,21 +88,39 @@ u32 evergreen_page_flip(struct radeon_device *rdev, int 
crtc_id, u64 crtc_base)
 /* get temperature in millidegrees */
 int evergreen_get_temp(struct radeon_device *rdev)
 {
-   u32 temp = (RREG32(CG_MULT_THERMAL_STATUS) & ASIC_T_MASK) >>
-   ASIC_T_SHIFT;
-   u32 actual_temp = 0;
-
-   if (temp & 0x400)
-   actual_temp = -256;
-   else if (temp & 0x200)
-   actual_temp = 255;
-   else if (temp & 0x100) {
-   actual_temp = temp & 0x1ff;
-   actual_temp |= ~0x1ff;
-   } else
-   actual_temp = temp & 0xff;
+   u32 temp, toffset, actual_temp = 0;
+
+   if (rdev->family == CHIP_JUNIPER) {
+   toffset = (RREG32(CG_THERMAL_CTRL) & TOFFSET_MASK) >>
+   TOFFSET_SHIFT;
+   temp = (RREG32(CG_TS0_STATUS) & TS0_ADC_DOUT_MASK) >>
+   TS0_ADC_DOUT_SHIFT;
+
+   if (toffset & 0x100)
+   actual_temp = temp / 2 - (0x200 - toffset);
+   else
+   actual_temp = temp / 2 + toffset;
+
+   actual_temp = actual_temp * 1000;
+
+   } else {
+   temp = (RREG32(CG_MULT_THERMAL_STATUS) & ASIC_T_MASK) >>
+   ASIC_T_SHIFT;
+
+   if (temp & 0x400)
+   actual_temp = -256;
+   else if (temp & 0x200)
+   actual_temp = 255;
+   else if (temp & 0x100) {
+   actual_temp = temp & 0x1ff;
+   actual_temp |= ~0x1ff;
+   } else
+   actual_temp = temp & 0xff;
+
+   actual_temp = (actual_temp * 1000) / 2;
+   }

-   return (actual_temp * 1000) / 2;
+   return actual_temp;
 }

 int sumo_get_temp(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index f37e91e..1636e34 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -168,10 +168,16 @@
 #defineSE_DB_BUSY  (1 << 
30)
 #defineSE_CB_BUSY  (1 << 
31)
 /* evergreen */
+#defineCG_THERMAL_CTRL 0x72c
+#defineTOFFSET_MASK0x3FE0
+#defineTOFFSET_SHIFT   5
 #defineCG_MULT_THERMAL_STATUS  0x740
 #defineASIC_T(x)   ((x) << 16)
-#defineASIC_T_MASK 0x7FF
+#defineASIC_T_MASK 0x07FF
 #defineASIC_T_SHIFT16
+#defineCG_TS0_STATUS   0x760
+#defineTS0_ADC_DOUT_MASK   0x03FF
+#defineTS0_ADC_DOUT_SHIFT  0
 /* APU */
 #defineCG_THERMAL_STATUS   0x678

-- 
1.7.1.1

BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

2011-05-25 Thread Frank van Maarseveen

On Wed, May 25, 2011 at 11:43:00AM -0400, Alex Deucher wrote:
> On Wed, May 25, 2011 at 8:29 AM, Frank van Maarseveen
>  wrote:
> > Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes
> > immediately upon start.
> >
> 
> Any reason you are not using kms?

The help on that kernel configuration option for Radeon and Nouveau
looked scary: it warned about pain for old userland and I'd prefer to
use the same kernel for older distro (Debian lenny) too, if possible.
I'll try it anyway.

FC14 and FC15 live images run fine on this system with compiz enabled.

> 
> Alex
> 
[...]

-- 
Frank

[Bug 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)

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

--- Comment #5 from Erdem U. Altinyurt  2011-05-25 
18:32:15 PDT ---
Don't know "nexuiz's timedemo demos/demo1.dem" but my barts (HD6850) hanging up
while I am in desktop (with compiz) too. So I don't believe if this is related
with just TURKS but BARTS...

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

[Bug 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)

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

--- Comment #4 from Dave Airlie  2011-05-25 
18:24:02 PDT ---
are you running nexuiz in any particular way?

I'm wondering if this is TURKS specific, my BARTS can run gnome-shell + nexuiz
timedemo demos/demo1.dem in full here with no hangs.

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

[PATCH] drm/radeon/kms: add missing case for cayman thermal sensor

The rest of the code is already in place.

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

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 86eda1e..aaa19dc 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -487,6 +487,7 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_RV6XX:
case THERMAL_TYPE_RV770:
case THERMAL_TYPE_EVERGREEN:
+   case THERMAL_TYPE_NI:
case THERMAL_TYPE_SUMO:
rdev->pm.int_hwmon_dev = hwmon_device_register(rdev->dev);
if (IS_ERR(rdev->pm.int_hwmon_dev)) {
-- 
1.7.1.1

[PATCH 2/2] drm/radeon/kms: add blit support for cayman

2011-05-25 Thread Nils Wallménius

>@@ -582,11 +588,17 @@ int evergreen_blit_init(struct radeon_device *rdev)
>   obj_size = ALIGN(obj_size, 256);
>
>   rdev->r600_blit.vs_offset = obj_size;
>-  obj_size += evergreen_vs_size * 4;
>+  if (rdev->family < CHIP_CAYMAN)
>+  obj_size += evergreen_vs_size * 4;
>+  else
>+  obj_size += cayman_vs_size * 4;
>   obj_size = ALIGN(obj_size, 256);
>
>   rdev->r600_blit.ps_offset = obj_size;
>-  obj_size += evergreen_ps_size * 4;
>+  if (rdev->family < CHIP_CAYMAN)
>+  obj_size += evergreen_ps_size * 4;
>+  else
>+  obj_size += evergreen_ps_size * 4;
>   obj_size = ALIGN(obj_size, 256);
>
>   r = radeon_bo_create(rdev, obj_size, PAGE_SIZE, true, 
> RADEON_GEM_DOMAIN_VRAM,


Hi, looks like a c error using evergreen_ps_size also for cayman

(Short?) merge window reminder

2011-05-25 Thread Boaz Harrosh

On 05/23/2011 11:52 PM, Alexey Zaytsev wrote:
> On Tue, May 24, 2011 at 00:33, Linus Torvalds
>  wrote:
>> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar  wrote:
>>>
>>> I really hope there's also a voice that tells you to wait until .42 before
>>> cutting 3.0.0! :-)
>>
>> So I'm toying with 3.0 (and in that case, it really would be "3.0",
>> not "3.0.0" - the stable team would get the third digit rather than
>> the fourth one.
>>
>> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
>> fairly nice round number.
>>
>> There's also the timing issue - since we no longer do version numbers
>> based on features, but based on time, just saying "we're about to
>> start the third decade" works as well as any other excuse.
>>
>> But we'll see.
> 
> Maybe, 2011.x, or 11.x, x increasing for every merge window started this year?
> This would better reflect the steady nature of the releases, but would
> certainly break a lot of scripts. ;)

My $0.017 on this. Clearly current process is time based. People have said.

* Keep Three digit numbers to retain script compatibility
* Make it clear from the version when it was released.
* Linus said 3 as for 3rd decade
* Nice single increment number progression
* Please make it look like a nice version number sys-admins will feel
  at home with

So if you combine all the above:

D. Y. N
D - Is the decade since birth (1991 not 1990)
Y - is the year in the decade so you have 3.1.x, 3.2.x, .. 3.10.x, 4.1.X and so 
on
Nice incremental number.
N - The Linus release of this Year. So this 3rd one goes up to 4 most probably.

Linus always likes, and feels very poetic about the Christmas version release.
He hates it when once it slipped into the next year. So now he gets to increment
the second digit as a bonus.

The 2nd digit gets to start on a *one*, never zero and goes up to *10*, to 
symbolize
the 1991 birth. And we never have .zero quality, right?

The first Digit gets incremented on decade from 1991 so on 2011 and not 2010

So here you have it, who said we need to compromise?

Free life
Boaz

(Short?) merge window reminder

2011-05-25 Thread Martin Nybo Andersen

On Tue, 24 May 2011, Zimny Lech wrote:
> Hi,
>
> 2011/5/24 Lisa Milne :
>>> So I'm toying with 3.0 (and in that case, it really would be "3.0",
>>> not "3.0.0" - the stable team would get the third digit rather than
>>> the fourth one.
>>
>> How about stardates?
>
> This is a wonderful idea! :)

I'd rather go for a gardensheduler, which can tell me the optimal color 
for any given moment *and* do the paint job. If it eventually ends this 
discussion, it could be renamed "completely fair gardensheduler".

>
>> That'd make a release made now 64860.8
>>
>> I really should sleep more...

Or drink less coffee ... ;)

-- 
Regards,
Martin

[PATCH] drm/radeon/kms: add blit support for cayman (v2)

Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.

v2: fix copy paste typo
Reported-by: Nils Wallm?nius 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/cayman_blit_shaders.c |  326 -
 drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
 drivers/gpu/drm/radeon/evergreen_blit_kms.c  |  505 ++
 drivers/gpu/drm/radeon/ni.c  |   13 +-
 drivers/gpu/drm/radeon/radeon_asic.c |6 +-
 5 files changed, 598 insertions(+), 255 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c 
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@

 const u32 cayman_default_state[] =
 {
-   /* XXX fill in additional blit state */
+   0xc0066900,
+   0x,
+   0x0060, /* DB_RENDER_CONTROL */
+   0x, /* DB_COUNT_CONTROL */
+   0x, /* DB_DEPTH_VIEW */
+   0x002a, /* DB_RENDER_OVERRIDE */
+   0x, /* DB_RENDER_OVERRIDE2 */
+   0x, /* DB_HTILE_DATA_BASE */

0xc0026900,
-   0x0316,
-   0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
-   0x0010, /*  */
+   0x000a,
+   0x, /* DB_STENCIL_CLEAR */
+   0x, /* DB_DEPTH_CLEAR */
+
+   0xc0036900,
+   0x000f,
+   0x, /* DB_DEPTH_INFO */
+   0x, /* DB_Z_INFO */
+   0x, /* DB_STENCIL_INFO */
+
+   0xc0016900,
+   0x0080,
+   0x, /* PA_SC_WINDOW_OFFSET */
+
+   0xc00d6900,
+   0x0083,
+   0x, /* PA_SC_CLIPRECT_RULE */
+   0x, /* PA_SC_CLIPRECT_0_TL */
+   0x20002000, /* PA_SC_CLIPRECT_0_BR */
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x, /* PA_SC_EDGERULE */
+   0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+   0x000f, /* CB_TARGET_MASK */
+   0x000f, /* CB_SHADER_MASK */
+
+   0xc0226900,
+   0x0094,
+   0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+   0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x, /* PA_SC_VPORT_ZMIN_0 */
+   0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+   0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */

0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+   0xc0096900,
+   0x0100,
+   0x00ff, /* VGT_MAX_VTX_INDX */
+   0x, /* VGT_MIN_VTX_INDX */
+   0x, /* VGT_INDX_OFFSET */
+   0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+   0x, /* SX_ALPHA_TEST_CONTROL */
+   0x, /* CB_BLEND_RED */
+   0x, /* CB_BLEND_GREEN */
+   0x, /* CB_BLEND_BLUE */
+   0x, /* CB_BLEND_ALPHA */
+
+   0xc0016900,
+   0x0187,
+   0x0100, /* SPI_VS_OUT_ID_0 */
+
+   0xc0026900,
+   0x0191,
+   0x0100, /* SPI_PS_INPUT_CNTL_0 */
+   0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+   0xc0016900,
+   0x01b1,
+   0x, /* SPI_VS_OUT_CONFIG */
+
+   0xc0106900,
+   0x01b3,
+   0x2001, /* SPI_PS_IN_CONTROL_0 */
+   0x, /* SPI_PS_IN_CONTROL_1 */
+   0x, /* SPI_INTERP_CONTROL_0 */
+   0x, /* SPI_INPUT_Z */
+   0x, /* SPI_FOG_CNTL */
+   0x0010, /* SPI_BARYC_CNTL */
+   0x, /* SPI_PS_IN_CONTROL_2 */
+   0x, /* SPI_COMPUTE_INPUT_CNTL */
+   0x, /* SPI_COMPUTE_NUM_THREAD_X */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+   0x, /* SPI_GPR_MGMT */
+   0x, /* SPI_LDS_MGMT */
+   0x, /* SPI_STACK_MGMT */
+   0x, /* SPI_WAVE_MGMT_1 */
+   0x, /* SPI_WAVE_MGMT_2 */
+
+   0xc0016900,
+   0x01e0,
+   0x, /* CB_BLEND0_CONTROL */
+
+   0xc00e6900,
+   0x0200,
+   0x, /* DB_DEPTH_CONTROL */
+   0x, /* DB_EQAA */
+   0x00cc0010, /* CB_COLOR_CONTROL */
+   0x0210, /* DB_SHADER_CONTROL */
+   0x0001, /*

(Short?) merge window reminder

2011-05-25 Thread Tony Luck

On Wed, May 25, 2011 at 7:12 AM, Boaz Harrosh  wrote:
> So if you combine all the above:
>
> D. Y. N
> D - Is the decade since birth (1991 not 1990)
> Y - is the year in the decade so you have 3.1.x, 3.2.x, .. 3.10.x, 4.1.X and 
> so on
> ? ?Nice incremental number.
> N - The Linus release of this Year. So this 3rd one goes up to 4 most 
> probably.
>
> Linus always likes, and feels very poetic about the Christmas version release.
> He hates it when once it slipped into the next year. So now he gets to 
> increment
> the second digit as a bonus.
>
> The 2nd digit gets to start on a *one*, never zero and goes up to *10*, to 
> symbolize
> the 1991 birth. And we never have .zero quality, right?
>
> The first Digit gets incremented on decade from 1991 so on 2011 and not 2010

This is clearly the best suggestion so far - small numbers, somewhat
date related (but without stuffing a "2011." on the front).  No ".0"
releases, ever.

But best of all it defines now when we will switch to 4.x.y and 5.x.y
so we don't have to keep having this discussion whenever someone thinks
that the numbers are getting "too big" (well perhaps when we get to the
tenth decade or so :-)

So the only thing left to argue is whether the upcoming release should
be numbered "3.1.1" as the first release in the first year of the 3rd
decade ...  or whether we should count 2.6.37 .. 2.6.39 as the first
three releases this year and thus we ought to start with "3.1.4" (so we
start with "pi"!).

Linus: If you go with this, you should let Boaz set the new "NAME"
as a prize for such an inspired solution.

-Tony

(Short?) merge window reminder

2011-05-25 Thread Jiri Kosina

On Tue, 24 May 2011, Andy Lutomirski wrote:

> Also, when someone in my lab installs  here> on a box that's running software I wrote that needs to support 
> modern high-speed peripherals, then I can say "What?  You seriously 
> expect this stuff to work on Linux 2007?  Let's install a slightly less 
> stable distro from at least 2010."  This sounds a lot less nerdy than 
> "What?  You seriously expect this stuff to work on Linux 2.6.27?  Let's 
> install a slightly less stable distro that uses at least 2.6.36."

I hate to jump into this excellent example of bike-shedding discussion, 
but anyway ...

Your example doesn't really reflect reality.

It's common for older enterprise distributions to gradually incorporate a 
lot of backported code (and most importantly new hardware support 
code/drivers) while not upgrading the kernel major version. So yes, you 
will in reality get 2.6.16 kernel (at least according to uname) with 
libata with newer service packs of SLES 10, for example (and you could 
find many of those across distributions).

-- 
Jiri Kosina
SUSE Labs

[Bug 37603] New: r600g with LLVM enabled makes Heroes of Newerth game unplayable

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

   Summary: r600g with LLVM enabled makes Heroes of Newerth game
unplayable
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: damien at grassart.com


Created an attachment (id=47162)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47162)
Blurry loading screen

Hi, recent versions of Mesa have made this game go from 30 fps down to under 1
fps, and have caused the bottom of textures to become blurry (see attachment).
I've bisected it down to commit a86fc719d6402eb482657707741890e69e81700f
(enable LLVM by default on x86 and x86_64). I don't know why LLVM causes this
but I've verified that disabling it via configure fixes this problem. I now
use: 

./configure --prefix=$HOME --enable-gallium-r600 --disable-gallium-r300
--disable-gallium-llvm --disable-gallium-egl --with-state-trackers=dri

I know r300g requires LLVM but are there any reasons to enable it for r600g?

Thanks,
-Damien

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

BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

2011-05-25 Thread Frank van Maarseveen

Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes
immediately upon start.

lspci excerpt:
01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon 
X1300/X1550 Series]
01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] 
(Secondary)

/var/log/messages excerpt:
[drm] Setting GART location based on new memory map
[drm] Loading R500 Microcode
[drm] Num pipes: 1
[drm] writeback test succeeded in 1 usecs
[drm] Num pipes: 1
BUG: unable to handle kernel paging request at 6b6b6b6b
IP: [] radeon_read_ring_rptr+0x19/0x30
*pdpt = 335ab001 *pde =  
Oops:  [#1] PREEMPT SMP 
last sysfs file: /sys/devices/pci:00/:00:01.0/:01:00.0/enable
Modules linked in: [last unloaded: scsi_wait_scan]
May 25 12:23:58 lokka kernel:
Pid: 4484, comm: X Not tainted 2.6.39-x255 #1 Dell Inc. Dell 
DXP051  /0FJ030
EIP: 0060:[] EFLAGS: 00213202 CPU: 1
EIP is at radeon_read_ring_rptr+0x19/0x30
EAX: f3484be0 EBX: f569baa0 ECX: 000a EDX: 6b6b6b6b
ESI: f85e5000 EDI: 0040 EBP: f37a1d0c ESP: f37a1d08
DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
Process X (pid: 4484, ti=f37a task=f378b3c0 task.ti=f37a)
Stack:
c1377387 f37a1d1c c1377b86 f569baa0 0010 f37a1d44 c137a0be 0001
c1a8a2f7 c188cb8a c1a648c4 f6424d60 f569baa0   f37a1d58
c137c7cf f569bbb0 f569baa0 f569baa0 f37a1d6c c137c9b7 f569bab4 f569bbe0
Call Trace:
[] ? radeon_get_ring_head+0x47/0x50
[] radeon_commit_ring+0x56/0xb0
[] radeon_do_cp_idle+0xce/0x170
[] radeon_apply_surface_regs+0x2f/0x150
[] free_surface+0xc7/0x100
[] radeon_driver_lastclose+0x45/0x60
[] drm_lastclose+0x40/0x2b0
[] ? drm_release+0x344/0x460
[] drm_release+0x376/0x460
[] __fput+0xa9/0x1c0
[] fput+0x1f/0x30
[] filp_close+0x4d/0x80
[] put_files_struct+0x76/0xe0
[] exit_files+0x42/0x60
[] do_exit+0x231/0x320
[] do_group_exit+0x33/0x90
[] ? sub_preempt_count+0x7b/0xa0
[] get_signal_to_deliver+0x17d/0x2a0
[] do_notify_resume+0xc0/0x180
[] ? mntput+0x13/0x30
[] ? __fput+0x12f/0x1c0
[] ? get_parent_ip+0xb/0x40
[] ? sub_preempt_count+0x7b/0xa0
[] ? _raw_spin_unlock_irq+0x18/0x40
[] ? sigprocmask+0x70/0xf0
[] ? sys_rt_sigprocmask+0xd4/0xf0
[] ? sys_rt_sigprocmask+0xd4/0xf0
[] work_notifysig+0x13/0x1b
Code: fe ff 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 f6 80 3a 03 00 
00 08 89 e5 75 14 8b 80 e0 00 00 00 83 e2 fc 5d 03 50 14 <8b> 02 c3 8d 74 26 00 
8b 80 e0 00 00 00 03 50 14 8b 02 5d c3 8d 
EIP: [] radeon_read_ring_rptr+0x19/0x30 SS:ESP 0068:f37a1d08
CR2: 6b6b6b6b
---[ end trace 9a6c2c396ea040f5 ]---
Fixing recursive fault but reboot is needed!

/var/log/Xorg.0.log:
[   111.905] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
[   111.906] _XSERVTransOpen: transport open failed for inet6/lokka.tasking.nl:0
[   111.906] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for 
inet6
[   111.917] 
X.Org X Server 1.9.5
Release Date: 2011-03-17
[   111.917] X Protocol Version 11, Revision 0
[   111.917] Build Operating System: x86-01 2.6.32-71.14.1.el6.x86_64 
[   111.917] Current Operating System: Linux lokka.tasking.nl 2.6.39-x255 #1 
SMP PREEMPT Wed May 25 10:34:33 CEST 2011 i686
[   111.917] Kernel command line: initrd=initrd nomodules panic=60 
nmi_watchdog=1 netconsole=@172.17.1.124/,514 at 172.17.1.64/00:12:3f:85:17:52 
BOOT_IMAGE=linux-2.6.39-x255 
[   111.917] Build Date: 18 March 2011  12:23:01AM
[   111.917] Build ID: xorg-x11-server 1.9.5-1.fc14 
[   111.918] Current version of pixman: 0.18.4
[   111.918]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   111.918] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   111.918] (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 25 12:23:57 
2011
[   111.964] (==) Using config directory: "/etc/X11/xorg.conf.d"
[   111.964] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   111.981] (==) No Layout section.  Using the first Screen section.
[   111.981] (==) No screen section available. Using defaults.
[   111.981] (**) |-->Screen "Default Screen Section" (0)
[   111.981] (**) |   |-->Monitor ""
[   111.982] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   111.982] (==) Automatically adding devices
[   111.982] (==) Automatically enabling devices
[   111.983] (==) FontPath set to:
catalogue:/etc/X11/fontpath.d,
built-ins
[   111.983] (==) ModulePath set to "/usr/lib/xorg/modules"
[   111.983] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   111.983] (II) 
***

[PATCH] drm/radeon/kms: properly set panel mode for eDP

This should make eDP more reliable.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c |   11 +++
 include/drm/drm_dp_helper.h  |3 +++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8c0f9e3..892b88d 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -543,6 +543,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,
 {
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
+   struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;

if (!ASIC_IS_DCE4(rdev))
@@ -550,10 +551,20 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,

if (radeon_connector_encoder_is_dp_bridge(connector))
panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
+   else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   u8 tmp = radeon_read_dpcd_reg(radeon_connector, 
DP_EDP_CONFIGURATION_CAP);
+   if (tmp & 1)
+   panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
+   }

atombios_dig_encoder_setup(encoder,
   ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
   panel_mode);
+
+   if ((connector->connector_type == DRM_MODE_CONNECTOR_eDP) &&
+   (panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
+   radeon_write_dpcd_reg(radeon_connector, 
DP_EDP_CONFIGURATION_SET, 1);
+   }
 }

 void radeon_dp_set_link_config(struct drm_connector *connector,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 91567bb..03eb1d6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -72,6 +72,7 @@

 #define DP_MAIN_LINK_CHANNEL_CODING 0x006

+#define DP_EDP_CONFIGURATION_CAP0x00d
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e

 /* link configuration */
@@ -133,6 +134,8 @@
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
 # define DP_SET_ANSI_8B10B (1 << 0)

+#define DP_EDP_CONFIGURATION_SET0x10a
+
 #define DP_LANE0_1_STATUS  0x202
 #define DP_LANE2_3_STATUS  0x203
 # define DP_LANE_CR_DONE   (1 << 0)
-- 
1.7.4

[PATCH] uv/x2apic: update for change in pci bridge handling.

2011-05-25 Thread Dave Airlie

From: Dave Airlie 

I forgot about the special uv handling code for this, so this
patch fixes it up.

Signed-off-by: Dave Airlie 
---
 arch/x86/kernel/apic/x2apic_uv_x.c |8 
 drivers/pci/pci.c  |4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 33b10a0..185cd1e 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -599,14 +599,14 @@ late_initcall(uv_init_heartbeat);

 /* Direct Legacy VGA I/O traffic to designated IOH */
 int uv_set_vga_state(struct pci_dev *pdev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
 {
int domain, bus, rc;

-   PR_DEVEL("devfn %x decode %d cmd %x chg_brdg %d\n",
-   pdev->devfn, decode, command_bits, change_bridge);
+   PR_DEVEL("devfn %x decode %d cmd %x flags %d\n",
+   pdev->devfn, decode, command_bits, flags);

-   if (!change_bridge)
+   if (!(flags & PCI_VGA_STATE_CHANGE_BRIDGE))
return 0;

if ((command_bits & PCI_COMMAND_IO) == 0)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a339237..4528ee7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2862,11 +2862,11 @@ void __init 
pci_register_set_vga_state(arch_set_vga_state_t func)
 }

 static int pci_set_vga_state_arch(struct pci_dev *dev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
 {
if (arch_set_vga_state)
return arch_set_vga_state(dev, decode, command_bits,
-   change_bridge);
+   flags);
return 0;
 }

-- 
1.7.1

[patch] drm/i915: fix if statement in ivybridge irq handler

2011-05-25 Thread Dan Carpenter

The extra semicolon was not intended.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b79619a..b9fafe3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -517,7 +517,7 @@ irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS)
if (de_iir & DE_PIPEA_VBLANK_IVB)
drm_handle_vblank(dev, 0);

-   if (de_iir & DE_PIPEB_VBLANK_IVB);
+   if (de_iir & DE_PIPEB_VBLANK_IVB)
drm_handle_vblank(dev, 1);

/* check event from PCH */

[PATCH] drm/radeon/kms: clean up the radeon kms Kconfig

- no longer in staging
- all radeons supported

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/Kconfig |9 +
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 9746fee..ea92bbe 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -28,11 +28,4 @@ config DRM_RADEON_KMS
  The kernel will also perform security check on command stream
  provided by the user, we want to catch and forbid any illegal use
  of the GPU such as DMA into random system memory or into memory
- not owned by the process supplying the command stream. This part
- of the code is still incomplete and this why we propose that patch
- as a staging driver addition, future security might forbid current
- experimental userspace to run.
-
- This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX
- (radeon up to X1950). Works is underway to provide support for R6XX,
- R7XX and newer hardware (radeon from HD2XXX to HD4XXX).
+ not owned by the process supplying the command stream.
-- 
1.7.1.1

PROBLEM: Oops in drm_vblank_put() 2.6.39-1 intel i915 82915G/GV/910GL

2011-05-25 Thread Milind Movasha

 0xf8469000
sr_mod 12668 0 - Live 0xf846
cdrom 30893 1 sr_mod, Live 0xf844f000
sd_mod 25091 4 - Live 0xf8439000
ata_piix 18337 3 - Live 0xf80b1000
pata_acpi 2292 0 - Live 0xf803d000
libata 150925 2 ata_piix,pata_acpi, Live 0xf82a5000
scsi_mod 107918 4 sg,sr_mod,sd_mod,libata, Live 0xf819f000
i915 551141 2 - Live 0xf82f3000
drm_kms_helper 23853 1 i915, Live 0xf8048000
drm 144133 3 i915,drm_kms_helper, Live 0xf80ba000
intel_agp 8496 1 i915, Live 0xf8079000
i2c_algo_bit 4263 1 i915, Live 0xf806a000
button 3518 1 i915, Live 0xf8005000
intel_gtt 11097 3 i915,intel_agp, Live 0xf8055000
agpgart 21456 3 drm,intel_agp,intel_gtt, Live 0xf804
i2c_core 15857 5 i2c_i801,i915,drm_kms_helper,drm,i2c_algo_bit, Live
0xf802a000
video 9652 1 i915, Live 0xf8018000
[milindm at milindm-desktop linux-2.6.39]$

[milindm at milindm-desktop linux-2.6.39]$ cat /proc/iomem
- : reserved
0001-0009 : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : reserved
  000f-000f : System ROM
0010-3f686bff : System RAM
  0100-01331dc0 : Kernel code
  01331dc1-0147197f : Kernel data
  014e6000-015c9fff : Kernel bss
3f686c00-3f688bff : ACPI Non-volatile Storage
3f688c00-3f68abff : ACPI Tables
3f68ac00-3fff : reserved
4000-401f : PCI Bus :02
c000-cfff : :00:02.0
dfa0-dfaf : PCI Bus :04
  dfafff00-dfaf : :04:00.0
dfafff00-dfaf : 8139too
dfb0-dfbf : PCI Bus :03
dfc0-dfcf : PCI Bus :02
  dfcf-dfcf : :02:00.0
dfcf-dfcf : tg3
dfd0-dfdf : PCI Bus :01
dfebfd00-dfebfdff : :00:1e.2
  dfebfd00-dfebfdff : Intel ICH6
dfebfe00-dfeb : :00:1e.2
  dfebfe00-dfeb : Intel ICH6
dfec-dfef : :00:02.0
dff0-dff7 : :00:02.0
dff8-dfff : :00:02.1
e000-efff : PCI MMCONFIG  [bus 00-ff]
  e000-efff : reserved
e000-efff : pnp 00:09
fec0-fed003ff : reserved
  fec0-fec003ff : IOAPIC 0
  fed0-fed003ff : HPET 0
fed2-fed9 : reserved
  fed2-fed9 : pnp 00:08
feda-fedacfff : pnp 00:09
fee0-feef : reserved
  fee0-feef : pnp 00:08
fee0-fee00fff : Local APIC
ffa80800-ffa80bff : :00:1d.7
  ffa80800-ffa80bff : ehci_hcd
ffb0- : reserved
  ffb0-ffbf : pnp 00:08
  ffc0- : pnp 00:08
[milindm at milindm-desktop linux-2.6.39]$

Regards,
Milind
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/6f5fd735/attachment-0001.htm>
-- next part --
00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory 
Controller Hub (rev 04)
Subsystem: Dell Device 0179
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp

00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express Root 
Port (rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: Intel Corporation Device 
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c  Data: 4149
Capabilities: [a0] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, 
L1 <1us
ExtTag- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency 
L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled+ Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- 
CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 000

[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm

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

--- Comment #6 from Rune K. Svendsen  2011-05-25 
12:34:00 PDT ---
Created an attachment (id=47160)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47160)
Second output of running 'thread apply all bt full' in gdb after attaching to
frozen/hung compiz

It just happened again.
I did a 'thread apply all bt full' again, and I can see that the output isn't
the same as the previous time. So I'm attaching this output in case it's
relevant.

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

[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm

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

--- Comment #5 from Rune K. Svendsen  2011-05-25 
12:27:24 PDT ---
Created an attachment (id=47157)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47157)
Output of running 'thread apply all bt full' in gdb after attaching to
frozen/hung compiz

(In reply to comment #3)
> Looks like it's hanging when trying to acquire the radeon->bo_handles_mutex .
> Does running
> 
>  thread apply all bt full
> 
> in gdb give backtraces for any other threads?

I'm attaching the output of that command here.
Please let me know if I'm missing any relevant debug symbols. I can see a lot
of the loaded libraries don't have debug symbols, so please let me know which
are relevant, if any.

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

[Bug 37193] Crash while switching between OpenGL window and other window

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

--- Comment #6 from Mathias Brodala  2011-05-25 12:09:16 
PDT ---
Any idea how I at least could prevent the sudden reboots to be able to gather
some debugging data?

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

connector - encoder relationship

On Wed, May 25, 2011 at 4:36 AM, Sascha Hauer  wrote:
> Hi All,
>
> I'm currently looking into implementing a SoC graphics core with KMS.
>
> What I wonder about is the relationship between connectors and encoders.
> On my board I have a sii9022 HDMI encoder connected via i2c. This chip
> supports reading edid data, tracks the connection status of the display
> and needs to be configured when the resolution changes. So my first
> guess is that I have to implement an encoder. looking at struct
> drm_encoder_funcs there are no callbacks suitable for this. struct
> drm_connector_funcs on the other hand has all the callbacks I need.
> Now I look at drivers/gpu/drm/i2c. The drivers there implement a
> drm_encoder_slave which also has all the callbacks I need. So from
> one point of view the functions should be implemented in the connector,
> while in the i2c case it's implemented in the (slave-) encoder.
> Generally I have the feeling that my sii9022 should be both an encoder
> and a connector, but this doesn't fit into the current scheme.
>
> I'm confused. Could someone clarify this a bit?

The general idea is this:
framebuffer -> crtc -> encoder -> connector -> monitor

- The framebuffer is just a buffer vram that has an image encoded in
it as an array of pixels.
- The crtc reads the data out of the framebuffer and generates the
video mode timing in conjunction with a PLL.  The crtc also determines
what part of the framebuffer is read; e.g., when multi-head is
enabled, each crtc scans out of a different part of vram; in clone
mode, each crtc scans out of the same part of vram.
- The encoder takes the digital bitstream from the crtc and converts
it to the appropriate analog levels for transmission across the
connector to the monitor.
- The connector provides the appropriate physical plug (HDMI, DVI-D,
VGA, S-video, etc.) for the monitor to connect to.

crtcs are usually routeable and can be connected to one or many
encoders simultaneously.  The encoders can also be connected to one or
more connectors (e.g., you might have a single TMDS encoder that is
connected to the digital portion of a DVI-I port and also to a HDMI
port, or you might have a DAC that is connected to a VGA port and an
S-video port).  Finally i2c lines are associated with connectors,
since generally the i2c pins are wired to the connector and in many
cases, each connectors has it's own i2c line.  For example, you might
have a single TMDS encoder that is wired to a DVI-D port with its own
i2c line and an HDMI port with its own i2c line.  Each connector may
have it's own hotplug (HPD) pin as well.  That way you could query the
EDID from each connector separately for example.

Is the sii9022 being driven by the output of a DVO encoder from your
display hw?  If so your display path would look like:

crtc -> DVO (master encoder) -> sii9022 (slave encoder) -> HDMI plug -> monitor

The general GPU driver might register the i2c buses that are used by
the various parts (encoder, connector), then it's just a matter of
plugging in the right parts for each component (e.g. you'd hook up the
sii9022 i2c control bus to the DVO encoder, and the ddc i2c bus to the
hdmi connector object, etc.).

I hope this helps.

>
> Thanks
> ?Sascha
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917- |
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

On Wed, May 25, 2011 at 8:29 AM, Frank van Maarseveen
 wrote:
> Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes
> immediately upon start.
>

Any reason you are not using kms?

Alex

> lspci excerpt:
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon 
> X1300/X1550 Series]
> 01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] 
> (Secondary)
>
> /var/log/messages excerpt:
> [drm] Setting GART location based on new memory map
> [drm] Loading R500 Microcode
> [drm] Num pipes: 1
> [drm] writeback test succeeded in 1 usecs
> [drm] Num pipes: 1
> BUG: unable to handle kernel paging request at 6b6b6b6b
> IP: [] radeon_read_ring_rptr+0x19/0x30
> *pdpt = 335ab001 *pde = 
> Oops:  [#1] PREEMPT SMP
> last sysfs file: /sys/devices/pci:00/:00:01.0/:01:00.0/enable
> Modules linked in: [last unloaded: scsi_wait_scan]
> May 25 12:23:58 lokka kernel:
> Pid: 4484, comm: X Not tainted 2.6.39-x255 #1 Dell Inc. ? ? ? ? ? ? ? ? Dell 
> DXP051 ? ? ? ? ? ? ? ? ?/0FJ030
> EIP: 0060:[] EFLAGS: 00213202 CPU: 1
> EIP is at radeon_read_ring_rptr+0x19/0x30
> EAX: f3484be0 EBX: f569baa0 ECX: 000a EDX: 6b6b6b6b
> ESI: f85e5000 EDI: 0040 EBP: f37a1d0c ESP: f37a1d08
> DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
> Process X (pid: 4484, ti=f37a task=f378b3c0 task.ti=f37a)
> Stack:
> c1377387 f37a1d1c c1377b86 f569baa0 0010 f37a1d44 c137a0be 0001
> c1a8a2f7 c188cb8a c1a648c4 f6424d60 f569baa0   f37a1d58
> c137c7cf f569bbb0 f569baa0 f569baa0 f37a1d6c c137c9b7 f569bab4 f569bbe0
> Call Trace:
> [] ? radeon_get_ring_head+0x47/0x50
> [] radeon_commit_ring+0x56/0xb0
> [] radeon_do_cp_idle+0xce/0x170
> [] radeon_apply_surface_regs+0x2f/0x150
> [] free_surface+0xc7/0x100
> [] radeon_driver_lastclose+0x45/0x60
> [] drm_lastclose+0x40/0x2b0
> [] ? drm_release+0x344/0x460
> [] drm_release+0x376/0x460
> [] __fput+0xa9/0x1c0
> [] fput+0x1f/0x30
> [] filp_close+0x4d/0x80
> [] put_files_struct+0x76/0xe0
> [] exit_files+0x42/0x60
> [] do_exit+0x231/0x320
> [] do_group_exit+0x33/0x90
> [] ? sub_preempt_count+0x7b/0xa0
> [] get_signal_to_deliver+0x17d/0x2a0
> [] do_notify_resume+0xc0/0x180
> [] ? mntput+0x13/0x30
> [] ? __fput+0x12f/0x1c0
> [] ? get_parent_ip+0xb/0x40
> [] ? sub_preempt_count+0x7b/0xa0
> [] ? _raw_spin_unlock_irq+0x18/0x40
> [] ? sigprocmask+0x70/0xf0
> [] ? sys_rt_sigprocmask+0xd4/0xf0
> [] ? sys_rt_sigprocmask+0xd4/0xf0
> [] work_notifysig+0x13/0x1b
> Code: fe ff 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 f6 80 3a 03 00 
> 00 08 89 e5 75 14 8b 80 e0 00 00 00 83 e2 fc 5d 03 50 14 <8b> 02 c3 8d 74 26 
> 00 8b 80 e0 00 00 00 03 50 14 8b 02 5d c3 8d
> EIP: [] radeon_read_ring_rptr+0x19/0x30 SS:ESP 0068:f37a1d08
> CR2: 6b6b6b6b
> ---[ end trace 9a6c2c396ea040f5 ]---
> Fixing recursive fault but reboot is needed!
>
> /var/log/Xorg.0.log:
> [ ? 111.905] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
> [ ? 111.906] _XSERVTransOpen: transport open failed for 
> inet6/lokka.tasking.nl:0
> [ ? 111.906] _XSERVTransMakeAllCOTSServerListeners: failed to open listener 
> for inet6
> [ ? 111.917]
> X.Org X Server 1.9.5
> Release Date: 2011-03-17
> [ ? 111.917] X Protocol Version 11, Revision 0
> [ ? 111.917] Build Operating System: x86-01 2.6.32-71.14.1.el6.x86_64
> [ ? 111.917] Current Operating System: Linux lokka.tasking.nl 2.6.39-x255 #1 
> SMP PREEMPT Wed May 25 10:34:33 CEST 2011 i686
> [ ? 111.917] Kernel command line: initrd=initrd nomodules panic=60 
> nmi_watchdog=1 netconsole=@172.17.1.124/,514 at 172.17.1.64/00:12:3f:85:17:52 
> BOOT_IMAGE=linux-2.6.39-x255
> [ ? 111.917] Build Date: 18 March 2011 ?12:23:01AM
> [ ? 111.917] Build ID: xorg-x11-server 1.9.5-1.fc14
> [ ? 111.918] Current version of pixman: 0.18.4
> [ ? 111.918] ? ?Before reporting problems, check http://wiki.x.org
> ? ? ? ?to make sure that you have the latest version.
> [ ? 111.918] Markers: (--) probed, (**) from config file, (==) default 
> setting,
> ? ? ? ?(++) from command line, (!!) notice, (II) informational,
> ? ? ? ?(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [ ? 111.918] (==) Log file: "/var/log/Xorg.0.log", Time: Wed May 25 12:23:57 
> 2011
> [ ? 111.964] (==) Using config directory: "/etc/X11/xorg.conf.d"
> [ ? 111.964] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> [ ? 111.981] (==) No Layout section. ?Using the first Screen section.
> [ ? 111.981] (==) No screen section available. Using defaults.
> [ ? 111.981] (**) |-->Screen "Default Screen Section" (0)
> [ ? 111.981] (**) | ? |-->Monitor ""
> [ ? 111.982] (==) No monitor specified for screen "Default Screen Section".
> ? ? ? ?Using a default monitor configuration.
> [ ? 111.982] (==) Automatically adding devices
> [ ? 111.982] (==) Automatically enabling devices
> [ ? 111.983] (==) FontPath set to:
> ? ? ? ?catalogue:/etc/X11/fontpath.d,
> ? ? ? ?built-ins
> [ ? 111.983] (==) ModulePath set to

(Short?) merge window reminder

2011-05-25 Thread Emil Langrock

On Tuesday 24 May 2011 23:05:30 Jan Engelhardt wrote:
> On Tuesday 2011-05-24 20:48, eschvoca wrote:
> >On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
> >> It's not about features. It hasn't been about features for forever.
> >
> >Using the date also clearly communicates it is not about features.
> 
> On the contrary: Whenever a 2.6.x release was set out the door, there
> was at least one new feature in the cycle. Given the endless manpower
> that seems to trail Linux, that seems unlikely to change in the near
> term.
> 
> On "It is not about features" - it is not /just/ about features - it
> is also about fixes, which are equally important, and they also
> warrant a version bump of some sort on their own. Pointing out the
> obvious, the stable serieses.

You are mixing up features based versioning and identifier for versions. Linux 
has no feature based concept for most parts of their version number (only the 
patch part clearly states: fixes, fixes, fixes). We only need something that 
is easily readable and maybe has no extreme weird meaning that leads to false 
conclusions. And yes, that is what eschvoca meant and not something like 
"linux is stagnating".

> "Fleeing" to date-based version numbering seems like an excuse
> for making way for releases without any change whatsoever.
> (IOW, if there were features/fixes, a non-date based scheme of
> incremental numbers could indicate them already.)

Yes, that is usally the case... release the same source tarball again and 
again. I always had that feeling when looking at those wine, ubuntu, gentoo, 
ms, texlive, iasl, hugin, u-boot, ... developers. They are doing nothing the 
whole day and the marketing department does everything.

> >Me, a nobody end user, would prefer a version number that corresponded
> >to the date.  Something like:
> >
> >%y.%m.
> >%Y.%m.
> 
> Except that LINUX_KERNEL_VERSION has only 8 bits for each,
> so 2011 is out of range, which would need to kept in mind.
> And a 2-digit spec.. nah that does not feel very 100-year
> proof. (Just look at struct tm.tm_year for the mess 2-digits
> made technically.)

What is LINUX_KERNEL_VERSION? I only know LINUX_VERSION_CODE and 
KERNEL_VERSION

And the calculation behind it is following:

(((a) << 16) + ((b) << 8) + (c))

So for KERNEL_VERSION(2,6,40) we would get 0x20628 and for 
KERNEL_VERSION(2011,2,0) we would get 0x07DB0200. Of course our 
grandgrandgrand...grand children would die in agony in the year 65536.

And maybe (probably the module version check guys will kill me) could use a 
compressed version of that without hurding the comparison function in out of 
kernel modules. KERNEL_VERSION_Y(a,b) would be defined as

#define KERNEL_VERSION_Y(a,b) ({typeof (a) _a = a; \
typeof (b) _b = b; \
KERNEL_VERSION(_a >> 8, _a & 0xff, _b); })

This would bring us to the year 16777216 before everybody gets punched in his 
private parts by the versioning scheme. It is also possible to get more out of 
32 bits when we can assume that Linus or his grandgrand...grand children will 
never do more than 128 releases a year.

But yes, I aggree not to use 2 digit numbers for years unless we want to 
start the y2k+100 problem here.

> >Then users would know the significance of the number and when a vendor
> >says they support Linux 11.09 the user will immediately know if they
> >are up to date.
> 
> An added issue with that would be that numbers would not increase in
> same-sized steps anymore and leave gaps. (There would probably be no
> 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)

Ok, this is really a good example why we should not use the month for 
releases, but an ever increasing number until the first number is also 
increased which resets the second number to 0.

Kind regards,
Emil

i915 and boot freeze

2011-05-25 Thread Yermandu Patapitafious

Hello Jean,

Thanks for answer, i will take more atention in subjects,

> What is the last kernel that works for you?
>
> Are you running self-built or distribution kernels?
> Can we please see the kernel configuration file?

My Last kernel working from git repository was 2.6.38-rc8+, the stable
line .38.X work fines.
I use the git version from kernel.org site pull and build manually be
me. The Latest Stable Kernel is from gentoo-sources, and i always
compile manually too.
I have attached .config kernel in mail.

> It would be great
> if you were able to get us the kernel logs in a text form, using some
> form of serial console.

Removing the CONFIG_I2C_CHARDEV has not effect, the panic continues
happing I looking for some way to send panic log in text, but no
success yet.



-- 
yermandu
-- next part --
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 101119 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/3f09f604/attachment-0001.obj>

connector - encoder relationship

2011-05-25 Thread Sascha Hauer

Hi All,

I'm currently looking into implementing a SoC graphics core with KMS.

What I wonder about is the relationship between connectors and encoders.
On my board I have a sii9022 HDMI encoder connected via i2c. This chip
supports reading edid data, tracks the connection status of the display
and needs to be configured when the resolution changes. So my first
guess is that I have to implement an encoder. looking at struct
drm_encoder_funcs there are no callbacks suitable for this. struct
drm_connector_funcs on the other hand has all the callbacks I need.
Now I look at drivers/gpu/drm/i2c. The drivers there implement a
drm_encoder_slave which also has all the callbacks I need. So from
one point of view the functions should be implemented in the connector,
while in the i2c case it's implemented in the (slave-) encoder.
Generally I have the feeling that my sii9022 should be both an encoder
and a connector, but this doesn't fit into the current scheme.

I'm confused. Could someone clarify this a bit?

Thanks
 Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[patch] drm/i915: fix if statement in ivybridge irq handler

2011-05-25 Thread Keith Packard

On Wed, 25 May 2011 12:56:56 +0300, Dan Carpenter  wrote:

> The extra semicolon was not intended.
> 
> Signed-off-by: Dan Carpenter 

Merged to drm-intel-next.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110525/f2220e75/attachment.pgp>

[Bug 31532] [RADEON:KMS:RV670:AGP:R600C-R600G] PCIE gart stalls

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

Andy Furniss  changed:

   What|Removed |Added

Summary|[RADEON:KMS:RV670:AGP:R600C |[RADEON:KMS:RV670:AGP:R600C
   |-R600G] rv670 AGP gart +|-R600G] PCIE gart stalls
   |gallium - GPU lockups. PCIE |
   |gart runs but stalls|

--- Comment #4 from Andy Furniss  2011-05-25 
08:11:21 PDT ---
Running agpgart with gallium is now fixed and runs without stalls since

r600g: bump domain selection up one layer.
ecc051d65b6e17115439fb3609cccfd59f6272bf

Running with agpmode=-1 + gallium is better than it was, all demos are stall
free apart from fbo_firecube, but nexuiz still stalls badly.

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

(Short?) merge window reminder

2011-05-25 Thread Lisa Milne

> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.

How about stardates? That'd make a release made now 64860.8

I really should sleep more...

-- 
Lisa Milne

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

--- Comment #8 from Maggioni Marcello  2011-05-25 
03:46:01 PDT ---
An update.

I noticed that in fullscreen the problem is not present with the new drivers
(no corruption at the bottom of the screen) , but the problem with the white
dots persists.
I also noticed that these dots are in random locations, but they surround point
light sources like candles. I thought they were random, because you can see
them trough walls , so the candles generating the dots were not directly
visible, but behind the wall and I haven't immediatly connected this problem
with the lights.

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

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

--- Comment #7 from Maggioni Marcello  2011-05-25 
02:48:12 PDT ---
Created an attachment (id=47128)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47128)
Problem

This is the screenshot where the problem is present

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

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

Maggioni Marcello  changed:

   What|Removed |Added

  Attachment #46494|0   |1
is obsolete||

--- Comment #6 from Maggioni Marcello  2011-05-25 
02:46:50 PDT ---
Created an attachment (id=47127)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=47127)
No problem

This is the screenshot where the problem is not present.

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

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

--- Comment #5 from Maggioni Marcello  2011-05-25 
02:45:09 PDT ---
I tried the RenderTest and it seemed to work fine (the SSAO test was completely
white though) .

I tried the latest git today and then tested Amnesia again.

The situation is improved. The game is not bug free, but now the black area in
the bottom of the screen has been substituted by a white area that is present
only under certain lighting conditions (I've attached two screenshots , one in
which the problem isn't present and one in which it is). Also, when present the
"disturbance" flickers at a very high frequency, so it's quite difficult to
capture it in a screenshot (you catch it while it is appearing or disappearing
on the screen very often), so it is bigger than the one that can be seen in the
screenshot.

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

[PATCH 2/2] drm/radeon/kms: add blit support for cayman

Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/cayman_blit_shaders.c |  326 -
 drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
 drivers/gpu/drm/radeon/evergreen_blit_kms.c  |  505 ++
 drivers/gpu/drm/radeon/ni.c  |   13 +-
 drivers/gpu/drm/radeon/radeon_asic.c |6 +-
 5 files changed, 598 insertions(+), 255 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c 
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@

 const u32 cayman_default_state[] =
 {
-   /* XXX fill in additional blit state */
+   0xc0066900,
+   0x,
+   0x0060, /* DB_RENDER_CONTROL */
+   0x, /* DB_COUNT_CONTROL */
+   0x, /* DB_DEPTH_VIEW */
+   0x002a, /* DB_RENDER_OVERRIDE */
+   0x, /* DB_RENDER_OVERRIDE2 */
+   0x, /* DB_HTILE_DATA_BASE */

0xc0026900,
-   0x0316,
-   0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
-   0x0010, /*  */
+   0x000a,
+   0x, /* DB_STENCIL_CLEAR */
+   0x, /* DB_DEPTH_CLEAR */
+
+   0xc0036900,
+   0x000f,
+   0x, /* DB_DEPTH_INFO */
+   0x, /* DB_Z_INFO */
+   0x, /* DB_STENCIL_INFO */
+
+   0xc0016900,
+   0x0080,
+   0x, /* PA_SC_WINDOW_OFFSET */
+
+   0xc00d6900,
+   0x0083,
+   0x, /* PA_SC_CLIPRECT_RULE */
+   0x, /* PA_SC_CLIPRECT_0_TL */
+   0x20002000, /* PA_SC_CLIPRECT_0_BR */
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x, /* PA_SC_EDGERULE */
+   0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+   0x000f, /* CB_TARGET_MASK */
+   0x000f, /* CB_SHADER_MASK */
+
+   0xc0226900,
+   0x0094,
+   0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+   0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x, /* PA_SC_VPORT_ZMIN_0 */
+   0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+   0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */

0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+   0xc0096900,
+   0x0100,
+   0x00ff, /* VGT_MAX_VTX_INDX */
+   0x, /* VGT_MIN_VTX_INDX */
+   0x, /* VGT_INDX_OFFSET */
+   0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+   0x, /* SX_ALPHA_TEST_CONTROL */
+   0x, /* CB_BLEND_RED */
+   0x, /* CB_BLEND_GREEN */
+   0x, /* CB_BLEND_BLUE */
+   0x, /* CB_BLEND_ALPHA */
+
+   0xc0016900,
+   0x0187,
+   0x0100, /* SPI_VS_OUT_ID_0 */
+
+   0xc0026900,
+   0x0191,
+   0x0100, /* SPI_PS_INPUT_CNTL_0 */
+   0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+   0xc0016900,
+   0x01b1,
+   0x, /* SPI_VS_OUT_CONFIG */
+
+   0xc0106900,
+   0x01b3,
+   0x2001, /* SPI_PS_IN_CONTROL_0 */
+   0x, /* SPI_PS_IN_CONTROL_1 */
+   0x, /* SPI_INTERP_CONTROL_0 */
+   0x, /* SPI_INPUT_Z */
+   0x, /* SPI_FOG_CNTL */
+   0x0010, /* SPI_BARYC_CNTL */
+   0x, /* SPI_PS_IN_CONTROL_2 */
+   0x, /* SPI_COMPUTE_INPUT_CNTL */
+   0x, /* SPI_COMPUTE_NUM_THREAD_X */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+   0x, /* SPI_GPR_MGMT */
+   0x, /* SPI_LDS_MGMT */
+   0x, /* SPI_STACK_MGMT */
+   0x, /* SPI_WAVE_MGMT_1 */
+   0x, /* SPI_WAVE_MGMT_2 */
+
+   0xc0016900,
+   0x01e0,
+   0x, /* CB_BLEND0_CONTROL */
+
+   0xc00e6900,
+   0x0200,
+   0x, /* DB_DEPTH_CONTROL */
+   0x, /* DB_EQAA */
+   0x00cc0010, /* CB_COLOR_CONTROL */
+   0x0210, /* DB_SHADER_CONTROL */
+   0x0001, /* PA_CL_CLIP_CNTL */
+   0x0004, /* PA_SU_SC_MODE_CNTL

[PATCH 1/2] drm/radeon/kms/blit: workaround some hw issues on evergreen+

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index ba06a69..4086729 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -199,6 +199,16 @@ static void
 set_scissors(struct radeon_device *rdev, int x1, int y1,
 int x2, int y2)
 {
+   /* workaround some hw bugs */
+   if (x2 == 0)
+   x1 = 1;
+   if (y2 == 0)
+   y1 = 1;
+   if (rdev->family == CHIP_CAYMAN) {
+   if ((x2 == 1) && (y2 == 1))
+   x2 = 2;
+   }
+
radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONTEXT_REG, 2));
radeon_ring_write(rdev, (PA_SC_SCREEN_SCISSOR_TL - 
PACKET3_SET_CONTEXT_REG_START) >> 2);
radeon_ring_write(rdev, (x1 << 0) | (y1 << 16));
-- 
1.7.1.1

(Short?) merge window reminder

2011-05-25 Thread Hans-Peter Jansen

On Monday 23 May 2011, 22:33:48 Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar  wrote:
> > I really hope there's also a voice that tells you to wait until .42
> > before cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.
>
> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
> fairly nice round number.
>
> There's also the timing issue - since we no longer do version numbers
> based on features, but based on time, just saying "we're about to
> start the third decade" works as well as any other excuse.

But hey, do you really want to release a Linux 3.0 kernel without 
serious layered filesystem functionality? 

Shame on you,
Pete

PS.: Sorry for being such a pest in this regard, but filesystem layering 
is one of the most important missing bits to excel out of the box in
 * live distros 
 * diskless computing
 * flash based systems
Even the linux based commercial PBX solution (mobydick), I bought, ships 
with it.
PPS.: Bad timing, I know, but I'm glad, that Al is back to life again..

[PATCH] drivers: Use kzalloc instead of 'kmalloc+memset', where possible.

2011-05-25 Thread Rakib Mullick

On Tue, May 24, 2011 at 11:09 PM, Joe Perches  wrote:

> On Tue, 2011-05-24 at 22:59 +0600, Rakib Mullick wrote:
> > On 5/23/11, Joe Perches  wrote:
> > > On Mon, 2011-05-23 at 23:40 +0600, Rakib Mullick wrote:
> > >> Following patch removes the uses of 'kmalloc+memset' from various
> > >> drivers subsystems, which is replaced by kzalloc. kzalloc take care of
> > >> setting allocated memory with null, so it helps to get rid from using
> > >> memset.
> > >> diff --git a/drivers/gpu/drm/drm_scatter.c
> b/drivers/gpu/drm/drm_scatter.c
> > > []
> > >> -  entry->pagelist = kmalloc(pages * sizeof(*entry->pagelist),
> GFP_KERNEL);
> > >> +  entry->pagelist = kzalloc(pages * sizeof(*entry->pagelist),
> GFP_KERNEL);
> > > Perhaps it's better to use:
> > > entry->pagelist =  kcalloc(pages, sizeof(*entry->pagelist),
> GFP_KERNEL);
> > >> -  entry->busaddr = kmalloc(pages * sizeof(*entry->busaddr),
> GFP_KERNEL);
> > >> +  entry->busaddr = kzalloc(pages * sizeof(*entry->busaddr),
> GFP_KERNEL);
> > > here too.
> > Is there any significant benefit of using kcalloc here?
>
> Overflow and tradition.
>
> static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
> {
>if (size != 0 && n > ULONG_MAX / size)
>return NULL;
>return __kmalloc(n * size, flags | __GFP_ZERO);
> }
>
> It's been used for allocating memory for an array. Maybe, using kcalloc in
entry->pagelist could be useful. But, not that much sure though. There's no
problem with current implementation.

This patch touches few drivers subsystems, they are added to the CC list.

Thanks,
Rakib

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-- next part --
An HTML attachment was scrubbed...
URL:

(Short?) merge window reminder

2011-05-25 Thread Jan Engelhardt

On Tuesday 2011-05-24 20:48, eschvoca wrote:
>On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
>>
>> It's not about features. It hasn't been about features for forever.
>
>Using the date also clearly communicates it is not about features.

On the contrary: Whenever a 2.6.x release was set out the door, there
was at least one new feature in the cycle. Given the endless manpower
that seems to trail Linux, that seems unlikely to change in the near
term.

On "It is not about features" - it is not /just/ about features - it
is also about fixes, which are equally important, and they also
warrant a version bump of some sort on their own. Pointing out the
obvious, the stable serieses.

"Fleeing" to date-based version numbering seems like an excuse
for making way for releases without any change whatsoever.
(IOW, if there were features/fixes, a non-date based scheme of
incremental numbers could indicate them already.)

>Me, a nobody end user, would prefer a version number that corresponded
>to the date.  Something like:
>
>%y.%m.
>%Y.%m.

Except that LINUX_KERNEL_VERSION has only 8 bits for each,
so 2011 is out of range, which would need to kept in mind.
And a 2-digit spec.. nah that does not feel very 100-year
proof. (Just look at struct tm.tm_year for the mess 2-digits
made technically.)

>Then users would know the significance of the number and when a vendor
>says they support Linux 11.09 the user will immediately know if they
>are up to date.

An added issue with that would be that numbers would not increase in
same-sized steps anymore and leave gaps. (There would probably be no
11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)

My 2?.

Re: (Short?) merge window reminder

2011-05-25 Thread Jan Engelhardt


On Tuesday 2011-05-24 17:46, Ralf Baechle wrote:
On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote:

 Can we drop most of MCA, EISA and ISA bus if we are going to have a big
 version change ? A driver spring clean is much overdue and it's all in
 git in case someone wishes to sneak out at midnight and bring some crawly
 horror back from the dead.

Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a
few others still refuse hard to die.  

Is it worth to setup a system to track success / failure reports for
drivers and ditch drivers once there are no success reports for a driver
for too long?  It may not be a good idea - people tend not report success
much more rarely than failure.

(On that matter, I wonder if there are 5.25 USB floppy drives ...)

If there were, they would appear as Mass Storage devices (at least
the 3.5 USB floppy gadgets do), and as such, don't depend on ISA
or the classic floppy driver at all.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-25 Thread Lisa Milne

 So I'm toying with 3.0 (and in that case, it really would be 3.0,
 not 3.0.0 - the stable team would get the third digit rather than
 the fourth one.

How about stardates? That'd make a release made now 64860.8

I really should sleep more...

-- 
Lisa Milne l...@ltmnet.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-25 Thread Ralf Baechle

On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote:

  So I'm toying with 3.0 (and in that case, it really would be 3.0,
  not 3.0.0 - the stable team would get the third digit rather than
  the fourth one.
 
 If we change from 2.6.X to 3.X, then if we don't change anything else,
 then successive stable release will cause the LINUX_VERSION_CODE to be
 incremented.  This isn't necessary bad, but it would be a different
 from what we have now.

It will require another bunch of changes to scripts that try to make sense
out of kernel Linux version numbers.  It's a minor issue and we might be
better off doing something else than version number magic.  Not last a
new major version number raises expectations - whatever those might be.

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

Re: (Short?) merge window reminder

2011-05-25 Thread Ralf Baechle

On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote:

 Can we drop most of MCA, EISA and ISA bus if we are going to have a big
 version change ? A driver spring clean is much overdue and it's all in
 git in case someone wishes to sneak out at midnight and bring some crawly
 horror back from the dead.

Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a
few others still refuse hard to die.  

Is it worth to setup a system to track success / failure reports for
drivers and ditch drivers once there are no success reports for a driver
for too long?  It may not be a good idea - people tend not report success
much more rarely than failure.

(On that matter, I wonder if there are 5.25 USB floppy drives ...)

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

Re: [PATCH] drivers: Use kzalloc instead of 'kmalloc+memset', where possible.

2011-05-25 Thread Rakib Mullick

On Tue, May 24, 2011 at 11:09 PM, Joe Perches j...@perches.com wrote:

 On Tue, 2011-05-24 at 22:59 +0600, Rakib Mullick wrote:
  On 5/23/11, Joe Perches j...@perches.com wrote:
   On Mon, 2011-05-23 at 23:40 +0600, Rakib Mullick wrote:
   Following patch removes the uses of 'kmalloc+memset' from various
   drivers subsystems, which is replaced by kzalloc. kzalloc take care of
   setting allocated memory with null, so it helps to get rid from using
   memset.
   diff --git a/drivers/gpu/drm/drm_scatter.c
 b/drivers/gpu/drm/drm_scatter.c
   []
   -  entry-pagelist = kmalloc(pages * sizeof(*entry-pagelist),
 GFP_KERNEL);
   +  entry-pagelist = kzalloc(pages * sizeof(*entry-pagelist),
 GFP_KERNEL);
   Perhaps it's better to use:
   entry-pagelist =  kcalloc(pages, sizeof(*entry-pagelist),
 GFP_KERNEL);
   -  entry-busaddr = kmalloc(pages * sizeof(*entry-busaddr),
 GFP_KERNEL);
   +  entry-busaddr = kzalloc(pages * sizeof(*entry-busaddr),
 GFP_KERNEL);
   here too.
  Is there any significant benefit of using kcalloc here?

 Overflow and tradition.

 static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
 {
if (size != 0  n  ULONG_MAX / size)
return NULL;
return __kmalloc(n * size, flags | __GFP_ZERO);
 }

 It's been used for allocating memory for an array. Maybe, using kcalloc in
entry-pagelist could be useful. But, not that much sure though. There's no
problem with current implementation.

This patch touches few drivers subsystems, they are added to the CC list.

Thanks,
Rakib


 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

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

Re: (Short?) merge window reminder

2011-05-25 Thread Matthias Schniedermeyer

On 23.05.2011 13:33, Linus Torvalds wrote:
 On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote:
 
  I really hope there's also a voice that tells you to wait until .42 before
  cutting 3.0.0! :-)
 
 So I'm toying with 3.0 (and in that case, it really would be 3.0,
 not 3.0.0 - the stable team would get the third digit rather than
 the fourth one.

What about strictly 3 part versions? Just add a .0.

3.0.0 - Release Kernel 3.0
3.0.1 - Stable 1
3.0.2 - Stable 2
3.1.0 - Release Kernel 3.1
3.1.1 - Stable 1
...

Biggest problem is likely version phobics that get pimples when they see 
trailing zeros. ;-)




Bis denn

-- 
Real Programmers consider what you see is what you get to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a you asked for it, you got it text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

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

Re: (Short?) merge window reminder

2011-05-25 Thread david


On Tue, 24 May 2011, Matthias Schniedermeyer wrote:


On 23.05.2011 13:33, Linus Torvalds wrote:

On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote:


I really hope there's also a voice that tells you to wait until .42 before
cutting 3.0.0! :-)


So I'm toying with 3.0 (and in that case, it really would be 3.0,
not 3.0.0 - the stable team would get the third digit rather than
the fourth one.


What about strictly 3 part versions? Just add a .0.

3.0.0 - Release Kernel 3.0
3.0.1 - Stable 1
3.0.2 - Stable 2
3.1.0 - Release Kernel 3.1
3.1.1 - Stable 1
...

Biggest problem is likely version phobics that get pimples when they see
trailing zeros. ;-)


since there are always issues discovered with a new kernel is released 
(which is why the -stable kernels exist), being wary of .0 kernels is not 
neccessarily a bad thing.


I still think a date based approach would be the best.

since people are worried about not knowing when a final release will 
happen, base the date on when the merge window opened or closed (always 
known at the time of the first -rc kernel)


in the thread on lwn, people pointed out that the latest 2.6.32 kernel 
would still be a 2009.12.X which doesn't reflect the fact that it was 
released this month. My suggestion for that is to make the X be the number 
of months (or years.months if you don't like large month values) between 
the merge window and the release of the -stable release. This would lead 
to a small problem when there are multiple -stable releases in a month, 
but since that doesn't last very long I don't see a real problem with just 
incramenting the month into the future in those cases.


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

Re: (Short?) merge window reminder

2011-05-25 Thread Emil Langrock

Linus Torvalds wrote:
 PS. The voices in my head also tell me that the numbers are getting
 too big. I may just call the thing 2.8.0. And I almost guarantee that
 this PS is going to result in more discussion than the rest, but when
 the voices tell me to do things, I listen.

Correct :)

I would still prefer the version number change to something like 2011.0 - 
already proposed at http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux

I don't think that it is reasonable to say that it is bad because third party 
scripts would break - they would break anyway (I would bet that many of them 
don't expect to see 3.x anyway). And changing now to 3.0 and then incrementing 
the second one everytime for 10 years will also lead to something like 3.56.7. 
I would also say that defining the release number using the time of the merge 
window start/end is easy understandable. 2.6.40 would be the third 
development cycle this year aka v2011.2 or v2011.2.0 when the patchlevel 
should always be included.
-- 
Emil Langrock
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-25 Thread Zimny Lech

Hi,

2011/5/24 Lisa Milne l...@ltmnet.com:
 So I'm toying with 3.0 (and in that case, it really would be 3.0,
 not 3.0.0 - the stable team would get the third digit rather than
 the fourth one.

 How about stardates?

This is a wonderful idea! :)

 That'd make a release made now 64860.8

 I really should sleep more...

 --
 Lisa Milne l...@ltmnet.com
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/




-- 
Slawa!
Zimny Lech z Wawelu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-25 Thread Jan Engelhardt


On Tuesday 2011-05-24 20:48, eschvoca wrote:
On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:

 It's not about features. It hasn't been about features for forever.

Using the date also clearly communicates it is not about features.

On the contrary: Whenever a 2.6.x release was set out the door, there
was at least one new feature in the cycle. Given the endless manpower
that seems to trail Linux, that seems unlikely to change in the near
term.

On It is not about features - it is not /just/ about features - it
is also about fixes, which are equally important, and they also
warrant a version bump of some sort on their own. Pointing out the
obvious, the stable serieses.

Fleeing to date-based version numbering seems like an excuse
for making way for releases without any change whatsoever.
(IOW, if there were features/fixes, a non-date based scheme of
incremental numbers could indicate them already.)


Me, a nobody end user, would prefer a version number that corresponded
to the date.  Something like:

%y.%m.stable patch
%Y.%m.stable patch

Except that LINUX_KERNEL_VERSION has only 8 bits for each,
so 2011 is out of range, which would need to kept in mind.
And a 2-digit spec.. nah that does not feel very 100-year
proof. (Just look at struct tm.tm_year for the mess 2-digits
made technically.)

Then users would know the significance of the number and when a vendor
says they support Linux 11.09 the user will immediately know if they
are up to date.

An added issue with that would be that numbers would not increase in
same-sized steps anymore and leave gaps. (There would probably be no
11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)


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

Re: (Short?) merge window reminder

2011-05-25 Thread Hans-Peter Jansen

On Monday 23 May 2011, 22:33:48 Linus Torvalds wrote:
 On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote:
  I really hope there's also a voice that tells you to wait until .42
  before cutting 3.0.0! :-)

 So I'm toying with 3.0 (and in that case, it really would be 3.0,
 not 3.0.0 - the stable team would get the third digit rather than
 the fourth one.

 But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a
 fairly nice round number.

 There's also the timing issue - since we no longer do version numbers
 based on features, but based on time, just saying we're about to
 start the third decade works as well as any other excuse.

But hey, do you really want to release a Linux 3.0 kernel without 
serious layered filesystem functionality? 

Shame on you,
Pete

PS.: Sorry for being such a pest in this regard, but filesystem layering 
is one of the most important missing bits to excel out of the box in
 * live distros 
 * diskless computing
 * flash based systems
Even the linux based commercial PBX solution (mobydick), I bought, ships 
with it.
PPS.: Bad timing, I know, but I'm glad, that Al is back to life again..
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

connector - encoder relationship

2011-05-25 Thread Sascha Hauer

Hi All,

I'm currently looking into implementing a SoC graphics core with KMS.

What I wonder about is the relationship between connectors and encoders.
On my board I have a sii9022 HDMI encoder connected via i2c. This chip
supports reading edid data, tracks the connection status of the display
and needs to be configured when the resolution changes. So my first
guess is that I have to implement an encoder. looking at struct
drm_encoder_funcs there are no callbacks suitable for this. struct
drm_connector_funcs on the other hand has all the callbacks I need.
Now I look at drivers/gpu/drm/i2c. The drivers there implement a
drm_encoder_slave which also has all the callbacks I need. So from
one point of view the functions should be implemented in the connector,
while in the i2c case it's implemented in the (slave-) encoder.
Generally I have the feeling that my sii9022 should be both an encoder
and a connector, but this doesn't fit into the current scheme.

I'm confused. Could someone clarify this a bit?

Thanks
 Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

--- Comment #5 from Maggioni Marcello haya...@gmail.com 2011-05-25 02:45:09 
PDT ---
I tried the RenderTest and it seemed to work fine (the SSAO test was completely
white though) .

I tried the latest git today and then tested Amnesia again.

The situation is improved. The game is not bug free, but now the black area in
the bottom of the screen has been substituted by a white area that is present
only under certain lighting conditions (I've attached two screenshots , one in
which the problem isn't present and one in which it is). Also, when present the
disturbance flickers at a very high frequency, so it's quite difficult to
capture it in a screenshot (you catch it while it is appearing or disappearing
on the screen very often), so it is bigger than the one that can be seen in the
screenshot.

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

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

Maggioni Marcello haya...@gmail.com changed:

   What|Removed |Added

  Attachment #46494|0   |1
is obsolete||

--- Comment #6 from Maggioni Marcello haya...@gmail.com 2011-05-25 02:46:50 
PDT ---
Created an attachment (id=47127)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47127)
No problem

This is the screenshot where the problem is not present.

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

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

--- Comment #7 from Maggioni Marcello haya...@gmail.com 2011-05-25 02:48:12 
PDT ---
Created an attachment (id=47128)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47128)
Problem

This is the screenshot where the problem is present

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

[patch] drm/i915: fix if statement in ivybridge irq handler

2011-05-25 Thread Dan Carpenter

The extra semicolon was not intended.

Signed-off-by: Dan Carpenter erro...@gmail.com

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b79619a..b9fafe3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -517,7 +517,7 @@ irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS)
if (de_iir  DE_PIPEA_VBLANK_IVB)
drm_handle_vblank(dev, 0);
 
-   if (de_iir  DE_PIPEB_VBLANK_IVB);
+   if (de_iir  DE_PIPEB_VBLANK_IVB)
drm_handle_vblank(dev, 1);
 
/* check event from PCH */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

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

--- Comment #8 from Maggioni Marcello haya...@gmail.com 2011-05-25 03:46:01 
PDT ---
An update.

I noticed that in fullscreen the problem is not present with the new drivers
(no corruption at the bottom of the screen) , but the problem with the white
dots persists.
I also noticed that these dots are in random locations, but they surround point
light sources like candles. I thought they were random, because you can see
them trough walls , so the candles generating the dots were not directly
visible, but behind the wall and I haven't immediatly connected this problem
with the lights.

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

BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

2011-05-25 Thread Frank van Maarseveen

Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes
immediately upon start.

lspci excerpt:
01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon 
X1300/X1550 Series]
01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] 
(Secondary)

/var/log/messages excerpt:
[drm] Setting GART location based on new memory map
[drm] Loading R500 Microcode
[drm] Num pipes: 1
[drm] writeback test succeeded in 1 usecs
[drm] Num pipes: 1
BUG: unable to handle kernel paging request at 6b6b6b6b
IP: [c1377329] radeon_read_ring_rptr+0x19/0x30
*pdpt = 335ab001 *pde =  
Oops:  [#1] PREEMPT SMP 
last sysfs file: /sys/devices/pci:00/:00:01.0/:01:00.0/enable
Modules linked in: [last unloaded: scsi_wait_scan]
May 25 12:23:58 lokka kernel:
Pid: 4484, comm: X Not tainted 2.6.39-x255 #1 Dell Inc. Dell 
DXP051  /0FJ030
EIP: 0060:[c1377329] EFLAGS: 00213202 CPU: 1
EIP is at radeon_read_ring_rptr+0x19/0x30
EAX: f3484be0 EBX: f569baa0 ECX: 000a EDX: 6b6b6b6b
ESI: f85e5000 EDI: 0040 EBP: f37a1d0c ESP: f37a1d08
DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
Process X (pid: 4484, ti=f37a task=f378b3c0 task.ti=f37a)
Stack:
c1377387 f37a1d1c c1377b86 f569baa0 0010 f37a1d44 c137a0be 0001
c1a8a2f7 c188cb8a c1a648c4 f6424d60 f569baa0   f37a1d58
c137c7cf f569bbb0 f569baa0 f569baa0 f37a1d6c c137c9b7 f569bab4 f569bbe0
Call Trace:
[c1377387] ? radeon_get_ring_head+0x47/0x50
[c1377b86] radeon_commit_ring+0x56/0xb0
[c137a0be] radeon_do_cp_idle+0xce/0x170
[c137c7cf] radeon_apply_surface_regs+0x2f/0x150
[c137c9b7] free_surface+0xc7/0x100
[c1387125] radeon_driver_lastclose+0x45/0x60
[c135ced0] drm_lastclose+0x40/0x2b0
[c135d804] ? drm_release+0x344/0x460
[c135d836] drm_release+0x376/0x460
[c10f6d19] __fput+0xa9/0x1c0
[c10f6e4f] fput+0x1f/0x30
[c10f35bd] filp_close+0x4d/0x80
[c10736a6] put_files_struct+0x76/0xe0
[c1073752] exit_files+0x42/0x60
[c10751a1] do_exit+0x231/0x320
[c10752c3] do_group_exit+0x33/0x90
[c106cbbb] ? sub_preempt_count+0x7b/0xa0
[c1080ded] get_signal_to_deliver+0x17d/0x2a0
[c1037c20] do_notify_resume+0xc0/0x180
[c110f6c3] ? mntput+0x13/0x30
[c10f6d9f] ? __fput+0x12f/0x1c0
[c106befb] ? get_parent_ip+0xb/0x40
[c106cbbb] ? sub_preempt_count+0x7b/0xa0
[c1834e68] ? _raw_spin_unlock_irq+0x18/0x40
[c107dd30] ? sigprocmask+0x70/0xf0
[c107e084] ? sys_rt_sigprocmask+0xd4/0xf0
[c107e084] ? sys_rt_sigprocmask+0xd4/0xf0
[c1835230] work_notifysig+0x13/0x1b
Code: fe ff 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 f6 80 3a 03 00 
00 08 89 e5 75 14 8b 80 e0 00 00 00 83 e2 fc 5d 03 50 14 8b 02 c3 8d 74 26 00 
8b 80 e0 00 00 00 03 50 14 8b 02 5d c3 8d 
EIP: [c1377329] radeon_read_ring_rptr+0x19/0x30 SS:ESP 0068:f37a1d08
CR2: 6b6b6b6b
---[ end trace 9a6c2c396ea040f5 ]---
Fixing recursive fault but reboot is needed!

/var/log/Xorg.0.log:
[   111.905] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
[   111.906] _XSERVTransOpen: transport open failed for inet6/lokka.tasking.nl:0
[   111.906] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for 
inet6
[   111.917] 
X.Org X Server 1.9.5
Release Date: 2011-03-17
[   111.917] X Protocol Version 11, Revision 0
[   111.917] Build Operating System: x86-01 2.6.32-71.14.1.el6.x86_64 
[   111.917] Current Operating System: Linux lokka.tasking.nl 2.6.39-x255 #1 
SMP PREEMPT Wed May 25 10:34:33 CEST 2011 i686
[   111.917] Kernel command line: initrd=initrd nomodules panic=60 
nmi_watchdog=1 netconsole=@172.17.1.124/,514@172.17.1.64/00:12:3f:85:17:52 
BOOT_IMAGE=linux-2.6.39-x255 
[   111.917] Build Date: 18 March 2011  12:23:01AM
[   111.917] Build ID: xorg-x11-server 1.9.5-1.fc14 
[   111.918] Current version of pixman: 0.18.4
[   111.918]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   111.918] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   111.918] (==) Log file: /var/log/Xorg.0.log, Time: Wed May 25 12:23:57 
2011
[   111.964] (==) Using config directory: /etc/X11/xorg.conf.d
[   111.964] (==) Using system config directory /usr/share/X11/xorg.conf.d
[   111.981] (==) No Layout section.  Using the first Screen section.
[   111.981] (==) No screen section available. Using defaults.
[   111.981] (**) |--Screen Default Screen Section (0)
[   111.981] (**) |   |--Monitor default monitor
[   111.982] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[   111.982] (==) Automatically adding devices
[   111.982] (==) Automatically enabling devices
[   111.983] (==) FontPath set to:
catalogue:/etc/X11/fontpath.d,
built-ins
[   111.983] (==) ModulePath set to /usr/lib/xorg/modules
[   111.983] (II) The server relies on udev to

Re: (Short?) merge window reminder

2011-05-25 Thread Jiri Kosina

On Tue, 24 May 2011, Andy Lutomirski wrote:

 Also, when someone in my lab installs insert ancient enterprise distro 
 here on a box that's running software I wrote that needs to support 
 modern high-speed peripherals, then I can say What?  You seriously 
 expect this stuff to work on Linux 2007?  Let's install a slightly less 
 stable distro from at least 2010.  This sounds a lot less nerdy than 
 What?  You seriously expect this stuff to work on Linux 2.6.27?  Let's 
 install a slightly less stable distro that uses at least 2.6.36.

I hate to jump into this excellent example of bike-shedding discussion, 
but anyway ...

Your example doesn't really reflect reality.

It's common for older enterprise distributions to gradually incorporate a 
lot of backported code (and most importantly new hardware support 
code/drivers) while not upgrading the kernel major version. So yes, you 
will in reality get 2.6.16 kernel (at least according to uname) with 
libata with newer service packs of SLES 10, for example (and you could 
find many of those across distributions).

-- 
Jiri Kosina
SUSE Labs

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

[Bug 31532] [RADEON:KMS:RV670:AGP:R600C-R600G] PCIE gart stalls

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

Andy Furniss li...@andyfurniss.entadsl.com changed:

   What|Removed |Added

Summary|[RADEON:KMS:RV670:AGP:R600C |[RADEON:KMS:RV670:AGP:R600C
   |-R600G] rv670 AGP gart +|-R600G] PCIE gart stalls
   |gallium - GPU lockups. PCIE |
   |gart runs but stalls|

--- Comment #4 from Andy Furniss li...@andyfurniss.entadsl.com 2011-05-25 
08:11:21 PDT ---
Running agpgart with gallium is now fixed and runs without stalls since

r600g: bump domain selection up one layer.
ecc051d65b6e17115439fb3609cccfd59f6272bf

Running with agpmode=-1 + gallium is better than it was, all demos are stall
free apart from fbo_firecube, but nexuiz still stalls badly.

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

Re: (Short?) merge window reminder

2011-05-25 Thread Emil Langrock

On Tuesday 24 May 2011 23:05:30 Jan Engelhardt wrote:
 On Tuesday 2011-05-24 20:48, eschvoca wrote:
 On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
  It's not about features. It hasn't been about features for forever.
 
 Using the date also clearly communicates it is not about features.
 
 On the contrary: Whenever a 2.6.x release was set out the door, there
 was at least one new feature in the cycle. Given the endless manpower
 that seems to trail Linux, that seems unlikely to change in the near
 term.
 
 On It is not about features - it is not /just/ about features - it
 is also about fixes, which are equally important, and they also
 warrant a version bump of some sort on their own. Pointing out the
 obvious, the stable serieses.

You are mixing up features based versioning and identifier for versions. Linux 
has no feature based concept for most parts of their version number (only the 
patch part clearly states: fixes, fixes, fixes). We only need something that 
is easily readable and maybe has no extreme weird meaning that leads to false 
conclusions. And yes, that is what eschvoca meant and not something like 
linux is stagnating.

 Fleeing to date-based version numbering seems like an excuse
 for making way for releases without any change whatsoever.
 (IOW, if there were features/fixes, a non-date based scheme of
 incremental numbers could indicate them already.)

Yes, that is usally the case... release the same source tarball again and 
again. I always had that feeling when looking at those wine, ubuntu, gentoo, 
ms, texlive, iasl, hugin, u-boot, ... developers. They are doing nothing the 
whole day and the marketing department does everything.

 Me, a nobody end user, would prefer a version number that corresponded
 to the date.  Something like:
 
 %y.%m.stable patch
 %Y.%m.stable patch
 
 Except that LINUX_KERNEL_VERSION has only 8 bits for each,
 so 2011 is out of range, which would need to kept in mind.
 And a 2-digit spec.. nah that does not feel very 100-year
 proof. (Just look at struct tm.tm_year for the mess 2-digits
 made technically.)

What is LINUX_KERNEL_VERSION? I only know LINUX_VERSION_CODE and 
KERNEL_VERSION

And the calculation behind it is following:

(((a)  16) + ((b)  8) + (c))

So for KERNEL_VERSION(2,6,40) we would get 0x20628 and for 
KERNEL_VERSION(2011,2,0) we would get 0x07DB0200. Of course our 
grandgrandgrand...grand children would die in agony in the year 65536.

And maybe (probably the module version check guys will kill me) could use a 
compressed version of that without hurding the comparison function in out of 
kernel modules. KERNEL_VERSION_Y(a,b) would be defined as

#define KERNEL_VERSION_Y(a,b) ({typeof (a) _a = a; \
typeof (b) _b = b; \
KERNEL_VERSION(_a  8, _a  0xff, _b); })

This would bring us to the year 16777216 before everybody gets punched in his 
private parts by the versioning scheme. It is also possible to get more out of 
32 bits when we can assume that Linus or his grandgrand...grand children will 
never do more than 128 releases a year.

But yes, I aggree not to use 2 digit numbers for years unless we want to 
start the y2k+100 problem here.

 Then users would know the significance of the number and when a vendor
 says they support Linux 11.09 the user will immediately know if they
 are up to date.
 
 An added issue with that would be that numbers would not increase in
 same-sized steps anymore and leave gaps. (There would probably be no
 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)

Ok, this is really a good example why we should not use the month for 
releases, but an ever increasing number until the first number is also 
increased which resets the second number to 0.

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

Re: connector - encoder relationship

On Wed, May 25, 2011 at 4:36 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
Hi All,

I'm currently looking into implementing a SoC graphics core with KMS.

What I wonder about is the relationship between connectors and encoders.
On my board I have a sii9022 HDMI encoder connected via i2c. This chip
supports reading edid data, tracks the connection status of the display
and needs to be configured when the resolution changes. So my first
guess is that I have to implement an encoder. looking at struct
drm_encoder_funcs there are no callbacks suitable for this. struct
drm_connector_funcs on the other hand has all the callbacks I need.
Now I look at drivers/gpu/drm/i2c. The drivers there implement a
drm_encoder_slave which also has all the callbacks I need. So from
one point of view the functions should be implemented in the connector,
while in the i2c case it's implemented in the (slave-) encoder.
Generally I have the feeling that my sii9022 should be both an encoder
and a connector, but this doesn't fit into the current scheme.

I'm confused. Could someone clarify this a bit?

The general idea is this:
framebuffer - crtc - encoder - connector - monitor

- The framebuffer is just a buffer vram that has an image encoded in
it as an array of pixels.
- The crtc reads the data out of the framebuffer and generates the
video mode timing in conjunction with a PLL. The crtc also determines
what part of the framebuffer is read; e.g., when multi-head is
enabled, each crtc scans out of a different part of vram; in clone
mode, each crtc scans out of the same part of vram.
- The encoder takes the digital bitstream from the crtc and converts
it to the appropriate analog levels for transmission across the
connector to the monitor.
- The connector provides the appropriate physical plug (HDMI, DVI-D,
VGA, S-video, etc.) for the monitor to connect to.

crtcs are usually routeable and can be connected to one or many
encoders simultaneously. The encoders can also be connected to one or
more connectors (e.g., you might have a single TMDS encoder that is
connected to the digital portion of a DVI-I port and also to a HDMI
port, or you might have a DAC that is connected to a VGA port and an
S-video port). Finally i2c lines are associated with connectors,
since generally the i2c pins are wired to the connector and in many
cases, each connectors has it's own i2c line. For example, you might
have a single TMDS encoder that is wired to a DVI-D port with its own
i2c line and an HDMI port with its own i2c line. Each connector may
have it's own hotplug (HPD) pin as well. That way you could query the
EDID from each connector separately for example.

Is the sii9022 being driven by the output of a DVO encoder from your
display hw? If so your display path would look like:

crtc - DVO (master encoder) - sii9022 (slave encoder) - HDMI plug - monitor

The general GPU driver might register the i2c buses that are used by
the various parts (encoder, connector), then it's just a matter of
plugging in the right parts for each component (e.g. you'd hook up the
sii9022 i2c control bus to the DVO encoder, and the ddc i2c bus to the
hdmi connector object, etc.).

I hope this helps.

Thanks
Sascha

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

[PATCH] drm/radeon/kms: properly set panel mode for eDP

This should make eDP more reliable.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/atombios_dp.c |   11 +++
 include/drm/drm_dp_helper.h  |3 +++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8c0f9e3..892b88d 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -543,6 +543,7 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,
 {
struct drm_device *dev = encoder-dev;
struct radeon_device *rdev = dev-dev_private;
+   struct radeon_connector *radeon_connector = 
to_radeon_connector(connector);
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
 
if (!ASIC_IS_DCE4(rdev))
@@ -550,10 +551,20 @@ static void radeon_dp_set_panel_mode(struct drm_encoder 
*encoder,
 
if (radeon_connector_encoder_is_dp_bridge(connector))
panel_mode = DP_PANEL_MODE_INTERNAL_DP1_MODE;
+   else if (connector-connector_type == DRM_MODE_CONNECTOR_eDP) {
+   u8 tmp = radeon_read_dpcd_reg(radeon_connector, 
DP_EDP_CONFIGURATION_CAP);
+   if (tmp  1)
+   panel_mode = DP_PANEL_MODE_INTERNAL_DP2_MODE;
+   }
 
atombios_dig_encoder_setup(encoder,
   ATOM_ENCODER_CMD_SETUP_PANEL_MODE,
   panel_mode);
+
+   if ((connector-connector_type == DRM_MODE_CONNECTOR_eDP) 
+   (panel_mode == DP_PANEL_MODE_INTERNAL_DP2_MODE)) {
+   radeon_write_dpcd_reg(radeon_connector, 
DP_EDP_CONFIGURATION_SET, 1);
+   }
 }
 
 void radeon_dp_set_link_config(struct drm_connector *connector,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 91567bb..03eb1d6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -72,6 +72,7 @@
 
 #define DP_MAIN_LINK_CHANNEL_CODING 0x006
 
+#define DP_EDP_CONFIGURATION_CAP0x00d
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e
 
 /* link configuration */
@@ -133,6 +134,8 @@
 #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108
 # define DP_SET_ANSI_8B10B (1  0)
 
+#define DP_EDP_CONFIGURATION_SET0x10a
+
 #define DP_LANE0_1_STATUS  0x202
 #define DP_LANE2_3_STATUS  0x203
 # define DP_LANE_CR_DONE   (1  0)
-- 
1.7.4

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

[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm

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

--- Comment #5 from Rune K. Svendsen runesv...@gmail.com 2011-05-25 12:27:24 
PDT ---
Created an attachment (id=47157)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47157)
Output of running 'thread apply all bt full' in gdb after attaching to
frozen/hung compiz

(In reply to comment #3)
 Looks like it's hanging when trying to acquire the radeon-bo_handles_mutex .
 Does running
 
  thread apply all bt full
 
 in gdb give backtraces for any other threads?

I'm attaching the output of that command here.
Please let me know if I'm missing any relevant debug symbols. I can see a lot
of the loaded libraries don't have debug symbols, so please let me know which
are relevant, if any.

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

[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm

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

--- Comment #6 from Rune K. Svendsen runesv...@gmail.com 2011-05-25 12:34:00 
PDT ---
Created an attachment (id=47160)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47160)
Second output of running 'thread apply all bt full' in gdb after attaching to
frozen/hung compiz

It just happened again.
I did a 'thread apply all bt full' again, and I can see that the output isn't
the same as the previous time. So I'm attaching this output in case it's
relevant.

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

[PATCH] drm/radeon/kms: add blit support for cayman (v2)

Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.

v2: fix copy paste typo
Reported-by: Nils Wallménius nils.wallmen...@gmail.com

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/cayman_blit_shaders.c |  326 -
 drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
 drivers/gpu/drm/radeon/evergreen_blit_kms.c  |  505 ++
 drivers/gpu/drm/radeon/ni.c  |   13 +-
 drivers/gpu/drm/radeon/radeon_asic.c |6 +-
 5 files changed, 598 insertions(+), 255 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c 
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@
 
 const u32 cayman_default_state[] =
 {
-   /* XXX fill in additional blit state */
+   0xc0066900,
+   0x,
+   0x0060, /* DB_RENDER_CONTROL */
+   0x, /* DB_COUNT_CONTROL */
+   0x, /* DB_DEPTH_VIEW */
+   0x002a, /* DB_RENDER_OVERRIDE */
+   0x, /* DB_RENDER_OVERRIDE2 */
+   0x, /* DB_HTILE_DATA_BASE */
 
0xc0026900,
-   0x0316,
-   0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
-   0x0010, /*  */
+   0x000a,
+   0x, /* DB_STENCIL_CLEAR */
+   0x, /* DB_DEPTH_CLEAR */
+
+   0xc0036900,
+   0x000f,
+   0x, /* DB_DEPTH_INFO */
+   0x, /* DB_Z_INFO */
+   0x, /* DB_STENCIL_INFO */
+
+   0xc0016900,
+   0x0080,
+   0x, /* PA_SC_WINDOW_OFFSET */
+
+   0xc00d6900,
+   0x0083,
+   0x, /* PA_SC_CLIPRECT_RULE */
+   0x, /* PA_SC_CLIPRECT_0_TL */
+   0x20002000, /* PA_SC_CLIPRECT_0_BR */
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x, /* PA_SC_EDGERULE */
+   0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+   0x000f, /* CB_TARGET_MASK */
+   0x000f, /* CB_SHADER_MASK */
+
+   0xc0226900,
+   0x0094,
+   0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+   0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x, /* PA_SC_VPORT_ZMIN_0 */
+   0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+   0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */
 
0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+   0xc0096900,
+   0x0100,
+   0x00ff, /* VGT_MAX_VTX_INDX */
+   0x, /* VGT_MIN_VTX_INDX */
+   0x, /* VGT_INDX_OFFSET */
+   0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+   0x, /* SX_ALPHA_TEST_CONTROL */
+   0x, /* CB_BLEND_RED */
+   0x, /* CB_BLEND_GREEN */
+   0x, /* CB_BLEND_BLUE */
+   0x, /* CB_BLEND_ALPHA */
+
+   0xc0016900,
+   0x0187,
+   0x0100, /* SPI_VS_OUT_ID_0 */
+
+   0xc0026900,
+   0x0191,
+   0x0100, /* SPI_PS_INPUT_CNTL_0 */
+   0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+   0xc0016900,
+   0x01b1,
+   0x, /* SPI_VS_OUT_CONFIG */
+
+   0xc0106900,
+   0x01b3,
+   0x2001, /* SPI_PS_IN_CONTROL_0 */
+   0x, /* SPI_PS_IN_CONTROL_1 */
+   0x, /* SPI_INTERP_CONTROL_0 */
+   0x, /* SPI_INPUT_Z */
+   0x, /* SPI_FOG_CNTL */
+   0x0010, /* SPI_BARYC_CNTL */
+   0x, /* SPI_PS_IN_CONTROL_2 */
+   0x, /* SPI_COMPUTE_INPUT_CNTL */
+   0x, /* SPI_COMPUTE_NUM_THREAD_X */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+   0x, /* SPI_GPR_MGMT */
+   0x, /* SPI_LDS_MGMT */
+   0x, /* SPI_STACK_MGMT */
+   0x, /* SPI_WAVE_MGMT_1 */
+   0x, /* SPI_WAVE_MGMT_2 */
+
+   0xc0016900,
+   0x01e0,
+   0x, /* CB_BLEND0_CONTROL */
+
+   0xc00e6900,
+   0x0200,
+   0x, /* DB_DEPTH_CONTROL */
+   0x, /* DB_EQAA */
+   0x00cc0010, /* CB_COLOR_CONTROL */
+   0x0210, /*

[Bug 37603] New: r600g with LLVM enabled makes Heroes of Newerth game unplayable

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

   Summary: r600g with LLVM enabled makes Heroes of Newerth game
unplayable
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: dam...@grassart.com


Created an attachment (id=47162)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=47162)
Blurry loading screen

Hi, recent versions of Mesa have made this game go from 30 fps down to under 1
fps, and have caused the bottom of textures to become blurry (see attachment).
I've bisected it down to commit a86fc719d6402eb482657707741890e69e81700f
(enable LLVM by default on x86 and x86_64). I don't know why LLVM causes this
but I've verified that disabling it via configure fixes this problem. I now
use: 

./configure --prefix=$HOME --enable-gallium-r600 --disable-gallium-r300
--disable-gallium-llvm --disable-gallium-egl --with-state-trackers=dri

I know r300g requires LLVM but are there any reasons to enable it for r600g?

Thanks,
-Damien

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

[PATCH] drm/radeon/kms: add missing case for cayman thermal sensor

The rest of the code is already in place.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/radeon_pm.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 86eda1e..aaa19dc 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -487,6 +487,7 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_RV6XX:
case THERMAL_TYPE_RV770:
case THERMAL_TYPE_EVERGREEN:
+   case THERMAL_TYPE_NI:
case THERMAL_TYPE_SUMO:
rdev-pm.int_hwmon_dev = hwmon_device_register(rdev-dev);
if (IS_ERR(rdev-pm.int_hwmon_dev)) {
-- 
1.7.1.1

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

[PATCH] drm/radeon/kms: fix thermal sensor reading on juniper

Uses a different method than other evergreen asics.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/evergreen.c  |   48 ---
 drivers/gpu/drm/radeon/evergreend.h |8 +-
 2 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 7c37638..5f0c345 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -88,21 +88,39 @@ u32 evergreen_page_flip(struct radeon_device *rdev, int 
crtc_id, u64 crtc_base)
 /* get temperature in millidegrees */
 int evergreen_get_temp(struct radeon_device *rdev)
 {
-   u32 temp = (RREG32(CG_MULT_THERMAL_STATUS)  ASIC_T_MASK) 
-   ASIC_T_SHIFT;
-   u32 actual_temp = 0;
-
-   if (temp  0x400)
-   actual_temp = -256;
-   else if (temp  0x200)
-   actual_temp = 255;
-   else if (temp  0x100) {
-   actual_temp = temp  0x1ff;
-   actual_temp |= ~0x1ff;
-   } else
-   actual_temp = temp  0xff;
+   u32 temp, toffset, actual_temp = 0;
+
+   if (rdev-family == CHIP_JUNIPER) {
+   toffset = (RREG32(CG_THERMAL_CTRL)  TOFFSET_MASK) 
+   TOFFSET_SHIFT;
+   temp = (RREG32(CG_TS0_STATUS)  TS0_ADC_DOUT_MASK) 
+   TS0_ADC_DOUT_SHIFT;
+
+   if (toffset  0x100)
+   actual_temp = temp / 2 - (0x200 - toffset);
+   else
+   actual_temp = temp / 2 + toffset;
+
+   actual_temp = actual_temp * 1000;
+
+   } else {
+   temp = (RREG32(CG_MULT_THERMAL_STATUS)  ASIC_T_MASK) 
+   ASIC_T_SHIFT;
+
+   if (temp  0x400)
+   actual_temp = -256;
+   else if (temp  0x200)
+   actual_temp = 255;
+   else if (temp  0x100) {
+   actual_temp = temp  0x1ff;
+   actual_temp |= ~0x1ff;
+   } else
+   actual_temp = temp  0xff;
+
+   actual_temp = (actual_temp * 1000) / 2;
+   }
 
-   return (actual_temp * 1000) / 2;
+   return actual_temp;
 }
 
 int sumo_get_temp(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/evergreend.h 
b/drivers/gpu/drm/radeon/evergreend.h
index f37e91e..1636e34 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -168,10 +168,16 @@
 #defineSE_DB_BUSY  (1  
30)
 #defineSE_CB_BUSY  (1  
31)
 /* evergreen */
+#defineCG_THERMAL_CTRL 0x72c
+#defineTOFFSET_MASK0x3FE0
+#defineTOFFSET_SHIFT   5
 #defineCG_MULT_THERMAL_STATUS  0x740
 #defineASIC_T(x)   ((x)  16)
-#defineASIC_T_MASK 0x7FF
+#defineASIC_T_MASK 0x07FF
 #defineASIC_T_SHIFT16
+#defineCG_TS0_STATUS   0x760
+#defineTS0_ADC_DOUT_MASK   0x03FF
+#defineTS0_ADC_DOUT_SHIFT  0
 /* APU */
 #defineCG_THERMAL_STATUS   0x678
 
-- 
1.7.1.1

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

Re: BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

2011-05-25 Thread Thierry Vignaud

On 25 May 2011 17:43, Alex Deucher alexdeuc...@gmail.com wrote:
 Xorg from FC14 plus linux kernel 2.6.37, 2.6.38 and 2.6.39 on x86 crashes
 immediately upon start.

 Any reason you are not using kms?

Any reason you are not respecting the netiquette ?
Quoting nearly 1000 lines unrelated to your one line answer is quite rude :-(
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: BUG: unable to handle kernel paging request at 6b6b6b6b in radeon_read_ring_rptr()

2011-05-25 Thread Dave Airlie

 Any reason you are not using kms?

 Any reason you are not respecting the netiquette ?
 Quoting nearly 1000 lines unrelated to your one line answer is quite rude :-(

Yeah we knows that only acceptable if you put,

Pardon my ignorance I sent this from my phone at the top ;-)

Sorry couldn't resist.

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

[Bug 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)

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

--- Comment #4 from Dave Airlie airl...@freedesktop.org 2011-05-25 18:24:02 
PDT ---
are you running nexuiz in any particular way?

I'm wondering if this is TURKS specific, my BARTS can run gnome-shell + nexuiz
timedemo demos/demo1.dem in full here with no hangs.

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

[Bug 36542] Radeon HD 6570 GPU lockup (waiting for 0x00000281 last fence id 0x00000280)

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

--- Comment #5 from Erdem U. Altinyurt spamjunkea...@gmail.com 2011-05-25 
18:32:15 PDT ---
Don't know nexuiz's timedemo demos/demo1.dem but my barts (HD6850) hanging up
while I am in desktop (with compiz) too. So I don't believe if this is related
with just TURKS but BARTS...

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

Re: [PULL] drm-intel-next

2011-05-25 Thread Keith Packard


This fixes a simple typo in the Ivybridge code -- an extra semicolon.

The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0:

  drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge 
(2011-05-18 15:14:39 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git 
drm-intel-next

Dan Carpenter (1):
  drm/i915: fix if statement in ivybridge irq handler

 drivers/gpu/drm/i915/i915_irq.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
keith.pack...@intel.com


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

[Bug 37603] r600g with LLVM enabled makes Heroes of Newerth game unplayable