[PATCH 11/11 v3] drm/i915/intel_i2c: reuse GMBUS2 value read in 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.

Signed-off-by: Daniel Kurtz 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_i2c.c |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 9619bde..7674c89 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -214,6 +214,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct drm_i915_private *dev_priv = bus->dev_priv;
int i, reg_offset;
int ret = 0;
+   u32 gmbus2 = 0;

mutex_lock(_priv->gmbus_mutex);

@@ -268,12 +269,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);
@@ -308,21 +309,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;
}

-- 
1.7.7.3

[PATCH 10/11 v3] 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 7396d6e..9619bde 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -227,12 +227,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 09/11 v3] 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 |   34 +++---
 1 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 9d5d286..7396d6e 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -212,7 +212,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
   struct intel_gmbus,
   adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
-   int i, reg_offset, ret;
+   int i, reg_offset;
+   int ret = 0;

mutex_lock(_priv->gmbus_mutex);

@@ -232,7 +233,6 @@ 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) |
   (len << GMBUS_BYTE_COUNT_SHIFT) |
   (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
   GMBUS_SLAVE_READ | GMBUS_SW_RDY);
@@ -266,21 +266,12 @@ gmbus_xfer(struct i2c_adapter *adapter,
I915_WRITE(GMBUS3 + reg_offset, val);
I915_WRITE(GMBUS1 + reg_offset,
   GMBUS_CYCLE_WAIT |
-  (i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
   (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);
@@ -288,11 +279,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;
@@ -300,15 +298,21 @@ gmbus_xfer(struct i2c_adapter *adapter,
goto clear_err;
}

+   /* Generate a STOP condition on the bus */
+   I915_WRITE(GMBUS1 + reg_offset, GMBUS_CYCLE_STOP | GMBUS_SW_RDY);
+
/* Mark the GMBUS interface as disabled after waiting for idle.
 * We will re-enable it at the start of the next xfer,
 * till then let it sleep.
 */
-   if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
+   if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
+10)) {
DRM_INFO("GMBUS [%s] timed out waiting for idle\n",
 adapter->name);
+ 

[PATCH 08/11 v3] drm/i915/intel_i2c: always wait for IDLE before clearing NAK

[Daniel Kurtz]

The GMBUS controller can report a NAK condition while a transaction is
still active. If the driver is fast enough, and the bus is slow enough,
the driver may clear the NAK condition while the controller is still
busy, resulting in a confused GMBUS controller.  This will leave the
controller in a bad state such that the next transaction may fail.

Also, return -ENXIO if a device NAKs a transaction.

Note: this patch also refactors gmbus_xfer to remove the "done" label.

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

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index c467a2e..9d5d286 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -300,26 +300,47 @@ gmbus_xfer(struct i2c_adapter *adapter,
goto clear_err;
}

-   goto done;
+   /* Mark the GMBUS interface as disabled after waiting for idle.
+* We will re-enable it at the start of the next xfer,
+* till then let it sleep.
+*/
+   if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
+   DRM_INFO("GMBUS [%s] timed out waiting for idle\n",
+adapter->name);
+   I915_WRITE(GMBUS0 + reg_offset, 0);
+   ret = i;
+   goto out;

 clear_err:
+   /*
+* Wait for bus to IDLE before clearing NAK.
+* If we clear the NAK while bus is still active, then it will stay
+* active and the next transaction may fail.
+*/
+   if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
+10))
+   DRM_INFO("GMBUS [%s] timed out after NAK\n", adapter->name);
+
/* Toggle the Software Clear Interrupt bit. This has the effect
 * of resetting the GMBUS controller and so clearing the
 * BUS_ERROR raised by the slave's NAK.
 */
I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
I915_WRITE(GMBUS1 + reg_offset, 0);
+   I915_WRITE(GMBUS0 + reg_offset, 0);

-done:
-   /* Mark the GMBUS interface as disabled after waiting for idle.
-* We will re-enable it at the start of the next xfer,
-* till then let it sleep.
+   DRM_DEBUG_DRIVER("GMBUS [%s] NAK for addr: %04x %c(%d)\n",
+adapter->name, msgs[i].addr,
+(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
+
+   /*
+* If no ACK is received during the address phase of a transaction,
+* the adapter must report -ENXIO.
+* It is not clear what to return if no ACK is received at other times.
+* So, we always return -ENXIO in all NAK cases, to ensure we send
+* it at least during the one case that is specified.
 */
-   if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
-   DRM_INFO("GMBUS [%s] timed out waiting for idle\n",
-bus->adapter.name);
-   I915_WRITE(GMBUS0 + reg_offset, 0);
-   ret = i;
+   ret = -ENXIO;
goto out;

 timeout:
-- 
1.7.7.3

[PATCH 07/11 v3] drm/i915/intel_i2c: handle zero-length writes

[Daniel Kurtz]

A common method of probing an i2c bus is trying to do a zero-length write.
Handle this case by checking the length first before decrementing it.

This is actually important, since attempting a zero-length write is one
of the ways that i2cdetect and i2c_new_probed_device detect whether
there is device present on the bus with a given address.

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

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index a04f773..c467a2e 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -258,9 +258,10 @@ gmbus_xfer(struct i2c_adapter *adapter,
u32 val, loop;

val = loop = 0;
-   do {
-   val |= *buf++ << (8 * loop);
-   } while (--len && ++loop < 4);
+   while (len && loop < 4) {
+   val |= *buf++ << (8 * loop++);
+   len -= 1;
+   }

I915_WRITE(GMBUS3 + reg_offset, val);
I915_WRITE(GMBUS1 + reg_offset,
-- 
1.7.7.3

[PATCH 06/11 v3] drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter

[Daniel Kurtz]

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

Note: The gmbus pin must be checked for validity before requesting the
corresponding gmbus port.  This is especially true when using a pin that
has been read from VBIOS, as an improperly or uninitialied BIOS might
indicate '0' for the 'disabled' pin pair, which doesn't actually exist. In
the case of an invalid pin, the driver falls back to using a safer default
pin pair.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/i915_drv.h|7 +++
 drivers/gpu/drm/i915/intel_bios.c  |4 ++--
 drivers/gpu/drm/i915/intel_crt.c   |   14 --
 drivers/gpu/drm/i915/intel_dvo.c   |6 +++---
 drivers/gpu/drm/i915/intel_hdmi.c  |9 ++---
 drivers/gpu/drm/i915/intel_i2c.c   |8 
 drivers/gpu/drm/i915/intel_lvds.c  |7 ---
 drivers/gpu/drm/i915/intel_modes.c |3 ++-
 drivers/gpu/drm/i915/intel_sdvo.c  |9 +
 9 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b132677..64e0ae1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1346,6 +1346,13 @@ 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 inline bool intel_gmbus_is_port_valid(unsigned port)
+{
+   return (port >= GMBUS_PORT_SSC && port <= GMBUS_PORT_DPD);
+}
+
+extern struct i2c_adapter *intel_gmbus_get_adapter(
+   struct drm_i915_private *dev_priv, unsigned port);
 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 e4317da..871aa27 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -372,11 +372,11 @@ parse_general_definitions(struct drm_i915_private 
*dev_priv,
if (block_size >= sizeof(*general)) {
int bus_pin = general->crt_ddc_gmbus_pin;
DRM_DEBUG_KMS("crt_ddc_bus_pin: %d\n", bus_pin);
-   if (bus_pin >= 1 && bus_pin <= 6)
+   if (intel_gmbus_is_port_valid(bus_pin))
dev_priv->crt_ddc_pin = bus_pin;
} else {
DRM_DEBUG_KMS("BDB_GD too small (%d). Invalid.\n",
- block_size);
+ block_size);
}
}
 }
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 4d3d736..d54d232 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -278,9 +278,10 @@ static bool intel_crt_detect_ddc(struct drm_connector 
*connector)
if (intel_ddc_probe(>base, dev_priv->crt_ddc_pin)) {
struct edid *edid;
bool is_digital = false;
+   struct i2c_adapter *i2c;

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

-   ret = intel_ddc_get_modes(connector,
-
_priv->gmbus[dev_priv->crt_ddc_pin].adapter);
+   i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
+   ret = intel_ddc_get_modes(connector, i2c);
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);
+   i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
+   return intel_ddc_get_modes(connector, i2c);
 }

 static int intel_crt_set_property(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 020a7d7..60ba50b9 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -243,7 +243,7 @@ static int intel_dvo_get_modes(struct 

[PATCH 05/11 v3] drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

[Daniel Kurtz]

This memory is always allocated, and it is always a fixed size, so just
allocate it along with the rest of the driver state.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 312dd4e..b132677 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -326,7 +326,7 @@ typedef struct drm_i915_private {
/** gt_lock is also taken in irq contexts. */
struct spinlock gt_lock;

-   struct intel_gmbus *gmbus;
+   struct intel_gmbus gmbus[GMBUS_NUM_PORTS];

/** gmbus_mutex protects against concurrent usage of the single hw gmbus
 * controller on different i2c buses. */
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 7396d7c..aa0670e 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -373,11 +373,6 @@ int intel_setup_gmbus(struct drm_device *dev)
else
dev_priv->gpio_mmio_base = 0;

-   dev_priv->gmbus = kcalloc(GMBUS_NUM_PORTS, sizeof(struct intel_gmbus),
- GFP_KERNEL);
-   if (dev_priv->gmbus == NULL)
-   return -ENOMEM;
-
mutex_init(_priv->gmbus_mutex);

for (i = 0; i < GMBUS_NUM_PORTS; i++) {
@@ -414,8 +409,6 @@ err:
struct intel_gmbus *bus = _priv->gmbus[i];
i2c_del_adapter(>adapter);
}
-   kfree(dev_priv->gmbus);
-   dev_priv->gmbus = NULL;
return ret;
 }

@@ -445,7 +438,4 @@ void intel_teardown_gmbus(struct drm_device *dev)
struct intel_gmbus *bus = _priv->gmbus[i];
i2c_del_adapter(>adapter);
}
-
-   kfree(dev_priv->gmbus);
-   dev_priv->gmbus = NULL;
 }
-- 
1.7.7.3

[PATCH 04/11 v3] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Kurtz]

There is no GMBUS "disabled" port 0, nor "reserved" port 7.
For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
gmbus ports, which means every real gmbus port has a gpio pin.

Given these realizations, clean up gmbus initialization.

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

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/i915_drv.h  |1 -
 drivers/gpu/drm/i915/i915_reg.h  |2 +-
 drivers/gpu/drm/i915/intel_i2c.c |   63 ++---
 3 files changed, 25 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c75a7b..312dd4e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -303,7 +303,6 @@ struct intel_fbc_work;
 struct intel_gmbus {
struct i2c_adapter adapter;
bool force_bit;
-   bool has_gpio;
u32 reg0;
u32 gpio_reg;
struct i2c_algo_bit_data bit_algo;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index accd8ee..a8d218c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -744,7 +744,7 @@
 #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   GMBUS_NUM_PORTS  (GMBUS_PORT_DPD - GMBUS_PORT_SSC + 1)
 #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 ae08a08..7396d7c 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 10
@@ -166,29 +180,16 @@ intel_gpio_post_xfer(struct i2c_adapter *adapter)
intel_i2c_quirk_set(dev_priv, false);
 }

-static bool
+static void
 intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
 {
struct drm_i915_private *dev_priv = bus->dev_priv;
-   static const int map_pin_to_reg[] = {
-   0,
-   GPIOB,
-   GPIOA,
-   GPIOC,
-   GPIOD,
-   GPIOE,
-   GPIOF,
-   0,
-   };
struct i2c_algo_bit_data *algo;

-   if (pin >= ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])
-   return false;
-
algo = >bit_algo;

-   bus->gpio_reg = map_pin_to_reg[pin];
-   bus->gpio_reg += dev_priv->gpio_mmio_base;
+   /* -1 to map pin pair to gmbus index */
+   bus->gpio_reg = dev_priv->gpio_mmio_base + gmbus_ports[pin - 1].reg;

bus->adapter.algo_data = algo;
algo->setsda = set_data;
@@ -200,8 +201,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo->udelay = I2C_RISEFALL_TIME;
algo->timeout = usecs_to_jiffies(2200);
algo->data = bus;
-
-   return true;
 }

 static int
@@ -328,12 +327,8 @@ timeout:
I915_WRITE(GMBUS0 + reg_offset, 0);

/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
-   if (!bus->has_gpio) {
-   ret = -EIO;
-   } else {
-   bus->force_bit = true;
-   ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
-   }
+   bus->force_bit = true;
+   ret = i2c_bit_algo.master_xfer(adapter, msgs, num);

 out:
mutex_unlock(_priv->gmbus_mutex);
@@ -370,16 +365,6 @@ 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;

@@ -397,13 +382,14 @@ int intel_setup_gmbus(struct drm_device *dev)

for (i = 0; i < GMBUS_NUM_PORTS; i++) {
struct intel_gmbus *bus = _priv->gmbus[i];
+   u32 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]);
+gmbus_ports[i].name);

bus->adapter.dev.parent = >pdev->dev;

[PATCH 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

[Daniel Kurtz]

Instead of rolling our own custom quirk_xfer function, use the bit_algo
pre_xfer and post_xfer functions to setup and teardown bit-banged
i2c transactions.

gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
either i2c_bit_algo.master_xfer or its own.  So, Similarly, let gmbus_func
use .force_bit to determine which i2c functionalities are available,
either i2c_bit_algo.functionality, or its own.

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

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 54f85a1..ae08a08 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -137,6 +137,35 @@ static void set_data(void *data, int state_high)
POSTING_READ(bus->gpio_reg);
 }

+static int
+intel_gpio_pre_xfer(struct i2c_adapter *adapter)
+{
+   struct intel_gmbus *bus = container_of(adapter,
+  struct intel_gmbus,
+  adapter);
+   struct drm_i915_private *dev_priv = bus->dev_priv;
+
+   intel_i2c_reset(dev_priv->dev);
+   intel_i2c_quirk_set(dev_priv, true);
+   set_data(bus, 1);
+   set_clock(bus, 1);
+   udelay(I2C_RISEFALL_TIME);
+   return 0;
+}
+
+static void
+intel_gpio_post_xfer(struct i2c_adapter *adapter)
+{
+   struct intel_gmbus *bus = container_of(adapter,
+  struct intel_gmbus,
+  adapter);
+   struct drm_i915_private *dev_priv = bus->dev_priv;
+
+   set_data(bus, 1);
+   set_clock(bus, 1);
+   intel_i2c_quirk_set(dev_priv, false);
+}
+
 static bool
 intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
 {
@@ -166,6 +195,8 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo->setscl = set_clock;
algo->getsda = get_data;
algo->getscl = get_clock;
+   algo->pre_xfer = intel_gpio_pre_xfer;
+   algo->post_xfer = intel_gpio_post_xfer;
algo->udelay = I2C_RISEFALL_TIME;
algo->timeout = usecs_to_jiffies(2200);
algo->data = bus;
@@ -174,30 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
 }

 static int
-intel_i2c_quirk_xfer(struct intel_gmbus *bus,
-struct i2c_msg *msgs,
-int num)
-{
-   struct drm_i915_private *dev_priv = bus->dev_priv;
-   int ret;
-
-   intel_i2c_reset(dev_priv->dev);
-
-   intel_i2c_quirk_set(dev_priv, true);
-   set_data(bus, 1);
-   set_clock(bus, 1);
-   udelay(I2C_RISEFALL_TIME);
-
-   ret = i2c_bit_algo.master_xfer(>adapter, msgs, num);
-
-   set_data(bus, 1);
-   set_clock(bus, 1);
-   intel_i2c_quirk_set(dev_priv, false);
-
-   return ret;
-}
-
-static int
 gmbus_xfer(struct i2c_adapter *adapter,
   struct i2c_msg *msgs,
   int num)
