[PATCH] drm/radeon/kms: set SX_MISC in the r6xx blit code (v2)

[Marek Olšák]

Mesa may set it to 1, causing all primitives to be killed.

v2: also update the r7xx code

Signed-off-by: Marek Ol??k 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/r600_blit_shaders.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c 
b/drivers/gpu/drm/radeon/r600_blit_shaders.c
index 2d1f6c5..73e2c7c 100644
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
@@ -314,6 +314,10 @@ const u32 r6xx_default_state[] =
0x, /* VGT_VTX_CNT_EN */

0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */
+
+   0xc0016900,
0x02c8,
0x, /* VGT_STRMOUT_BUFFER_EN */

@@ -626,6 +630,10 @@ const u32 r7xx_default_state[] =
0x, /* VGT_VTX_CNT_EN */

0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */
+
+   0xc0016900,
0x02c8,
0x, /* VGT_STRMOUT_BUFFER_EN */

-- 
1.7.5.4

[Bug 42887] New: Garbled display on external screen when using 1920x1080 instead of 1920x1200

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

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

   Summary: Garbled display on external screen when using
1920x1080 instead of 1920x1200
   Product: Drivers
   Version: 2.5
Kernel Version: 3.3
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: thejoe at gmail.com
Regression: No


also reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=44755
and here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/915408



[Problem]
i have an external monitor (1920x1200 resolution) that, when set to 1920x1080
resolution (native resolution of laptop display), garbles the screen as seen in
the screenshot below.  The problem doesn't happen using the catalyst driver.

https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/813566/+attachment/2221015/+files/2011-07-20_07-51-28_83.jpg

ProblemType: BugDistroRelease: Ubuntu 11.10
Package: xorg 1:7.6+7ubuntu7
ProcVersionSignature: Ubuntu 3.0.0-15.25-generic 3.0.13
Uname: Linux 3.0.0-15-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.23-0ubuntu4
Architecture: amd64
CompizPlugins:
[core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,unitymtgrabhandles,scale,session,unityshell]
CompositorRunning: None
Date: Thu Jan 12 07:42:25 2012
DistUpgraded: Log time: 2011-07-13 10:07:59.371965
DistroCodename: oneiric
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
ATI Technologies Inc Broadway PRO [Mobility Radeon HD 5800 Series] [1002:68a1]
(prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device [103c:1522]InstallationMedia: Ubuntu
10.04 "Lucid Lynx" - Release Candidate amd64 (20100419.1)
MachineType: Hewlett-Packard HP ENVY 15 Notebook PC
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-15-generic
root=UUID=639dc488-e095-42a4-8c1f-ffb1a9299e1c ro
crashkernel=384M-2G:64M,2G-:128M quiet splash vt.handoff=7SourcePackage: xorg
UpgradeStatus: Upgraded to oneiric on 2011-07-13 (182 days ago)
dmi.bios.date: 04/23/2010
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.26
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 1522
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 36.34
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: N/A
dmi.modalias:
dmi:bvnHewlett-Packard:bvrF.26:bd04/23/2010:svnHewlett-Packard:pnHPENVY15NotebookPC:pvr048F1124192000153:rvnHewlett-Packard:rn1522:rvr36.34:cvnHewlett-Packard:ct10:cvrN/A:
dmi.product.name: HP ENVY 15 Notebook PC
dmi.product.version: 048F1124192000153
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz 1:0.9.6+bzr20110929-0ubuntu6
version.ia32-libs: ia32-libs 20090808ubuntu26
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati
1:6.14.99~git20110811.g93fc084-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel
2:2.15.901-1ubuntu2.1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau
1:0.0.16+git20110411+8378443-1
[reply] [-] Comment 1


discussion from freedesktop.org bug:
Alex Deucher 2012-01-13 08:25:54 UTC
The problem is the modeline from your monitor for the 1920x1080 mode is greater
than 165 Mhz which is the current cut off for single link mode in the driver:
(II) RADEON(0): Modeline "1920x1080"x60.0  172.78  1920 2040 2248 2576  1080
1081 1084 1118 -hsync +vsync (67.1 kHz)

It should work if you specify a modeline with a lower clock  E.g.,
Modeline "1920x1080R"  138.50  1920 1968 2000 2080  1080 1083 1088  +hsync
-vsync
[reply] [-] Comment 5


Alex Deucher 2012-01-13 08:34:21 UTC
Created attachment 7 [details] [review]
possible fix

This patch against drm-next or Linus git should fix the issue.
[reply] [-] Comment 6 thejoe at gmail.com 2012-01-13 08:53:54 UTC
confirmed that the following sequence displays a non-garbled 1920x1080 display
on the external monitor:

# xrandr --newmode "1920x1080R"  138.50  1920 1968 2000 2080  1080 1083 1088
 +hsync -vsync
# xrandr --addmode HDMI-0 1920x1080R
# xrandr 1920x1080R
[reply] [-] Comment 7 Florian Mickler 2012-02-01 13:09:58 UTC
A patch referencing this bug report has been merged in Linux v3.3-rc2:

commit 9aa59993e226af94088adaee993eb8cfd33ae295
Author: Alex Deucher 
Date:   Fri Jan 20 

[Bug 42876] System doesn't boot with GTX 550 Ti

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

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


Sergio  changed:

   What|Removed |Added

 CC||sergiomartinj at gmail.com




--- Comment #1 from Sergio   2012-03-07 21:52:01 ---
Same problem here.
Same graphic card, and nouveau driver.
I'm using Fedora 16.

With kernel 3.1.10-2 works fine.
With kernels 3.2.x don't work.

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

[PATCH 4/9] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Kurtz]

On Wed, Mar 7, 2012 at 8:17 PM, Chris Wilson  
wrote:
> On Wed, ?7 Mar 2012 19:50:45 +0800, Daniel Kurtz  
> wrote:
>> There is no "disabled" port 0. ?So, don't even try to initialize/scan
>> it, etc. ?This saves a bit of time when initializing the driver, since
>> the we can avoid a 50ms timeout waiting for a device to respond on
>> a port that doesn't even exist.
>>
>> Similarly, don't initialize the reserved port, either.
>
>> @@ -150,32 +164,23 @@ static void set_data(void *data, int state_high)
>> ?static struct i2c_adapter *
>> ?intel_gpio_create(struct drm_i915_private *dev_priv, u32 pin)
>> ?{
>> - ? ? static const int map_pin_to_reg[] = {
>> - ? ? ? ? ? ? 0,
>> - ? ? ? ? ? ? GPIOB,
>> - ? ? ? ? ? ? GPIOA,
>> - ? ? ? ? ? ? GPIOC,
>> - ? ? ? ? ? ? GPIOD,
>> - ? ? ? ? ? ? GPIOE,
>> - ? ? ? ? ? ? GPIOF,
>> - ? ? ? ? ? ? 0,
>> - ? ? };
>> ? ? ? struct intel_gpio *gpio;
>>
>> - ? ? if (pin >= ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])
>
> And that doesn't do what your changelog proposes? Why?

This changelog proposes to optimize initialization of the gmbus ports,
not the gpio-bit-bang ports.

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre

[PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

[Daniel Kurtz]

On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson  
wrote:
> On Wed, ?7 Mar 2012 19:50:47 +0800, Daniel Kurtz  
> wrote:
>> Return -ENXIO if a device NAKs a transaction.
>>
>> Note: We should return -ETIMEDOUT, too if the transaction times out,
>> however, that error path is currently handled by the 'bit-bang fallback'.
>>
>> Signed-off-by: Daniel Kurtz 
>
> Can you clarify what the rule is if an error is detected part-way
> through a xfer?

A priceless comment from drivers/i2c/i2c-core::i2c_transfer...

/* REVISIT the fault reporting model here is weak:
 *
 *  - When we get an error after receiving N bytes from a slave,
 *there is no way to report "N".
 *
 *  - When we get a NAK after transmitting N bytes to a slave,
 *there is no way to report "N" ... or to let the master
 *continue executing the rest of this combined message, if
 *that's the appropriate response.
 *
 *  - When for example "num" is two and we successfully complete
 *the first message but get an error part way through the
 *second, it's unclear whether that should be reported as
 *one (discarding status on the second message) or errno
 *(discarding status on the first one).
 */

As for which error code to use, all I have found is this:

Documentation/i2c/fault-codes:
ENXIO
Returned by I2C adapters to indicate that the address phase
of a transfer didn't get an ACK.  While it might just mean
an I2C device was temporarily not responding, usually it
means there's nothing listening at that address.

This doesn't specify what to do if the transfer doesn't get an ACK
during another phase of the transfer.
However, it does say to send -ENXIO "if no ACK during address phase",
which is a subset of the possible no-ACK conditions during a transfer.
 Thus, I choose to return ENXIO in all no-ACK cases, to ensure we send
it during the one case that is specified.

For different i2c adapters i've seen wildly different behavior:
   -ENXIO (i2c-algo-pca)
   -EIO (i2c-algo-bit)
   -EREMOTEIO (i2c-algo-pcf).

-Dan

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

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

--- Comment #8 from Alex Deucher  2012-03-07 12:03:07 PST 
---
(In reply to comment #7)
> Poll helper is running every ten seconds because VGA connector "asks it to",
> given how it has DRM_CONNECTOR_POLL_CONNECT set.

Right.  The VGA connector has to poll because analog VGA does not support
hotplug detect.

> 
> Since the poll helper runs, and HDMI connector has DRM_CONNECTOR_POLL_HPD set
> due to hpd.hpd being not RADEON_HPD_NONE, it calls it's detect method
> (radeon_dvi_detect).
> 
> This in turns discards an re-fetches the full EDID every time it runs.
> 
> What is the bug here?
> 
> 1. That HDMI connector has DRM_CONNECTOR_POLL_HPD set when hpd.hpd is not
> RADEON_HPD_NONE?

That's correct.  If the connector supports an hotplug pin (hpd.hpd !=
RADEON_HPD_NONE), there is no need for the driver to poll every 10 seconds
because the hw will generate an interrupt on a plug or unplug event.  When an
interrupt arrives, the the poll handler runs to see if the monitor is still
there and to send an event to userspace (same poll handler that is run by the
driver for non-HPD capable connectors).

> 2. That discard and full fetch of EDID is done when is not needed?
> 
> Or both? Or something else? Hard to say for me. HPD sounds like Hotplug 
> detect?

Yes, HPD stands for hotplug detect.

Does your monitor have multiple inputs?  Some monitors have an option to poll
their inputs at regular intervals.  When they do that, it often causes a
disconnect/connect signal on the HPD pin which generates an interrupt and the
driver's detect logic runs.  Try and disable the monitor's polling logic if you
can and see if that helps.

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

[PATCH 9/9] drm/i915/intel_i2c: reuse GMBUS2 value from polling loop

[Daniel Kurtz]

Save the GMBUS2 value read while polling for state changes, and then
reuse this value when determining for which reason the loops were exited.
This is a small optimization which saves a couple of bus accesses for
memory mapped IO registers.

Note: checkpatch doesn't like this ('assigning in if condition'), but it seems
like the cleanest implementation.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/intel_i2c.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 41f9ae2..450f2b8 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -244,6 +244,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct drm_i915_private *dev_priv = adapter->algo_data;
int i, reg_offset;
int ret = 0;
+   u32 gmbus2 = 0;

if (bus->force_bit)
return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs,
@@ -297,12 +298,12 @@ gmbus_xfer(struct i2c_adapter *adapter,
do {
u32 val, loop = 0;

-   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
+   if (wait_for((gmbus2 = I915_READ(GMBUS2 +
+reg_offset)) &
 (GMBUS_SATOER | GMBUS_HW_RDY),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset) &
-   GMBUS_SATOER)
+   if (gmbus2 & GMBUS_SATOER)
goto clear_err;

val = I915_READ(GMBUS3 + reg_offset);
@@ -336,21 +337,21 @@ gmbus_xfer(struct i2c_adapter *adapter,
I915_WRITE(GMBUS3 + reg_offset, val);
POSTING_READ(GMBUS2 + reg_offset);

-   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
+   if (wait_for((gmbus2 = I915_READ(GMBUS2 +
+reg_offset)) &
 (GMBUS_SATOER | GMBUS_HW_RDY),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset) &
- GMBUS_SATOER)
+   if (gmbus2 & GMBUS_SATOER)
goto clear_err;
}
}

-   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
+   if (wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
 (GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset) & GMBUS_SATOER)
+   if (gmbus2 & GMBUS_SATOER)
goto clear_err;
}

@@ -366,7 +367,7 @@ clear_err:
ret = -ENXIO;

 done:
-   if (I915_READ(GMBUS2 + reg_offset) & GMBUS_HW_WAIT_PHASE) {
+   if (gmbus2 & GMBUS_HW_WAIT_PHASE) {
I915_WRITE(GMBUS1 + reg_offset,
   GMBUS_CYCLE_STOP | GMBUS_SW_RDY);
POSTING_READ(GMBUS2 + reg_offset);
-- 
1.7.7.3

[PATCH 8/9] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

[Daniel Kurtz]

It is very common for an i2c device to require a small 1 or 2 byte write
followed by a read.  For example, when reading from an i2c EEPROM it is
common to write and address, offset or index followed by a reading some
values.

The i915 gmbus controller provides a special "INDEX" cycle for performing
such a small write followed by a read.  The INDEX can be either one or two
bytes long.  The advantage of using such a cycle is that the CPU has
slightly less work to do once the read with INDEX cycle is started.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/intel_i2c.c |   32 ++--
 1 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index c3d8c70..41f9ae2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -256,12 +256,40 @@ gmbus_xfer(struct i2c_adapter *adapter,
I915_WRITE(GMBUS0 + reg_offset, bus->reg0);

for (i = 0; i < num; i++) {
-   u16 len = msgs[i].len;
-   u8 *buf = msgs[i].buf;
+   u16 len;
+   u8 *buf;
+   u32 gmbus5 = 0;
+   u32 gmbus1_index = 0;
+
+   /*
+* The gmbus controller can combine a 1 or 2 byte write with a
+* read that immediately follows it by using an "INDEX" cycle.
+*/
+   if (i + 1 < num &&
+   !(msgs[i].flags & I2C_M_RD) &&
+   (msgs[i + 1].flags & I2C_M_RD) &&
+   msgs[i].len <= 2) {
+   if (msgs[i].len == 2)
+   gmbus5 = GMBUS_2BYTE_INDEX_EN |
+msgs[i].buf[1] |
+(msgs[i].buf[0] << 8);
+   if (msgs[i].len == 1)
+   gmbus1_index = GMBUS_CYCLE_INDEX |
+  (msgs[i].buf[0] <<
+   GMBUS_SLAVE_INDEX_SHIFT);
+   i += 1;  /* set i to the index of the read xfer */
+   }
+
+   len = msgs[i].len;
+   buf = msgs[i].buf;
+
+   /* GMBUS5 holds 16-bit index, but must be 0 if not used */
+   I915_WRITE(GMBUS5 + reg_offset, gmbus5);

if (msgs[i].flags & I2C_M_RD) {
I915_WRITE(GMBUS1 + reg_offset,
   GMBUS_CYCLE_WAIT |
+  gmbus1_index |
   (len << GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_READ | GMBUS_SW_RDY);
-- 
1.7.7.3

[PATCH 7/9] drm/i915/intel_i2c: use WAIT cycle, not STOP

[Daniel Kurtz]

The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
transaction) during a DATA or WAIT phase.  In other words, the
controller rejects a STOP requested as part of the first transaction in a
sequence.

Thus, for the first transaction we must always use a WAIT cycle, detect
when the device has finished (and is in a WAIT phase), and then either
start the next transaction, or, if there are no more transactions,
generate a STOP cycle.

Note: Theoretically, the last transaction of a multi-transaction sequence
could initiate a STOP cycle.  However, this slight optimization is left
for another patch.  We return -ETIMEDOUT if the hardware doesn't
deactivate after the STOP cycle.

This patch also takes advantage (in the write path) of the double-buffered
GMBUS3 data register by writing two 4-byte words before the first wait for
HW_RDY.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/intel_i2c.c |   42 +
 1 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 2cdd531..c3d8c70 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -261,7 +261,7 @@ gmbus_xfer(struct i2c_adapter *adapter,

if (msgs[i].flags & I2C_M_RD) {
I915_WRITE(GMBUS1 + reg_offset,
-  GMBUS_CYCLE_WAIT | (i + 1 == num ? 
GMBUS_CYCLE_STOP : 0) |
+  GMBUS_CYCLE_WAIT |
   (len << GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_READ | GMBUS_SW_RDY);
@@ -273,7 +273,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
 (GMBUS_SATOER | GMBUS_HW_RDY),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset) & 
GMBUS_SATOER)
+   if (I915_READ(GMBUS2 + reg_offset) &
+   GMBUS_SATOER)
goto clear_err;

val = I915_READ(GMBUS3 + reg_offset);
@@ -292,20 +293,13 @@ gmbus_xfer(struct i2c_adapter *adapter,

I915_WRITE(GMBUS3 + reg_offset, val);
I915_WRITE(GMBUS1 + reg_offset,
-  (i + 1 == num ? GMBUS_CYCLE_STOP : 
GMBUS_CYCLE_WAIT) |
+  GMBUS_CYCLE_WAIT |
   (msgs[i].len << GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
POSTING_READ(GMBUS2 + reg_offset);

while (len) {
-   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
-(GMBUS_SATOER | GMBUS_HW_RDY),
-50))
-   goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset) & 
GMBUS_SATOER)
-   goto clear_err;
-
val = loop = 0;
do {
val |= *buf++ << (8 * loop);
@@ -313,11 +307,18 @@ gmbus_xfer(struct i2c_adapter *adapter,

I915_WRITE(GMBUS3 + reg_offset, val);
POSTING_READ(GMBUS2 + reg_offset);
+
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
+(GMBUS_SATOER | GMBUS_HW_RDY),
+50))
+   goto timeout;
+   if (I915_READ(GMBUS2 + reg_offset) &
+ GMBUS_SATOER)
+   goto clear_err;
}
}

-   if (i + 1 < num &&
-   wait_for(I915_READ(GMBUS2 + reg_offset) &
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
 (GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
 50))
goto timeout;
@@ -337,9 +338,22 @@ clear_err:
ret = -ENXIO;

 done:
-   /* Mark the GMBUS interface as disabled. We will re-enable it at the
-* start of the next xfer, till then let it sleep.
+   if (I915_READ(GMBUS2 + reg_offset) & GMBUS_HW_WAIT_PHASE) {
+   I915_WRITE(GMBUS1 + reg_offset,
+  GMBUS_CYCLE_STOP | GMBUS_SW_RDY);
+   POSTING_READ(GMBUS2 + reg_offset);
+   }
+
+   /* Mark the GMBUS interface as disabled after 

[PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

[Daniel Kurtz]

Return -ENXIO if a device NAKs a transaction.

Note: We should return -ETIMEDOUT, too if the transaction times out,
however, that error path is currently handled by the 'bit-bang fallback'.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/intel_i2c.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b97392c..2cdd531 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -243,6 +243,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
   adapter);
struct drm_i915_private *dev_priv = adapter->algo_data;
int i, reg_offset;
+   int ret = 0;

if (bus->force_bit)
return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs,
@@ -333,6 +334,7 @@ clear_err:
 */
I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
I915_WRITE(GMBUS1 + reg_offset, 0);
+   ret = -ENXIO;

 done:
/* Mark the GMBUS interface as disabled. We will re-enable it at the
@@ -342,7 +344,7 @@ done:

mutex_unlock(_priv->gmbus_mutex);

-   return i;
+   return ret ?: i;

 timeout:
DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d 
[%s]\n",
-- 
1.7.7.3

[PATCH 5/9] drm/i915/intel_i2c: add locking around i2c algorithm accesses

[Daniel Kurtz]

The i915 has multiple i2c adapters.  However, they all share a single
single set of i2c control registers (algorithm).  Thus, different threads
trying to access different adapters could interfere with each other.

Note: different threads trying to access the same channel is already
handled in the i2c-core using the i2c adapter lock.

This patch adds a mutex to serialize access to the gmbus_xfer routine.
Note: the same mutex serializes both bit banged and native xfers.

Signed-off-by: Yufeng Shen 
Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_i2c.c |   12 
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64d1276..c7f0809 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -301,6 +301,7 @@ typedef struct drm_i915_private {
struct i2c_adapter *force_bit;
u32 reg0;
} *gmbus;
+   struct mutex gmbus_mutex;

struct pci_dev *bridge_dev;
struct intel_ring_buffer ring[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b2cc7f2..b97392c 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -213,6 +213,8 @@ intel_i2c_quirk_xfer(struct drm_i915_private *dev_priv,
   adapter);
int ret;

+   mutex_lock(_priv->gmbus_mutex);
+
intel_i2c_reset(dev_priv->dev);

intel_i2c_quirk_set(dev_priv, true);
@@ -226,6 +228,8 @@ intel_i2c_quirk_xfer(struct drm_i915_private *dev_priv,
set_clock(gpio, 1);
intel_i2c_quirk_set(dev_priv, false);

+   mutex_unlock(_priv->gmbus_mutex);
+
return ret;
 }

@@ -244,6 +248,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs,
num);

+   mutex_lock(_priv->gmbus_mutex);

reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0;

@@ -334,6 +339,9 @@ done:
 * start of the next xfer, till then let it sleep.
 */
I915_WRITE(GMBUS0 + reg_offset, 0);
+
+   mutex_unlock(_priv->gmbus_mutex);
+
return i;

 timeout:
@@ -341,6 +349,8 @@ timeout:
 bus->reg0 & 0xff, bus->adapter.name);
I915_WRITE(GMBUS0 + reg_offset, 0);

+   mutex_unlock(_priv->gmbus_mutex);
+
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff);
if (!bus->force_bit)
@@ -383,6 +393,8 @@ int intel_setup_gmbus(struct drm_device *dev)
if (dev_priv->gmbus == NULL)
return -ENOMEM;

+   mutex_init(_priv->gmbus_mutex);
+
for (i = 0; i < ARRAY_SIZE(gmbus_ports); i++) {
struct intel_gmbus *bus = _priv->gmbus[i];
int port = i + 1; /* +1 to map gmbus index to pin pair */
-- 
1.7.7.3

[PATCH 4/9] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Kurtz]

There is no "disabled" port 0.  So, don't even try to initialize/scan
it, etc.  This saves a bit of time when initializing the driver, since
the we can avoid a 50ms timeout waiting for a device to respond on
a port that doesn't even exist.

Similarly, don't initialize the reserved port, either.

Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/i915_reg.h  |1 -
 drivers/gpu/drm/i915/intel_i2c.c |   64 ++
 2 files changed, 30 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 56af0df..89cace2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -699,7 +699,6 @@
 #define   GMBUS_PORT_DPB   5 /* SDVO, HDMIB */
 #define   GMBUS_PORT_DPD   6 /* HDMID */
 #define   GMBUS_PORT_RESERVED  7 /* 7 reserved */
-#define   GMBUS_NUM_PORTS  8
 #define GMBUS1 0x5104 /* command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
 #define   GMBUS_SW_RDY (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index dd8c699..b2cc7f2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -35,6 +35,20 @@
 #include "i915_drm.h"
 #include "i915_drv.h"

+struct gmbus_port {
+   const char *name;
+   int reg;
+};
+
+static const struct gmbus_port gmbus_ports[] = {
+   { "ssc", GPIOB },
+   { "vga", GPIOA },
+   { "panel", GPIOC },
+   { "dpc", GPIOD },
+   { "dpb", GPIOE },
+   { "dpd", GPIOF },
+};
+
 /* Intel GPIO access functions */

 #define I2C_RISEFALL_TIME 20
@@ -150,32 +164,23 @@ static void set_data(void *data, int state_high)
 static struct i2c_adapter *
 intel_gpio_create(struct drm_i915_private *dev_priv, u32 pin)
 {
-   static const int map_pin_to_reg[] = {
-   0,
-   GPIOB,
-   GPIOA,
-   GPIOC,
-   GPIOD,
-   GPIOE,
-   GPIOF,
-   0,
-   };
struct intel_gpio *gpio;

-   if (pin >= ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])
+   pin -= 1;  /* NB: -1 to map pin pair to gmbus array index */
+   if (pin >= ARRAY_SIZE(gmbus_ports))
return NULL;

gpio = kzalloc(sizeof(struct intel_gpio), GFP_KERNEL);
if (gpio == NULL)
return NULL;

-   gpio->reg = map_pin_to_reg[pin];
+   gpio->reg = gmbus_ports[pin].reg;
if (HAS_PCH_SPLIT(dev_priv->dev))
gpio->reg += PCH_GPIOA - GPIOA;
gpio->dev_priv = dev_priv;

snprintf(gpio->adapter.name, sizeof(gpio->adapter.name),
-"i915 GPIO%c", "?BACDE?F"[pin]);
+"i915 GPIO%c", "BACDEF"[pin]);
gpio->adapter.owner = THIS_MODULE;
gpio->adapter.algo_data = >algo;
gpio->adapter.dev.parent = _priv->dev->pdev->dev;
@@ -370,33 +375,22 @@ static const struct i2c_algorithm gmbus_algorithm = {
  */
 int intel_setup_gmbus(struct drm_device *dev)
 {
-   static const char *names[GMBUS_NUM_PORTS] = {
-   "disabled",
-   "ssc",
-   "vga",
-   "panel",
-   "dpc",
-   "dpb",
-   "dpd",
-   "reserved",
-   };
struct drm_i915_private *dev_priv = dev->dev_private;
int ret, i;

-   dev_priv->gmbus = kcalloc(sizeof(struct intel_gmbus), GMBUS_NUM_PORTS,
- GFP_KERNEL);
+   dev_priv->gmbus = kcalloc(sizeof(struct intel_gmbus),
+ ARRAY_SIZE(gmbus_ports), GFP_KERNEL);
if (dev_priv->gmbus == NULL)
return -ENOMEM;

-   for (i = 0; i < GMBUS_NUM_PORTS; i++) {
+   for (i = 0; i < ARRAY_SIZE(gmbus_ports); i++) {
struct intel_gmbus *bus = _priv->gmbus[i];
+   int port = i + 1; /* +1 to map gmbus index to pin pair */

bus->adapter.owner = THIS_MODULE;
bus->adapter.class = I2C_CLASS_DDC;
-   snprintf(bus->adapter.name,
-sizeof(bus->adapter.name),
-"i915 gmbus %s",
-names[i]);
+   snprintf(bus->adapter.name, sizeof(bus->adapter.name),
+"i915 gmbus %s", gmbus_ports[i].name);

bus->adapter.dev.parent = >pdev->dev;
bus->adapter.algo_data  = dev_priv;
@@ -407,10 +401,10 @@ int intel_setup_gmbus(struct drm_device *dev)
goto err;

/* By default use a conservative clock rate */
-   bus->reg0 = i | GMBUS_RATE_100KHZ;
+   bus->reg0 = port | GMBUS_RATE_100KHZ;

/* XXX force bit banging until GMBUS is fully debugged */
-   bus->force_bit = intel_gpio_create(dev_priv, i);
+   bus->force_bit = 

[PATCH 3/9] drm/i915/intel_i2c: refactor using intel_gmbus_get_bus

[Daniel Kurtz]

Instead of letting other modules directly access the ->gmbus array,
introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
a given gmbus pin pair identifier.  This API enables later refactoring
of the gmbus pin pair list.

Note: It is critical that intel_setup_gmbus() gets called before
intel_gmbus_get_bus().

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/i915_drv.h|4 +++-
 drivers/gpu/drm/i915/intel_bios.c  |   10 ++
 drivers/gpu/drm/i915/intel_crt.c   |   13 ++---
 drivers/gpu/drm/i915/intel_drv.h   |3 ++-
 drivers/gpu/drm/i915/intel_dvo.c   |4 ++--
 drivers/gpu/drm/i915/intel_hdmi.c  |   29 ++---
 drivers/gpu/drm/i915/intel_i2c.c   |6 ++
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |6 +++---
 drivers/gpu/drm/i915/intel_sdvo.c  |   10 --
 10 files changed, 47 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9689ca3..64d1276 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -391,7 +391,7 @@ typedef struct drm_i915_private {

struct notifier_block lid_notifier;

-   int crt_ddc_pin;
+   struct i2c_adapter *crt_ddc;
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
@@ -1274,6 +1274,8 @@ extern int i915_restore_state(struct drm_device *dev);
 /* intel_i2c.c */
 extern int intel_setup_gmbus(struct drm_device *dev);
 extern void intel_teardown_gmbus(struct drm_device *dev);
+extern struct i2c_adapter *intel_gmbus_get_bus(
+   struct drm_i915_private *dev_priv, int pin);
 extern void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed);
 extern void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit);
 extern inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 63880e2..16456f7 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -330,12 +330,14 @@ parse_general_definitions(struct drm_i915_private 
*dev_priv,
u16 block_size = get_blocksize(general);
if (block_size >= sizeof(*general)) {
int bus_pin = general->crt_ddc_gmbus_pin;
+   struct i2c_adapter *i2c;
DRM_DEBUG_KMS("crt_ddc_bus_pin: %d\n", bus_pin);
-   if (bus_pin >= 1 && bus_pin <= 6)
-   dev_priv->crt_ddc_pin = bus_pin;
+   i2c = intel_gmbus_get_bus(dev_priv, bus_pin);
+   if (i2c)
+   dev_priv->crt_ddc = i2c;
} else {
DRM_DEBUG_KMS("BDB_GD too small (%d). Invalid.\n",
- block_size);
+ block_size);
}
}
 }
@@ -599,7 +601,7 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;

-   dev_priv->crt_ddc_pin = GMBUS_PORT_VGADDC;
+   dev_priv->crt_ddc = intel_gmbus_get_bus(dev_priv, GMBUS_PORT_VGADDC);

/* LFP panel data */
dev_priv->lvds_dither = 1;
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index dd729d4..71d6a50 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -275,12 +275,11 @@ static bool intel_crt_detect_ddc(struct drm_connector 
*connector)
if (crt->base.type != INTEL_OUTPUT_ANALOG)
return false;

-   if (intel_ddc_probe(>base, dev_priv->crt_ddc_pin)) {
+   if (intel_ddc_probe(>base, dev_priv->crt_ddc)) {
struct edid *edid;
bool is_digital = false;

-   edid = drm_get_edid(connector,
-   _priv->gmbus[dev_priv->crt_ddc_pin].adapter);
+   edid = drm_get_edid(connector, dev_priv->crt_ddc);
/*
 * This may be a DVI-I connector with a shared DDC
 * link between analog and digital outputs, so we
@@ -484,14 +483,14 @@ static int intel_crt_get_modes(struct drm_connector 
*connector)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;

-   ret = intel_ddc_get_modes(connector,
-
_priv->gmbus[dev_priv->crt_ddc_pin].adapter);
+   ret = intel_ddc_get_modes(connector, dev_priv->crt_ddc);
if (ret || !IS_G4X(dev))
return ret;

/* Try to probe digital port for output in DVI-I -> VGA mode. */
-   return intel_ddc_get_modes(connector,
-  _priv->gmbus[GMBUS_PORT_DPB].adapter);
+   return 

[PATCH 2/9] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Daniel Kurtz]

According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
Pin pair 7 is a reserved pair.

[1] Documentation for [DevSNB+] and [DevIBX], as found on
http://intellinuxgraphics.org

Note: the "reserved" and "disabled" pairs do not actually map to a
physical pair of pins, nor GPIO regs and shouldn't be initialized or used.
Fixing this is left for a later patch.

This bug has not been noticed for two reasons:
 1) "gmbus" mode is currently disabled - all transfers are actually using
"bit-bang" mode which uses the GPIO port 5 (the "HDMI/DPD CTLDATA/CLK"
pair), at register 0x5024 (defined as GPIOF i915_reg.h).
Since this is the correct pair of pins for HDMI1, transfers succeed.

 2) Even if gmbus mode is re-enabled, the first attempted transaction
will fail because it tries to use the wrong ("Reserved") pin pair.
However, the driver immediately falls back again to the bit-bang
method, which correctly uses GPIOF, so again, transfers succeed.

However, if gmbus mode is re-enabled and the GPIO fall-back mode is
disabled, then reading an attached monitor's EDID fail.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/i915_reg.h  |6 +++---
 drivers/gpu/drm/i915/intel_i2c.c |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 03c53fc..56af0df 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -697,9 +697,9 @@
 #define   GMBUS_PORT_PANEL 3
 #define   GMBUS_PORT_DPC   4 /* HDMIC */
 #define   GMBUS_PORT_DPB   5 /* SDVO, HDMIB */
- /* 6 reserved */
-#define   GMBUS_PORT_DPD   7 /* HDMID */
-#define   GMBUS_NUM_PORTS   8
+#define   GMBUS_PORT_DPD   6 /* HDMID */
+#define   GMBUS_PORT_RESERVED  7 /* 7 reserved */
+#define   GMBUS_NUM_PORTS  8
 #define GMBUS1 0x5104 /* command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
 #define   GMBUS_SW_RDY (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index a94e383..45ce1d2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -157,8 +157,8 @@ intel_gpio_create(struct drm_i915_private *dev_priv, u32 
pin)
GPIOC,
GPIOD,
GPIOE,
-   0,
GPIOF,
+   0,
};
struct intel_gpio *gpio;

@@ -377,8 +377,8 @@ int intel_setup_gmbus(struct drm_device *dev)
"panel",
"dpc",
"dpb",
-   "reserved",
"dpd",
+   "reserved",
};
struct drm_i915_private *dev_priv = dev->dev_private;
int ret, i;
-- 
1.7.7.3

[PATCH 1/9] drm/i915/intel_i2c: cleanup

[Daniel Kurtz]

80 col, spaces around operators and other basic cleanup.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/intel_i2c.c |   24 
 1 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d30..a94e383 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -236,8 +236,9 @@ gmbus_xfer(struct i2c_adapter *adapter,
int i, reg_offset;

if (bus->force_bit)
-   return intel_i2c_quirk_xfer(dev_priv,
-   bus->force_bit, msgs, num);
+   return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs,
+   num);
+

reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0;

@@ -253,11 +254,13 @@ gmbus_xfer(struct i2c_adapter *adapter,
   (len << GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_READ | GMBUS_SW_RDY);
-   POSTING_READ(GMBUS2+reg_offset);
+   POSTING_READ(GMBUS2 + reg_offset);
do {
u32 val, loop = 0;

-   if (wait_for(I915_READ(GMBUS2 + reg_offset) & 
(GMBUS_SATOER | GMBUS_HW_RDY), 50))
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
+(GMBUS_SATOER | GMBUS_HW_RDY),
+50))
goto timeout;
if (I915_READ(GMBUS2 + reg_offset) & 
GMBUS_SATOER)
goto clear_err;
@@ -282,10 +285,12 @@ gmbus_xfer(struct i2c_adapter *adapter,
   (msgs[i].len << GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
-   POSTING_READ(GMBUS2+reg_offset);
+   POSTING_READ(GMBUS2 + reg_offset);

while (len) {
-   if (wait_for(I915_READ(GMBUS2 + reg_offset) & 
(GMBUS_SATOER | GMBUS_HW_RDY), 50))
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) &
+(GMBUS_SATOER | GMBUS_HW_RDY),
+50))
goto timeout;
if (I915_READ(GMBUS2 + reg_offset) & 
GMBUS_SATOER)
goto clear_err;
@@ -296,11 +301,14 @@ gmbus_xfer(struct i2c_adapter *adapter,
} while (--len && ++loop < 4);

I915_WRITE(GMBUS3 + reg_offset, val);
-   POSTING_READ(GMBUS2+reg_offset);
+   POSTING_READ(GMBUS2 + reg_offset);
}
}