@@ -211,7 +218,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
mutex_lock(_priv->gmbus_mutex);

if (bus->force_bit) {
-   ret = intel_i2c_quirk_xfer(bus, msgs, num);
+   ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
goto out;
}

@@ -325,8 +332,9 @@ timeout:
ret = -EIO;
} else {
bus->force_bit = true;
-   ret = intel_i2c_quirk_xfer(bus, msgs, num);
+   ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
}
+
 out:
mutex_unlock(_priv->gmbus_mutex);
return ret;
@@ -334,11 +342,21 @@ out:

 static u32 gmbus_func(struct i2c_adapter *adapter)
 {
-   return i2c_bit_algo.functionality(adapter) &
+   struct intel_gmbus *bus = container_of(adapter,
+  struct intel_gmbus,
+  adapter);
+   struct drm_i915_private *dev_priv = bus->dev_priv;
+   u32 func;
+
+   mutex_lock(_priv->gmbus_mutex);
+   func = bus->force_bit ? i2c_bit_algo.functionality(adapter) :
(I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
/* I2C_FUNC_10BIT_ADDR | */
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
I2C_FUNC_SMBUS_BLOCK_PROC_CALL);
+   mutex_unlock(_priv->gmbus_mutex);
+
+   return func;
 }

 static const struct i2c_algorithm gmbus_algorithm = {
-- 
1.7.7.3

[PATCH 02/11 v3] 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 f3609f2..accd8ee 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -742,9 +742,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 86b1861..54f85a1 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -148,8 +148,8 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
GPIOC,
GPIOD,
GPIOE,
-   0,
GPIOF,
+   0,
};
struct i2c_algo_bit_data *algo;

@@ -359,8 +359,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 01/11 v3] drm/i915/intel_i2c: cleanup

[Daniel Kurtz]

80 col, spaces around operators and other basic cleanup.
Some info message cleanup.

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

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 0713cc2..86b1861 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -230,13 +230,16 @@ 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)
+   if (I915_READ(GMBUS2 + reg_offset) &
+   GMBUS_SATOER)
goto clear_err;

val = I915_READ(GMBUS3 + reg_offset);
@@ -260,12 +263,15 @@ 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)
+   if (I915_READ(GMBUS2 + reg_offset) &
+   GMBUS_SATOER)
goto clear_err;

val = loop = 0;
@@ -274,11 +280,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;
@@ -300,14 +309,15 @@ done:
 * till then let it sleep.
 */
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
-   DRM_INFO("GMBUS timed out waiting for idle\n");
+   DRM_INFO("GMBUS [%s] timed out waiting for idle\n",
+bus->adapter.name);
I915_WRITE(GMBUS0 + reg_offset, 0);
ret = i;
goto out;

 timeout:
-   DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d 
[%s]\n",
-bus->reg0 & 0xff, bus->adapter.name);
+   DRM_INFO("GMBUS [%s] timed out, falling back to bit banging on pin 
%d\n",
+bus->adapter.name, bus->reg0 & 0xff);
I915_WRITE(GMBUS0 + reg_offset, 0);

/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
-- 
1.7.7.3

[PATCH 00/11 v3] 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) by terminating every transaction with a
   WAIT cycle.
 * 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
v3:
 * rebased onto Daniel Vetter's drm-intel-next-queued branch
   at git://people.freedesktop.org/~danvet/drm-intel
 * replace intel_i2c_quirk_xfer with pre/post_xfer i2c routines
 * pre-allocate gmbus array
 * drop interrupt approach since I could not make it stable, probably due to
   difficulty in clearing and resetting the GMBUS interrupt which is buffered
   behind the SDE's PCH interrupt.
 * Fix zero-length writes
 * Wait for IDLE before clearing NAK

Daniel Kurtz (11):
  drm/i915/intel_i2c: cleanup
  drm/i915/intel_i2c: assign HDMI port D to pin pair 6
  drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio
xfers
  drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments
  drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private
  drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter
  drm/i915/intel_i2c: handle zero-length writes
  drm/i915/intel_i2c: always wait for IDLE before clearing 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|   10 +-
 drivers/gpu/drm/i915/i915_reg.h|6 +-
 drivers/gpu/drm/i915/intel_bios.c  |4 +-
 drivers/gpu/drm/i915/intel_crt.c   |   14 +-
 drivers/gpu/drm/i915/intel_dvo.c   |6 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |9 +-
 drivers/gpu/drm/i915/intel_i2c.c   |  278 ++--
 drivers/gpu/drm/i915/intel_lvds.c  |7 +-
 drivers/gpu/drm/i915/intel_modes.c |3 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |9 +-
 10 files changed, 213 insertions(+), 133 deletions(-)

-- 
1.7.7.3

[PATCH] drm: Validate requested virtual size against allocated fb size

[Chris Wilson]

mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.

References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_fb_helper.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 7740dd2..a0d6e89 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -559,9 +559,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;

/* Need to resize the fb object !!! */
-   if (var->bits_per_pixel > fb->bits_per_pixel || var->xres > fb->width 
|| var->yres > fb->height) {
+   if (var->bits_per_pixel > fb->bits_per_pixel ||
+   var->xres > fb->width || var->yres > fb->height ||
+   var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
DRM_DEBUG("fb userspace requested width/height/bpp is greater 
than current fb "
- "object %dx%d-%d > %dx%d-%d\n", var->xres, var->yres, 
var->bits_per_pixel,
+ "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
+ var->xres, var->yres, var->bits_per_pixel,
+ var->xres_virtual, var->yres_virtual,
  fb->width, fb->height, fb->bits_per_pixel);
return -EINVAL;
}
-- 
1.7.9.1

[PATCH 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

[Daniel Vetter]

On Tue, Mar 27, 2012 at 01:58:47AM +0800, Daniel Kurtz wrote:
> On Mon, Mar 26, 2012 at 10:49 PM, Daniel Vetter  wrote:
> > On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
> >> Instead of rolling our own custom quirk_xfer function, use the bit_algo
> >> pre_xfer and post_xfer functions to setup and teardown bit-banged
> >> i2c transactions.
> >>
> >> gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
> >> either i2c_bit_algo.master_xfer or its own. ?So, Similarly, let gmbus_func
> >> use .force_bit to determine which i2c functionalities are available,
> >> either i2c_bit_algo.functionality, or its own.
> >
> > Please split this part of the patch into a separate patch. Furthermore I'm
> > not sure what this should buy us, given that we might magically changes
> > our i2c feature set once with gone to fallback mode. Can you please
> > elaborate why we need this?
> 
> An i2c adapter's functionality is provided by its algorithm.
> Since these gmbus adapters can [for now] change their algorithm at
> runtime, I thought the functionality returned should match the
> currently selected algorithm at any given moment.
> 
> Arguably, the adapter actually sort of provides the union of the two
> functionalities since if a particular transfer fails using gmbus, it
> gets retried using bit-banged.  But then again, this is a one-shot
> permanent switch, so perhaps we should return the union of the
> functionalities if force_bit == 0, and then only the bit-algo
> functionality after the switch?

In that case I guess we can drop it - current edid reading seems to work
and without a good reason I'd like not to play clever tricks because it
doesn't seem to be worth it.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 33309] [855GM] GPU freeze due to overlay hang

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

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

--- Comment #15 from Daniel Vetter  2012-03-26 13:40:43 PDT 
---
> --- Comment #14 from stefan  2012-03-26 13:17:45 
> PDT ---
> Hi Daniel,
> I believe I'm also bitten by this bug and I'd like to test your patch.
> Unfortunately, MI_WRITE_NOPID_REG is not defined in the newest kernels
> and I couldn't find any reference. If you could update your patch with
> its definition, I can give it a go.

Just add
#define MI_WRITE_NOPID_REG (1 << 22)
somewhere.
Yours, Daniel

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

[Bug 33309] [855GM] GPU freeze due to overlay hang

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

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

--- Comment #14 from stefan  2012-03-26 13:17:45 PDT 
---
Hi Daniel,
I believe I'm also bitten by this bug and I'd like to test your patch.
Unfortunately, MI_WRITE_NOPID_REG is not defined in the newest kernels
and I couldn't find any reference. If you could update your patch with
its definition, I can give it a go.

Cheers,
Stefan.

-- 
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: base prime/dma-buf support

[Ville Syrjälä]

On Mon, Mar 26, 2012 at 04:02:55PM +0100, Dave Airlie wrote:

> +int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> + struct drm_file *file_priv, uint32_t handle, uint32_t flags,
> + int *prime_fd)
> +{
> + struct drm_gem_object *obj;
> +
> + obj = drm_gem_object_lookup(dev, file_priv, handle);
> + if (!obj)
> + return -ENOENT;
> +
> + /* don't allow imported buffers to be re-exported */
> + if (obj->import_attach) {
> + drm_gem_object_unreference_unlocked(obj);
> + return -EINVAL;
> + }
> +
> + if (obj->export_dma_buf) {
> + get_file(obj->export_dma_buf->file);
> + *prime_fd = dma_buf_fd(obj->export_dma_buf, flags);
> + drm_gem_object_unreference_unlocked(obj);
> + } else {
> + obj->export_dma_buf =
> + dev->driver->gem_prime_export(dev, obj, flags);
> + if (IS_ERR_OR_NULL(obj->export_dma_buf)) {
> + /* normally the created dma-buf takes ownership of the 
> ref,
> +  * but if that fails then drop the ref
> +  */
> + drm_gem_object_unreference_unlocked(obj);
> + return PTR_ERR(obj->export_dma_buf);

PTR_ERR(NULL) seems like a bad idea. Also, you're accessing 'obj' after
dropping the reference.

> + }
> + *prime_fd = dma_buf_fd(obj->export_dma_buf, flags);
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
> +
> +int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> + struct drm_file *file_priv, int prime_fd, uint32_t *handle)
> +{
> + struct dma_buf *dma_buf;
> + struct drm_gem_object *obj;
> + int ret;
> +
> + dma_buf = dma_buf_get(prime_fd);
> + if (IS_ERR(dma_buf))
> + return PTR_ERR(dma_buf);
> +
> + ret = drm_prime_lookup_fd_handle_mapping(_priv->prime,
> + dma_buf, handle);
> + if (!ret) {
> + dma_buf_put(dma_buf);
> + return 0;
> + }
> +
> + /* never seen this one, need to import */
> + obj = dev->driver->gem_prime_import(dev, dma_buf);
> + if (IS_ERR_OR_NULL(obj)) {
> + ret = PTR_ERR(obj);

PTR_ERR(NULL) again.

> + goto fail_put;
> + }
> +
> + ret = drm_gem_handle_create(file_priv, obj, handle);
> + drm_gem_object_unreference_unlocked(obj);
> + if (ret)
> + goto fail_put;
> +
> + ret = drm_prime_insert_fd_handle_mapping(_priv->prime,
> + dma_buf, *handle);
> + if (ret)
> + goto fail;
> +
> + return 0;
> +
> +fail:
> + /* hmm, if driver attached, we are relying on the free-object path
> +  * to detach.. which seems ok..
> +  */
> + drm_gem_object_handle_unreference_unlocked(obj);
> +fail_put:
> + dma_buf_put(dma_buf);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
> +
> +int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file_priv)
> +{
> + struct drm_prime_handle *args = data;
> + uint32_t flags;
> +
> + if (!drm_core_check_feature(dev, DRIVER_PRIME))
> + return -EINVAL;
> +
> + if (!dev->driver->prime_handle_to_fd)
> + return -ENOSYS;
> +
> + /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
> + flags = args->flags & DRM_CLOEXEC;

Check that the unused flags are 0? If you allow broken userspace to
pass uninitialized 'flags' to the kernel, you may have compatibility
problems if/when you want to add more flags.

> +
> + return dev->driver->prime_handle_to_fd(dev, file_priv,
> + args->handle, flags, >fd);
> +}
> +
> +int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
> +  struct drm_file *file_priv)
> +{
> + struct drm_prime_handle *args = data;
> +
> + if (!drm_core_check_feature(dev, DRIVER_PRIME))
> + return -EINVAL;
> +
> + if (!dev->driver->prime_fd_to_handle)
> + return -ENOSYS;
> +
> + return dev->driver->prime_fd_to_handle(dev, file_priv,
> + args->fd, >handle);
> +}
> +
> +/*
> + * drm_prime_pages_to_sg
> + *
> + * this helper creates an sg table object from a set of pages
> + * the driver is responsible for mapping the pages into the
> + * importers address space
> + */
> +struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
> +{
> + struct sg_table *sg = NULL;
> + struct scatterlist *iter;
> + int i;
> + int ret;
> +
> + sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);

kmalloc() would be enough. sg_alloc_table() already does a memset().

> + if (!sg)
> + goto out;
> +
> + ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
> + if (ret)
> + goto out;
> +
> + 

[RFCv2 PATCH 3/9] v4l: vb2: Add dma-contig allocator as dma_buf user

[Tomasz Stanislawski]

Hi Laurent,
Please refer to the comments below.

On 03/22/2012 12:04 PM, Laurent Pinchart wrote:
> Hi Tomasz,
> 
> On Tuesday 13 March 2012 11:17:01 Tomasz Stanislawski wrote:
>> From: Sumit Semwal 
>>
>> This patch makes changes for adding dma-contig as a dma_buf user. It
>> provides function implementations for the {attach, detach, map,
>> unmap}_dmabuf() mem_ops of DMABUF memory type.
>>
>> Signed-off-by: Sumit Semwal 
>> Signed-off-by: Sumit Semwal 
>>  [author of the original patch]
>> Signed-off-by: Tomasz Stanislawski 
>>  [integration with refactored dma-contig allocator]
>> ---
>>  drivers/media/video/videobuf2-dma-contig.c |  116
>>  1 files changed, 116 insertions(+), 0
>> deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index c1dc043..746dd5f 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>> @@ -35,6 +35,9 @@ struct vb2_dc_buf {
>>
>>  /* USERPTR related */
>>  struct vm_area_struct   *vma;
>> +
>> +/* DMABUF related */
>> +struct dma_buf_attachment   *db_attach;
>>  };
>>
>>  /*/
>> @@ -485,6 +488,115 @@ fail_buf:
>>  }
>>
>>  /*/
>> +/*   callbacks for DMABUF buffers*/
>> +/*/
>> +
>> +static int vb2_dc_map_dmabuf(void *mem_priv)
>> +{
>> +struct vb2_dc_buf *buf = mem_priv;
>> +struct sg_table *sgt;
>> +unsigned long contig_size;
>> +int ret = 0;
>> +
>> +if (WARN_ON(!buf->db_attach)) {
>> +printk(KERN_ERR "trying to pin a non attached buffer\n");
>> +return -EINVAL;
>> +}
>> +
>> +if (WARN_ON(buf->dma_sgt)) {
>> +printk(KERN_ERR "dmabuf buffer is already pinned\n");
>> +return 0;
>> +}
>> +
>> +/* get the associated scatterlist for this buffer */
>> +sgt = dma_buf_map_attachment(buf->db_attach, buf->dma_dir);
>> +if (IS_ERR_OR_NULL(sgt)) {
>> +printk(KERN_ERR "Error getting dmabuf scatterlist\n");
>> +return -EINVAL;
>> +}
> 
> I've checked why dma_map_sg() was missing from here, and then remembered that 
> the exporter is still responsible for mapping the buffer to the importer's 
> device address space :-) I'll raise that topic separately.
> 
>> +
>> +/* checking if dmabuf is big enough to store contiguous chunk */
>> +contig_size = vb2_dc_get_contiguous_size(sgt);
>> +if (contig_size < buf->size) {
>> +printk(KERN_ERR "contiguous chunk of dmabuf is too small\n");
>> +ret = -EFAULT;
>> +goto fail_map;
>> +}
>> +
>> +buf->dma_addr = sg_dma_address(sgt->sgl);
>> +buf->dma_sgt = sgt;
>> +
>> +return 0;
>> +
>> +fail_map:
>> +dma_buf_unmap_attachment(buf->db_attach, sgt);
>> +
>> +return ret;
>> +}
>> +
>> +static void vb2_dc_unmap_dmabuf(void *mem_priv)
>> +{
>> +struct vb2_dc_buf *buf = mem_priv;
>> +struct sg_table *sgt = buf->dma_sgt;
>> +
>> +if (WARN_ON(!buf->db_attach)) {
>> +printk(KERN_ERR "trying to unpin a not attached buffer\n");
>> +return;
>> +}
>> +
>> +if (WARN_ON(!sgt)) {
>> +printk(KERN_ERR "dmabuf buffer is already unpinned\n");
>> +return;
>> +}
>> +
>> +dma_buf_unmap_attachment(buf->db_attach, sgt);
>> +
>> +buf->dma_addr = 0;
>> +buf->dma_sgt = NULL;
>> +}
>> +
>> +static void vb2_dc_detach_dmabuf(void *mem_priv)
>> +{
>> +struct vb2_dc_buf *buf = mem_priv;
>> +
>> +if (buf->dma_addr)
>> +vb2_dc_unmap_dmabuf(buf);
> 
> Can detach() be called with the buffer still mapped() ? Wouldn't that be a 
> bug 
> in the caller ?
> 

No, it is not. The functions from vb2_dc_*_dmabuf are called by vb2-core.
It is not a part of DMABUF API itself. Therefore usage can be a bit different.
Please refer to the function __qbuf_dmabuf function vb2-core. If new DMABUF
is passed to in the QBUF then old DMABUF is released by calling detach_dmabuf
without unmap. However, this part of code is probably not reachable if the
buffer was not dequeued.

Detach without unmap may happen in a case of closing a video fd
without prior dequeuing of all buffers.

Do you think it would be a good idea to move a call map_dmabuf to
__enqueue_in_driver and add calling unmap_dmabuf to vb2_buffer_done?

>> +
>> +/* detach this attachment */
>> +dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
>> +kfree(buf);
>> +}
> 
> There's nothing allocator-specific in the attach/detach operations. Shouldn't 
> they be moved to the vb2 core ?
> 