-   if (i + 1 < num && wait_for(I915_READ(GMBUS2 + reg_offset) & 
(GMBUS_SATOER | GMBUS_HW_WAIT_PHASE), 50))
+   if (i + 1 < num &&
+   wait_for(I915_READ(GMBUS2 + reg_offset) &
+(GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
+50))
goto timeout;
if (I915_READ(GMBUS2 + reg_offset) & GMBUS_SATOER)
goto clear_err;
-- 
1.7.7.3

[PATCH 0/9] drm/i915/intel_i2c: fix gmbus writes and related issues

[Daniel Kurtz]

This patchset addresses a couple of issues with the i915 gmbus implementation:
  * fixes misassigned pin port pair for HDMI-D
  * fixes write transactions when they are the only transaction requested
(including large >4-byte writes)
  * returns -ENXIO and -ETIMEDOUT as appropriate so upper layers can handled
i2c transaction failures
  * optimizes the typical read transaction case by using the INDEX cycle

The patchset should apply cleanly onto linus/master.
It is inspired by, but completely supercedes, a similar patch submitted
recently by Benson Leung (bleung at chromium.org).
I'd be happy to rebase on a different tree if necessary.

Note: 
There is one more patch in the set which I have not included here.  It enables
the PCH GMBUS interrupt and makes use of it to eliminate the very slow
'wait_for' polling loop.  This patch was not included, however, because there
is at least one case I have discovered where the i915 driver issues a GMBUS
transaction AFTER its interrupts have been initialized, but BEFORE it they have
been enabled.  Both the gmbus transaction and irq initialization occur during
i915_load_modeset_init(), but the gmbus transaction happens first, during:
  intel_modeset_init()
intel_setup_outputs()
  intel_lvds_init()
drm_get_edid()
Is there a way to switch the order of these to events?
Or does it make more sense for the gmbus driver to check a "bool irq_enabled",
and choose whether to poll or use the GMBUS interrupt?
... or both?


Daniel Kurtz (9):
  drm/i915/intel_i2c: cleanup
  drm/i915/intel_i2c: assign HDMI port D to pin pair 6
  drm/i915/intel_i2c: refactor using intel_gmbus_get_bus
  drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments
  drm/i915/intel_i2c: add locking around i2c algorithm accesses
  drm/i915/intel_i2c: return -ENXIO for device NAK
  drm/i915/intel_i2c: use WAIT cycle, not STOP
  drm/i915/intel_i2c: use INDEX cycles for i2c read transactions
  drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop

 drivers/gpu/drm/i915/i915_drv.h|5 +-
 drivers/gpu/drm/i915/i915_reg.h|5 +-
 drivers/gpu/drm/i915/intel_bios.c  |   10 ++-
 drivers/gpu/drm/i915/intel_crt.c   |   13 ++--
 drivers/gpu/drm/i915/intel_drv.h   |3 +-
 drivers/gpu/drm/i915/intel_dvo.c   |4 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |   29 +++---
 drivers/gpu/drm/i915/intel_i2c.c   |  175 +---
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |6 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   10 +--
 11 files changed, 165 insertions(+), 97 deletions(-)

-- 
1.7.7.3

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #58064|text/x-log  |text/plain
  mime type||
  Attachment #58064|0   |1
   is patch||

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

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #58063|application/octet-stream|text/plain
  mime type||
  Attachment #58063|0   |1
   is patch||

-- 
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: skip cb/db checking if SX_MISC is 1 on r600+

[Alex Deucher]

On Wed, Mar 7, 2012 at 6:56 PM, Marek Ol??k  wrote:
> Signed-off-by: Marek Ol??k 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/evergreen_cs.c ? ? | ? ?8 
> ?drivers/gpu/drm/radeon/r600_cs.c ? ? ? ? ?| ? ?8 
> ?drivers/gpu/drm/radeon/reg_srcs/cayman ? ?| ? ?1 -
> ?drivers/gpu/drm/radeon/reg_srcs/evergreen | ? ?1 -
> ?drivers/gpu/drm/radeon/reg_srcs/r600 ? ? ?| ? ?1 -
> ?5 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index bc6a2ea..78d115a 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -85,6 +85,7 @@ struct evergreen_cs_track {
> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? db_s_write_offset;
> ? ? ? ?struct radeon_bo ? ? ? ?*db_s_read_bo;
> ? ? ? ?struct radeon_bo ? ? ? ?*db_s_write_bo;
> + ? ? ? bool ? ? ? ? ? ? ? ? ? ?sx_misc_kill_all_prims;
> ?};
>
> ?static u32 evergreen_cs_get_aray_mode(u32 tiling_flags)
> @@ -162,6 +163,7 @@ static void evergreen_cs_track_init(struct 
> evergreen_cs_track *track)
> ? ? ? ? ? ? ? ?track->vgt_strmout_bo_offset[i] = 0x;
> ? ? ? ? ? ? ? ?track->vgt_strmout_bo_mc[i] = 0x;
> ? ? ? ?}
> + ? ? ? track->sx_misc_kill_all_prims = false;
> ?}
>
> ?struct eg_surface {
> @@ -821,6 +823,9 @@ static int evergreen_cs_track_check(struct 
> radeon_cs_parser *p)
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> + ? ? ? if (track->sx_misc_kill_all_prims)
> + ? ? ? ? ? ? ? return 0;
> +
> ? ? ? ?/* check that we have a cb for each enabled target
> ? ? ? ? */
> ? ? ? ?tmp = track->cb_target_mask;
> @@ -1748,6 +1753,9 @@ static int evergreen_cs_check_reg(struct 
> radeon_cs_parser *p, u32 reg, u32 idx)
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> ? ? ? ? ? ? ? ?break;
> + ? ? ? case SX_MISC:
> + ? ? ? ? ? ? ? track->sx_misc_kill_all_prims = (radeon_get_ib_value(p, idx) 
> & 0x1) != 0;
> + ? ? ? ? ? ? ? break;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?dev_warn(p->dev, "forbidden register 0x%08x at %d\n", reg, 
> idx);
> ? ? ? ? ? ? ? ?return -EINVAL;
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c 
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 5cbe948..abddfd0 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -74,6 +74,7 @@ struct r600_cs_track {
> ? ? ? ?u32 ? ? ? ? ? ? ? ? ? ? db_offset;
> ? ? ? ?struct radeon_bo ? ? ? ?*db_bo;
> ? ? ? ?u64 ? ? ? ? ? ? ? ? ? ? db_bo_mc;
> + ? ? ? bool ? ? ? ? ? ? ? ? ? ?sx_misc_kill_all_prims;
> ?};
>
> ?#define FMT_8_BIT(fmt, vc) ? [fmt] = { 1, 1, 1, vc, CHIP_R600 }
> @@ -322,6 +323,7 @@ static void r600_cs_track_init(struct r600_cs_track 
> *track)
> ? ? ? ? ? ? ? ?track->vgt_strmout_bo_offset[i] = 0x;
> ? ? ? ? ? ? ? ?track->vgt_strmout_bo_mc[i] = 0x;
> ? ? ? ?}
> + ? ? ? track->sx_misc_kill_all_prims = false;
> ?}
>
> ?static int r600_cs_track_validate_cb(struct radeon_cs_parser *p, int i)
> @@ -479,6 +481,9 @@ static int r600_cs_track_check(struct radeon_cs_parser *p)
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> + ? ? ? if (track->sx_misc_kill_all_prims)
> + ? ? ? ? ? ? ? return 0;
> +
> ? ? ? ?/* check that we have a cb for each enabled target, we don't check
> ? ? ? ? * shader_mask because it seems mesa isn't always setting it :(
> ? ? ? ? */
> @@ -1279,6 +1284,9 @@ static int r600_cs_check_reg(struct radeon_cs_parser 
> *p, u32 reg, u32 idx)
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> ? ? ? ? ? ? ? ?break;
> + ? ? ? case SX_MISC:
> + ? ? ? ? ? ? ? track->sx_misc_kill_all_prims = (radeon_get_ib_value(p, idx) 
> & 0x1) != 0;
> + ? ? ? ? ? ? ? break;
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?dev_warn(p->dev, "forbidden register 0x%08x at %d\n", reg, 
> idx);
> ? ? ? ? ? ? ? ?return -EINVAL;
> diff --git a/drivers/gpu/drm/radeon/reg_srcs/cayman 
> b/drivers/gpu/drm/radeon/reg_srcs/cayman
> index 7b526d3..2d30b06 100644
> --- a/drivers/gpu/drm/radeon/reg_srcs/cayman
> +++ b/drivers/gpu/drm/radeon/reg_srcs/cayman
> @@ -208,7 +208,6 @@ cayman 0x9400
> ?0x00028344 PA_SC_VPORT_ZMAX_14
> ?0x00028348 PA_SC_VPORT_ZMIN_15
> ?0x0002834C PA_SC_VPORT_ZMAX_15
> -0x00028350 SX_MISC
> ?0x00028354 SX_SURFACE_SYNC
> ?0x0002835C SX_SCATTER_EXPORT_SIZE
> ?0x00028380 SQ_VTX_SEMANTIC_0
> diff --git a/drivers/gpu/drm/radeon/reg_srcs/evergreen 
> b/drivers/gpu/drm/radeon/reg_srcs/evergreen
> index 7f43394..ba48394 100644
> --- a/drivers/gpu/drm/radeon/reg_srcs/evergreen
> +++ b/drivers/gpu/drm/radeon/reg_srcs/evergreen
> @@ -224,7 +224,6 @@ evergreen 0x9400
> ?0x00028344 PA_SC_VPORT_ZMAX_14
> ?0x00028348 PA_SC_VPORT_ZMIN_15
> ?0x0002834C PA_SC_VPORT_ZMAX_15
> -0x00028350 SX_MISC
> ?0x00028354 SX_SURFACE_SYNC
> ?0x00028380 SQ_VTX_SEMANTIC_0
> ?0x00028384 SQ_VTX_SEMANTIC_1
> diff --git a/drivers/gpu/drm/radeon/reg_srcs/r600 
> b/drivers/gpu/drm/radeon/reg_srcs/r600
> index 79d2455..626c24e 100644
> --- a/drivers/gpu/drm/radeon/reg_srcs/r600
> +++ 

[PATCH] drm/radeon/kms: fix hdmi duallink checks

[alexdeuc...@gmail.com]

From: Alex Deucher 