Calling dma_buf_attach could be moved to vb2-core. But it gives little gain.
First, the pointer of dma_buf_attachment would have to be added to struct 
vb2_plane.
Second, the allocator would have to keep in the copy of this pointer in its

[PATCH 00/11 v3] fix gmbus writes and related issues

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:39PM +0800, Daniel Kurtz wrote:
> 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) by terminating every transaction with a
>WAIT cycle.
>  * 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
> v3:
>  * rebased onto Daniel Vetter's drm-intel-next-queued branch
>at git://people.freedesktop.org/~danvet/drm-intel
>  * replace intel_i2c_quirk_xfer with pre/post_xfer i2c routines
>  * pre-allocate gmbus array
>  * drop interrupt approach since I could not make it stable, probably due to
>difficulty in clearing and resetting the GMBUS interrupt which is buffered
>behind the SDE's PCH interrupt.
>  * Fix zero-length writes
>  * Wait for IDLE before clearing NAK

Ok, I've found a few more things to complain about ;-) I haven't looked to
closely add the later patches that fix up the actual gmbus code, but on a
quick read I don't see any issues there - I'll cross check the code
somewhen later with Bspec.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 01/11 v3] drm/i915/intel_i2c: cleanup

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:40PM +0800, Daniel Kurtz wrote:
> 80 col, spaces around operators and other basic cleanup.
> Some info message cleanup.
> 
> Signed-off-by: Daniel Kurtz 

On reconsideration, nacked. You desperately try to squeeze a function with
already 5 indent levels (not counting indentation due to function
arguments and overflow) with already 100+ lines of code into 80 columns.

Please do the right thing and split out a few of helper functions. I
suggest you split out the read and write code, i.e.

if (msgs[i].flags & I2C_M_RD)
gmbus_xfer_read()
else
gmbus_xfer_write

This way you get 3 levels of tab space of room and I won't have to
complain as much that some of your later patches make gmbus_xfer way too
bug.

Yours, Daniel

> ---
>  drivers/gpu/drm/i915/intel_i2c.c |   32 +---
>  1 files changed, 21 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 0713cc2..86b1861 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -230,13 +230,16 @@ 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)
> + if (I915_READ(GMBUS2 + reg_offset) &
> + GMBUS_SATOER)
>   goto clear_err;
>  
>   val = I915_READ(GMBUS3 + reg_offset);
> @@ -260,12 +263,15 @@ 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)
> + if (I915_READ(GMBUS2 + reg_offset) &
> + GMBUS_SATOER)
>   goto clear_err;
>  
>   val = loop = 0;
> @@ -274,11 +280,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;
> @@ -300,14 +309,15 @@ done:
>* till then let it sleep.
>*/
>   if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
> - DRM_INFO("GMBUS timed out waiting for idle\n");
> + DRM_INFO("GMBUS [%s] timed out waiting for idle\n",
> +  bus->adapter.name);
>   I915_WRITE(GMBUS0 + reg_offset, 0);
>   ret = i;
>   goto out;
>  
>  timeout:
> - DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d 
> [%s]\n",
> -  bus->reg0 & 0xff, bus->adapter.name);
> + DRM_INFO("GMBUS [%s] timed out, falling back to bit banging on pin 
> %d\n",
> +  bus->adapter.name, bus->reg0 & 0xff);
>   

[PATCH 06/11 v3] drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:45PM +0800, Daniel Kurtz wrote:
> Instead of letting other modules directly access the ->gmbus array,
> introduce a new API, intel_gmbus_get_adapter(), to lookup an i2c_adapter
> for a given gmbus pin pair identifier.  This API enables later refactoring
> of the gmbus pin pair list.
> 
> Note: The gmbus pin must be checked for validity before requesting the
> corresponding gmbus port.  This is especially true when using a pin that
> has been read from VBIOS, as an improperly or uninitialied BIOS might
> indicate '0' for the 'disabled' pin pair, which doesn't actually exist. In
> the case of an invalid pin, the driver falls back to using a safer default
> pin pair.
> 
> Signed-off-by: Daniel Kurtz 

With the cavet of the patch ordering issue, this looks ok. One comment
below.

> ---
>  drivers/gpu/drm/i915/i915_drv.h|7 +++
>  drivers/gpu/drm/i915/intel_bios.c  |4 ++--
>  drivers/gpu/drm/i915/intel_crt.c   |   14 --
>  drivers/gpu/drm/i915/intel_dvo.c   |6 +++---
>  drivers/gpu/drm/i915/intel_hdmi.c  |9 ++---
>  drivers/gpu/drm/i915/intel_i2c.c   |8 
>  drivers/gpu/drm/i915/intel_lvds.c  |7 ---
>  drivers/gpu/drm/i915/intel_modes.c |3 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c  |9 +
>  9 files changed, 45 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b132677..64e0ae1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1346,6 +1346,13 @@ 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 inline bool intel_gmbus_is_port_valid(unsigned port)
> +{
> + return (port >= GMBUS_PORT_SSC && port <= GMBUS_PORT_DPD);
> +}
> +
> +extern struct i2c_adapter *intel_gmbus_get_adapter(
> + struct drm_i915_private *dev_priv, unsigned port);
>  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 e4317da..871aa27 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -372,11 +372,11 @@ parse_general_definitions(struct drm_i915_private 
> *dev_priv,
>   if (block_size >= sizeof(*general)) {
>   int bus_pin = general->crt_ddc_gmbus_pin;
>   DRM_DEBUG_KMS("crt_ddc_bus_pin: %d\n", bus_pin);
> - if (bus_pin >= 1 && bus_pin <= 6)
> + if (intel_gmbus_is_port_valid(bus_pin))
>   dev_priv->crt_ddc_pin = bus_pin;
>   } else {
>   DRM_DEBUG_KMS("BDB_GD too small (%d). Invalid.\n",
> -   block_size);
> +   block_size);
>   }
>   }
>  }
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 4d3d736..d54d232 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -278,9 +278,10 @@ static bool intel_crt_detect_ddc(struct drm_connector 
> *connector)
>   if (intel_ddc_probe(>base, dev_priv->crt_ddc_pin)) {
>   struct edid *edid;
>   bool is_digital = false;
> + struct i2c_adapter *i2c;
>  
> - edid = drm_get_edid(connector,
> - _priv->gmbus[dev_priv->crt_ddc_pin].adapter);
> + i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
> + edid = drm_get_edid(connector, i2c);
>   /*
>* This may be a DVI-I connector with a shared DDC
>* link between analog and digital outputs, so we
> @@ -483,15 +484,16 @@ static int intel_crt_get_modes(struct drm_connector 
> *connector)
>   struct drm_device *dev = connector->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
> + struct i2c_adapter *i2c;
>  
> - ret = intel_ddc_get_modes(connector,
> -  
> _priv->gmbus[dev_priv->crt_ddc_pin].adapter);
> + i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->crt_ddc_pin);
> + ret = intel_ddc_get_modes(connector, i2c);
>   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);
> + i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
> + return intel_ddc_get_modes(connector, i2c);
>  }
>  
>  static int intel_crt_set_property(struct 

[PATCH 05/11 v3] drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
> This memory is always allocated, and it is always a fixed size, so just
> allocate it along with the rest of the driver state.
> 
> Signed-off-by: Daniel Kurtz 
Reviewed-by: Daniel Vetter 
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 04/11 v3] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
> There is no GMBUS "disabled" port 0, nor "reserved" port 7.
> For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
> gmbus ports, which means every real gmbus port has a gpio pin.
> 
> Given these realizations, clean up gmbus initialization.
> 
> Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.
> 
> Signed-off-by: Daniel Kurtz 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |1 -
>  drivers/gpu/drm/i915/i915_reg.h  |2 +-
>  drivers/gpu/drm/i915/intel_i2c.c |   63 ++---
>  3 files changed, 25 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> @@ -370,16 +365,6 @@ 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;
>  
> @@ -397,13 +382,14 @@ int intel_setup_gmbus(struct drm_device *dev)
>  
>   for (i = 0; i < GMBUS_NUM_PORTS; i++) {
>   struct intel_gmbus *bus = _priv->gmbus[i];
> + u32 port = i + 1; /* +1 to map gmbus index to pin pair */

On reconsideration you move around gmbus ports here, which will break
things horribly. I've wondered a bit how that could possible work and
noticed that you fix things up in the a later patch when introducing
get_adapter.

This ordering breaks bisecting is a complete no-go. If you want to do this
(I still think the refactor is nice) you need to introduce get_adapter
first, then change the meaning of the array index in this patch while
adjusting the lookup in the new get_adapter function.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 05/11 v3] drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
> This memory is always allocated, and it is always a fixed size, so just
> allocate it along with the rest of the driver state.
> 
> Signed-off-by: Daniel Kurtz 
Reviewed-by: Daniel Vetter 
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 04/11 v3] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
> There is no GMBUS "disabled" port 0, nor "reserved" port 7.
> For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
> gmbus ports, which means every real gmbus port has a gpio pin.
> 
> Given these realizations, clean up gmbus initialization.
> 
> Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.
> 
> Signed-off-by: Daniel Kurtz 

Nice cleanup.
Reviewed-by: Daniel Vetter 
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Daniel Vetter]

On Mon, Mar 26, 2012 at 04:47:11PM +0200, Daniel Vetter wrote:
> On Mon, Mar 26, 2012 at 10:26:41PM +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
> > 
> > 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.
> 
> ... this is no longer true on drm-intel-next.
> 
> >  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 
> 
> Otherwise this looks ok to me - I've checked with gen3 Bspec and we seem
> to indeed have a 1:1 mapping, see "Display Registers", 1.5.3 "GPIO Control
> Registers", the list right below the heading.

well, scrap that, I've confused myself here a bit. Afaict we don't
actually use these gmbus ports on earlier chips.
> 
> Reviewed-by: Daniel Vetter 
> 
> When resending, can you please add the Bspec reference above?

Can you you instead add a clear reference (Volume, Full Section plus
Heading Title) for the Snb/Ibx public Bspec.

Thanks, Daneil
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[Bug 46724] radeon_drm_winsys compile fail with libdrm in non standard directory

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

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

Jerome Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Jerome Glisse  2012-03-26 
10:01:24 PDT ---
Should be working now, reopen if it's not the case

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

[PATCH 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
> Instead of rolling our own custom quirk_xfer function, use the bit_algo
> pre_xfer and post_xfer functions to setup and teardown bit-banged
> i2c transactions.
> 
> gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
> either i2c_bit_algo.master_xfer or its own.  So, Similarly, let gmbus_func
> use .force_bit to determine which i2c functionalities are available,
> either i2c_bit_algo.functionality, or its own.

Please split this part of the patch into a separate patch. Furthermore I'm
not sure what this should buy us, given that we might magically changes
our i2c feature set once with gone to fallback mode. Can you please
elaborate why we need this?

The pre_xfer/post_xfer stuff looks good to me, that part along is
Reviewed-by: Daniel Vetter 

Yours, Daniel

> 
> Signed-off-by: Daniel Kurtz 
> ---
>  drivers/gpu/drm/i915/intel_i2c.c |   72 +++--
>  1 files changed, 45 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 54f85a1..ae08a08 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -137,6 +137,35 @@ static void set_data(void *data, int state_high)
>   POSTING_READ(bus->gpio_reg);
>  }
>  
> +static int
> +intel_gpio_pre_xfer(struct i2c_adapter *adapter)
> +{
> + struct intel_gmbus *bus = container_of(adapter,
> +struct intel_gmbus,
> +adapter);
> + struct drm_i915_private *dev_priv = bus->dev_priv;
> +
> + intel_i2c_reset(dev_priv->dev);
> + intel_i2c_quirk_set(dev_priv, true);
> + set_data(bus, 1);
> + set_clock(bus, 1);
> + udelay(I2C_RISEFALL_TIME);
> + return 0;
> +}
> +
> +static void
> +intel_gpio_post_xfer(struct i2c_adapter *adapter)
> +{
> + struct intel_gmbus *bus = container_of(adapter,
> +struct intel_gmbus,
> +adapter);
> + struct drm_i915_private *dev_priv = bus->dev_priv;
> +
> + set_data(bus, 1);
> + set_clock(bus, 1);
> + intel_i2c_quirk_set(dev_priv, false);
> +}
> +
>  static bool
>  intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
>  {
> @@ -166,6 +195,8 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
>   algo->setscl = set_clock;
>   algo->getsda = get_data;
>   algo->getscl = get_clock;
> + algo->pre_xfer = intel_gpio_pre_xfer;
> + algo->post_xfer = intel_gpio_post_xfer;
>   algo->udelay = I2C_RISEFALL_TIME;
>   algo->timeout = usecs_to_jiffies(2200);
>   algo->data = bus;
> @@ -174,30 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
>  }
>  
>  static int
> -intel_i2c_quirk_xfer(struct intel_gmbus *bus,
> -  struct i2c_msg *msgs,
> -  int num)
> -{
> - struct drm_i915_private *dev_priv = bus->dev_priv;
> - int ret;
> -
> - intel_i2c_reset(dev_priv->dev);
> -
> - intel_i2c_quirk_set(dev_priv, true);
> - set_data(bus, 1);
> - set_clock(bus, 1);
> - udelay(I2C_RISEFALL_TIME);
> -
> - ret = i2c_bit_algo.master_xfer(>adapter, msgs, num);
> -
> - set_data(bus, 1);
> - set_clock(bus, 1);
> - intel_i2c_quirk_set(dev_priv, false);
> -
> - return ret;
> -}
> -
> -static int
>  gmbus_xfer(struct i2c_adapter *adapter,
>  struct i2c_msg *msgs,
>  int num)
> @@ -211,7 +218,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
>   mutex_lock(_priv->gmbus_mutex);
>  
>   if (bus->force_bit) {
> - ret = intel_i2c_quirk_xfer(bus, msgs, num);
> + ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
>   goto out;
>   }
>  
> @@ -325,8 +332,9 @@ timeout:
>   ret = -EIO;
>   } else {
>   bus->force_bit = true;
> - ret = intel_i2c_quirk_xfer(bus, msgs, num);
> + ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
>   }
> +
>  out:
>   mutex_unlock(_priv->gmbus_mutex);
>   return ret;
> @@ -334,11 +342,21 @@ out:
>  
>  static u32 gmbus_func(struct i2c_adapter *adapter)
>  {
> - return i2c_bit_algo.functionality(adapter) &
> + struct intel_gmbus *bus = container_of(adapter,
> +struct intel_gmbus,
> +adapter);
> + struct drm_i915_private *dev_priv = bus->dev_priv;
> + u32 func;
> +
> + mutex_lock(_priv->gmbus_mutex);
> + func = bus->force_bit ? i2c_bit_algo.functionality(adapter) :
>   (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
>   /* I2C_FUNC_10BIT_ADDR | */
>   I2C_FUNC_SMBUS_READ_BLOCK_DATA |
>   I2C_FUNC_SMBUS_BLOCK_PROC_CALL);
> + mutex_unlock(_priv->gmbus_mutex);
> +
> + return func;
>  }
>  
>  static const struct i2c_algorithm 

[PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:41PM +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
> 
> 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.

... this is no longer true on drm-intel-next.

>  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 

Otherwise this looks ok to me - I've checked with gen3 Bspec and we seem
to indeed have a 1:1 mapping, see "Display Registers", 1.5.3 "GPIO Control
Registers", the list right below the heading.

Reviewed-by: Daniel Vetter 

When resending, can you please add the Bspec reference above?

Thanks, Daniel

> ---
>  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 f3609f2..accd8ee 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -742,9 +742,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_RESERVED7 /* 7 reserved */
> +#define   GMBUS_NUM_PORTS8
>  #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 86b1861..54f85a1 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -148,8 +148,8 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
>   GPIOC,
>   GPIOD,
>   GPIOE,
> - 0,
>   GPIOF,
> + 0,
>   };
>   struct i2c_algo_bit_data *algo;
>  
> @@ -359,8 +359,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
> 

-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[git pull] drm main pull for 3.4-rc1

[Daniel Vetter]

On Mon, Mar 26, 2012 at 02:59:43PM +0100, Tony Vroon wrote:
> On 21/03/12 10:47, Dave Airlie wrote:
> > i915: re-enabling GMBUS, finish gpu patch (might help hibernation who 
> > knows), missed irq fixes, stencil tiling fixes, interlaced support, 
> > aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB, semaphore fixes
> 
> This causes an eventual (after barely a minute of use) lockup that I can
> not recover from on my Lifebook S761. It does not switch to a text
> console for me, but by stopping my graphical login manager (slim) early
> I got this:
> DRHD: handling fault status reg 3
> DMAR:[DMA Write] Request device [00:02.0] fault addr 12806b000
> DMAR:[fault reason 05] PTE Write access is not set
> DRHD: handling fault status reg 3
> DMAR:[DMA Write] Request device [00:02.0] fault addr 128183000
> DMAR:[fault reason 05] PTE Write access is not set
> DRHD: handling fault status reg 3
> DMAR:[DMA Write] Request device [00:02.0] fault addr 4147562000
> DMAR:[fault reason 05] PTE Write access is not set
> DRHD: handling fault status reg 3
> DMAR:[DMA Write] Request device [00:02.0] fault addr 4147562000
> DMAR:[fault reason 05] PTE Write access is not set
> 
> (The full dmesg is attached so you can see it in context)
> In the interest of full disclosure, this is a dual-screen setup:
> Screen 0: minimum 320 x 200, current 1680 x 1818, maximum 8192 x 8192
> LVDS1 connected 1366x768+0+1050 (normal left inverted right x axis y
> axis) 293mm x 165mm
> HDMI2 connected 1680x1050+0+0 (normal left inverted right x axis y axis)
> 459mm x 296mm
> 
> To confirm, that is the i915 graphics:
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
> Processor Family Integrated Graphics Controller (rev 09) (prog-if 00
> [VGA controller])
>   Subsystem: Fujitsu Limited. Device 15e9
>   Flags: bus master, fast devsel, latency 0, IRQ 42
>   Memory at e000 (64-bit, non-prefetchable) [size=4M]
>   Memory at d000 (64-bit, prefetchable) [size=256M]
>   I/O ports at 3000 [size=64]
>   Expansion ROM at  [disabled]
>   Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>   Capabilities: [d0] Power Management version 2
>   Capabilities: [a4] PCI Advanced Features
>   Kernel driver in use: i915
> 
> Please let me know if you want a full lspci, and what your favourite
> options are. I am back on a Thursday git snapshot now, which runs fine:
> Linux adrastea 3.3.0-04074-g5375871 #1 SMP PREEMPT Thu Mar 22 09:27:24
> GMT 2012 x86_64 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz GenuineIntel
> GNU/Linux

Ok, this is ugly. Do you have any special module options for i915 set
(like i915_enable_rc6)? Also, can you check whether disabling vt-d does
work around the issue? Last but not least, can you please bisect where
this regression got introduced so we have an idea why it breaks?

Thanks a lot,

Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[GIT PULL]: dma-buf updates for 3.4

[Sumit Semwal]

Hi Linus,

Could you please pull the dma-buf updates for 3.4? This includes the
following key items:

- kernel cpu access support,
- flag-passing to dma_buf_fd,
- relevant Documentation updates, and
- some minor cleanups and fixes.

These changes are needed for the drm prime/dma-buf interface code that
Dave Airlie plans to submit in this merge window.

Thanks, and best regards,
~Sumit.

The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7:

  Linux 3.3 (2012-03-18 16:15:34 -0700)

are available in the git repository at:
  git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git for-linus-3.4

Daniel Vetter (3):
  dma-buf: don't hold the mutex around map/unmap calls
  dma-buf: add support for kernel cpu access
  dma_buf: Add documentation for the new cpu access support

Dave Airlie (1):
  dma-buf: pass flags into dma_buf_fd.

Laurent Pinchart (4):
  dma-buf: Constify ops argument to dma_buf_export()
  dma-buf: Remove unneeded sanity checks
  dma-buf: Return error instead of using a goto statement when possible
  dma-buf: Move code out of mutex-protected section in dma_buf_attach()

Rob Clark (2):
  dma-buf: add get_dma_buf()
  dma-buf: document fd flags and O_CLOEXEC requirement

Sumit Semwal (2):
  dma-buf: add dma_data_direction to unmap dma_buf_op
  dma-buf: correct dummy function declarations.

 Documentation/dma-buf-sharing.txt |  120 ++-
 drivers/base/dma-buf.c|  165 +++--
 include/linux/dma-buf.h   |   97 +++--
 3 files changed, 345 insertions(+), 37 deletions(-)

[PATCH] drm: base prime/dma-buf support

[Dave Airlie]

From: Dave Airlie 

This adds the basic drm dma-buf interface layer, called PRIME,

The main APIs exposed to userspace allow translating a 32-bit object handle
to a file descriptor, and a file descriptor to a 32-bit object handle.

The flags value is currently limited to O_CLOEXEC.

Acknowledgements:
Daniel Vetter: lots of review
Rob Clark: cleaned up lots of the internals and did lifetime review.

This is what I intend to send to Linus to form the basis for prime work
in the drivers.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/Kconfig |1 +
 drivers/gpu/drm/Makefile|2 +-
 drivers/gpu/drm/drm_drv.c   |4 +
 drivers/gpu/drm/drm_fops.c  |7 +
 drivers/gpu/drm/drm_gem.c   |9 ++
 drivers/gpu/drm/drm_prime.c |  281 +++
 include/drm/drm.h   |   14 ++-
 include/drm/drmP.h  |   61 ++
 8 files changed, 377 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_prime.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index cc11488..e354bc0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU
select I2C
select I2C_ALGOBIT
+   select DMA_SHARED_BUFFER
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a858532..c20da5b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
-   drm_trace_points.o drm_global.o
+   drm_trace_points.o drm_global.o drm_prime.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 0b65fbc..6116e3b 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -136,6 +136,10 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
DRM_AUTH|DRM_UNLOCKED),

DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
+
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 7348a3d..cdfbf27 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -271,6 +271,9 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (dev->driver->driver_features & DRIVER_GEM)
drm_gem_open(dev, priv);