All pre-SI chips are limited to 165 Mhz for single link.
Code in question will be re-enabled when SI support is added.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44755
https://bugzilla.kernel.org/show_bug.cgi?id=42887

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index e7cb3ab..931a41d 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1057,7 +1057,7 @@ static int radeon_dvi_mode_valid(struct drm_connector 
*connector,
(radeon_connector->connector_object_id == 
CONNECTOR_OBJECT_ID_HDMI_TYPE_B))
return MODE_OK;
else if (radeon_connector->connector_object_id == 
CONNECTOR_OBJECT_ID_HDMI_TYPE_A) {
-   if (ASIC_IS_DCE3(rdev)) {
+   if (0) {
/* HDMI 1.3+ supports max clock of 340 Mhz */
if (mode->clock > 34)
return MODE_CLOCK_HIGH;
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 9419c51..26e9270 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -307,8 +307,6 @@ void radeon_panel_mode_fixup(struct drm_encoder *encoder,
 bool radeon_dig_monitor_is_duallink(struct drm_encoder *encoder,
u32 pixel_clock)
 {
-   struct drm_device *dev = encoder->dev;
-   struct radeon_device *rdev = dev->dev_private;
struct drm_connector *connector;
struct radeon_connector *radeon_connector;
struct radeon_connector_atom_dig *dig_connector;
@@ -326,7 +324,7 @@ bool radeon_dig_monitor_is_duallink(struct drm_encoder 
*encoder,
case DRM_MODE_CONNECTOR_HDMIB:
if (radeon_connector->use_digital) {
/* HDMI 1.3 supports up to 340 Mhz over single link */
-   if (ASIC_IS_DCE3(rdev) && 
drm_detect_hdmi_monitor(radeon_connector->edid)) {
+   if (0 && 
drm_detect_hdmi_monitor(radeon_connector->edid)) {
if (pixel_clock > 34)
return true;
else
@@ -348,7 +346,7 @@ bool radeon_dig_monitor_is_duallink(struct drm_encoder 
*encoder,
return false;
else {
/* HDMI 1.3 supports up to 340 Mhz over single link */
-   if (ASIC_IS_DCE3(rdev) && 
drm_detect_hdmi_monitor(radeon_connector->edid)) {
+   if (0 && 
drm_detect_hdmi_monitor(radeon_connector->edid)) {
if (pixel_clock > 34)
return true;
else
-- 
1.7.7.5

[PATCH] drm/i915: no-lvds quirk on MSI DC500

[Anisse Astier]

This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.

Cc: stable at kernel.org
Signed-off-by: Anisse Astier 
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index b103c3b..2dee11e 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -739,6 +739,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_BOARD_NAME, "AT5NM10T-I"),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = "MSI Wind Box DC500",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, "MICRO-STAR INTERNATIONAL 
CO., LTD"),
+   DMI_MATCH(DMI_BOARD_NAME, "MS-7469"),
+   },
+   },

{ } /* terminating entry */
 };
-- 
1.7.9

[PATCH] drm/radeon/kms: set SX_MISC in the r6xx blit code (v2)

[Alex Deucher]

On Wed, Mar 7, 2012 at 5:33 PM, Marek Ol??k  wrote:
> Mesa may set it to 1, causing all primitives to be killed.
>
> v2: also update the r7xx code
>
> Signed-off-by: Marek Ol??k 
> Cc: stable at kernel.org

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/r600_blit_shaders.c | ? ?8 
> ?1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c 
> b/drivers/gpu/drm/radeon/r600_blit_shaders.c
> index 2d1f6c5..73e2c7c 100644
> --- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
> +++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
> @@ -314,6 +314,10 @@ const u32 r6xx_default_state[] =
> ? ? ? ?0x, /* VGT_VTX_CNT_EN */
>
> ? ? ? ?0xc0016900,
> + ? ? ? 0x00d4,
> + ? ? ? 0x, /* SX_MISC */
> +
> + ? ? ? 0xc0016900,
> ? ? ? ?0x02c8,
> ? ? ? ?0x, /* VGT_STRMOUT_BUFFER_EN */
>
> @@ -626,6 +630,10 @@ const u32 r7xx_default_state[] =
> ? ? ? ?0x, /* VGT_VTX_CNT_EN */
>
> ? ? ? ?0xc0016900,
> + ? ? ? 0x00d4,
> + ? ? ? 0x, /* SX_MISC */
> +
> + ? ? ? 0xc0016900,
> ? ? ? ?0x02c8,
> ? ? ? ?0x, /* VGT_STRMOUT_BUFFER_EN */
>
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

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

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

--- Comment #15 from runetmember at gmail.com 2012-03-07 10:17:06 PST ---
Ok, filled: https://bugs.freedesktop.org/show_bug.cgi?id=47067

-- 
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/9] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Chris Wilson]

On Thu, 8 Mar 2012 02:02:03 +0800, Daniel Kurtz  wrote:
> I'm not sure what exactly you mean by gen2 and gen3 specs, but, as far as I
> can tell, the GPIO pin assignment is the same for both Cougar Point (Sandy
> Bridge) [1] and Ibex Peak (?) [2].  Although, the documentation is a bit
> confusing and it is difficult to tell.
> 
> [1] http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
> [2] http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf
> 
> What do you mean exactly by gen2 & gen3?  Can you point to docs?
gen2 == 830gm,845g,855gm,865g
gen3 == 915g,945g,PineView

Those docs have not been completely scrubbed and made public yet.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] r6xx: initialize SX_MISC

[Marek Olšák]

If Mesa set it to 1, the DDX would not render anything = the monitor would
basically freeze.
---
If it's right, please apply it to xf86-video-ati. I don't have commit access.

 src/r6xx_accel.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/r6xx_accel.c b/src/r6xx_accel.c
index 8e6bffa..ab878c3 100644
--- a/src/r6xx_accel.c
+++ b/src/r6xx_accel.c
@@ -1200,6 +1200,7 @@ r600_set_default_state(ScrnInfoPtr pScrn, drmBufPtr ib)
 E32(ib, 0); // VGT_VTX_CNT_EN

 EREG(ib, VGT_STRMOUT_BUFFER_EN,   0);
+EREG(ib, SX_MISC, 0);
 END_BATCH();
 }

-- 
1.7.5.4

[PATCH] drm/radeon/kms: set SX_MISC in the r6xx blit code

[Marek Olšák]

Mesa may set it to 1, causing all primitives to be killed.

Signed-off-by: Marek Ol??k 
---
I hope it's right.

 drivers/gpu/drm/radeon/r600_blit_shaders.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c 
b/drivers/gpu/drm/radeon/r600_blit_shaders.c
index 2d1f6c5..ccec7d2 100644
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
@@ -314,6 +314,10 @@ const u32 r6xx_default_state[] =
0x, /* VGT_VTX_CNT_EN */

0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */
+
+   0xc0016900,
0x02c8,
0x, /* VGT_STRMOUT_BUFFER_EN */

-- 
1.7.5.4

No subject

by the DMM so that we can do the PAT programming and that can only be
gotten from the hwmod entry.  And if you use the hwmod device entry,
you have to match the name used for that entry.

Regards,

Andy

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote:
> On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen  
> wrote:

> > Hmm, why does the drm core care about it?
> 
> Because it is the one generating the bus-id.. see
> drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
> 
> Anyways, it's just a detail about how libdrm/drmOpen() can
> differentiate between multiple instances of the same driver, similar
> to how PCI bus-id is used in the desktop world.  It is not difficult
> to change in drm_platform_set_busid(), although not sure if that would
> be considered an ABI change to userspace.  (Maybe it is less critical,
> I'm under the impression that other platform-drm users didn't even
> realize we had a bus-id.)

Ok. Well, I'm fine with id 0 also, if it makes sense in the DRM side. It
was just something that caught my eye.

> > Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
> > a value like that without any possibility to adjust it just sounds like
> > a rather bad thing.
> 
> The main requirement is that, on omap3 or before (platforms without
> DMM) you need enough to allocate all of your scanout buffers.
> 
> I'm not against having a bootarg to adjust, although I strongly prefer
> sane defaults and not requiring a million bootargs just to boot in
> some usable fashion.

Well, those are two different things. I'm fine with a default of 32MB.
My point was, what if I need more, or I don't need any.

 Tomi

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

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
> 
> 
> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen 
> wrote:
> 
> 
> I have to say I don't know much about DMM, but my
> understanding is that
> DMM is a bigger entity, of which TILER is only a small part,
> and DMM
> manages all memory accesses.
> 
> Can there be other users for the DMM than DRM? I know there
> could be
> other users for the TILER, and I know you want to combine that
> with the
> DRM driver, but I'm wondering about the other parts of DMM
> than the
> TILER.
> 
> Somehow having a DMM driver inside omapdrm sounds strange.
> 
> 
> The DMM does indeed contain a number of entities.  However, the TILER
> portion is the only part that requires a driver.  All other register
> modifications (LISA map settings, EMIF, etc) are done statically in
> the loader or u-boot and never changed again.  As such, DMM has become
> synonymous with TILER.

Ok. Well, as I said, I don't know much about that, just sounds rather
strange to me =).

Does this "DMM has become synonymous" mean that people just started
calling TILER DMM, and thus the name has stuck, or are there technical
reasons to handle it as DMM in the kernel? If the former, and if TILER
is the technically exact name for it, perhaps it would make sense to
call it TILER, as that's what (at least I) would be looking for if I
read the TRM and try to find the code for the TILER.

 Tomi


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

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen  
> wrote:
> > On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
> >> On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen  
> >> wrote:
> >
> >> > Can there be more than one omapdrm device? I guess not. If so, the id
> >> > should be -1.
> >>
> >> in the past, we have used multiple devices (using the platform-data to
> >> divide up the dss resources), although this was sort of a
> >> special-case.  But in theory you could have multiple.  (Think of a
> >> multi-seat scenario, where multiple compositors need to run and each
> >> need to be drm-master of their own device to do mode-setting on their
> >> corresponding display.)
> >>
> >> I think if we use .id = -1, then we'd end up with a funny looking
> >> bus-id for the device: "platform:omapdrm:-1"
> >
> > I don't know about that, but it's the way platform devices are meant to
> > be used if there can be only one instance. If the case where there are
> > multiple omapdrm devices is rather theoretical, or only used for certain
> > debugging scenarios or such, I think having the id as -1 in the mainline
> > is cleaner.
> 
> well, I don't care much one way or another, but need to check if there
> is a small patch needed in drm core code that generates the bus-id for
> .id = -1..

Hmm, why does the drm core care about it?

And generally, I think if the bus id is -1, there is no bus id in a
sense. For example, with bus id 0 you'll get a device "omapdrm.0". With
bus id -1 you'll get a device "omapdrm".

> >> >> +arch_initcall(omap_init_gpu);
> >> >> +
> >> >> +void omapdrm_reserve_vram(void)
> >> >> +{
> >> >> +#ifdef CONFIG_CMA
> >> >> + /*
> >> >> +  * Create private 32MiB contiguous memory area for omapdrm.0 
> >> >> device
> >> >> +  * TODO revisit size.. if uc/wc buffers are allocated from CMA 
> >> >> pages
> >> >> +  * then the amount of memory we need goes up..
> >> >> +  */
> >> >> + dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);
> >> >
> >> > What does this actually do? Does it reserve the memory, i.e. it's not
> >> > usable for others? If so, shouldn't there be a way for the user to
> >> > configure it?
> >>
> >> It can be re-used by others.. see http://lwn.net/Articles/479297/
> >
> > The link didn't tell much. I looked at the patches, and
> > dma_declare_contiguous allocates the memory with memblock_alloc. So is
> > that allocated memory available for any users? If so, why does the
> > function want a device pointer as an argument...
> >
> > Is the memory available for normal kmalloc, or only available via the
> > CMA functions? Surely there must be some downside to the above? =) And
> > if so, it should be configurable. You could have a board with no display
> > at all, and you probably don't want to have 32MB allocated for DRM in
> > that case.
> 
> Basically the short version is memory from a CMA carveout can be
> re-used for unpinnable memory.  Not kmalloc, but it can be used for
> anon userspace pages, for example.  Userspace needs memory too.

Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
a value like that without any possibility to adjust it just sounds like
a rather bad thing.

 Tomi

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

[Bug 47039] radeon: The kernel rejected CS

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

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

Sylvain R?ault  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Sylvain R?ault  2012-03-07 
05:53:23 PST ---
It's very good!

Thank you for the correction and your work in general

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

[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

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

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

--- Comment #14 from Alex Deucher  2012-03-07 05:37:50 PST 
---
(In reply to comment #13)
> 
> The interesting thing I notice: issue reproduceable only with OpenGL version 
> of
> KWin. I never can get it reproduced with OpenGL ES version of KWin.
> 
> Alex, I have the same issue or I need to fill separate bugreport?

Probably a separate issue.  Please file a new bug.

-- 
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/9] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:43 +0800, Daniel Kurtz  
wrote:
> According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
> actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
> Pin pair 7 is a reserved pair.
> 
> [1] Documentation for [DevSNB+] and [DevIBX], as found on
> http://intellinuxgraphics.org

The problem is I took those definitions from the gen2 specs, and munged
in the obvious changes with gen3... And it appears that the GPIO pin
assignment versus GMBUS has changed over the years. And so the can of
worms is opened!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

[Chris Wilson]

On Wed, 7 Mar 2012 20:41:03 +0800, Daniel Kurtz  wrote:
> On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson  
> wrote:
> > On Wed, ??7 Mar 2012 19:50:47 +0800, Daniel Kurtz  
> > wrote:
> >> Return -ENXIO if a device NAKs a transaction.
> >>
> >> Note: We should return -ETIMEDOUT, too if the transaction times out,
> >> however, that error path is currently handled by the 'bit-bang fallback'.
> >>
> >> Signed-off-by: Daniel Kurtz 
> >
> > Can you clarify what the rule is if an error is detected part-way
> > through a xfer?
> 
> A priceless comment from drivers/i2c/i2c-core::i2c_transfer...

Thanks, that is about as consistent as one expects with i2c. ;)

> This doesn't specify what to do if the transfer doesn't get an ACK
> during another phase of the transfer.
> However, it does say to send -ENXIO "if no ACK during address phase",
> which is a subset of the possible no-ACK conditions during a transfer.
>  Thus, I choose to return ENXIO in all no-ACK cases, to ensure we send
> it during the one case that is specified.

This (and a summary of the rest) deserves to be captured as a comment in
the code.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 4/9] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:45 +0800, Daniel Kurtz  
wrote:
> There is no "disabled" port 0.  So, don't even try to initialize/scan
> it, etc.  This saves a bit of time when initializing the driver, since
> the we can avoid a 50ms timeout waiting for a device to respond on
> a port that doesn't even exist.
> 
> Similarly, don't initialize the reserved port, either.

> @@ -150,32 +164,23 @@ static void set_data(void *data, int state_high)
>  static struct i2c_adapter *
>  intel_gpio_create(struct drm_i915_private *dev_priv, u32 pin)
>  {
> - static const int map_pin_to_reg[] = {
> - 0,
> - GPIOB,
> - GPIOA,
> - GPIOC,
> - GPIOD,
> - GPIOE,
> - GPIOF,
> - 0,
> - };
>   struct intel_gpio *gpio;
>  
> - if (pin >= ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])

And that doesn't do what your changelog proposes? Why?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 3/9] drm/i915/intel_i2c: refactor using intel_gmbus_get_bus

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:44 +0800, Daniel Kurtz  
wrote:
> Instead of letting other modules directly access the ->gmbus array,
> introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
> a given gmbus pin pair identifier.  This API enables later refactoring
> of the gmbus pin pair list.
> 
> Note: It is critical that intel_setup_gmbus() gets called before
> intel_gmbus_get_bus().

If you are going to rename it, perhaps a better choice than
intel_gmbus_get_bus(int gpio_pin) ?

intel_i2c_get_adapter(int gpio_pin) since the rest of the code really
does not care how the bits are transferred but that it interfaces using
i2c.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:47 +0800, Daniel Kurtz  
wrote:
> Return -ENXIO if a device NAKs a transaction.
> 
> Note: We should return -ETIMEDOUT, too if the transaction times out,
> however, that error path is currently handled by the 'bit-bang fallback'.
> 
> Signed-off-by: Daniel Kurtz 

Can you clarify what the rule is if an error is detected part-way
through a xfer?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 9/9] drm/i915/intel_i2c: reuse GMBUS2 value from polling loop

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:50 +0800, Daniel Kurtz  
wrote:
> Save the GMBUS2 value read while polling for state changes, and then
> reuse this value when determining for which reason the loops were exited.
> This is a small optimization which saves a couple of bus accesses for
> memory mapped IO registers.
> 
> Note: checkpatch doesn't like this ('assigning in if condition'), but it seems
> like the cleanest implementation.
> 
> Signed-off-by: Daniel Kurtz 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 3/9] drm/i915/intel_i2c: refactor using intel_gmbus_get_bus

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:44 +0800, Daniel Kurtz  
wrote:
> +struct i2c_adapter *intel_gmbus_get_bus(struct drm_i915_private *dev_priv,
> + int pin)
> +{
BUG_ON(pin >= GMBUS_NUM_PORTS);

> + return (pin < GMBUS_NUM_PORTS) ? _priv->gmbus[pin].adapter : NULL;
You just turned a programming error into a nearly undecipherable OOPS.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/9] drm/i915/intel_i2c: cleanup

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:42 +0800, Daniel Kurtz  
wrote:
> 80 col, spaces around operators and other basic cleanup.
> 
> Signed-off-by: Daniel Kurtz 
> ---
>  drivers/gpu/drm/i915/intel_i2c.c |   24 
>  1 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index d30..a94e383 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -236,8 +236,9 @@ gmbus_xfer(struct i2c_adapter *adapter,
>   int i, reg_offset;
>  
>   if (bus->force_bit)
> - return intel_i2c_quirk_xfer(dev_priv,
> - bus->force_bit, msgs, num);
> + return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs,
> + num);
> +
NAK just on that around. The new line was put there for a reason as
there is a distinction in the types of parameters, it visually grouped
the control arguments from the object.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

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

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

--- Comment #13 from runetmember at gmail.com 2012-03-07 03:58:22 PST ---
> I just tried with the latest Fedora 16 Final RC1 (using Linux 3.1.0 final), 
> and
I noticed the LVDS flickering actually happens *sometimes* also when booting
the laptop with lid open.

Same here on Acer Aspire 7560G (A8-3500M - Radeon HD 6620G) with Kubuntu 12.04
Beta 1 and external HDMI display (selected as main in xrandr settings). I
didn't try yet boot with disabled LVDS, but I indeed have flickering on LVDS in
some use-cases. For example every time when I use "carousel" KWin feature for
switch between applications by Alt+Tab.
Issue is reproduceable even when I boot without external display.

The interesting thing I notice: issue reproduceable only with OpenGL version of
KWin. I never can get it reproduced with OpenGL ES version of KWin.

Alex, I have the same issue or I need to fill separate bugreport?

-- 
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: fix a semaphore deadlock on pre cayman asics

[Christian König]

The out of order execution of semaphore commands on
pre cayman asics doesn't work correctly and can
cause deadlocks, so turn it off for now.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/r600.c  |3 +++
 drivers/gpu/drm/radeon/r600d.h |1 +
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 8a6d68c..f0b3323 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2362,6 +2362,9 @@ void r600_semaphore_ring_emit(struct radeon_device *rdev,
uint64_t addr = semaphore->gpu_addr;
unsigned sel = emit_wait ? PACKET3_SEM_SEL_WAIT : 
PACKET3_SEM_SEL_SIGNAL;

+   if (rdev->family < CHIP_CAYMAN)
+   sel |= PACKET3_SEM_WAIT_ON_SIGNAL;
+
radeon_ring_write(ring, PACKET3(PACKET3_MEM_SEMAPHORE, 1));
radeon_ring_write(ring, addr & 0x);
radeon_ring_write(ring, (upper_32_bits(addr) & 0xff) | sel);
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 2ba460b..8ae328f 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -850,6 +850,7 @@
 #definePACKET3_STRMOUT_BUFFER_UPDATE   0x34
 #definePACKET3_INDIRECT_BUFFER_MP  0x38
 #definePACKET3_MEM_SEMAPHORE   0x39
+#  define PACKET3_SEM_WAIT_ON_SIGNAL(0x1 << 12)
 #  define PACKET3_SEM_SEL_SIGNAL   (0x6 << 29)
 #  define PACKET3_SEM_SEL_WAIT (0x7 << 29)
 #definePACKET3_MPEG_INDEX  0x3A
-- 
1.7.5.4

[PATCH] r6xx: initialize SX_MISC

[Alex Deucher]

On Wed, Mar 7, 2012 at 10:56 AM, Marek Ol??k  wrote:
> If Mesa set it to 1, the DDX would not render anything = the monitor would
> basically freeze.
> ---
> If it's right, please apply it to xf86-video-ati. I don't have commit access.

Pushed.  thanks!

>
> ?src/r6xx_accel.c | ? ?1 +
> ?1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/src/r6xx_accel.c b/src/r6xx_accel.c
> index 8e6bffa..ab878c3 100644
> --- a/src/r6xx_accel.c
> +++ b/src/r6xx_accel.c
> @@ -1200,6 +1200,7 @@ r600_set_default_state(ScrnInfoPtr pScrn, drmBufPtr ib)
> ? ? E32(ib, 0); // VGT_VTX_CNT_EN
>
> ? ? EREG(ib, VGT_STRMOUT_BUFFER_EN, ? ? ? ? ? ? ? 0);
> + ? ?EREG(ib, SX_MISC, ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0);
> ? ? END_BATCH();
> ?}
>
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: set SX_MISC in the r6xx blit code

[Alex Deucher]

On Wed, Mar 7, 2012 at 10:51 AM, Marek Ol??k  wrote:
> Mesa may set it to 1, causing all primitives to be killed.
>
> Signed-off-by: Marek Ol??k 

Looks good.  Should probably cc stable as well.

Reviewed-by: Alex Deucher 

> ---
> I hope it's right.
>
> ?drivers/gpu/drm/radeon/r600_blit_shaders.c | ? ?4 
> ?1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c 
> b/drivers/gpu/drm/radeon/r600_blit_shaders.c
> index 2d1f6c5..ccec7d2 100644
> --- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
> +++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
> @@ -314,6 +314,10 @@ const u32 r6xx_default_state[] =
> ? ? ? ?0x, /* VGT_VTX_CNT_EN */
>
> ? ? ? ?0xc0016900,
> + ? ? ? 0x00d4,
> + ? ? ? 0x, /* SX_MISC */
> +
> + ? ? ? 0xc0016900,
> ? ? ? ?0x02c8,
> ? ? ? ?0x, /* VGT_STRMOUT_BUFFER_EN */
>
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

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

--- Comment #7 from Tvrtko Ursulin  2012-03-07 
02:42:18 PST ---
Poll helper is running every ten seconds because VGA connector "asks it to",
given how it has DRM_CONNECTOR_POLL_CONNECT set.

Since the poll helper runs, and HDMI connector has DRM_CONNECTOR_POLL_HPD set
due to hpd.hpd being not RADEON_HPD_NONE, it calls it's detect method
(radeon_dvi_detect).

This in turns discards an re-fetches the full EDID every time it runs.

What is the bug here?

1. That HDMI connector has DRM_CONNECTOR_POLL_HPD set when hpd.hpd is not
RADEON_HPD_NONE?
2. That discard and full fetch of EDID is done when is not needed?

Or both? Or something else? Hard to say for me. HPD sounds like Hotplug detect?
So setting that DRM_CONNECTOR_POLL_HPD when the connector supports something
other than RADEON_HPD_NONE sounds fishy to me.

But re-fetching full EDID is also silly. Might not be relevant if the detect
"method" should not run in the first place...

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

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

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

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

--- Comment #6 from Tvrtko Ursulin  2012-03-07 
02:10:26 PST ---
Further investigation along the lines of your comment.

For the HDMI connector ATOM_HPD_INT_RECORD_TYPE contains a gpio->mask of 0x100
which translates to RADEON_HPD_2. hpd.plugged_state is zero.

When hpd.hpd is not RADEON_HPD_NONE radeon_add_atom_connector sets
connector->polled to DRM_CONNECTOR_POLL_HPD. So if poll helper is running it
will result in the observed behaviour -> discard and re-fetch full EDID on
every poll even when the connector hasn't been re-connected.

But you are saying poll helper should not be running right? I'll investigate
that area next.

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

[Bug 47039] radeon: The kernel rejected CS

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

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

Sylvain R?ault  changed:

   What|Removed |Added

   Priority|medium  |highest

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

[PATCH] omap2+: add drm device

[Gross, Andy]

On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen  wrote:
>
> Does this "DMM has become synonymous" mean that people just started
> calling TILER DMM, and thus the name has stuck, or are there technical
> reasons to handle it as DMM in the kernel? If the former, and if TILER
> is the technically exact name for it, perhaps it would make sense to
> call it TILER, as that's what (at least I) would be looking for if I
> read the TRM and try to find the code for the TILER.
>
> ?Tomi

Well the breakdown of the DMM/Tiler kind of goes like this.  The DMM
defines a set of registers used to manipulate the PAT table that backs
the address space with physical memory.  The Tiler portion of the DMM
really just describes the address space that is exposed.  Depending on
what address range you access, you'll get a different mode of access
and rotation.  Management of the address space is attributed to the
Tiler as well and that is where we have managed the address space and
provided APIs to reserve address space and pin/unpin memory to those
regions.

[Bug 47039] New: radeon: The kernel rejected CS

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

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

 Bug #: 47039
   Summary: radeon: The kernel rejected CS
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vindicators1 at yahoo.fr


Report bug in Opengl accelered :

report glxgear :

radeon: The kernel rejected CS, see dmesg for more information.
EE r600_pipe.c:78 r600_create_fence - r600: too many concurrent fences


And dmesg :

[52416.024710] radeon :02:00.0: forbidden register 0x00028354 at 168
[52416.024713] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

In Fedora 16 and kernel 3.2.9-2

My computeur description :

 cat /proc/bus/pci/devices | grep VGA || lspci | grep VGA | colrm 1 4 ; \
> cat /proc/cpuinfo | egrep "model name|MHz" ; \
> xdpyinfo | egrep "version:|dimensions|depth of" ; \
> glxinfo | egrep -A2 "rendering|OpenGL" ; \
> uname -sr;

0.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850]
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
cpu MHz : 1000.000
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
cpu MHz : 1000.000
  dimensions:2560x1024 pixels (677x270 millimeters)
  depth of root window:24 planes
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
--
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 8.1-devel (git-43af02a)
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, 
Linux 3.2.9-2.fc16.x86_64

Reproductible :
permanently

-- 
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: fix a semaphore deadlock on pre cayman asics

[Alex Deucher]

2012/3/7 Christian K?nig :
> The out of order execution of semaphore commands on
> pre cayman asics doesn't work correctly and can
> cause deadlocks, so turn it off for now.
>
> Signed-off-by: Christian K?nig 