+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_init_file_private(>prime);
+
if (dev->driver->open) {
ret = dev->driver->open(dev, priv);
if (ret < 0)
@@ -571,6 +574,10 @@ int drm_release(struct inode *inode, struct file *filp)

if (dev->driver->postclose)
dev->driver->postclose(dev, file_priv);
+
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_destroy_file_private(_priv->prime);
+
kfree(file_priv);

/* 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 0ef358e..f337497 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drmP.h"

 /** @file drm_gem.c
@@ -232,6 +233,10 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(>object_idr, handle);
spin_unlock(>table_lock);

+   if (obj->import_attach)
+   drm_prime_remove_fd_handle_mapping(>prime,
+   obj->import_attach->dmabuf);
+
if (dev->driver->gem_close_object)
dev->driver->gem_close_object(obj, filp);
drm_gem_object_handle_unreference_unlocked(obj);
@@ -527,6 +532,10 @@ drm_gem_object_release_handle(int id, void *ptr, void 
*data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj->dev;

+   if (obj->import_attach)
+   drm_prime_remove_fd_handle_mapping(_priv->prime,

[lm-sensors] Incorrect Temperature Readings

[Scott Ondercin]

d at address 0x50
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... No
> > Probing for `EDID EEPROM'...Yes
> > (confidence 8, not a hardware monitoring chip)
> > Client found at address 0x51
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... No
> > Client found at address 0x52
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... No
> > Client found at address 0x53
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... No
> > 
> > Next adapter: nouveau-:01:00.0-0 (i2c-1)
> > Do you want to scan it? (YES/no/selectively): y
> > 
> > Next adapter: SMBus I801 adapter at 10c0 (i2c-2)
> > Do you want to scan it? (YES/no/selectively): y
> > Client found at address 0x50
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... Yes
> > (confidence 8, not a hardware monitoring chip)
> > Probing for `EDID EEPROM'...No
> > Client found at address 0x52
> > Probing for `Analog Devices ADM1033'... No
> > Probing for `Analog Devices ADM1034'... No
> > Probing for `SPD EEPROM'... Yes
> > (confidence 8, not a hardware monitoring chip)
> > 
> > Now follows a summary of the probes I have just done.
> > Just press ENTER to continue:
> > 
> > Driver `coretemp':
> >   * Chip `Intel digital thermal sensor' (confidence: 9)
> > 
> > To load everything that is needed, add this to /etc/modules:
> > #cut here
> > # Chip drivers
> > coretemp
> > #cut here
> > If you have some drivers built into your kernel, the list above will
> > contain too many modules. Skip the appropriate ones!
> > 
> > Do you want to add these lines automatically to /etc/modules? (yes/NO)y
> > Successful!
> > 
> > Monitoring programs won't work until the needed modules are
> > loaded. You may want to run 'service module-init-tools start'
> > to load them.
> > 
> > Unloading i2c-dev... OK
> > Unloading cpuid... OK
> > 
> > And when I try to run module-init-tools, I get:
> > 
> > sgo542 at NostalgiaforInfinity:~$ sudo service module-init-tools start
> > module-init-tools stop/waiting
> > 
> > I've heard I might be able to fix this by tweaking the /etc/sensors.conf 
> > file,
> > but I'm unsure how to even start with that.  I am moderately experiences 
> > with
> > Linux, but by no means an expert.  Any help would be appreciated, before it
> > gets hot outside and my computer becomes completely unusable.
> 
> > ___
> > lm-sensors mailing list
> > lm-sensors at lm-sensors.org
> > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
> 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120326/58bae7cb/attachment-0001.htm>

[git pull] drm main pull for 3.4-rc1

[Tony Vroon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/03/12 15:32, Daniel Vetter wrote:
> Also, can you check whether disabling vt-d does work around the
> issue?

Yes, that does appear to stay operational for longer on:
Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Mon Mar 26 11:29:21
BST 2012 x86_64 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz GenuineIntel
GNU/Linux

Obviously I would like to have x2apic and my IOMMU back...

Regards,
- -- 
Tony Vroon
UNIX systems administrator
London Internet Exchange Ltd, Trinity Court, Trinity Street,
Peterborough, PE1 1DA
Registered in England number 3137929
E-Mail: tony at linx.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9wgNEACgkQp5vW4rUFj5rhHwCgpwcw0Ydx53CPBcsF1vdo8h1P
ffYAoJYL7RKv0hgc96ZKtFjP7v2V7iRZ
=J/HD
-END PGP SIGNATURE-

[git pull] drm main pull for 3.4-rc1

[Tony Vroon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/03/12 15:32, Daniel Vetter wrote:
> Ok, this is ugly. Do you have any special module options for i915
> set (like i915_enable_rc6)?

None set:
adrastea ~ # cat /proc/cmdline
BOOT_IMAGE=3.3.0-04074-g53 rw root=0

> Also, can you check whether disabling vt-d does work around the
> issue?

Will try. More to follow shortly.

> Last but not least, can you please bisect where this regression got
> introduced so we have an idea why it breaks?

I do not know how to turn these 3.3.0-04074-g5375871 type indicators
into useful git bisect arguments.

Regards,
- -- 
Tony Vroon
UNIX systems administrator
London Internet Exchange Ltd, Trinity Court, Trinity Street,
Peterborough, PE1 1DA
Registered in England number 3137929
E-Mail: tony at linx.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9wfwUACgkQp5vW4rUFj5pMjQCgoW9nayPhTCkLJZNuuhhpPZTK
Cy4An2GxAzqQN/1xSxF1Fsl/XX73O09d
=2eHw
-END PGP SIGNATURE-

[PATCH] drm/radeon/kms: improve bpc handling (v2)

[alexdeuc...@gmail.com]

From: Alex Deucher 

Improve handling of bpc (bits per color) in radeon.
In most cases we want 8 except for HDMI, DP, LVDS, and eDP.

v2: handle DP better.

Signed-off-by: Alex Deucher 
Tested-by: Lennert Buytenhek 
---
 drivers/gpu/drm/radeon/atombios_crtc.c |7 +--
 drivers/gpu/drm/radeon/atombios_dp.c   |7 +--
 drivers/gpu/drm/radeon/atombios_encoders.c |4 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |   56 
 drivers/gpu/drm/radeon/radeon_mode.h   |1 +
 5 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b5ff1f7..2fab38f 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -588,8 +588,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder->crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
-   /* if (connector && connector->display_info.bpc)
-   bpc = connector->display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode->clock);
if ((radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -965,9 +964,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
struct radeon_connector_atom_dig *dig_connector =
radeon_connector->con_priv;
int dp_clock;
-
-   /* if (connector->display_info.bpc)
-   bpc = connector->display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);

switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index c57d856..cadbb10 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -405,13 +405,10 @@ static void dp_get_adjust_train(u8 
link_status[DP_LINK_STATUS_SIZE],
 /* get bpc from the EDID */
 static int convert_bpc_to_bpp(int bpc)
 {
-#if 0
if (bpc == 0)
return 24;
else
return bpc * 3;
-#endif
-   return 24;
 }

 /* get the max pix clock supported by the link rate and lane num */
@@ -463,7 +460,7 @@ static int radeon_dp_get_dp_lane_number(struct 
drm_connector *connector,
u8 dpcd[DP_DPCD_SIZE],
int pix_clock)
 {
-   int bpp = convert_bpc_to_bpp(connector->display_info.bpc);
+   int bpp = convert_bpc_to_bpp(radeon_get_monitor_bpc(connector));
int max_link_rate = dp_get_max_link_rate(dpcd);
int max_lane_num = dp_get_max_lane_number(dpcd);
int lane_num;
@@ -482,7 +479,7 @@ static int radeon_dp_get_dp_link_clock(struct drm_connector 
*connector,
   u8 dpcd[DP_DPCD_SIZE],
   int pix_clock)
 {
-   int bpp = convert_bpc_to_bpp(connector->display_info.bpc);
+   int bpp = convert_bpc_to_bpp(radeon_get_monitor_bpc(connector));
int lane_num, max_pix_clock;

if (radeon_connector_encoder_get_dp_bridge_encoder_id(connector) ==
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e607c4d..06b209b 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -541,7 +541,7 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder, int 
action, int panel_mo
dp_clock = dig_connector->dp_clock;
dp_lane_count = dig_connector->dp_lane_count;
hpd_id = radeon_connector->hpd.hpd;
-   /* bpc = connector->display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);
}

/* no dig encoder assigned */
@@ -1159,7 +1159,7 @@ atombios_external_encoder_setup(struct drm_encoder 
*encoder,
dp_lane_count = dig_connector->dp_lane_count;
connector_object_id =
(radeon_connector->connector_object_id & 
OBJECT_ID_MASK) >> OBJECT_ID_SHIFT;
-   /* bpc = connector->display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);
}

memset(, 0, sizeof(args));
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index bd05156..71fa389 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -84,6 +84,62 @@ static void 

[git pull] drm main pull for 3.4-rc1

[Tony Vroon]

On 21/03/12 10:47, Dave Airlie wrote:
> i915: re-enabling GMBUS, finish gpu patch (might help hibernation who 
> knows), missed irq fixes, stencil tiling fixes, interlaced support, 
> aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB, semaphore fixes

This causes an eventual (after barely a minute of use) lockup that I can
not recover from on my Lifebook S761. It does not switch to a text
console for me, but by stopping my graphical login manager (slim) early
I got this:
DRHD: handling fault status reg 3
DMAR:[DMA Write] Request device [00:02.0] fault addr 12806b000
DMAR:[fault reason 05] PTE Write access is not set
DRHD: handling fault status reg 3
DMAR:[DMA Write] Request device [00:02.0] fault addr 128183000
DMAR:[fault reason 05] PTE Write access is not set
DRHD: handling fault status reg 3
DMAR:[DMA Write] Request device [00:02.0] fault addr 4147562000
DMAR:[fault reason 05] PTE Write access is not set
DRHD: handling fault status reg 3
DMAR:[DMA Write] Request device [00:02.0] fault addr 4147562000
DMAR:[fault reason 05] PTE Write access is not set

(The full dmesg is attached so you can see it in context)
In the interest of full disclosure, this is a dual-screen setup:
Screen 0: minimum 320 x 200, current 1680 x 1818, maximum 8192 x 8192
LVDS1 connected 1366x768+0+1050 (normal left inverted right x axis y
axis) 293mm x 165mm
HDMI2 connected 1680x1050+0+0 (normal left inverted right x axis y axis)
459mm x 296mm

To confirm, that is the i915 graphics:
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00
[VGA controller])
Subsystem: Fujitsu Limited. Device 15e9
Flags: bus master, fast devsel, latency 0, IRQ 42
Memory at e000 (64-bit, non-prefetchable) [size=4M]
Memory at d000 (64-bit, prefetchable) [size=256M]
I/O ports at 3000 [size=64]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915

Please let me know if you want a full lspci, and what your favourite
options are. I am back on a Thursday git snapshot now, which runs fine:
Linux adrastea 3.3.0-04074-g5375871 #1 SMP PREEMPT Thu Mar 22 09:27:24
GMT 2012 x86_64 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz GenuineIntel
GNU/Linux

I only subscribe to LKML, please CC me to be sure.

Regards,
-- 
Tony Vroon
UNIX systems administrator
London Internet Exchange Ltd, Trinity Court, Trinity Street,
Peterborough, PE1 1DA
Registered in England number 3137929
E-Mail: tony at linx.net
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.3.0 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="adrastea"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y

[Bug 47900] New: Sampler does not work with cubemaps in 16-bit component pixel format

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

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

 Bug #: 47900
   Summary: Sampler does not work with cubemaps in 16-bit
component pixel format
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: llyzs at 163.com


If a cubemap is created using 16-bit component pixel format like
PIPE_FORMAT_R16G16B16A16_UNORM or PIPE_FORMAT_R16G16B16A16_FLOAT, it will not
be sampled correctly in fragment shader and generate garbage output. Those
16-bit formats works just fine when using in 2D texture, and the cubemap using
8-bit format also works. It's just the combination cubemap+16bit that does not
work.

Any hints?

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

[PATCH 1/3 xf86-video-intel] Avoid duplicated code with intel_output_create_ranged_atom

[Chris Wilson]

On Tue, 20 Mar 2012 11:53:21 -0300, Paulo Zanoni  wrote:
> From: Paulo Zanoni 
> 
> Same change for intel_display.c and sna_display.c.

Applied, thanks.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/3 xf86-video-intel] Update the rotation property whenever we change the rotation.

[Chris Wilson]

On Tue, 20 Mar 2012 11:53:22 -0300, Paulo Zanoni  wrote:
> From: Paulo Zanoni 
> 
> Don't worry if that fails: only the KVMr feature will be affected.

This introduces a dependency on libdrm changes that are not yet upstream.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 47875] Making r600_dri.so fails when building 32bit on 64bit when setting LIBDRM_LIBS (maybe other env vars also) manually: missing -L

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

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

--- Comment #3 from Alexandre Demers  
2012-03-26 05:29:57 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > After testing, I can confirm the problem comes from  "export
> > LIBDRM_LIBS=/usr/lib/i386-linux-gnu/".
> 
> LIBDRM_LIBS must contain linker flags, not just a path.

It seems to do the trick, thank you.

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

[Bug 43278] RS482: Hibernation reliably hangs, suspend-to-RAM unreliably hangs

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

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

--- Comment #20 from Rolf  2012-03-26 01:46:54 PDT ---
On 21.03.2012 18:49, bugzilla-daemon at freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=43278
>
> --- Comment #19 from Jonathan Nieder  2012-03-21 
> 10:49:34 PDT ---
> (In reply to comment #18)
>
>> Today I am using kernel 3.2.0-2-amd64 .
>> The problem still exists in exactly the same way - the first hibernate
>> always works perfectly fine - the second hibernate causes system hangup.
> Thanks.  Please try 3.3 when it hits experimental, too.
>
> [...]
>> But at this point [in the initramfs shell] I do not know how to load
>> the radeon driver cause "modprobe radeon" brings up error message
>> "module radeon not found in  modules.dep", so I cannot tell if radeon
>> has the same error message as last year.
> Not necessary.  The initramfs shell is a weird environment that we were
> using for debugging, and we've already retrieved all the information we
> wanted from there.
>
Hi,
the problem still exists in kernel 3.3.0-trunk-amd64
Regards

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

[Bug 21652] several problems with intel graphics since 2.6.36

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

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


Daniel Vetter  changed:

   What|Removed |Added

  Component|Video(DRI - non Intel)  |Video(DRI - Intel)
 AssignedTo|drivers_video-dri at kernel-bu |drivers_video-dri-intel at 
ker
   |gs.osdl.org |nel-bugs.osdl.org




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

[Bug 21652] several problems with intel graphics since 2.6.36

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

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


Daniel Vetter  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




--- Comment #15 from Daniel Vetter   2012-03-26 08:02:38 ---
Oh dear, sorry I've missed that. Anyway, still closing because the bug reporter
seems to have disappeared.

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

[Bug 21652] several problems with intel graphics since 2.6.36

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

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





--- Comment #14 from Michel D?nzer   2012-03-26 07:58:40 
---
(In reply to comment #13)
> Also, it's a radeon issue afaict.

AFAICT Norbert's original report was for Intel, Mark's problem was unrelated.

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

[Bug 47881] r600_asm.c:780:12: internal compiler error with gcc-4.7.0

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

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

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #1 from Michel D?nzer  2012-03-26 00:51:22 
PDT ---
An internal compiler error is a compiler bug. Please report this to GCC.

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

[Bug 47881] New: r600_asm.c:780:12: internal compiler error with gcc-4.7.0

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

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

 Bug #: 47881
   Summary: r600_asm.c:780:12: internal compiler error with
gcc-4.7.0
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: treeve at sourcemage.org


using gcc-4.7.0, I get the following  error when compiling Mesalib-8.0.2


changing optimisation to -O2 works


root at Gemini-64:/usr/src/Mesa-8.0.2/src/gallium/drivers/r600# make
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../include -march=native -mtune=native -m64 -pipe -O3 -Wall
-Wmissing-prototypes -std=c99 -fno-strict-aliasing -fno-builtin-memcmp
-march=native -mtune=native -m64 -pipe -O3  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0300 -fvisibility=hidden -I/usr/include 
  -D_GNU_SOURCE   -Wno-unused-parameter -Wwrite-strings  -Wno-long-long
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
r600_asm.c -o r600_asm.o
r600_asm.c: In function 'check_and_set_bank_swizzle':
r600_asm.c:780:12: internal compiler error: in try_move_mult_to_index, at
fold-const.c:6995
Please submit a full bug report,
with preprocessed source if appropriate.

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

[Bug 45760] World of warcraft 4.3 slow down after a hour of game

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

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

--- Comment #9 from Andrew  2012-03-26 00:45:40 PDT ---
I use World of warcraft 4.3 Cataclysm with all updates on official server

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

[Bug 47875] Making r600_dri.so fails when building 32bit on 64bit when setting LIBDRM_LIBS (maybe other env vars also) manually: missing -L

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

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

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #2 from Michel D?nzer  2012-03-26 00:22:06 
PDT ---
(In reply to comment #1)
> After testing, I can confirm the problem comes from  "export
> LIBDRM_LIBS=/usr/lib/i386-linux-gnu/".

LIBDRM_LIBS must contain linker flags, not just a path.

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

[Bug 47875] Making r600_dri.so fails when building 32bit on 64bit when setting LIBDRM_LIBS (maybe other env vars also) manually: missing -L

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

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

Alexandre Demers  changed:

   What|Removed |Added

Summary|Making r600_dri.so fails|Making r600_dri.so fails
   |when building 32bit on  |when building 32bit on
   |64bit   |64bit when setting
   ||LIBDRM_LIBS (maybe other
   ||env vars also) manually:
   ||missing -L

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

[Bug 47875] Making r600_dri.so fails when building 32bit on 64bit

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

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

--- Comment #1 from Alexandre Demers  
2012-03-25 22:32:19 PDT ---
After testing, I can confirm the problem comes from  "export
LIBDRM_LIBS=/usr/lib/i386-linux-gnu/". When it is not set, the build goes all
the way to the end.

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

[Bug 47875] New: Making r600_dri.so fails when building 32bit on 64bit

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

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

 Bug #: 47875
   Summary: Making r600_dri.so fails when building 32bit on 64bit
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: alexandre.f.demers at gmail.com


under ./src/gallium/targets/dri-r600, making lib fails:

/bin/sh ../../../../bin/mklib -o r600_dri.so.tmp -noprefix -linker 'g++'
-ldflags '' \
target.o ../../../../src/mesa/drivers/dri/common/utils.o
../../../../src/mesa/drivers/dri/common/dri_util.o
../../../../src/mesa/drivers/dri/common/xmlconfig.o  
../../../../src/gallium/drivers/r600/libr600.a
../../../../src/gallium/state_trackers/dri/drm/libdridrm.a
../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a
../../../../src/gallium/drivers/trace/libtrace.a
../../../../src/gallium/drivers/rbug/librbug.a
../../../../src/gallium/drivers/noop/libnoop.a \
-Wl,--start-group ../../../../src/mesa/libmesagallium.a
../../../../src/gallium/auxiliary/libgallium.a -Wl,--end-group \
  -L../../../../i386-linux-gnu
-Wl,-R/usr/lib/i386-linux-gnu/dri -ldricore -lglsl  /usr/lib/i386-linux-gnu/
-lexpat -lm -lpthread -ldl -ldrm_radeon

mklib: Making Linux shared library:  r600_dri.so.tmp
/usr/lib/i386-linux-gnu/: file not recognized: Is a directory
collect2: ld returned 1 exit status
g++ -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration
-Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -m32 -g -O2
 -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN
-DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING
-DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -fvisibility=hidden -o
r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o
r600_dri.so.tmp  -L../../../../i386-linux-gnu -Wl,-R/usr/lib/i386-linux-gnu/dri
-ldricore -lglsl  /usr/lib/i386-linux-gnu/ -lexpat -lm -lpthread -ldl
-ldrm_radeon ;
g++: error: r600_dri.so.tmp: No such file or directory
make[3]: *** [r600_dri.so] Error 1

However, adding -L before /usr/lib/i386-linux-gnu/. I'm compiling with
"--enable-32-bit --libdir=/usr/lib/i386-linux-gnu
--includedir=/usr/include/i386-linux-gnu" on a 64bit OS and I manually set
"export LIBDRM_LIBS=/usr/lib/i386-linux-gnu/".

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

[Bug 47875] Making r600_dri.so fails when building 32bit on 64bit when setting LIBDRM_LIBS (maybe other env vars also) manually: missing -L

[bugzilla-daemon]

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

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #2 from Michel Dänzer mic...@daenzer.net 2012-03-26 00:22:06 PDT 
---
(In reply to comment #1)
 After testing, I can confirm the problem comes from  export
 LIBDRM_LIBS=/usr/lib/i386-linux-gnu/.

LIBDRM_LIBS must contain linker flags, not just a path.

-- 
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 45760] World of warcraft 4.3 slow down after a hour of game

[bugzilla-daemon]

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

--- Comment #9 from Andrew maa...@gmail.com 2012-03-26 00:45:40 PDT ---
I use World of warcraft 4.3 Cataclysm with all updates on official server

-- 
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 47881] New: r600_asm.c:780:12: internal compiler error with gcc-4.7.0

[bugzilla-daemon]

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

 Bug #: 47881
   Summary: r600_asm.c:780:12: internal compiler error with
gcc-4.7.0
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: tre...@sourcemage.org


using gcc-4.7.0, I get the following  error when compiling Mesalib-8.0.2


changing optimisation to -O2 works


root@Gemini-64:/usr/src/Mesa-8.0.2/src/gallium/drivers/r600# make
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-I../../../../include -march=native -mtune=native -m64 -pipe -O3 -Wall
-Wmissing-prototypes -std=c99 -fno-strict-aliasing -fno-builtin-memcmp
-march=native -mtune=native -m64 -pipe -O3  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XCB
-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2
-D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0300 -fvisibility=hidden -I/usr/include 
  -D_GNU_SOURCE   -Wno-unused-parameter -Wwrite-strings  -Wno-long-long
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
r600_asm.c -o r600_asm.o
r600_asm.c: In function 'check_and_set_bank_swizzle':
r600_asm.c:780:12: internal compiler error: in try_move_mult_to_index, at
fold-const.c:6995
Please submit a full bug report,
with preprocessed source if appropriate.

-- 
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 47881] r600_asm.c:780:12: internal compiler error with gcc-4.7.0

[bugzilla-daemon]

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

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2012-03-26 00:51:22 PDT 
---
An internal compiler error is a compiler bug. Please report this to GCC.

-- 
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 21652] several problems with intel graphics since 2.6.36

[bugzilla-daemon]

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





--- Comment #14 from Michel Dänzer mic...@daenzer.net  2012-03-26 07:58:40 ---
(In reply to comment #13)
 Also, it's a radeon issue afaict.

AFAICT Norbert's original report was for Intel, Mark's problem was unrelated.

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

[Bug 21652] several problems with intel graphics since 2.6.36

[bugzilla-daemon]

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


Daniel Vetter dan...@ffwll.ch changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




--- Comment #15 from Daniel Vetter dan...@ffwll.ch  2012-03-26 08:02:38 ---
Oh dear, sorry I've missed that. Anyway, still closing because the bug reporter
seems to have disappeared.

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

[Bug 21652] several problems with intel graphics since 2.6.36

[bugzilla-daemon]

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


Daniel Vetter dan...@ffwll.ch changed:

   What|Removed |Added

  Component|Video(DRI - non Intel)  |Video(DRI - Intel)
 AssignedTo|drivers_video-dri@kernel-bu |drivers_video-dri-intel@ker
   |gs.osdl.org |nel-bugs.osdl.org




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

[Bug 43278] RS482: Hibernation reliably hangs, suspend-to-RAM unreliably hangs

[bugzilla-daemon]

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

--- Comment #20 from Rolf hu...@online.de 2012-03-26 01:46:54 PDT ---
On 21.03.2012 18:49, bugzilla-dae...@freedesktop.org wrote:
 https://bugs.freedesktop.org/show_bug.cgi?id=43278

 --- Comment #19 from Jonathan Niederjrnie...@gmail.com  2012-03-21 10:49:34 
 PDT ---
 (In reply to comment #18)

 Today I am using kernel 3.2.0-2-amd64 .
 The problem still exists in exactly the same way - the first hibernate
 always works perfectly fine - the second hibernate causes system hangup.
 Thanks.  Please try 3.3 when it hits experimental, too.

 [...]
 But at this point [in the initramfs shell] I do not know how to load
 the radeon driver cause modprobe radeon brings up error message
 module radeon not found in  modules.dep, so I cannot tell if radeon
 has the same error message as last year.
 Not necessary.  The initramfs shell is a weird environment that we were
 using for debugging, and we've already retrieved all the information we
 wanted from there.

Hi,
the problem still exists in kernel 3.3.0-trunk-amd64
Regards

-- 
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 47875] Making r600_dri.so fails when building 32bit on 64bit when setting LIBDRM_LIBS (maybe other env vars also) manually: missing -L

[bugzilla-daemon]

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

--- Comment #3 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-03-26 
05:29:57 PDT ---
(In reply to comment #2)
 (In reply to comment #1)
  After testing, I can confirm the problem comes from  export
  LIBDRM_LIBS=/usr/lib/i386-linux-gnu/.
 
 LIBDRM_LIBS must contain linker flags, not just a path.

It seems to do the trick, thank you.

-- 
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/3 xf86-video-intel] Update the rotation property whenever we change the rotation.

[Chris Wilson]

On Tue, 20 Mar 2012 11:53:22 -0300, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com
 
 Don't worry if that fails: only the KVMr feature will be affected.

This introduces a dependency on libdrm changes that are not yet upstream.
-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 1/3 xf86-video-intel] Avoid duplicated code with intel_output_create_ranged_atom

[Chris Wilson]

On Tue, 20 Mar 2012 11:53:21 -0300, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com
 
 Same change for intel_display.c and sna_display.c.

Applied, thanks.
-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: [git pull] drm main pull for 3.4-rc1

[Daniel Vetter]

On Mon, Mar 26, 2012 at 02:59:43PM +0100, Tony Vroon wrote:
 On 21/03/12 10:47, Dave Airlie wrote:
  i915: re-enabling GMBUS, finish gpu patch (might help hibernation who 
  knows), missed irq fixes, stencil tiling fixes, interlaced support, 
  aliasesd PPGTT support for SNB/IVB, swizzling for SNB/IVB, semaphore fixes
 
 This causes an eventual (after barely a minute of use) lockup that I can
 not recover from on my Lifebook S761. It does not switch to a text
 console for me, but by stopping my graphical login manager (slim) early
 I got this:
 DRHD: handling fault status reg 3
 DMAR:[DMA Write] Request device [00:02.0] fault addr 12806b000
 DMAR:[fault reason 05] PTE Write access is not set
 DRHD: handling fault status reg 3
 DMAR:[DMA Write] Request device [00:02.0] fault addr 128183000
 DMAR:[fault reason 05] PTE Write access is not set
 DRHD: handling fault status reg 3
 DMAR:[DMA Write] Request device [00:02.0] fault addr 4147562000
 DMAR:[fault reason 05] PTE Write access is not set
 DRHD: handling fault status reg 3
 DMAR:[DMA Write] Request device [00:02.0] fault addr 4147562000
 DMAR:[fault reason 05] PTE Write access is not set
 
 (The full dmesg is attached so you can see it in context)
 In the interest of full disclosure, this is a dual-screen setup:
 Screen 0: minimum 320 x 200, current 1680 x 1818, maximum 8192 x 8192
 LVDS1 connected 1366x768+0+1050 (normal left inverted right x axis y
 axis) 293mm x 165mm
 HDMI2 connected 1680x1050+0+0 (normal left inverted right x axis y axis)
 459mm x 296mm
 
 To confirm, that is the i915 graphics:
 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
 Processor Family Integrated Graphics Controller (rev 09) (prog-if 00
 [VGA controller])
   Subsystem: Fujitsu Limited. Device 15e9
   Flags: bus master, fast devsel, latency 0, IRQ 42
   Memory at e000 (64-bit, non-prefetchable) [size=4M]
   Memory at d000 (64-bit, prefetchable) [size=256M]
   I/O ports at 3000 [size=64]
   Expansion ROM at unassigned [disabled]
   Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
   Capabilities: [d0] Power Management version 2
   Capabilities: [a4] PCI Advanced Features
   Kernel driver in use: i915
 
 Please let me know if you want a full lspci, and what your favourite
 options are. I am back on a Thursday git snapshot now, which runs fine:
 Linux adrastea 3.3.0-04074-g5375871 #1 SMP PREEMPT Thu Mar 22 09:27:24
 GMT 2012 x86_64 Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz GenuineIntel
 GNU/Linux

Ok, this is ugly. Do you have any special module options for i915 set
(like i915_enable_rc6)? Also, can you check whether disabling vt-d does
work around the issue? Last but not least, can you please bisect where
this regression got introduced so we have an idea why it breaks?

Thanks a lot,

Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:41PM +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
 
 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.

... this is no longer true on drm-intel-next.

  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

Otherwise this looks ok to me - I've checked with gen3 Bspec and we seem
to indeed have a 1:1 mapping, see Display Registers, 1.5.3 GPIO Control
Registers, the list right below the heading.

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

When resending, can you please add the Bspec reference above?

Thanks, Daniel

 ---
  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 f3609f2..accd8ee 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -742,9 +742,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_RESERVED7 /* 7 reserved */
 +#define   GMBUS_NUM_PORTS8
  #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 86b1861..54f85a1 100644
 --- a/drivers/gpu/drm/i915/intel_i2c.c
 +++ b/drivers/gpu/drm/i915/intel_i2c.c
 @@ -148,8 +148,8 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
   GPIOC,
   GPIOD,
   GPIOE,
 - 0,
   GPIOF,
 + 0,
   };
   struct i2c_algo_bit_data *algo;
  
 @@ -359,8 +359,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
 

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
 Instead of rolling our own custom quirk_xfer function, use the bit_algo
 pre_xfer and post_xfer functions to setup and teardown bit-banged
 i2c transactions.
 
 gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
 either i2c_bit_algo.master_xfer or its own.  So, Similarly, let gmbus_func
 use .force_bit to determine which i2c functionalities are available,
 either i2c_bit_algo.functionality, or its own.

Please split this part of the patch into a separate patch. Furthermore I'm
not sure what this should buy us, given that we might magically changes
our i2c feature set once with gone to fallback mode. Can you please
elaborate why we need this?

The pre_xfer/post_xfer stuff looks good to me, that part along is
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

Yours, Daniel

 
 Signed-off-by: Daniel Kurtz djku...@chromium.org
 ---
  drivers/gpu/drm/i915/intel_i2c.c |   72 +++--
  1 files changed, 45 insertions(+), 27 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
 b/drivers/gpu/drm/i915/intel_i2c.c
 index 54f85a1..ae08a08 100644
 --- a/drivers/gpu/drm/i915/intel_i2c.c
 +++ b/drivers/gpu/drm/i915/intel_i2c.c
 @@ -137,6 +137,35 @@ static void set_data(void *data, int state_high)
   POSTING_READ(bus-gpio_reg);
  }
  
 +static int
 +intel_gpio_pre_xfer(struct i2c_adapter *adapter)
 +{
 + struct intel_gmbus *bus = container_of(adapter,
 +struct intel_gmbus,
 +adapter);
 + struct drm_i915_private *dev_priv = bus-dev_priv;
 +
 + intel_i2c_reset(dev_priv-dev);
 + intel_i2c_quirk_set(dev_priv, true);
 + set_data(bus, 1);
 + set_clock(bus, 1);
 + udelay(I2C_RISEFALL_TIME);
 + return 0;
 +}
 +
 +static void
 +intel_gpio_post_xfer(struct i2c_adapter *adapter)
 +{
 + struct intel_gmbus *bus = container_of(adapter,
 +struct intel_gmbus,
 +adapter);
 + struct drm_i915_private *dev_priv = bus-dev_priv;
 +
 + set_data(bus, 1);
 + set_clock(bus, 1);
 + intel_i2c_quirk_set(dev_priv, false);
 +}
 +
  static bool
  intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
  {
 @@ -166,6 +195,8 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
   algo-setscl = set_clock;
   algo-getsda = get_data;
   algo-getscl = get_clock;
 + algo-pre_xfer = intel_gpio_pre_xfer;
 + algo-post_xfer = intel_gpio_post_xfer;
   algo-udelay = I2C_RISEFALL_TIME;
   algo-timeout = usecs_to_jiffies(2200);
   algo-data = bus;
 @@ -174,30 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
  }
  
  static int
 -intel_i2c_quirk_xfer(struct intel_gmbus *bus,
 -  struct i2c_msg *msgs,
 -  int num)
 -{
 - struct drm_i915_private *dev_priv = bus-dev_priv;
 - int ret;
 -
 - intel_i2c_reset(dev_priv-dev);
 -
 - intel_i2c_quirk_set(dev_priv, true);
 - set_data(bus, 1);
 - set_clock(bus, 1);
 - udelay(I2C_RISEFALL_TIME);
 -
 - ret = i2c_bit_algo.master_xfer(bus-adapter, msgs, num);
 -
 - set_data(bus, 1);
 - set_clock(bus, 1);
 - intel_i2c_quirk_set(dev_priv, false);
 -
 - return ret;
 -}
 -
 -static int
  gmbus_xfer(struct i2c_adapter *adapter,
  struct i2c_msg *msgs,
  int num)
 @@ -211,7 +218,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
   mutex_lock(dev_priv-gmbus_mutex);
  
   if (bus-force_bit) {
 - ret = intel_i2c_quirk_xfer(bus, msgs, num);
 + ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
   goto out;
   }
  
 @@ -325,8 +332,9 @@ timeout:
   ret = -EIO;
   } else {
   bus-force_bit = true;
 - ret = intel_i2c_quirk_xfer(bus, msgs, num);
 + ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
   }
 +
  out:
   mutex_unlock(dev_priv-gmbus_mutex);
   return ret;
 @@ -334,11 +342,21 @@ out:
  
  static u32 gmbus_func(struct i2c_adapter *adapter)
  {
 - return i2c_bit_algo.functionality(adapter) 
 + struct intel_gmbus *bus = container_of(adapter,
 +struct intel_gmbus,
 +adapter);
 + struct drm_i915_private *dev_priv = bus-dev_priv;
 + u32 func;
 +
 + mutex_lock(dev_priv-gmbus_mutex);
 + func = bus-force_bit ? i2c_bit_algo.functionality(adapter) :
   (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
   /* I2C_FUNC_10BIT_ADDR | */
   I2C_FUNC_SMBUS_READ_BLOCK_DATA |
   I2C_FUNC_SMBUS_BLOCK_PROC_CALL);
 + mutex_unlock(dev_priv-gmbus_mutex);
 +
 + return func;
  }
  
  static const struct i2c_algorithm gmbus_algorithm = {
 -- 
 1.7.7.3
 

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm: base prime/dma-buf support

[Dave Airlie]

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

This adds the basic drm dma-buf interface layer, called PRIME,

The main APIs exposed to userspace allow translating a 32-bit object handle
to a file descriptor, and a file descriptor to a 32-bit object handle.

The flags value is currently limited to O_CLOEXEC.

Acknowledgements:
Daniel Vetter: lots of review
Rob Clark: cleaned up lots of the internals and did lifetime review.

This is what I intend to send to Linus to form the basis for prime work
in the drivers.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/Kconfig |1 +
 drivers/gpu/drm/Makefile|2 +-
 drivers/gpu/drm/drm_drv.c   |4 +
 drivers/gpu/drm/drm_fops.c  |7 +
 drivers/gpu/drm/drm_gem.c   |9 ++
 drivers/gpu/drm/drm_prime.c |  281 +++
 include/drm/drm.h   |   14 ++-
 include/drm/drmP.h  |   61 ++
 8 files changed, 377 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_prime.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index cc11488..e354bc0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n)  !EMULATED_CMPXCHG  MMU
select I2C
select I2C_ALGOBIT
+   select DMA_SHARED_BUFFER
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a858532..c20da5b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
-   drm_trace_points.o drm_global.o
+   drm_trace_points.o drm_global.o drm_prime.o
 
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 0b65fbc..6116e3b 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -136,6 +136,10 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
DRM_AUTH|DRM_UNLOCKED),
 
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
+
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 7348a3d..cdfbf27 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -271,6 +271,9 @@ static int drm_open_helper(struct inode *inode, struct file 
*filp,
if (dev-driver-driver_features  DRIVER_GEM)
drm_gem_open(dev, priv);
 
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_init_file_private(priv-prime);
+
if (dev-driver-open) {
ret = dev-driver-open(dev, priv);
if (ret  0)
@@ -571,6 +574,10 @@ int drm_release(struct inode *inode, struct file *filp)
 
if (dev-driver-postclose)
dev-driver-postclose(dev, file_priv);
+
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_destroy_file_private(file_priv-prime);
+
kfree(file_priv);
 
/* 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 0ef358e..f337497 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -35,6 +35,7 @@
 #include linux/mman.h
 #include linux/pagemap.h
 #include linux/shmem_fs.h
+#include linux/dma-buf.h
 #include drmP.h
 
 /** @file drm_gem.c
@@ -232,6 +233,10 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(filp-object_idr, handle);
spin_unlock(filp-table_lock);
 
+   if (obj-import_attach)
+   drm_prime_remove_fd_handle_mapping(filp-prime,
+   obj-import_attach-dmabuf);
+
if (dev-driver-gem_close_object)
dev-driver-gem_close_object(obj, filp);
drm_gem_object_handle_unreference_unlocked(obj);
@@ -527,6 +532,10 @@ drm_gem_object_release_handle(int id, void *ptr, void 
*data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj-dev;
 
+   if 

Re: [PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

[Daniel Vetter]

On Mon, Mar 26, 2012 at 04:47:11PM +0200, Daniel Vetter wrote:
 On Mon, Mar 26, 2012 at 10:26:41PM +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
  
  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.
 
 ... this is no longer true on drm-intel-next.
 
   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
 
 Otherwise this looks ok to me - I've checked with gen3 Bspec and we seem
 to indeed have a 1:1 mapping, see Display Registers, 1.5.3 GPIO Control
 Registers, the list right below the heading.

well, scrap that, I've confused myself here a bit. Afaict we don't
actually use these gmbus ports on earlier chips.
 
 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 When resending, can you please add the Bspec reference above?

Can you you instead add a clear reference (Volume, Full Section plus
Heading Title) for the Snb/Ibx public Bspec.

Thanks, Daneil
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/11 v3] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
 There is no GMBUS disabled port 0, nor reserved port 7.
 For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
 gmbus ports, which means every real gmbus port has a gpio pin.
 
 Given these realizations, clean up gmbus initialization.
 
 Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org

Nice cleanup.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/11 v3] drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
 This memory is always allocated, and it is always a fixed size, so just
 allocate it along with the rest of the driver state.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/11 v3] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:43PM +0800, Daniel Kurtz wrote:
 There is no GMBUS disabled port 0, nor reserved port 7.
 For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
 gmbus ports, which means every real gmbus port has a gpio pin.
 
 Given these realizations, clean up gmbus initialization.
 
 Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org
 ---
  drivers/gpu/drm/i915/i915_drv.h  |1 -
  drivers/gpu/drm/i915/i915_reg.h  |2 +-
  drivers/gpu/drm/i915/intel_i2c.c |   63 ++---
  3 files changed, 25 insertions(+), 41 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 @@ -370,16 +365,6 @@ 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;
  
 @@ -397,13 +382,14 @@ int intel_setup_gmbus(struct drm_device *dev)
  
   for (i = 0; i  GMBUS_NUM_PORTS; i++) {
   struct intel_gmbus *bus = dev_priv-gmbus[i];
 + u32 port = i + 1; /* +1 to map gmbus index to pin pair */

On reconsideration you move around gmbus ports here, which will break
things horribly. I've wondered a bit how that could possible work and
noticed that you fix things up in the a later patch when introducing
get_adapter.

This ordering breaks bisecting is a complete no-go. If you want to do this
(I still think the refactor is nice) you need to introduce get_adapter
first, then change the meaning of the array index in this patch while
adjusting the lookup in the new get_adapter function.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/11 v3] drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:44PM +0800, Daniel Kurtz wrote:
 This memory is always allocated, and it is always a fixed size, so just
 allocate it along with the rest of the driver state.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/11 v3] drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:45PM +0800, Daniel Kurtz wrote:
 Instead of letting other modules directly access the -gmbus array,
 introduce a new API, intel_gmbus_get_adapter(), to lookup an i2c_adapter
 for a given gmbus pin pair identifier.  This API enables later refactoring
 of the gmbus pin pair list.
 
 Note: The gmbus pin must be checked for validity before requesting the
 corresponding gmbus port.  This is especially true when using a pin that
 has been read from VBIOS, as an improperly or uninitialied BIOS might
 indicate '0' for the 'disabled' pin pair, which doesn't actually exist. In
 the case of an invalid pin, the driver falls back to using a safer default
 pin pair.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org

With the cavet of the patch ordering issue, this looks ok. One comment
below.

 ---
  drivers/gpu/drm/i915/i915_drv.h|7 +++
  drivers/gpu/drm/i915/intel_bios.c  |4 ++--
  drivers/gpu/drm/i915/intel_crt.c   |   14 --
  drivers/gpu/drm/i915/intel_dvo.c   |6 +++---
  drivers/gpu/drm/i915/intel_hdmi.c  |9 ++---
  drivers/gpu/drm/i915/intel_i2c.c   |8 
  drivers/gpu/drm/i915/intel_lvds.c  |7 ---
  drivers/gpu/drm/i915/intel_modes.c |3 ++-
  drivers/gpu/drm/i915/intel_sdvo.c  |9 +
  9 files changed, 45 insertions(+), 22 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index b132677..64e0ae1 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1346,6 +1346,13 @@ 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 inline bool intel_gmbus_is_port_valid(unsigned port)
 +{
 + return (port = GMBUS_PORT_SSC  port = GMBUS_PORT_DPD);
 +}
 +
 +extern struct i2c_adapter *intel_gmbus_get_adapter(
 + struct drm_i915_private *dev_priv, unsigned port);
  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 e4317da..871aa27 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -372,11 +372,11 @@ parse_general_definitions(struct drm_i915_private 
 *dev_priv,
   if (block_size = sizeof(*general)) {
   int bus_pin = general-crt_ddc_gmbus_pin;
   DRM_DEBUG_KMS(crt_ddc_bus_pin: %d\n, bus_pin);
 - if (bus_pin = 1  bus_pin = 6)
 + if (intel_gmbus_is_port_valid(bus_pin))
   dev_priv-crt_ddc_pin = bus_pin;
   } else {
   DRM_DEBUG_KMS(BDB_GD too small (%d). Invalid.\n,
 -   block_size);
 +   block_size);
   }
   }
  }
 diff --git a/drivers/gpu/drm/i915/intel_crt.c 
 b/drivers/gpu/drm/i915/intel_crt.c
 index 4d3d736..d54d232 100644
 --- a/drivers/gpu/drm/i915/intel_crt.c
 +++ b/drivers/gpu/drm/i915/intel_crt.c
 @@ -278,9 +278,10 @@ static bool intel_crt_detect_ddc(struct drm_connector 
 *connector)
   if (intel_ddc_probe(crt-base, dev_priv-crt_ddc_pin)) {
   struct edid *edid;
   bool is_digital = false;
 + struct i2c_adapter *i2c;
  
 - edid = drm_get_edid(connector,
 - dev_priv-gmbus[dev_priv-crt_ddc_pin].adapter);
 + i2c = intel_gmbus_get_adapter(dev_priv, dev_priv-crt_ddc_pin);
 + edid = drm_get_edid(connector, i2c);
   /*
* This may be a DVI-I connector with a shared DDC
* link between analog and digital outputs, so we
 @@ -483,15 +484,16 @@ static int intel_crt_get_modes(struct drm_connector 
 *connector)
   struct drm_device *dev = connector-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   int ret;
 + struct i2c_adapter *i2c;
  
 - ret = intel_ddc_get_modes(connector,
 -  
 dev_priv-gmbus[dev_priv-crt_ddc_pin].adapter);
 + i2c = intel_gmbus_get_adapter(dev_priv, dev_priv-crt_ddc_pin);
 + ret = intel_ddc_get_modes(connector, i2c);
   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);
 + i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
 + return intel_ddc_get_modes(connector, i2c);
  }
  
  static int intel_crt_set_property(struct drm_connector *connector,
 diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
 

Re: [PATCH 01/11 v3] drm/i915/intel_i2c: cleanup

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:40PM +0800, Daniel Kurtz wrote:
 80 col, spaces around operators and other basic cleanup.
 Some info message cleanup.
 
 Signed-off-by: Daniel Kurtz djku...@chromium.org

On reconsideration, nacked. You desperately try to squeeze a function with
already 5 indent levels (not counting indentation due to function
arguments and overflow) with already 100+ lines of code into 80 columns.

Please do the right thing and split out a few of helper functions. I
suggest you split out the read and write code, i.e.

if (msgs[i].flags  I2C_M_RD)
gmbus_xfer_read()
else
gmbus_xfer_write

This way you get 3 levels of tab space of room and I won't have to
complain as much that some of your later patches make gmbus_xfer way too
bug.

Yours, Daniel

 ---
  drivers/gpu/drm/i915/intel_i2c.c |   32 +---
  1 files changed, 21 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
 b/drivers/gpu/drm/i915/intel_i2c.c
 index 0713cc2..86b1861 100644
 --- a/drivers/gpu/drm/i915/intel_i2c.c
 +++ b/drivers/gpu/drm/i915/intel_i2c.c
 @@ -230,13 +230,16 @@ 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)
 + if (I915_READ(GMBUS2 + reg_offset) 
 + GMBUS_SATOER)
   goto clear_err;
  
   val = I915_READ(GMBUS3 + reg_offset);
 @@ -260,12 +263,15 @@ 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)
 + if (I915_READ(GMBUS2 + reg_offset) 
 + GMBUS_SATOER)
   goto clear_err;
  
   val = loop = 0;
 @@ -274,11 +280,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;
 @@ -300,14 +309,15 @@ done:
* till then let it sleep.
*/
   if (wait_for((I915_READ(GMBUS2 + reg_offset)  GMBUS_ACTIVE) == 0, 10))
 - DRM_INFO(GMBUS timed out waiting for idle\n);
 + DRM_INFO(GMBUS [%s] timed out waiting for idle\n,
 +  bus-adapter.name);
   I915_WRITE(GMBUS0 + reg_offset, 0);
   ret = i;
   goto out;
  
  timeout:
 - DRM_INFO(GMBUS timed out, falling back to bit banging on pin %d 
 [%s]\n,
 -  bus-reg0  0xff, bus-adapter.name);
 + DRM_INFO(GMBUS [%s] timed out, falling back to bit banging on pin 
 %d\n,
 +  bus-adapter.name, bus-reg0  0xff);
   I915_WRITE(GMBUS0 + reg_offset, 0);
  
   /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
 

Re: [PATCH 00/11 v3] fix gmbus writes and related issues

[Daniel Vetter]

On Mon, Mar 26, 2012 at 10:26:39PM +0800, Daniel Kurtz wrote:
 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) by terminating every transaction with a
WAIT cycle.
  * 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
 v3:
  * rebased onto Daniel Vetter's drm-intel-next-queued branch
at git://people.freedesktop.org/~danvet/drm-intel
  * replace intel_i2c_quirk_xfer with pre/post_xfer i2c routines
  * pre-allocate gmbus array
  * drop interrupt approach since I could not make it stable, probably due to
difficulty in clearing and resetting the GMBUS interrupt which is buffered
behind the SDE's PCH interrupt.
  * Fix zero-length writes
  * Wait for IDLE before clearing NAK

Ok, I've found a few more things to complain about ;-) I haven't looked to
closely add the later patches that fix up the actual gmbus code, but on a
quick read I don't see any issues there - I'll cross check the code
somewhen later with Bspec.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: base prime/dma-buf support

[daeinki]

Reviewed-by: Inki Dae inki@samsung.com

2012. 3. 27. 오전 12:02 Dave Airlie airl...@gmail.com 작성:

 From: Dave Airlie airl...@redhat.com
 
 This adds the basic drm dma-buf interface layer, called PRIME,
 
 The main APIs exposed to userspace allow translating a 32-bit object handle
 to a file descriptor, and a file descriptor to a 32-bit object handle.
 
 The flags value is currently limited to O_CLOEXEC.
 
 Acknowledgements:
 Daniel Vetter: lots of review
 Rob Clark: cleaned up lots of the internals and did lifetime review.
 
 This is what I intend to send to Linus to form the basis for prime work
 in the drivers.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
 drivers/gpu/drm/Kconfig |1 +
 drivers/gpu/drm/Makefile|2 +-
 drivers/gpu/drm/drm_drv.c   |4 +
 drivers/gpu/drm/drm_fops.c  |7 +
 drivers/gpu/drm/drm_gem.c   |9 ++
 drivers/gpu/drm/drm_prime.c |  281 +++
 include/drm/drm.h   |   14 ++-
 include/drm/drmP.h  |   61 ++
 8 files changed, 377 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_prime.c
 
 diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
 index cc11488..e354bc0 100644
 --- a/drivers/gpu/drm/Kconfig
 +++ b/drivers/gpu/drm/Kconfig
 @@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n)  !EMULATED_CMPXCHG  MMU