Good catch.

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/r600.c ?| ? ?3 +++
> ?drivers/gpu/drm/radeon/r600d.h | ? ?1 +
> ?2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 8a6d68c..f0b3323 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2362,6 +2362,9 @@ void r600_semaphore_ring_emit(struct radeon_device 
> *rdev,
> ? ? ? ?uint64_t addr = semaphore->gpu_addr;
> ? ? ? ?unsigned sel = emit_wait ? PACKET3_SEM_SEL_WAIT : 
> PACKET3_SEM_SEL_SIGNAL;
>
> + ? ? ? if (rdev->family < CHIP_CAYMAN)
> + ? ? ? ? ? ? ? sel |= PACKET3_SEM_WAIT_ON_SIGNAL;
> +
> ? ? ? ?radeon_ring_write(ring, PACKET3(PACKET3_MEM_SEMAPHORE, 1));
> ? ? ? ?radeon_ring_write(ring, addr & 0x);
> ? ? ? ?radeon_ring_write(ring, (upper_32_bits(addr) & 0xff) | sel);
> diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
> index 2ba460b..8ae328f 100644
> --- a/drivers/gpu/drm/radeon/r600d.h
> +++ b/drivers/gpu/drm/radeon/r600d.h
> @@ -850,6 +850,7 @@
> ?#define ? ? ? ?PACKET3_STRMOUT_BUFFER_UPDATE ? ? ? ? ? ? ? ? ? 0x34
> ?#define ? ? ? ?PACKET3_INDIRECT_BUFFER_MP ? ? ? ? ? ? ? ? ? ? ?0x38
> ?#define ? ? ? ?PACKET3_MEM_SEMAPHORE ? ? ? ? ? ? ? ? ? ? ? ? ? 0x39
> +# ? ? ? ? ? ? ?define PACKET3_SEM_WAIT_ON_SIGNAL ? ?(0x1 << 12)
> ?# ? ? ? ? ? ? ?define PACKET3_SEM_SEL_SIGNAL ? ? ? (0x6 << 29)
> ?# ? ? ? ? ? ? ?define PACKET3_SEM_SEL_WAIT ? ? ? ? (0x7 << 29)
> ?#define ? ? ? ?PACKET3_MPEG_INDEX ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x3A
> --
> 1.7.5.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

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

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

--- Comment #8 from Michel D?nzer  2012-03-07 00:21:12 
PST ---
(In reply to comment #7)
> I got the source for xserver-xorg-video-ati from the Ubuntu repositories and
> tried to apply the patch to it.

That can't work, as the patch is for the kernel, not the X driver.

You should be able to get the source for your running kernel with

apt-get source linux-image-$(uname -r)


> I've also never tested a kernel mod so I'm not sure what I would do if
> I got the patch to compile.

Boot the patched kernel (or load the patched radeon kernel module) and try to
reproduce the problem. Look for the message from comment #6 in dmesg.

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

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #57853|0   |1
is obsolete||

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

[PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen  wrote:
> On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
>>
>>
>> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen 
>> wrote:
>>
>>
>> ? ? ? ? I have to say I don't know much about DMM, but my
>> ? ? ? ? understanding is that
>> ? ? ? ? DMM is a bigger entity, of which TILER is only a small part,
>> ? ? ? ? and DMM
>> ? ? ? ? manages all memory accesses.
>>
>> ? ? ? ? Can there be other users for the DMM than DRM? I know there
>> ? ? ? ? could be
>> ? ? ? ? other users for the TILER, and I know you want to combine that
>> ? ? ? ? with the
>> ? ? ? ? DRM driver, but I'm wondering about the other parts of DMM
>> ? ? ? ? than the
>> ? ? ? ? TILER.
>>
>> ? ? ? ? Somehow having a DMM driver inside omapdrm sounds strange.
>>
>>
>> The DMM does indeed contain a number of entities. ?However, the TILER
>> portion is the only part that requires a driver. ?All other register
>> modifications (LISA map settings, EMIF, etc) are done statically in
>> the loader or u-boot and never changed again. ?As such, DMM has become
>> synonymous with TILER.
>
> Ok. Well, as I said, I don't know much about that, just sounds rather
> strange to me =).
>
> Does this "DMM has become synonymous" mean that people just started
> calling TILER DMM, and thus the name has stuck, or are there technical
> reasons to handle it as DMM in the kernel? If the former, and if TILER
> is the technically exact name for it, perhaps it would make sense to
> call it TILER, as that's what (at least I) would be looking for if I
> read the TRM and try to find the code for the TILER.

Well, "dmm" is the name in hwmod, so either way we are sort of "stuck"
with that.. but if you look in the TRM, you'd be looking for "dynamic
memory manager", so I tend to think "dmm" is the better name.  But for
some reason the old driver (in some product kernels but never made it
upstream) was called "tiler", which might be part of the reason that
people have started using the names interchangeably.

At any rate, neither "tiler" nor "dmm" appear in any userspace facing
API (instead you just have some bits you can set in the flags you
specify if you want tiled buffer or not when allocating a gem buffer
object).  So I guess it isn't as critical.

BR,
-R

> ?Tomi
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen  wrote:
> On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
>> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen  
>> wrote:
>> > On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
>> >> On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen  
>> >> wrote:
>> >
>> >> > Can there be more than one omapdrm device? I guess not. If so, the id
>> >> > should be -1.
>> >>
>> >> in the past, we have used multiple devices (using the platform-data to
>> >> divide up the dss resources), although this was sort of a
>> >> special-case. ?But in theory you could have multiple. ?(Think of a
>> >> multi-seat scenario, where multiple compositors need to run and each
>> >> need to be drm-master of their own device to do mode-setting on their
>> >> corresponding display.)
>> >>
>> >> I think if we use .id = -1, then we'd end up with a funny looking
>> >> bus-id for the device: "platform:omapdrm:-1"
>> >
>> > I don't know about that, but it's the way platform devices are meant to
>> > be used if there can be only one instance. If the case where there are
>> > multiple omapdrm devices is rather theoretical, or only used for certain
>> > debugging scenarios or such, I think having the id as -1 in the mainline
>> > is cleaner.
>>
>> well, I don't care much one way or another, but need to check if there
>> is a small patch needed in drm core code that generates the bus-id for
>> .id = -1..
>
> Hmm, why does the drm core care about it?

Because it is the one generating the bus-id.. see
drivers/gpu/drm/drm_platform.c drm_platform_set_busid()

Anyways, it's just a detail about how libdrm/drmOpen() can
differentiate between multiple instances of the same driver, similar
to how PCI bus-id is used in the desktop world.  It is not difficult
to change in drm_platform_set_busid(), although not sure if that would
be considered an ABI change to userspace.  (Maybe it is less critical,
I'm under the impression that other platform-drm users didn't even
realize we had a bus-id.)

> And generally, I think if the bus id is -1, there is no bus id in a
> sense. For example, with bus id 0 you'll get a device "omapdrm.0". With
> bus id -1 you'll get a device "omapdrm".
>
>> >> >> +arch_initcall(omap_init_gpu);
>> >> >> +
>> >> >> +void omapdrm_reserve_vram(void)
>> >> >> +{
>> >> >> +#ifdef CONFIG_CMA
>> >> >> + ? ? /*
>> >> >> + ? ? ?* Create private 32MiB contiguous memory area for omapdrm.0 
>> >> >> device
>> >> >> + ? ? ?* TODO revisit size.. if uc/wc buffers are allocated from CMA 
>> >> >> pages
>> >> >> + ? ? ?* then the amount of memory we need goes up..
>> >> >> + ? ? ?*/
>> >> >> + ? ? dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);
>> >> >
>> >> > What does this actually do? Does it reserve the memory, i.e. it's not
>> >> > usable for others? If so, shouldn't there be a way for the user to
>> >> > configure it?
>> >>
>> >> It can be re-used by others.. see http://lwn.net/Articles/479297/
>> >
>> > The link didn't tell much. I looked at the patches, and
>> > dma_declare_contiguous allocates the memory with memblock_alloc. So is
>> > that allocated memory available for any users? If so, why does the
>> > function want a device pointer as an argument...
>> >
>> > Is the memory available for normal kmalloc, or only available via the
>> > CMA functions? Surely there must be some downside to the above? =) And
>> > if so, it should be configurable. You could have a board with no display
>> > at all, and you probably don't want to have 32MB allocated for DRM in
>> > that case.
>>
>> Basically the short version is memory from a CMA carveout can be
>> re-used for unpinnable memory. ?Not kmalloc, but it can be used for
>> anon userspace pages, for example. ?Userspace needs memory too.
>
> Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
> a value like that without any possibility to adjust it just sounds like
> a rather bad thing.

The main requirement is that, on omap3 or before (platforms without
DMM) you need enough to allocate all of your scanout buffers.

I'm not against having a bootarg to adjust, although I strongly prefer
sane defaults and not requiring a million bootargs just to boot in
some usable fashion.

BR,
-R

> ?Tomi
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

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

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

--- Comment #39 from Alexandre Demers  
2012-03-06 22:25:26 PST ---
(In reply to comment #38)
> Some news: today, I updated xserver and it seems I'm now able to boot under
> Gnome-Shell correctly.
> 
> However, launching RenderFeatTest.bin64 still hangs exactly where it has been
> hanging for some time now and freeze my window manager. At least, it seems one
> of the problem was related to xserver.
> 
> I'll hope I'll be able to find something new in the logs.

After one testing day, it happened again. It's just not happening at start as
it was doing, but more randomly. Too bad.

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

[Bug 47039] radeon: The kernel rejected CS

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

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

--- Comment #1 from Marek Ol??k  2012-03-07 04:55:45 UTC 
---
The commit d0f8561574023aa8f2e0fdf553ee168253567437 should fix this. Please
test Mesa master and close this bug if the issue is gone.

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

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

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

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

--- Comment #7 from jonathan  2012-03-06 19:41:29 
PST ---
This is a bit above my head I think. I got the source for
xserver-xorg-video-ati from the Ubuntu repositories and tried to apply the
patch to it. It looks like a lot of the right files are there, but there's no
radeon_gem.c. The package version is 6.14.99~git20111219.aacbd629-0ubuntu2,
which includes a date that I think indicates that it's not TOO old, however I
cloned the git repository at
git://anongit.freedesktop.org/xorg/driver/xf86-video-ati and had the same
problem. I've also never tested a kernel mod so I'm not sure what I would do if
I got the patch to compile.

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

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-daemon]

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

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

  Attachment #57853|0   |1
is obsolete||

-- 
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 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer mic...@daenzer.net 2012-03-07 00:21:12 PST 
---
(In reply to comment #7)
 I got the source for xserver-xorg-video-ati from the Ubuntu repositories and
 tried to apply the patch to it.

That can't work, as the patch is for the kernel, not the X driver.

You should be able to get the source for your running kernel with

apt-get source linux-image-$(uname -r)


 I've also never tested a kernel mod so I'm not sure what I would do if
 I got the patch to compile.

Boot the patched kernel (or load the patched radeon kernel module) and try to
reproduce the problem. Look for the message from comment #6 in dmesg.

-- 
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 47039] New: radeon: The kernel rejected CS

[bugzilla-daemon]

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

 Bug #: 47039
   Summary: radeon: The kernel rejected CS
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: vindicato...@yahoo.fr


Report bug in Opengl accelered :

report glxgear :

radeon: The kernel rejected CS, see dmesg for more information.
EE r600_pipe.c:78 r600_create_fence - r600: too many concurrent fences


And dmesg :

[52416.024710] radeon :02:00.0: forbidden register 0x00028354 at 168
[52416.024713] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

In Fedora 16 and kernel 3.2.9-2

My computeur description :

 cat /proc/bus/pci/devices | grep VGA || lspci | grep VGA | colrm 1 4 ; \
 cat /proc/cpuinfo | egrep model name|MHz ; \
 xdpyinfo | egrep version:|dimensions|depth of ; \
 glxinfo | egrep -A2 rendering|OpenGL ; \
 uname -sr;

0.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850]
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
cpu MHz : 1000.000
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
cpu MHz : 1000.000
  dimensions:2560x1024 pixels (677x270 millimeters)
  depth of root window:24 planes
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
--
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 8.1-devel (git-43af02a)
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, 
Linux 3.2.9-2.fc16.x86_64

Reproductible :
permanently

-- 
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 47039] radeon: The kernel rejected CS

[bugzilla-daemon]

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

Sylvain Réault vindicato...@yahoo.fr changed:

   What|Removed |Added

   Priority|medium  |highest

-- 
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 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

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

--- Comment #6 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-07 
02:10:26 PST ---
Further investigation along the lines of your comment.

For the HDMI connector ATOM_HPD_INT_RECORD_TYPE contains a gpio-mask of 0x100
which translates to RADEON_HPD_2. hpd.plugged_state is zero.

When hpd.hpd is not RADEON_HPD_NONE radeon_add_atom_connector sets
connector-polled to DRM_CONNECTOR_POLL_HPD. So if poll helper is running it
will result in the observed behaviour - discard and re-fetch full EDID on
every poll even when the connector hasn't been re-connected.

But you are saying poll helper should not be running right? I'll investigate
that area next.

-- 
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: fix a semaphore deadlock on pre cayman asics

[Christian König]

The out of order execution of semaphore commands on
pre cayman asics doesn't work correctly and can
cause deadlocks, so turn it off for now.

Signed-off-by: Christian König deathsim...@vodafone.de
---
 drivers/gpu/drm/radeon/r600.c  |3 +++
 drivers/gpu/drm/radeon/r600d.h |1 +
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 8a6d68c..f0b3323 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2362,6 +2362,9 @@ void r600_semaphore_ring_emit(struct radeon_device *rdev,
uint64_t addr = semaphore-gpu_addr;
unsigned sel = emit_wait ? PACKET3_SEM_SEL_WAIT : 
PACKET3_SEM_SEL_SIGNAL;
 
+   if (rdev-family  CHIP_CAYMAN)
+   sel |= PACKET3_SEM_WAIT_ON_SIGNAL;
+
radeon_ring_write(ring, PACKET3(PACKET3_MEM_SEMAPHORE, 1));
radeon_ring_write(ring, addr  0x);
radeon_ring_write(ring, (upper_32_bits(addr)  0xff) | sel);
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 2ba460b..8ae328f 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -850,6 +850,7 @@
 #definePACKET3_STRMOUT_BUFFER_UPDATE   0x34
 #definePACKET3_INDIRECT_BUFFER_MP  0x38
 #definePACKET3_MEM_SEMAPHORE   0x39
+#  define PACKET3_SEM_WAIT_ON_SIGNAL(0x1  12)
 #  define PACKET3_SEM_SEL_SIGNAL   (0x6  29)
 #  define PACKET3_SEM_SEL_WAIT (0x7  29)
 #definePACKET3_MPEG_INDEX  0x3A
-- 
1.7.5.4

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

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

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

--- Comment #7 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-07 
02:42:18 PST ---
Poll helper is running every ten seconds because VGA connector asks it to,
given how it has DRM_CONNECTOR_POLL_CONNECT set.

Since the poll helper runs, and HDMI connector has DRM_CONNECTOR_POLL_HPD set
due to hpd.hpd being not RADEON_HPD_NONE, it calls it's detect method
(radeon_dvi_detect).

This in turns discards an re-fetches the full EDID every time it runs.

What is the bug here?

1. That HDMI connector has DRM_CONNECTOR_POLL_HPD set when hpd.hpd is not
RADEON_HPD_NONE?
2. That discard and full fetch of EDID is done when is not needed?

Or both? Or something else? Hard to say for me. HPD sounds like Hotplug detect?
So setting that DRM_CONNECTOR_POLL_HPD when the connector supports something
other than RADEON_HPD_NONE sounds fishy to me.

But re-fetching full EDID is also silly. Might not be relevant if the detect
method should not run in the first place...

-- 
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 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

[bugzilla-daemon]

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

--- Comment #13 from runetmem...@gmail.com 2012-03-07 03:58:22 PST ---
 I just tried with the latest Fedora 16 Final RC1 (using Linux 3.1.0 final), 
 and
I noticed the LVDS flickering actually happens *sometimes* also when booting
the laptop with lid open.

Same here on Acer Aspire 7560G (A8-3500M - Radeon HD 6620G) with Kubuntu 12.04
Beta 1 and external HDMI display (selected as main in xrandr settings). I
didn't try yet boot with disabled LVDS, but I indeed have flickering on LVDS in
some use-cases. For example every time when I use carousel KWin feature for
switch between applications by Alt+Tab.
Issue is reproduceable even when I boot without external display.

The interesting thing I notice: issue reproduceable only with OpenGL version of
KWin. I never can get it reproduced with OpenGL ES version of KWin.

Alex, I have the same issue or I need to fill separate bugreport?

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

Re: [PATCH 1/9] drm/i915/intel_i2c: cleanup

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:42 +0800, Daniel Kurtz djku...@chromium.org wrote:
 80 col, spaces around operators and other basic cleanup.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org
 ---
  drivers/gpu/drm/i915/intel_i2c.c |   24 
  1 files changed, 16 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
 b/drivers/gpu/drm/i915/intel_i2c.c
 index d30..a94e383 100644
 --- a/drivers/gpu/drm/i915/intel_i2c.c
 +++ b/drivers/gpu/drm/i915/intel_i2c.c
 @@ -236,8 +236,9 @@ gmbus_xfer(struct i2c_adapter *adapter,
   int i, reg_offset;
  
   if (bus-force_bit)
 - return intel_i2c_quirk_xfer(dev_priv,
 - bus-force_bit, msgs, num);
 + return intel_i2c_quirk_xfer(dev_priv, bus-force_bit, msgs,
 + num);
 +
NAK just on that around. The new line was put there for a reason as
there is a distinction in the types of parameters, it visually grouped
the control arguments from the object.
-Chris

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

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
 On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
  On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
  On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com 
  wrote:
 
   Can there be more than one omapdrm device? I guess not. If so, the id
   should be -1.
 
  in the past, we have used multiple devices (using the platform-data to
  divide up the dss resources), although this was sort of a
  special-case.  But in theory you could have multiple.  (Think of a
  multi-seat scenario, where multiple compositors need to run and each
  need to be drm-master of their own device to do mode-setting on their
  corresponding display.)
 
  I think if we use .id = -1, then we'd end up with a funny looking
  bus-id for the device: platform:omapdrm:-1
 
  I don't know about that, but it's the way platform devices are meant to
  be used if there can be only one instance. If the case where there are
  multiple omapdrm devices is rather theoretical, or only used for certain
  debugging scenarios or such, I think having the id as -1 in the mainline
  is cleaner.
 
 well, I don't care much one way or another, but need to check if there
 is a small patch needed in drm core code that generates the bus-id for
 .id = -1..

Hmm, why does the drm core care about it?

And generally, I think if the bus id is -1, there is no bus id in a
sense. For example, with bus id 0 you'll get a device omapdrm.0. With
bus id -1 you'll get a device omapdrm.

   +arch_initcall(omap_init_gpu);
   +
   +void omapdrm_reserve_vram(void)
   +{
   +#ifdef CONFIG_CMA
   + /*
   +  * Create private 32MiB contiguous memory area for omapdrm.0 
   device
   +  * TODO revisit size.. if uc/wc buffers are allocated from CMA 
   pages
   +  * then the amount of memory we need goes up..
   +  */
   + dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
  
   What does this actually do? Does it reserve the memory, i.e. it's not
   usable for others? If so, shouldn't there be a way for the user to
   configure it?
 
  It can be re-used by others.. see http://lwn.net/Articles/479297/
 
  The link didn't tell much. I looked at the patches, and
  dma_declare_contiguous allocates the memory with memblock_alloc. So is
  that allocated memory available for any users? If so, why does the
  function want a device pointer as an argument...
 
  Is the memory available for normal kmalloc, or only available via the
  CMA functions? Surely there must be some downside to the above? =) And
  if so, it should be configurable. You could have a board with no display
  at all, and you probably don't want to have 32MB allocated for DRM in
  that case.
 
 Basically the short version is memory from a CMA carveout can be
 re-used for unpinnable memory.  Not kmalloc, but it can be used for
 anon userspace pages, for example.  Userspace needs memory too.

Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
a value like that without any possibility to adjust it just sounds like
a rather bad thing.

 Tomi



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

Re: [PATCH 3/9] drm/i915/intel_i2c: refactor using intel_gmbus_get_bus

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:44 +0800, Daniel Kurtz djku...@chromium.org wrote:
 +struct i2c_adapter *intel_gmbus_get_bus(struct drm_i915_private *dev_priv,
 + int pin)
 +{
BUG_ON(pin = GMBUS_NUM_PORTS);

 + return (pin  GMBUS_NUM_PORTS) ? dev_priv-gmbus[pin].adapter : NULL;
You just turned a programming error into a nearly undecipherable OOPS.
-Chris

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

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
 
 
 On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com
 wrote:
 
 
 I have to say I don't know much about DMM, but my
 understanding is that
 DMM is a bigger entity, of which TILER is only a small part,
 and DMM
 manages all memory accesses.
 
 Can there be other users for the DMM than DRM? I know there
 could be
 other users for the TILER, and I know you want to combine that
 with the
 DRM driver, but I'm wondering about the other parts of DMM
 than the
 TILER.
 
 Somehow having a DMM driver inside omapdrm sounds strange.
 
 
 The DMM does indeed contain a number of entities.  However, the TILER
 portion is the only part that requires a driver.  All other register
 modifications (LISA map settings, EMIF, etc) are done statically in
 the loader or u-boot and never changed again.  As such, DMM has become
 synonymous with TILER.

Ok. Well, as I said, I don't know much about that, just sounds rather
strange to me =).

Does this DMM has become synonymous mean that people just started
calling TILER DMM, and thus the name has stuck, or are there technical
reasons to handle it as DMM in the kernel? If the former, and if TILER
is the technically exact name for it, perhaps it would make sense to
call it TILER, as that's what (at least I) would be looking for if I
read the TRM and try to find the code for the TILER.

 Tomi




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

Re: [PATCH 9/9] drm/i915/intel_i2c: reuse GMBUS2 value from polling loop

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:50 +0800, Daniel Kurtz djku...@chromium.org wrote:
 Save the GMBUS2 value read while polling for state changes, and then
 reuse this value when determining for which reason the loops were exited.
 This is a small optimization which saves a couple of bus accesses for
 memory mapped IO registers.
 
 Note: checkpatch doesn't like this ('assigning in if condition'), but it seems
 like the cleanest implementation.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

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

Re: [PATCH 3/9] drm/i915/intel_i2c: refactor using intel_gmbus_get_bus

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:44 +0800, Daniel Kurtz djku...@chromium.org wrote:
 Instead of letting other modules directly access the -gmbus array,
 introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
 a given gmbus pin pair identifier.  This API enables later refactoring
 of the gmbus pin pair list.
 
 Note: It is critical that intel_setup_gmbus() gets called before
 intel_gmbus_get_bus().

If you are going to rename it, perhaps a better choice than
intel_gmbus_get_bus(int gpio_pin) ?

intel_i2c_get_adapter(int gpio_pin) since the rest of the code really
does not care how the bits are transferred but that it interfaces using
i2c.
-Chris

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

Re: [PATCH 4/9] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:45 +0800, Daniel Kurtz djku...@chromium.org wrote:
 There is no disabled port 0.  So, don't even try to initialize/scan
 it, etc.  This saves a bit of time when initializing the driver, since
 the we can avoid a 50ms timeout waiting for a device to respond on
 a port that doesn't even exist.
 
 Similarly, don't initialize the reserved port, either.

 @@ -150,32 +164,23 @@ static void set_data(void *data, int state_high)
  static struct i2c_adapter *
  intel_gpio_create(struct drm_i915_private *dev_priv, u32 pin)
  {
 - static const int map_pin_to_reg[] = {
 - 0,
 - GPIOB,
 - GPIOA,
 - GPIOC,
 - GPIOD,
 - GPIOE,
 - GPIOF,
 - 0,
 - };
   struct intel_gpio *gpio;
  
 - if (pin = ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])

And that doesn't do what your changelog proposes? Why?
-Chris

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

Re: [PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

[Chris Wilson]

On Wed, 7 Mar 2012 20:41:03 +0800, Daniel Kurtz djku...@chromium.org wrote:
 On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
  On Wed,  7 Mar 2012 19:50:47 +0800, Daniel Kurtz djku...@chromium.org 
  wrote:
  Return -ENXIO if a device NAKs a transaction.
 
  Note: We should return -ETIMEDOUT, too if the transaction times out,
  however, that error path is currently handled by the 'bit-bang fallback'.
 
  Signed-off-by: Daniel Kurtz djku...@chromium.org
 
  Can you clarify what the rule is if an error is detected part-way
  through a xfer?
 
 A priceless comment from drivers/i2c/i2c-core::i2c_transfer...

Thanks, that is about as consistent as one expects with i2c. ;)
 
 This doesn't specify what to do if the transfer doesn't get an ACK
 during another phase of the transfer.
 However, it does say to send -ENXIO if no ACK during address phase,
 which is a subset of the possible no-ACK conditions during a transfer.
  Thus, I choose to return ENXIO in all no-ACK cases, to ensure we send
 it during the one case that is specified.

This (and a summary of the rest) deserves to be captured as a comment in
the code.
-Chris

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

[Bug 47039] radeon: The kernel rejected CS

[bugzilla-daemon]

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

--- Comment #1 from Marek Olšák mar...@gmail.com 2012-03-07 04:55:45 UTC ---
The commit d0f8561574023aa8f2e0fdf553ee168253567437 should fix this. Please
test Mesa master and close this bug if the issue is gone.

-- 
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 1/9] drm/i915/intel_i2c: cleanup

[Daniel Kurtz]

80 col, spaces around operators and other basic cleanup.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/intel_i2c.c |   24 
 1 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d30..a94e383 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -236,8 +236,9 @@ gmbus_xfer(struct i2c_adapter *adapter,
int i, reg_offset;
 
if (bus-force_bit)
-   return intel_i2c_quirk_xfer(dev_priv,
-   bus-force_bit, msgs, num);
+   return intel_i2c_quirk_xfer(dev_priv, bus-force_bit, msgs,
+   num);
+
 
reg_offset = HAS_PCH_SPLIT(dev_priv-dev) ? PCH_GMBUS0 - GMBUS0 : 0;
 
@@ -253,11 +254,13 @@ gmbus_xfer(struct i2c_adapter *adapter,
   (len  GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr  GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_READ | GMBUS_SW_RDY);
-   POSTING_READ(GMBUS2+reg_offset);
+   POSTING_READ(GMBUS2 + reg_offset);
do {
u32 val, loop = 0;
 
-   if (wait_for(I915_READ(GMBUS2 + reg_offset)  
(GMBUS_SATOER | GMBUS_HW_RDY), 50))
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
+(GMBUS_SATOER | GMBUS_HW_RDY),
+50))
goto timeout;
if (I915_READ(GMBUS2 + reg_offset)  
GMBUS_SATOER)
goto clear_err;
@@ -282,10 +285,12 @@ gmbus_xfer(struct i2c_adapter *adapter,
   (msgs[i].len  GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr  GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
-   POSTING_READ(GMBUS2+reg_offset);
+   POSTING_READ(GMBUS2 + reg_offset);
 
while (len) {
-   if (wait_for(I915_READ(GMBUS2 + reg_offset)  
(GMBUS_SATOER | GMBUS_HW_RDY), 50))
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
+(GMBUS_SATOER | GMBUS_HW_RDY),
+50))
goto timeout;
if (I915_READ(GMBUS2 + reg_offset)  
GMBUS_SATOER)
goto clear_err;
@@ -296,11 +301,14 @@ gmbus_xfer(struct i2c_adapter *adapter,
} while (--len  ++loop  4);
 
I915_WRITE(GMBUS3 + reg_offset, val);
-   POSTING_READ(GMBUS2+reg_offset);
+   POSTING_READ(GMBUS2 + reg_offset);
}
}
 
-   if (i + 1  num  wait_for(I915_READ(GMBUS2 + reg_offset)  
(GMBUS_SATOER | GMBUS_HW_WAIT_PHASE), 50))
+   if (i + 1  num 
+   wait_for(I915_READ(GMBUS2 + reg_offset) 
+(GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
+50))
goto timeout;
if (I915_READ(GMBUS2 + reg_offset)  GMBUS_SATOER)
goto clear_err;
-- 
1.7.7.3

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

[PATCH 5/9] drm/i915/intel_i2c: add locking around i2c algorithm accesses

[Daniel Kurtz]

The i915 has multiple i2c adapters.  However, they all share a single
single set of i2c control registers (algorithm).  Thus, different threads
trying to access different adapters could interfere with each other.

Note: different threads trying to access the same channel is already
handled in the i2c-core using the i2c adapter lock.

This patch adds a mutex to serialize access to the gmbus_xfer routine.
Note: the same mutex serializes both bit banged and native xfers.

Signed-off-by: Yufeng Shen mile...@chromium.org
Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_i2c.c |   12 
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64d1276..c7f0809 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -301,6 +301,7 @@ typedef struct drm_i915_private {
struct i2c_adapter *force_bit;
u32 reg0;
} *gmbus;
+   struct mutex gmbus_mutex;
 
struct pci_dev *bridge_dev;
struct intel_ring_buffer ring[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b2cc7f2..b97392c 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -213,6 +213,8 @@ intel_i2c_quirk_xfer(struct drm_i915_private *dev_priv,
   adapter);
int ret;
 
+   mutex_lock(dev_priv-gmbus_mutex);
+
intel_i2c_reset(dev_priv-dev);
 
intel_i2c_quirk_set(dev_priv, true);
@@ -226,6 +228,8 @@ intel_i2c_quirk_xfer(struct drm_i915_private *dev_priv,
set_clock(gpio, 1);
intel_i2c_quirk_set(dev_priv, false);
 
+   mutex_unlock(dev_priv-gmbus_mutex);
+
return ret;
 }
 
@@ -244,6 +248,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
return intel_i2c_quirk_xfer(dev_priv, bus-force_bit, msgs,
num);
 
+   mutex_lock(dev_priv-gmbus_mutex);
 
reg_offset = HAS_PCH_SPLIT(dev_priv-dev) ? PCH_GMBUS0 - GMBUS0 : 0;
 
@@ -334,6 +339,9 @@ done:
 * start of the next xfer, till then let it sleep.
 */
I915_WRITE(GMBUS0 + reg_offset, 0);
+
+   mutex_unlock(dev_priv-gmbus_mutex);
+
return i;
 
 timeout:
@@ -341,6 +349,8 @@ timeout:
 bus-reg0  0xff, bus-adapter.name);
I915_WRITE(GMBUS0 + reg_offset, 0);
 
+   mutex_unlock(dev_priv-gmbus_mutex);
+
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
bus-force_bit = intel_gpio_create(dev_priv, bus-reg0  0xff);
if (!bus-force_bit)
@@ -383,6 +393,8 @@ int intel_setup_gmbus(struct drm_device *dev)
if (dev_priv-gmbus == NULL)
return -ENOMEM;
 
+   mutex_init(dev_priv-gmbus_mutex);
+
for (i = 0; i  ARRAY_SIZE(gmbus_ports); i++) {
struct intel_gmbus *bus = dev_priv-gmbus[i];
int port = i + 1; /* +1 to map gmbus index to pin pair */
-- 
1.7.7.3

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

[PATCH 0/9] drm/i915/intel_i2c: fix gmbus writes and related issues

[Daniel Kurtz]

This patchset addresses a couple of issues with the i915 gmbus implementation:
  * fixes misassigned pin port pair for HDMI-D
  * fixes write transactions when they are the only transaction requested
(including large 4-byte writes)
  * returns -ENXIO and -ETIMEDOUT as appropriate so upper layers can handled
i2c transaction failures
  * optimizes the typical read transaction case by using the INDEX cycle

The patchset should apply cleanly onto linus/master.
It is inspired by, but completely supercedes, a similar patch submitted
recently by Benson Leung (ble...@chromium.org).
I'd be happy to rebase on a different tree if necessary.

Note: 
There is one more patch in the set which I have not included here.  It enables
the PCH GMBUS interrupt and makes use of it to eliminate the very slow
'wait_for' polling loop.  This patch was not included, however, because there
is at least one case I have discovered where the i915 driver issues a GMBUS
transaction AFTER its interrupts have been initialized, but BEFORE it they have
been enabled.  Both the gmbus transaction and irq initialization occur during
i915_load_modeset_init(), but the gmbus transaction happens first, during:
  intel_modeset_init()
intel_setup_outputs()
  intel_lvds_init()
drm_get_edid()
Is there a way to switch the order of these to events?
Or does it make more sense for the gmbus driver to check a bool irq_enabled,
and choose whether to poll or use the GMBUS interrupt?
... or both?


Daniel Kurtz (9):
  drm/i915/intel_i2c: cleanup
  drm/i915/intel_i2c: assign HDMI port D to pin pair 6
  drm/i915/intel_i2c: refactor using intel_gmbus_get_bus
  drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments
  drm/i915/intel_i2c: add locking around i2c algorithm accesses
  drm/i915/intel_i2c: return -ENXIO for device NAK
  drm/i915/intel_i2c: use WAIT cycle, not STOP
  drm/i915/intel_i2c: use INDEX cycles for i2c read transactions
  drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop

 drivers/gpu/drm/i915/i915_drv.h|5 +-
 drivers/gpu/drm/i915/i915_reg.h|5 +-
 drivers/gpu/drm/i915/intel_bios.c  |   10 ++-
 drivers/gpu/drm/i915/intel_crt.c   |   13 ++--
 drivers/gpu/drm/i915/intel_drv.h   |3 +-
 drivers/gpu/drm/i915/intel_dvo.c   |4 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |   29 +++---
 drivers/gpu/drm/i915/intel_i2c.c   |  175 +---
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |6 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   10 +--
 11 files changed, 165 insertions(+), 97 deletions(-)

-- 
1.7.7.3

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

[PATCH 2/9] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Daniel Kurtz]

According to i915 documentation [1], Port D (DP/HDMI Port D) is
actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
Pin pair 7 is a reserved pair.

[1] Documentation for [DevSNB+] and [DevIBX], as found on
http://intellinuxgraphics.org

Note: the reserved and disabled pairs do not actually map to a
physical pair of pins, nor GPIO regs and shouldn't be initialized or used.
Fixing this is left for a later patch.

This bug has not been noticed for two reasons:
 1) gmbus mode is currently disabled - all transfers are actually using
bit-bang mode which uses the GPIO port 5 (the HDMI/DPD CTLDATA/CLK
pair), at register 0x5024 (defined as GPIOF i915_reg.h).
Since this is the correct pair of pins for HDMI1, transfers succeed.

 2) Even if gmbus mode is re-enabled, the first attempted transaction
will fail because it tries to use the wrong (Reserved) pin pair.
However, the driver immediately falls back again to the bit-bang
method, which correctly uses GPIOF, so again, transfers succeed.

However, if gmbus mode is re-enabled and the GPIO fall-back mode is
disabled, then reading an attached monitor's EDID fail.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/i915_reg.h  |6 +++---
 drivers/gpu/drm/i915/intel_i2c.c |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 03c53fc..56af0df 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -697,9 +697,9 @@
 #define   GMBUS_PORT_PANEL 3
 #define   GMBUS_PORT_DPC   4 /* HDMIC */
 #define   GMBUS_PORT_DPB   5 /* SDVO, HDMIB */
- /* 6 reserved */
-#define   GMBUS_PORT_DPD   7 /* HDMID */
-#define   GMBUS_NUM_PORTS   8
+#define   GMBUS_PORT_DPD   6 /* HDMID */
+#define   GMBUS_PORT_RESERVED  7 /* 7 reserved */
+#define   GMBUS_NUM_PORTS  8
 #define GMBUS1 0x5104 /* command/status */
 #define   GMBUS_SW_CLR_INT (131)
 #define   GMBUS_SW_RDY (130)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index a94e383..45ce1d2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -157,8 +157,8 @@ intel_gpio_create(struct drm_i915_private *dev_priv, u32 
pin)
GPIOC,
GPIOD,
GPIOE,
-   0,
GPIOF,
+   0,
};
struct intel_gpio *gpio;
 
@@ -377,8 +377,8 @@ int intel_setup_gmbus(struct drm_device *dev)
panel,
dpc,
dpb,
-   reserved,
dpd,
+   reserved,
};
struct drm_i915_private *dev_priv = dev-dev_private;
int ret, i;
-- 
1.7.7.3

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

[PATCH 7/9] drm/i915/intel_i2c: use WAIT cycle, not STOP