select I2C
select I2C_ALGOBIT
 +select DMA_SHARED_BUFFER
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
 diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
 index a858532..c20da5b 100644
 --- a/drivers/gpu/drm/Makefile
 +++ b/drivers/gpu/drm/Makefile
 @@ -12,7 +12,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
 drm_cache.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
 -drm_trace_points.o drm_global.o
 +drm_trace_points.o drm_global.o drm_prime.o
 
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 
 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index 0b65fbc..6116e3b 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -136,6 +136,10 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
 DRM_AUTH|DRM_UNLOCKED),
 
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 
 DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 +
 +DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
 drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
 +DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
 drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),
 +
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
 DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
 DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, 
 DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 7348a3d..cdfbf27 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -271,6 +271,9 @@ static int drm_open_helper(struct inode *inode, struct 
 file *filp,
if (dev-driver-driver_features  DRIVER_GEM)
drm_gem_open(dev, priv);
 
 +if (drm_core_check_feature(dev, DRIVER_PRIME))
 +drm_prime_init_file_private(priv-prime);
 +
if (dev-driver-open) {
ret = dev-driver-open(dev, priv);
if (ret  0)
 @@ -571,6 +574,10 @@ int drm_release(struct inode *inode, struct file *filp)
 
if (dev-driver-postclose)
dev-driver-postclose(dev, file_priv);
 +
 +if (drm_core_check_feature(dev, DRIVER_PRIME))
 +drm_prime_destroy_file_private(file_priv-prime);
 +
kfree(file_priv);
 
/* 
 diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
 index 0ef358e..f337497 100644
 --- a/drivers/gpu/drm/drm_gem.c
 +++ b/drivers/gpu/drm/drm_gem.c
 @@ -35,6 +35,7 @@
 #include linux/mman.h
 #include linux/pagemap.h
 #include linux/shmem_fs.h
 +#include linux/dma-buf.h
 #include drmP.h
 
 /** @file drm_gem.c
 @@ -232,6 +233,10 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(filp-object_idr, handle);
spin_unlock(filp-table_lock);
 
 +if (obj-import_attach)
 +drm_prime_remove_fd_handle_mapping(filp-prime,
 +obj-import_attach-dmabuf);
 +
if (dev-driver-gem_close_object)
dev-driver-gem_close_object(obj, filp);
drm_gem_object_handle_unreference_unlocked(obj);
 @@ -527,6 +532,10 @@ drm_gem_object_release_handle(int id, void *ptr, void 
 *data)
struct drm_gem_object *obj = ptr;
struct drm_device *dev = obj-dev;
 
 +if (obj-import_attach)
 +

Re: [PATCH] drm: base prime/dma-buf support

[Ville Syrjälä]

On Mon, Mar 26, 2012 at 04:02:55PM +0100, Dave Airlie wrote:
snip
 +int drm_gem_prime_handle_to_fd(struct drm_device *dev,
 + struct drm_file *file_priv, uint32_t handle, uint32_t flags,
 + int *prime_fd)
 +{
 + struct drm_gem_object *obj;
 +
 + obj = drm_gem_object_lookup(dev, file_priv, handle);
 + if (!obj)
 + return -ENOENT;
 +
 + /* don't allow imported buffers to be re-exported */
 + if (obj-import_attach) {
 + drm_gem_object_unreference_unlocked(obj);
 + return -EINVAL;
 + }
 +
 + if (obj-export_dma_buf) {
 + get_file(obj-export_dma_buf-file);
 + *prime_fd = dma_buf_fd(obj-export_dma_buf, flags);
 + drm_gem_object_unreference_unlocked(obj);
 + } else {
 + obj-export_dma_buf =
 + dev-driver-gem_prime_export(dev, obj, flags);
 + if (IS_ERR_OR_NULL(obj-export_dma_buf)) {
 + /* normally the created dma-buf takes ownership of the 
 ref,
 +  * but if that fails then drop the ref
 +  */
 + drm_gem_object_unreference_unlocked(obj);
 + return PTR_ERR(obj-export_dma_buf);

PTR_ERR(NULL) seems like a bad idea. Also, you're accessing 'obj' after
dropping the reference.

 + }
 + *prime_fd = dma_buf_fd(obj-export_dma_buf, flags);
 + }
 + return 0;
 +}
 +EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
 +
 +int drm_gem_prime_fd_to_handle(struct drm_device *dev,
 + struct drm_file *file_priv, int prime_fd, uint32_t *handle)
 +{
 + struct dma_buf *dma_buf;
 + struct drm_gem_object *obj;
 + int ret;
 +
 + dma_buf = dma_buf_get(prime_fd);
 + if (IS_ERR(dma_buf))
 + return PTR_ERR(dma_buf);
 +
 + ret = drm_prime_lookup_fd_handle_mapping(file_priv-prime,
 + dma_buf, handle);
 + if (!ret) {
 + dma_buf_put(dma_buf);
 + return 0;
 + }
 +
 + /* never seen this one, need to import */
 + obj = dev-driver-gem_prime_import(dev, dma_buf);
 + if (IS_ERR_OR_NULL(obj)) {
 + ret = PTR_ERR(obj);

PTR_ERR(NULL) again.

 + goto fail_put;
 + }
 +
 + ret = drm_gem_handle_create(file_priv, obj, handle);
 + drm_gem_object_unreference_unlocked(obj);
 + if (ret)
 + goto fail_put;
 +
 + ret = drm_prime_insert_fd_handle_mapping(file_priv-prime,
 + dma_buf, *handle);
 + if (ret)
 + goto fail;
 +
 + return 0;
 +
 +fail:
 + /* hmm, if driver attached, we are relying on the free-object path
 +  * to detach.. which seems ok..
 +  */
 + drm_gem_object_handle_unreference_unlocked(obj);
 +fail_put:
 + dma_buf_put(dma_buf);
 + return ret;
 +}
 +EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
 +
 +int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
 +  struct drm_file *file_priv)
 +{
 + struct drm_prime_handle *args = data;
 + uint32_t flags;
 +
 + if (!drm_core_check_feature(dev, DRIVER_PRIME))
 + return -EINVAL;
 +
 + if (!dev-driver-prime_handle_to_fd)
 + return -ENOSYS;
 +
 + /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
 + flags = args-flags  DRM_CLOEXEC;

Check that the unused flags are 0? If you allow broken userspace to
pass uninitialized 'flags' to the kernel, you may have compatibility
problems if/when you want to add more flags.

 +
 + return dev-driver-prime_handle_to_fd(dev, file_priv,
 + args-handle, flags, args-fd);
 +}
 +
 +int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
 +  struct drm_file *file_priv)
 +{
 + struct drm_prime_handle *args = data;
 +
 + if (!drm_core_check_feature(dev, DRIVER_PRIME))
 + return -EINVAL;
 +
 + if (!dev-driver-prime_fd_to_handle)
 + return -ENOSYS;
 +
 + return dev-driver-prime_fd_to_handle(dev, file_priv,
 + args-fd, args-handle);
 +}
 +
 +/*
 + * drm_prime_pages_to_sg
 + *
 + * this helper creates an sg table object from a set of pages
 + * the driver is responsible for mapping the pages into the
 + * importers address space
 + */
 +struct sg_table *drm_prime_pages_to_sg(struct page **pages, int nr_pages)
 +{
 + struct sg_table *sg = NULL;
 + struct scatterlist *iter;
 + int i;
 + int ret;
 +
 + sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);