[Daniel Kurtz]

The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
transaction) during a DATA or WAIT phase.  In other words, the
controller rejects a STOP requested as part of the first transaction in a
sequence.

Thus, for the first transaction we must always use a WAIT cycle, detect
when the device has finished (and is in a WAIT phase), and then either
start the next transaction, or, if there are no more transactions,
generate a STOP cycle.

Note: Theoretically, the last transaction of a multi-transaction sequence
could initiate a STOP cycle.  However, this slight optimization is left
for another patch.  We return -ETIMEDOUT if the hardware doesn't
deactivate after the STOP cycle.

This patch also takes advantage (in the write path) of the double-buffered
GMBUS3 data register by writing two 4-byte words before the first wait for
HW_RDY.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/intel_i2c.c |   42 +
 1 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 2cdd531..c3d8c70 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -261,7 +261,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
 
if (msgs[i].flags  I2C_M_RD) {
I915_WRITE(GMBUS1 + reg_offset,
-  GMBUS_CYCLE_WAIT | (i + 1 == num ? 
GMBUS_CYCLE_STOP : 0) |
+  GMBUS_CYCLE_WAIT |
   (len  GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr  GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_READ | GMBUS_SW_RDY);
@@ -273,7 +273,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
 (GMBUS_SATOER | GMBUS_HW_RDY),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset)  
GMBUS_SATOER)
+   if (I915_READ(GMBUS2 + reg_offset) 
+   GMBUS_SATOER)
goto clear_err;
 
val = I915_READ(GMBUS3 + reg_offset);
@@ -292,20 +293,13 @@ gmbus_xfer(struct i2c_adapter *adapter,
 
I915_WRITE(GMBUS3 + reg_offset, val);
I915_WRITE(GMBUS1 + reg_offset,
-  (i + 1 == num ? GMBUS_CYCLE_STOP : 
GMBUS_CYCLE_WAIT) |
+  GMBUS_CYCLE_WAIT |
   (msgs[i].len  GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr  GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
POSTING_READ(GMBUS2 + reg_offset);
 
while (len) {
-   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
-(GMBUS_SATOER | GMBUS_HW_RDY),
-50))
-   goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset)  
GMBUS_SATOER)
-   goto clear_err;
-
val = loop = 0;
do {
val |= *buf++  (8 * loop);
@@ -313,11 +307,18 @@ gmbus_xfer(struct i2c_adapter *adapter,
 
I915_WRITE(GMBUS3 + reg_offset, val);
POSTING_READ(GMBUS2 + reg_offset);
+
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
+(GMBUS_SATOER | GMBUS_HW_RDY),
+50))
+   goto timeout;
+   if (I915_READ(GMBUS2 + reg_offset) 
+ GMBUS_SATOER)
+   goto clear_err;
}
}
 
-   if (i + 1  num 
-   wait_for(I915_READ(GMBUS2 + reg_offset) 
+   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
 (GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
 50))
goto timeout;
@@ -337,9 +338,22 @@ clear_err:
ret = -ENXIO;
 
 done:
-   /* Mark the GMBUS interface as disabled. We will re-enable it at the
-* start of the next xfer, till then let it sleep.
+   if (I915_READ(GMBUS2 + reg_offset)  GMBUS_HW_WAIT_PHASE) {
+   I915_WRITE(GMBUS1 + reg_offset,
+  GMBUS_CYCLE_STOP | GMBUS_SW_RDY);
+   POSTING_READ(GMBUS2 + reg_offset);
+   }
+
+   /* Mark the GMBUS interface as disabled after 

[PATCH 4/9] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Kurtz]

There is no disabled port 0.  So, don't even try to initialize/scan
it, etc.  This saves a bit of time when initializing the driver, since
the we can avoid a 50ms timeout waiting for a device to respond on
a port that doesn't even exist.

Similarly, don't initialize the reserved port, either.

Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/i915_reg.h  |1 -
 drivers/gpu/drm/i915/intel_i2c.c |   64 ++
 2 files changed, 30 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 56af0df..89cace2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -699,7 +699,6 @@
 #define   GMBUS_PORT_DPB   5 /* SDVO, HDMIB */
 #define   GMBUS_PORT_DPD   6 /* HDMID */
 #define   GMBUS_PORT_RESERVED  7 /* 7 reserved */
-#define   GMBUS_NUM_PORTS  8
 #define GMBUS1 0x5104 /* command/status */
 #define   GMBUS_SW_CLR_INT (131)
 #define   GMBUS_SW_RDY (130)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index dd8c699..b2cc7f2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -35,6 +35,20 @@
 #include i915_drm.h
 #include i915_drv.h
 
+struct gmbus_port {
+   const char *name;
+   int reg;
+};
+
+static const struct gmbus_port gmbus_ports[] = {
+   { ssc, GPIOB },
+   { vga, GPIOA },
+   { panel, GPIOC },
+   { dpc, GPIOD },
+   { dpb, GPIOE },
+   { dpd, GPIOF },
+};
+
 /* Intel GPIO access functions */
 
 #define I2C_RISEFALL_TIME 20
@@ -150,32 +164,23 @@ static void set_data(void *data, int state_high)
 static struct i2c_adapter *
 intel_gpio_create(struct drm_i915_private *dev_priv, u32 pin)
 {
-   static const int map_pin_to_reg[] = {
-   0,
-   GPIOB,
-   GPIOA,
-   GPIOC,
-   GPIOD,
-   GPIOE,
-   GPIOF,
-   0,
-   };
struct intel_gpio *gpio;
 
-   if (pin = ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])
+   pin -= 1;  /* NB: -1 to map pin pair to gmbus array index */
+   if (pin = ARRAY_SIZE(gmbus_ports))
return NULL;
 
gpio = kzalloc(sizeof(struct intel_gpio), GFP_KERNEL);
if (gpio == NULL)
return NULL;
 
-   gpio-reg = map_pin_to_reg[pin];
+   gpio-reg = gmbus_ports[pin].reg;
if (HAS_PCH_SPLIT(dev_priv-dev))
gpio-reg += PCH_GPIOA - GPIOA;
gpio-dev_priv = dev_priv;
 
snprintf(gpio-adapter.name, sizeof(gpio-adapter.name),
-i915 GPIO%c, ?BACDE?F[pin]);
+i915 GPIO%c, BACDEF[pin]);
gpio-adapter.owner = THIS_MODULE;
gpio-adapter.algo_data = gpio-algo;
gpio-adapter.dev.parent = dev_priv-dev-pdev-dev;
@@ -370,33 +375,22 @@ static const struct i2c_algorithm gmbus_algorithm = {
  */
 int intel_setup_gmbus(struct drm_device *dev)
 {
-   static const char *names[GMBUS_NUM_PORTS] = {
-   disabled,
-   ssc,
-   vga,
-   panel,
-   dpc,
-   dpb,
-   dpd,
-   reserved,
-   };
struct drm_i915_private *dev_priv = dev-dev_private;
int ret, i;
 
-   dev_priv-gmbus = kcalloc(sizeof(struct intel_gmbus), GMBUS_NUM_PORTS,
- GFP_KERNEL);
+   dev_priv-gmbus = kcalloc(sizeof(struct intel_gmbus),
+ ARRAY_SIZE(gmbus_ports), GFP_KERNEL);
if (dev_priv-gmbus == NULL)
return -ENOMEM;
 
-   for (i = 0; i  GMBUS_NUM_PORTS; i++) {
+   for (i = 0; i  ARRAY_SIZE(gmbus_ports); i++) {
struct intel_gmbus *bus = dev_priv-gmbus[i];
+   int port = i + 1; /* +1 to map gmbus index to pin pair */
 
bus-adapter.owner = THIS_MODULE;
bus-adapter.class = I2C_CLASS_DDC;
-   snprintf(bus-adapter.name,
-sizeof(bus-adapter.name),
-i915 gmbus %s,
-names[i]);
+   snprintf(bus-adapter.name, sizeof(bus-adapter.name),
+i915 gmbus %s, gmbus_ports[i].name);
 
bus-adapter.dev.parent = dev-pdev-dev;
bus-adapter.algo_data  = dev_priv;
@@ -407,10 +401,10 @@ int intel_setup_gmbus(struct drm_device *dev)
goto err;
 
/* By default use a conservative clock rate */
-   bus-reg0 = i | GMBUS_RATE_100KHZ;
+   bus-reg0 = port | GMBUS_RATE_100KHZ;
 
/* XXX force bit banging until GMBUS is fully debugged */
-   bus-force_bit = intel_gpio_create(dev_priv, i);
+   bus-force_bit = intel_gpio_create(dev_priv, port);
}
 
   

[PATCH 9/9] drm/i915/intel_i2c: reuse GMBUS2 value from polling loop

[Daniel Kurtz]

Save the GMBUS2 value read while polling for state changes, and then
reuse this value when determining for which reason the loops were exited.
This is a small optimization which saves a couple of bus accesses for
memory mapped IO registers.

Note: checkpatch doesn't like this ('assigning in if condition'), but it seems
like the cleanest implementation.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/intel_i2c.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 41f9ae2..450f2b8 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -244,6 +244,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct drm_i915_private *dev_priv = adapter-algo_data;
int i, reg_offset;
int ret = 0;
+   u32 gmbus2 = 0;
 
if (bus-force_bit)
return intel_i2c_quirk_xfer(dev_priv, bus-force_bit, msgs,
@@ -297,12 +298,12 @@ gmbus_xfer(struct i2c_adapter *adapter,
do {
u32 val, loop = 0;
 
-   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
+   if (wait_for((gmbus2 = I915_READ(GMBUS2 +
+reg_offset)) 
 (GMBUS_SATOER | GMBUS_HW_RDY),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset) 
-   GMBUS_SATOER)
+   if (gmbus2  GMBUS_SATOER)
goto clear_err;
 
val = I915_READ(GMBUS3 + reg_offset);
@@ -336,21 +337,21 @@ gmbus_xfer(struct i2c_adapter *adapter,
I915_WRITE(GMBUS3 + reg_offset, val);
POSTING_READ(GMBUS2 + reg_offset);
 
-   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
+   if (wait_for((gmbus2 = I915_READ(GMBUS2 +
+reg_offset)) 
 (GMBUS_SATOER | GMBUS_HW_RDY),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset) 
- GMBUS_SATOER)
+   if (gmbus2  GMBUS_SATOER)
goto clear_err;
}
}
 
-   if (wait_for(I915_READ(GMBUS2 + reg_offset) 
+   if (wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) 
 (GMBUS_SATOER | GMBUS_HW_WAIT_PHASE),
 50))
goto timeout;
-   if (I915_READ(GMBUS2 + reg_offset)  GMBUS_SATOER)
+   if (gmbus2  GMBUS_SATOER)
goto clear_err;
}
 
@@ -366,7 +367,7 @@ clear_err:
ret = -ENXIO;
 
 done:
-   if (I915_READ(GMBUS2 + reg_offset)  GMBUS_HW_WAIT_PHASE) {
+   if (gmbus2  GMBUS_HW_WAIT_PHASE) {
I915_WRITE(GMBUS1 + reg_offset,
   GMBUS_CYCLE_STOP | GMBUS_SW_RDY);
POSTING_READ(GMBUS2 + reg_offset);
-- 
1.7.7.3

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

[PATCH 8/9] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

[Daniel Kurtz]

It is very common for an i2c device to require a small 1 or 2 byte write
followed by a read.  For example, when reading from an i2c EEPROM it is
common to write and address, offset or index followed by a reading some
values.

The i915 gmbus controller provides a special INDEX cycle for performing
such a small write followed by a read.  The INDEX can be either one or two
bytes long.  The advantage of using such a cycle is that the CPU has
slightly less work to do once the read with INDEX cycle is started.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/intel_i2c.c |   32 ++--
 1 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index c3d8c70..41f9ae2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -256,12 +256,40 @@ gmbus_xfer(struct i2c_adapter *adapter,
I915_WRITE(GMBUS0 + reg_offset, bus-reg0);
 
for (i = 0; i  num; i++) {
-   u16 len = msgs[i].len;
-   u8 *buf = msgs[i].buf;
+   u16 len;
+   u8 *buf;
+   u32 gmbus5 = 0;
+   u32 gmbus1_index = 0;
+
+   /*
+* The gmbus controller can combine a 1 or 2 byte write with a
+* read that immediately follows it by using an INDEX cycle.
+*/
+   if (i + 1  num 
+   !(msgs[i].flags  I2C_M_RD) 
+   (msgs[i + 1].flags  I2C_M_RD) 
+   msgs[i].len = 2) {
+   if (msgs[i].len == 2)
+   gmbus5 = GMBUS_2BYTE_INDEX_EN |
+msgs[i].buf[1] |
+(msgs[i].buf[0]  8);
+   if (msgs[i].len == 1)
+   gmbus1_index = GMBUS_CYCLE_INDEX |
+  (msgs[i].buf[0] 
+   GMBUS_SLAVE_INDEX_SHIFT);
+   i += 1;  /* set i to the index of the read xfer */
+   }
+
+   len = msgs[i].len;
+   buf = msgs[i].buf;
+
+   /* GMBUS5 holds 16-bit index, but must be 0 if not used */
+   I915_WRITE(GMBUS5 + reg_offset, gmbus5);
 
if (msgs[i].flags  I2C_M_RD) {
I915_WRITE(GMBUS1 + reg_offset,
   GMBUS_CYCLE_WAIT |
+  gmbus1_index |
   (len  GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr  GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_READ | GMBUS_SW_RDY);
-- 
1.7.7.3

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

[PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

[Daniel Kurtz]

Return -ENXIO if a device NAKs a transaction.

Note: We should return -ETIMEDOUT, too if the transaction times out,
however, that error path is currently handled by the 'bit-bang fallback'.

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/intel_i2c.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b97392c..2cdd531 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -243,6 +243,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
   adapter);
struct drm_i915_private *dev_priv = adapter-algo_data;
int i, reg_offset;
+   int ret = 0;
 
if (bus-force_bit)
return intel_i2c_quirk_xfer(dev_priv, bus-force_bit, msgs,
@@ -333,6 +334,7 @@ clear_err:
 */
I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
I915_WRITE(GMBUS1 + reg_offset, 0);
+   ret = -ENXIO;
 
 done:
/* Mark the GMBUS interface as disabled. We will re-enable it at the
@@ -342,7 +344,7 @@ done:
 
mutex_unlock(dev_priv-gmbus_mutex);
 
-   return i;
+   return ret ?: i;
 
 timeout:
DRM_INFO(GMBUS timed out, falling back to bit banging on pin %d 
[%s]\n,
-- 
1.7.7.3

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

[PATCH 3/9] drm/i915/intel_i2c: refactor using intel_gmbus_get_bus

[Daniel Kurtz]

Instead of letting other modules directly access the -gmbus array,
introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
a given gmbus pin pair identifier.  This API enables later refactoring
of the gmbus pin pair list.

Note: It is critical that intel_setup_gmbus() gets called before
intel_gmbus_get_bus().

Signed-off-by: Daniel Kurtz djku...@chromium.org
---
 drivers/gpu/drm/i915/i915_drv.h|4 +++-
 drivers/gpu/drm/i915/intel_bios.c  |   10 ++
 drivers/gpu/drm/i915/intel_crt.c   |   13 ++---
 drivers/gpu/drm/i915/intel_drv.h   |3 ++-
 drivers/gpu/drm/i915/intel_dvo.c   |4 ++--
 drivers/gpu/drm/i915/intel_hdmi.c  |   29 ++---
 drivers/gpu/drm/i915/intel_i2c.c   |6 ++
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |6 +++---
 drivers/gpu/drm/i915/intel_sdvo.c  |   10 --
 10 files changed, 47 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9689ca3..64d1276 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -391,7 +391,7 @@ typedef struct drm_i915_private {
 
struct notifier_block lid_notifier;
 
-   int crt_ddc_pin;
+   struct i2c_adapter *crt_ddc;
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
@@ -1274,6 +1274,8 @@ extern int i915_restore_state(struct drm_device *dev);
 /* intel_i2c.c */
 extern int intel_setup_gmbus(struct drm_device *dev);
 extern void intel_teardown_gmbus(struct drm_device *dev);
+extern struct i2c_adapter *intel_gmbus_get_bus(
+   struct drm_i915_private *dev_priv, int pin);
 extern void intel_gmbus_set_speed(struct i2c_adapter *adapter, int speed);
 extern void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit);
 extern inline bool intel_gmbus_is_forced_bit(struct i2c_adapter *adapter)
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 63880e2..16456f7 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -330,12 +330,14 @@ parse_general_definitions(struct drm_i915_private 
*dev_priv,
u16 block_size = get_blocksize(general);
if (block_size = sizeof(*general)) {
int bus_pin = general-crt_ddc_gmbus_pin;
+   struct i2c_adapter *i2c;
DRM_DEBUG_KMS(crt_ddc_bus_pin: %d\n, bus_pin);
-   if (bus_pin = 1  bus_pin = 6)
-   dev_priv-crt_ddc_pin = bus_pin;
+   i2c = intel_gmbus_get_bus(dev_priv, bus_pin);
+   if (i2c)
+   dev_priv-crt_ddc = i2c;
} else {
DRM_DEBUG_KMS(BDB_GD too small (%d). Invalid.\n,
- block_size);
+ block_size);
}
}
 }
@@ -599,7 +601,7 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
 
-   dev_priv-crt_ddc_pin = GMBUS_PORT_VGADDC;
+   dev_priv-crt_ddc = intel_gmbus_get_bus(dev_priv, GMBUS_PORT_VGADDC);
 
/* LFP panel data */
dev_priv-lvds_dither = 1;
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index dd729d4..71d6a50 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -275,12 +275,11 @@ static bool intel_crt_detect_ddc(struct drm_connector 
*connector)
if (crt-base.type != INTEL_OUTPUT_ANALOG)
return false;
 
-   if (intel_ddc_probe(crt-base, dev_priv-crt_ddc_pin)) {
+   if (intel_ddc_probe(crt-base, dev_priv-crt_ddc)) {
struct edid *edid;
bool is_digital = false;
 
-   edid = drm_get_edid(connector,
-   dev_priv-gmbus[dev_priv-crt_ddc_pin].adapter);
+   edid = drm_get_edid(connector, dev_priv-crt_ddc);
/*
 * This may be a DVI-I connector with a shared DDC
 * link between analog and digital outputs, so we
@@ -484,14 +483,14 @@ static int intel_crt_get_modes(struct drm_connector 
*connector)
struct drm_i915_private *dev_priv = dev-dev_private;
int ret;
 
-   ret = intel_ddc_get_modes(connector,
-
dev_priv-gmbus[dev_priv-crt_ddc_pin].adapter);
+   ret = intel_ddc_get_modes(connector, dev_priv-crt_ddc);
if (ret || !IS_G4X(dev))
return ret;
 
/* Try to probe digital port for output in DVI-I - VGA mode. */
-   return intel_ddc_get_modes(connector,
-  dev_priv-gmbus[GMBUS_PORT_DPB].adapter);
+   

Re: [PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

[Daniel Kurtz]

On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Wed,  7 Mar 2012 19:50:47 +0800, Daniel Kurtz djku...@chromium.org wrote:
 Return -ENXIO if a device NAKs a transaction.

 Note: We should return -ETIMEDOUT, too if the transaction times out,
 however, that error path is currently handled by the 'bit-bang fallback'.

 Signed-off-by: Daniel Kurtz djku...@chromium.org

 Can you clarify what the rule is if an error is detected part-way
 through a xfer?

A priceless comment from drivers/i2c/i2c-core::i2c_transfer...

/* REVISIT the fault reporting model here is weak:
 *
 *  - When we get an error after receiving N bytes from a slave,
 *there is no way to report N.
 *
 *  - When we get a NAK after transmitting N bytes to a slave,
 *there is no way to report N ... or to let the master
 *continue executing the rest of this combined message, if
 *that's the appropriate response.
 *
 *  - When for example num is two and we successfully complete
 *the first message but get an error part way through the
 *second, it's unclear whether that should be reported as
 *one (discarding status on the second message) or errno
 *(discarding status on the first one).
 */

As for which error code to use, all I have found is this:

Documentation/i2c/fault-codes:
ENXIO
Returned by I2C adapters to indicate that the address phase
of a transfer didn't get an ACK.  While it might just mean
an I2C device was temporarily not responding, usually it
means there's nothing listening at that address.

This doesn't specify what to do if the transfer doesn't get an ACK
during another phase of the transfer.
However, it does say to send -ENXIO if no ACK during address phase,
which is a subset of the possible no-ACK conditions during a transfer.
 Thus, I choose to return ENXIO in all no-ACK cases, to ensure we send
it during the one case that is specified.

For different i2c adapters i've seen wildly different behavior:
   -ENXIO (i2c-algo-pca)
   -EIO (i2c-algo-bit)
   -EREMOTEIO (i2c-algo-pcf).

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

Re: [PATCH 4/9] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Kurtz]

On Wed, Mar 7, 2012 at 8:17 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Wed,  7 Mar 2012 19:50:45 +0800, Daniel Kurtz djku...@chromium.org wrote:
 There is no disabled port 0.  So, don't even try to initialize/scan
 it, etc.  This saves a bit of time when initializing the driver, since
 the we can avoid a 50ms timeout waiting for a device to respond on
 a port that doesn't even exist.

 Similarly, don't initialize the reserved port, either.

 @@ -150,32 +164,23 @@ static void set_data(void *data, int state_high)
  static struct i2c_adapter *
  intel_gpio_create(struct drm_i915_private *dev_priv, u32 pin)
  {
 -     static const int map_pin_to_reg[] = {
 -             0,
 -             GPIOB,
 -             GPIOA,
 -             GPIOC,
 -             GPIOD,
 -             GPIOE,
 -             GPIOF,
 -             0,
 -     };
       struct intel_gpio *gpio;

 -     if (pin = ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])

 And that doesn't do what your changelog proposes? Why?

This changelog proposes to optimize initialization of the gmbus ports,
not the gpio-bit-bang ports.

 -Chris

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

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
 On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
  On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
  On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com 
  wrote:
 
   Can there be more than one omapdrm device? I guess not. If so, the id
   should be -1.
 
  in the past, we have used multiple devices (using the platform-data to
  divide up the dss resources), although this was sort of a
  special-case.  But in theory you could have multiple.  (Think of a
  multi-seat scenario, where multiple compositors need to run and each
  need to be drm-master of their own device to do mode-setting on their
  corresponding display.)
 
  I think if we use .id = -1, then we'd end up with a funny looking
  bus-id for the device: platform:omapdrm:-1
 
  I don't know about that, but it's the way platform devices are meant to
  be used if there can be only one instance. If the case where there are
  multiple omapdrm devices is rather theoretical, or only used for certain
  debugging scenarios or such, I think having the id as -1 in the mainline
  is cleaner.

 well, I don't care much one way or another, but need to check if there
 is a small patch needed in drm core code that generates the bus-id for
 .id = -1..

 Hmm, why does the drm core care about it?

Because it is the one generating the bus-id.. see
drivers/gpu/drm/drm_platform.c drm_platform_set_busid()

Anyways, it's just a detail about how libdrm/drmOpen() can
differentiate between multiple instances of the same driver, similar
to how PCI bus-id is used in the desktop world.  It is not difficult
to change in drm_platform_set_busid(), although not sure if that would
be considered an ABI change to userspace.  (Maybe it is less critical,
I'm under the impression that other platform-drm users didn't even
realize we had a bus-id.)

 And generally, I think if the bus id is -1, there is no bus id in a
 sense. For example, with bus id 0 you'll get a device omapdrm.0. With
 bus id -1 you'll get a device omapdrm.

   +arch_initcall(omap_init_gpu);
   +
   +void omapdrm_reserve_vram(void)
   +{
   +#ifdef CONFIG_CMA
   +     /*
   +      * Create private 32MiB contiguous memory area for omapdrm.0 
   device
   +      * TODO revisit size.. if uc/wc buffers are allocated from CMA 
   pages
   +      * then the amount of memory we need goes up..
   +      */
   +     dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
  
   What does this actually do? Does it reserve the memory, i.e. it's not
   usable for others? If so, shouldn't there be a way for the user to
   configure it?
 
  It can be re-used by others.. see http://lwn.net/Articles/479297/
 
  The link didn't tell much. I looked at the patches, and
  dma_declare_contiguous allocates the memory with memblock_alloc. So is
  that allocated memory available for any users? If so, why does the
  function want a device pointer as an argument...
 
  Is the memory available for normal kmalloc, or only available via the
  CMA functions? Surely there must be some downside to the above? =) And
  if so, it should be configurable. You could have a board with no display
  at all, and you probably don't want to have 32MB allocated for DRM in
  that case.

 Basically the short version is memory from a CMA carveout can be
 re-used for unpinnable memory.  Not kmalloc, but it can be used for
 anon userspace pages, for example.  Userspace needs memory too.

 Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
 a value like that without any possibility to adjust it just sounds like
 a rather bad thing.

The main requirement is that, on omap3 or before (platforms without
DMM) you need enough to allocate all of your scanout buffers.

I'm not against having a bootarg to adjust, although I strongly prefer
sane defaults and not requiring a million bootargs just to boot in
some usable fashion.

BR,
-R

  Tomi


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

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

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote:
 On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:

  Hmm, why does the drm core care about it?
 
 Because it is the one generating the bus-id.. see
 drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
 
 Anyways, it's just a detail about how libdrm/drmOpen() can
 differentiate between multiple instances of the same driver, similar
 to how PCI bus-id is used in the desktop world.  It is not difficult
 to change in drm_platform_set_busid(), although not sure if that would
 be considered an ABI change to userspace.  (Maybe it is less critical,
 I'm under the impression that other platform-drm users didn't even
 realize we had a bus-id.)

Ok. Well, I'm fine with id 0 also, if it makes sense in the DRM side. It
was just something that caught my eye.

  Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
  a value like that without any possibility to adjust it just sounds like
  a rather bad thing.
 
 The main requirement is that, on omap3 or before (platforms without
 DMM) you need enough to allocate all of your scanout buffers.
 
 I'm not against having a bootarg to adjust, although I strongly prefer
 sane defaults and not requiring a million bootargs just to boot in
 some usable fashion.

Well, those are two different things. I'm fine with a default of 32MB.
My point was, what if I need more, or I don't need any.

 Tomi



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

Re: [PATCH 2/9] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Chris Wilson]

On Wed,  7 Mar 2012 19:50:43 +0800, Daniel Kurtz djku...@chromium.org wrote:
 According to i915 documentation [1], Port D (DP/HDMI Port D) is
 actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
 Pin pair 7 is a reserved pair.
 
 [1] Documentation for [DevSNB+] and [DevIBX], as found on
 http://intellinuxgraphics.org

The problem is I took those definitions from the gen2 specs, and munged
in the obvious changes with gen3... And it appears that the GPIO pin
assignment versus GMBUS has changed over the years. And so the can of
worms is opened!
-Chris

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

Re: [PATCH] drm/radeon: fix a semaphore deadlock on pre cayman asics

[Alex Deucher]

2012/3/7 Christian König deathsim...@vodafone.de:
 The out of order execution of semaphore commands on
 pre cayman asics doesn't work correctly and can
 cause deadlocks, so turn it off for now.

 Signed-off-by: Christian König deathsim...@vodafone.de

Good catch.

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

 ---
  drivers/gpu/drm/radeon/r600.c  |    3 +++
  drivers/gpu/drm/radeon/r600d.h |    1 +
  2 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
 index 8a6d68c..f0b3323 100644
 --- a/drivers/gpu/drm/radeon/r600.c
 +++ b/drivers/gpu/drm/radeon/r600.c
 @@ -2362,6 +2362,9 @@ void r600_semaphore_ring_emit(struct radeon_device 
 *rdev,
        uint64_t addr = semaphore-gpu_addr;
        unsigned sel = emit_wait ? PACKET3_SEM_SEL_WAIT : 
 PACKET3_SEM_SEL_SIGNAL;

 +       if (rdev-family  CHIP_CAYMAN)
 +               sel |= PACKET3_SEM_WAIT_ON_SIGNAL;
 +
        radeon_ring_write(ring, PACKET3(PACKET3_MEM_SEMAPHORE, 1));
        radeon_ring_write(ring, addr  0x);
        radeon_ring_write(ring, (upper_32_bits(addr)  0xff) | sel);
 diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
 index 2ba460b..8ae328f 100644
 --- a/drivers/gpu/drm/radeon/r600d.h
 +++ b/drivers/gpu/drm/radeon/r600d.h
 @@ -850,6 +850,7 @@
  #define        PACKET3_STRMOUT_BUFFER_UPDATE                   0x34
  #define        PACKET3_INDIRECT_BUFFER_MP                      0x38
  #define        PACKET3_MEM_SEMAPHORE                           0x39
 +#              define PACKET3_SEM_WAIT_ON_SIGNAL    (0x1  12)
  #              define PACKET3_SEM_SEL_SIGNAL       (0x6  29)
  #              define PACKET3_SEM_SEL_WAIT         (0x7  29)
  #define        PACKET3_MPEG_INDEX                              0x3A
 --
 1.7.5.4

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

[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

[bugzilla-daemon]

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

--- Comment #14 from Alex Deucher ag...@yahoo.com 2012-03-07 05:37:50 PST ---
(In reply to comment #13)
 
 The interesting thing I notice: issue reproduceable only with OpenGL version 
 of
 KWin. I never can get it reproduced with OpenGL ES version of KWin.
 
 Alex, I have the same issue or I need to fill separate bugreport?

Probably a separate issue.  Please file a new bug.

-- 
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 47039] radeon: The kernel rejected CS

[bugzilla-daemon]

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

Sylvain Réault vindicato...@yahoo.fr changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Sylvain Réault vindicato...@yahoo.fr 2012-03-07 05:53:23 
PST ---
It's very good!

Thank you for the correction and your work in general

-- 
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: set SX_MISC in the r6xx blit code

[Marek Olšák]

Mesa may set it to 1, causing all primitives to be killed.

Signed-off-by: Marek Olšák mar...@gmail.com
---
I hope it's right.

 drivers/gpu/drm/radeon/r600_blit_shaders.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c 
b/drivers/gpu/drm/radeon/r600_blit_shaders.c
index 2d1f6c5..ccec7d2 100644
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
@@ -314,6 +314,10 @@ const u32 r6xx_default_state[] =
0x, /* VGT_VTX_CNT_EN */
 
0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */
+
+   0xc0016900,
0x02c8,
0x, /* VGT_STRMOUT_BUFFER_EN */
 
-- 
1.7.5.4

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

Re: [PATCH] drm/radeon/kms: set SX_MISC in the r6xx blit code

[Alex Deucher]

On Wed, Mar 7, 2012 at 10:51 AM, Marek Olšák mar...@gmail.com wrote:
 Mesa may set it to 1, causing all primitives to be killed.

 Signed-off-by: Marek Olšák mar...@gmail.com

Looks good.  Should probably cc stable as well.

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

 ---
 I hope it's right.

  drivers/gpu/drm/radeon/r600_blit_shaders.c |    4 
  1 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c 
 b/drivers/gpu/drm/radeon/r600_blit_shaders.c
 index 2d1f6c5..ccec7d2 100644
 --- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
 +++ b/drivers/gpu/drm/radeon/r600_blit_shaders.c
 @@ -314,6 +314,10 @@ const u32 r6xx_default_state[] =
        0x, /* VGT_VTX_CNT_EN */

        0xc0016900,
 +       0x00d4,
 +       0x, /* SX_MISC */
 +
 +       0xc0016900,
        0x02c8,
        0x, /* VGT_STRMOUT_BUFFER_EN */

 --
 1.7.5.4

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

[PATCH] r6xx: initialize SX_MISC

[Marek Olšák]

If Mesa set it to 1, the DDX would not render anything = the monitor would
basically freeze.
---
If it's right, please apply it to xf86-video-ati. I don't have commit access.

 src/r6xx_accel.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/r6xx_accel.c b/src/r6xx_accel.c
index 8e6bffa..ab878c3 100644
--- a/src/r6xx_accel.c
+++ b/src/r6xx_accel.c
@@ -1200,6 +1200,7 @@ r600_set_default_state(ScrnInfoPtr pScrn, drmBufPtr ib)
 E32(ib, 0); // VGT_VTX_CNT_EN
 
 EREG(ib, VGT_STRMOUT_BUFFER_EN,   0);
+EREG(ib, SX_MISC, 0);
 END_BATCH();
 }
 
-- 
1.7.5.4

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

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:

 Does this DMM has become synonymous mean that people just started
 calling TILER DMM, and thus the name has stuck, or are there technical
 reasons to handle it as DMM in the kernel? If the former, and if TILER
 is the technically exact name for it, perhaps it would make sense to
 call it TILER, as that's what (at least I) would be looking for if I
 read the TRM and try to find the code for the TILER.

  Tomi

Well the breakdown of the DMM/Tiler kind of goes like this.  The DMM
defines a set of registers used to manipulate the PAT table that backs
the address space with physical memory.  The Tiler portion of the DMM
really just describes the address space that is exposed.  Depending on
what address range you access, you'll get a different mode of access
and rotation.  Management of the address space is attributed to the
Tiler as well and that is where we have managed the address space and
provided APIs to reserve address space and pin/unpin memory to those
regions.

From a hardware perspective, we need access to the resources provided
by the DMM so that we can do the PAT programming and that can only be
gotten from the hwmod entry.  And if you use the hwmod device entry,
you have to match the name used for that entry.

Regards,

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

[PATCH] drm/i915: no-lvds quirk on MSI DC500

[Anisse Astier]

This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.

Cc: sta...@kernel.org
Signed-off-by: Anisse Astier ani...@astier.eu
---
 drivers/gpu/drm/i915/intel_lvds.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index b103c3b..2dee11e 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -739,6 +739,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
DMI_MATCH(DMI_BOARD_NAME, AT5NM10T-I),
},
},
+   {
+   .callback = intel_no_lvds_dmi_callback,
+   .ident = MSI Wind Box DC500,
+   .matches = {
+   DMI_MATCH(DMI_BOARD_VENDOR, MICRO-STAR INTERNATIONAL 
CO., LTD),
+   DMI_MATCH(DMI_BOARD_NAME, MS-7469),
+   },
+   },
 
{ } /* terminating entry */
 };
-- 
1.7.9

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

Re: [PATCH 2/9] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Chris Wilson]

On Thu, 8 Mar 2012 02:02:03 +0800, Daniel Kurtz djku...@chromium.org wrote:
 I'm not sure what exactly you mean by gen2 and gen3 specs, but, as far as I
 can tell, the GPIO pin assignment is the same for both Cougar Point (Sandy
 Bridge) [1] and Ibex Peak (?) [2].  Although, the documentation is a bit
 confusing and it is difficult to tell.
 
 [1] http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
 [2] http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf
 
 What do you mean exactly by gen2  gen3?  Can you point to docs?
gen2 == 830gm,845g,855gm,865g
gen3 == 915g,945g,PineView

Those docs have not been completely scrubbed and made public yet.
-Chris

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

[Bug 41766] radeon lvds panel heavy flickering after opening laptop lid (Mobility Radeon HD 3650)

[bugzilla-daemon]

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

--- Comment #15 from runetmem...@gmail.com 2012-03-07 10:17:06 PST ---
Ok, filled: https://bugs.freedesktop.org/show_bug.cgi?id=47067

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

Re: [PATCH 2/9] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Daniel Kurtz]

On Wed, Mar 7, 2012 at 9:23 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:

 On Wed,  7 Mar 2012 19:50:43 +0800, Daniel Kurtz djku...@chromium.org
 wrote:
  According to i915 documentation [1], Port D (DP/HDMI Port D) is
  actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
  Pin pair 7 is a reserved pair.
 
  [1] Documentation for [DevSNB+] and [DevIBX], as found on
  http://intellinuxgraphics.org

 The problem is I took those definitions from the gen2 specs, and munged
 in the obvious changes with gen3... And it appears that the GPIO pin
 assignment versus GMBUS has changed over the years. And so the can of
 worms is opened!

I'm not sure what exactly you mean by gen2 and gen3 specs, but, as far
as I can tell, the GPIO pin assignment is the same for both Cougar
Point (Sandy Bridge) [1] and Ibex Peak (?) [2].  Although, the
documentation is a bit confusing and it is difficult to tell.

[1] http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
[2] http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf

What do you mean exactly by gen2  gen3?  Can you point to docs?

 -Chris

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