kmalloc() would be enough. sg_alloc_table() already does a memset().

 + if (!sg)
 + goto out;
 +
 + ret = sg_alloc_table(sg, nr_pages, GFP_KERNEL);
 + if (ret)
 + goto out;
 +
 + for_each_sg(sg-sgl, iter, nr_pages, i)
 + sg_set_page(iter, pages[i], PAGE_SIZE, 0);
 +
 + return sg;
 +out:
 + kfree(sg);
 + return NULL;
 +}
 

[Bug 46724] radeon_drm_winsys compile fail with libdrm in non standard directory

[bugzilla-daemon]

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

Jerome Glisse gli...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Jerome Glisse gli...@freedesktop.org 2012-03-26 10:01:24 
PDT ---
Should be working now, reopen if it's not the case

-- 
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 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

[Daniel Vetter]

On Tue, Mar 27, 2012 at 01:58:47AM +0800, Daniel Kurtz wrote:
 On Mon, Mar 26, 2012 at 10:49 PM, Daniel Vetter dan...@ffwll.ch wrote:
  On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote:
  Instead of rolling our own custom quirk_xfer function, use the bit_algo
  pre_xfer and post_xfer functions to setup and teardown bit-banged
  i2c transactions.
 
  gmbus_xfer uses .force_bit to determine which i2c_algorithm to use,
  either i2c_bit_algo.master_xfer or its own.  So, Similarly, let gmbus_func
  use .force_bit to determine which i2c functionalities are available,
  either i2c_bit_algo.functionality, or its own.
 
  Please split this part of the patch into a separate patch. Furthermore I'm
  not sure what this should buy us, given that we might magically changes
  our i2c feature set once with gone to fallback mode. Can you please
  elaborate why we need this?
 
 An i2c adapter's functionality is provided by its algorithm.
 Since these gmbus adapters can [for now] change their algorithm at
 runtime, I thought the functionality returned should match the
 currently selected algorithm at any given moment.
 
 Arguably, the adapter actually sort of provides the union of the two
 functionalities since if a particular transfer fails using gmbus, it
 gets retried using bit-banged.  But then again, this is a one-shot
 permanent switch, so perhaps we should return the union of the
 functionalities if force_bit == 0, and then only the bit-algo
 functionality after the switch?

In that case I guess we can drop it - current edid reading seems to work
and without a good reason I'd like not to play clever tricks because it
doesn't seem to be worth it.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: improve bpc handling (v2)

[alexdeucher]

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

Improve handling of bpc (bits per color) in radeon.
In most cases we want 8 except for HDMI, DP, LVDS, and eDP.

v2: handle DP better.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Tested-by: Lennert Buytenhek buyt...@wantstofly.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |7 +--
 drivers/gpu/drm/radeon/atombios_dp.c   |7 +--
 drivers/gpu/drm/radeon/atombios_encoders.c |4 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |   56 
 drivers/gpu/drm/radeon/radeon_mode.h   |1 +
 5 files changed, 63 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b5ff1f7..2fab38f 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -588,8 +588,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
if (encoder-crtc == crtc) {
radeon_encoder = to_radeon_encoder(encoder);
connector = radeon_get_connector_for_encoder(encoder);
-   /* if (connector  connector-display_info.bpc)
-   bpc = connector-display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);
encoder_mode = atombios_get_encoder_mode(encoder);
is_duallink = radeon_dig_monitor_is_duallink(encoder, 
mode-clock);
if ((radeon_encoder-devices  (ATOM_DEVICE_LCD_SUPPORT 
| ATOM_DEVICE_DFP_SUPPORT)) ||
@@ -965,9 +964,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
struct radeon_connector_atom_dig *dig_connector =
radeon_connector-con_priv;
int dp_clock;
-
-   /* if (connector-display_info.bpc)
-   bpc = connector-display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);
 
switch (encoder_mode) {
case ATOM_ENCODER_MODE_DP_MST:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index c57d856..cadbb10 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -405,13 +405,10 @@ static void dp_get_adjust_train(u8 
link_status[DP_LINK_STATUS_SIZE],
 /* get bpc from the EDID */
 static int convert_bpc_to_bpp(int bpc)
 {
-#if 0
if (bpc == 0)
return 24;
else
return bpc * 3;
-#endif
-   return 24;
 }
 
 /* get the max pix clock supported by the link rate and lane num */
@@ -463,7 +460,7 @@ static int radeon_dp_get_dp_lane_number(struct 
drm_connector *connector,
u8 dpcd[DP_DPCD_SIZE],
int pix_clock)
 {
-   int bpp = convert_bpc_to_bpp(connector-display_info.bpc);
+   int bpp = convert_bpc_to_bpp(radeon_get_monitor_bpc(connector));
int max_link_rate = dp_get_max_link_rate(dpcd);
int max_lane_num = dp_get_max_lane_number(dpcd);
int lane_num;
@@ -482,7 +479,7 @@ static int radeon_dp_get_dp_link_clock(struct drm_connector 
*connector,
   u8 dpcd[DP_DPCD_SIZE],
   int pix_clock)
 {
-   int bpp = convert_bpc_to_bpp(connector-display_info.bpc);
+   int bpp = convert_bpc_to_bpp(radeon_get_monitor_bpc(connector));
int lane_num, max_pix_clock;
 
if (radeon_connector_encoder_get_dp_bridge_encoder_id(connector) ==
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index e607c4d..06b209b 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -541,7 +541,7 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder, int 
action, int panel_mo
dp_clock = dig_connector-dp_clock;
dp_lane_count = dig_connector-dp_lane_count;
hpd_id = radeon_connector-hpd.hpd;
-   /* bpc = connector-display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);
}
 
/* no dig encoder assigned */
@@ -1159,7 +1159,7 @@ atombios_external_encoder_setup(struct drm_encoder 
*encoder,
dp_lane_count = dig_connector-dp_lane_count;
connector_object_id =
(radeon_connector-connector_object_id  
OBJECT_ID_MASK)  OBJECT_ID_SHIFT;
-   /* bpc = connector-display_info.bpc; */
+   bpc = radeon_get_monitor_bpc(connector);
}
 
memset(args, 0, sizeof(args));
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index bd05156..71fa389 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -84,6 +84,62 @@ static 

[PATCH] drm: Validate requested virtual size against allocated fb size

[Chris Wilson]

mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for doublebuffering. By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.

References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/drm_fb_helper.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 7740dd2..a0d6e89 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -559,9 +559,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
 
/* Need to resize the fb object !!! */
-   if (var-bits_per_pixel  fb-bits_per_pixel || var-xres  fb-width 
|| var-yres  fb-height) {
+   if (var-bits_per_pixel  fb-bits_per_pixel ||
+   var-xres  fb-width || var-yres  fb-height ||
+   var-xres_virtual  fb-width || var-yres_virtual  fb-height) {
DRM_DEBUG(fb userspace requested width/height/bpp is greater 
than current fb 
- object %dx%d-%d  %dx%d-%d\n, var-xres, var-yres, 
var-bits_per_pixel,
+ request %dx%d-%d (virtual %dx%d)  %dx%d-%d\n,
+ var-xres, var-yres, var-bits_per_pixel,
+ var-xres_virtual, var-yres_virtual,
  fb-width, fb-height, fb-bits_per_pixel);
return -EINVAL;
}
-- 
1.7.9.1

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

[Bug 33309] [855GM] GPU freeze due to overlay hang

[bugzilla-daemon]

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

--- Comment #14 from stefan fdo.12.ben...@xoxy.net 2012-03-26 13:17:45 PDT ---
Hi Daniel,
I believe I'm also bitten by this bug and I'd like to test your patch.
Unfortunately, MI_WRITE_NOPID_REG is not defined in the newest kernels
and I couldn't find any reference. If you could update your patch with
its definition, I can give it a go.

Cheers,
Stefan.

-- 
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 33309] [855GM] GPU freeze due to overlay hang

[bugzilla-daemon]

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

--- Comment #15 from Daniel Vetter dan...@ffwll.ch 2012-03-26 13:40:43 PDT ---
 --- Comment #14 from stefan fdo.12.ben...@xoxy.net 2012-03-26 13:17:45 PDT 
 ---
 Hi Daniel,
 I believe I'm also bitten by this bug and I'd like to test your patch.
 Unfortunately, MI_WRITE_NOPID_REG is not defined in the newest kernels
 and I couldn't find any reference. If you could update your patch with
 its definition, I can give it a go.

Just add
#define MI_WRITE_NOPID_REG (1  22)
somewhere.
Yours, Daniel

-- 
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 42876] System doesn't boot with GTX 550 Ti

[bugzilla-daemon]

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


ArTourter artour...@gmail.com changed:

   What|Removed |Added

 CC||artour...@gmail.com




--- Comment #6 from ArTourter artour...@gmail.com  2012-03-27 00:31:37 ---
I have had the same problem with the 3.2 series on Slackware64 (I haven't tried
3.3)
Lenovo T520 laptop
Intel i7 2720QM CPU
Nvidia NVS 4200M

but I am not using the nouveau driver, but the proprietary nvidia driver which
I think hasn't got the time to get loaded before the system freezes.

I have tried booting with both nouveau and nvidia blacklisted in console mode
and still get the same behaviour.

As mention in comment #4, acpi=off noapic allows normal boot but it is really
not practical on a laptop.

3.1.2 works fine (I haven't tried the more recent versions of the 3.1.x
series).

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

[Bug 42941] Resume from suspend to memory leaves display blank on Lenovo Ideapad U455

[bugzilla-daemon]

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


Len Brown l...@kernel.org changed:

   What|Removed |Added

 CC||l...@kernel.org
  Component|Hibernation/Suspend |Video(DRI - non Intel)
 AssignedTo|power-management_other@kern |drivers_video-dri@kernel-bu
   |el-bugs.osdl.org|gs.osdl.org
Product|Power Management|Drivers




--- Comment #2 from Len Brown l...@kernel.org  2012-03-27 02:06:15 ---
1:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon
HD 3200 Graphics] (prog-if 00 [VGA controller])

The AMD Radeon driver is responsible for resuming graphics on this platform.

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