[PATCH 3/7] i2c: export bit-banging algo functions

[Daniel Vetter]

On Mon, Feb 27, 2012 at 11:20:40PM +0100, Jean Delvare wrote:
> Hi Daniel,
> 
> Sorry for the late reply.
> 
> On Tue, 14 Feb 2012 22:37:21 +0100, Daniel Vetter wrote:
> > i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> > we need to be able to fall back to the bit-banging algo on gpio pins.
> > 
> > The current code sets up a 2nd i2c controller for the same i2c bus using
> > the bit-banging algo. This has a bunch of issues, the major one being
> > that userspace can directly access this fallback i2c adaptor behind
> > the drivers back.
> > 
> > But we need to frob a few registers before and after using fallback
> > gpio bit-banging, so this horribly fails.
> 
> You could use the pre_xfer and post_xfer hooks together with a shared
> mutex to solve the problem. But I agree its much cleaner to expose a
> single adapter in the first place.

Yeah, I've seen these and I think we could use them. Still it's cleaner to
only expose one algo for a single bus.

> If you need to hot-switch between hardware and bit-banged I2C, I suggest
> that you lock the bus while doing so, to avoid switching while a
> transaction is in progress. This can be achieved with
> i2c_lock_adapter() and i2c_unlock_adapter().

The drm/i915 xfer function is currently protected by a single mutex
(because the hw i2c controller can only be used on one bus at a time). So
I think we're covered. Also we do the fallback in our xfer function when
we notice that things don't quite work as they should, so we actually want
to switch while a transfer is in progress. Dunno whether that's the best
approach, but the current code is structured like this.

> > The new plan is to only set up one i2c adaptor and transparently fall
> > back to bit-banging by directly calling the xfer function of the bit-
> > banging algo in the i2c core.
> > 
> > To make that possible, export the 2 i2c algo functions.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/i2c/algos/i2c-algo-bit.c |   12 +++-
> >  include/linux/i2c-algo-bit.h |4 
> >  2 files changed, 11 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/i2c/algos/i2c-algo-bit.c 
> > b/drivers/i2c/algos/i2c-algo-bit.c
> > index 525c734..ec1651a 100644
> > --- a/drivers/i2c/algos/i2c-algo-bit.c
> > +++ b/drivers/i2c/algos/i2c-algo-bit.c
> > @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap, 
> > struct i2c_msg *msg)
> > return 0;
> >  }
> >  
> > -static int bit_xfer(struct i2c_adapter *i2c_adap,
> > -   struct i2c_msg msgs[], int num)
> > +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> > +struct i2c_msg msgs[], int num)
> >  {
> > struct i2c_msg *pmsg;
> > struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
> > @@ -598,21 +598,23 @@ bailout:
> > adap->post_xfer(i2c_adap);
> > return ret;
> >  }
> > +EXPORT_SYMBOL(i2c_bit_xfer);
> >  
> > -static u32 bit_func(struct i2c_adapter *adap)
> > +u32 i2c_bit_func(struct i2c_adapter *adap)
> >  {
> > return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
> >I2C_FUNC_SMBUS_READ_BLOCK_DATA |
> >I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
> >I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
> >  }
> > +EXPORT_SYMBOL(i2c_bit_func);
> >  
> >  
> >  /* -exported algorithm data: - 
> > */
> >  
> >  static const struct i2c_algorithm i2c_bit_algo = {
> > -   .master_xfer= bit_xfer,
> > -   .functionality  = bit_func,
> > +   .master_xfer= i2c_bit_xfer,
> > +   .functionality  = i2c_bit_func,
> >  };
> >  
> >  /*
> > diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
> > index 4f98148..cdd6336 100644
> > --- a/include/linux/i2c-algo-bit.h
> > +++ b/include/linux/i2c-algo-bit.h
> > @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
> > int timeout;/* in jiffies */
> >  };
> >  
> > +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> > +struct i2c_msg msgs[], int num);
> > +u32 i2c_bit_func(struct i2c_adapter *adap);
> > +
> >  int i2c_bit_add_bus(struct i2c_adapter *);
> >  int i2c_bit_add_numbered_bus(struct i2c_adapter *);
> 
> I have no problem with this in the principle. In the details, I don't
> understand why you don't simply export i2c_bit_algo? This is one fewer
> export and should serve the same purpose - even allowing faster
> initializations in some cases.

I've figured that hunting for magic functions in a struct is a bit to
intransparent and hence exported the 2 functions I needed instead of the
struct. But if you prefer me to export the vtable I'll gladly do so - that
way I can drop a patch to rename some functions in drm/nouveau that
conflict with these here.

> Looking a bit more to the i2c-algo-bit code, I also notice that
> bypassing i2c_bit_add_bus() means you'll miss some of its features,
> namely bus testing, default retries value and warning on non-compliant
> buses. While none of these are mandatory, it may 

[PATCH 3/7] i2c: export bit-banging algo functions

[Jean Delvare]

Hi Daniel,

Sorry for the late reply.

On Tue, 14 Feb 2012 22:37:21 +0100, Daniel Vetter wrote:
> i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> we need to be able to fall back to the bit-banging algo on gpio pins.
> 
> The current code sets up a 2nd i2c controller for the same i2c bus using
> the bit-banging algo. This has a bunch of issues, the major one being
> that userspace can directly access this fallback i2c adaptor behind
> the drivers back.
> 
> But we need to frob a few registers before and after using fallback
> gpio bit-banging, so this horribly fails.

You could use the pre_xfer and post_xfer hooks together with a shared
mutex to solve the problem. But I agree its much cleaner to expose a
single adapter in the first place.

If you need to hot-switch between hardware and bit-banged I2C, I suggest
that you lock the bus while doing so, to avoid switching while a
transaction is in progress. This can be achieved with
i2c_lock_adapter() and i2c_unlock_adapter().

> The new plan is to only set up one i2c adaptor and transparently fall
> back to bit-banging by directly calling the xfer function of the bit-
> banging algo in the i2c core.
> 
> To make that possible, export the 2 i2c algo functions.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/i2c/algos/i2c-algo-bit.c |   12 +++-
>  include/linux/i2c-algo-bit.h |4 
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/i2c/algos/i2c-algo-bit.c 
> b/drivers/i2c/algos/i2c-algo-bit.c
> index 525c734..ec1651a 100644
> --- a/drivers/i2c/algos/i2c-algo-bit.c
> +++ b/drivers/i2c/algos/i2c-algo-bit.c
> @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap, 
> struct i2c_msg *msg)
>   return 0;
>  }
>  
> -static int bit_xfer(struct i2c_adapter *i2c_adap,
> - struct i2c_msg msgs[], int num)
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> +  struct i2c_msg msgs[], int num)
>  {
>   struct i2c_msg *pmsg;
>   struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
> @@ -598,21 +598,23 @@ bailout:
>   adap->post_xfer(i2c_adap);
>   return ret;
>  }
> +EXPORT_SYMBOL(i2c_bit_xfer);
>  
> -static u32 bit_func(struct i2c_adapter *adap)
> +u32 i2c_bit_func(struct i2c_adapter *adap)
>  {
>   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
>  I2C_FUNC_SMBUS_READ_BLOCK_DATA |
>  I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
>  I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
>  }
> +EXPORT_SYMBOL(i2c_bit_func);
>  
>  
>  /* -exported algorithm data: -   
> */
>  
>  static const struct i2c_algorithm i2c_bit_algo = {
> - .master_xfer= bit_xfer,
> - .functionality  = bit_func,
> + .master_xfer= i2c_bit_xfer,
> + .functionality  = i2c_bit_func,
>  };
>  
>  /*
> diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
> index 4f98148..cdd6336 100644
> --- a/include/linux/i2c-algo-bit.h
> +++ b/include/linux/i2c-algo-bit.h
> @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
>   int timeout;/* in jiffies */
>  };
>  
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> +  struct i2c_msg msgs[], int num);
> +u32 i2c_bit_func(struct i2c_adapter *adap);
> +
>  int i2c_bit_add_bus(struct i2c_adapter *);
>  int i2c_bit_add_numbered_bus(struct i2c_adapter *);

I have no problem with this in the principle. In the details, I don't
understand why you don't simply export i2c_bit_algo? This is one fewer
export and should serve the same purpose - even allowing faster
initializations in some cases.

Looking a bit more to the i2c-algo-bit code, I also notice that
bypassing i2c_bit_add_bus() means you'll miss some of its features,
namely bus testing, default retries value and warning on non-compliant
buses. While none of these are mandatory, it may make sense to export a
new function i2c_bit_add_numbered_bus() which would call
__i2c_bit_add_bus() with no callback function. If you do that, you may
not have to export anything else.

I leave it up to you which way you want to implement it, all are fine
with me, and we can always change later if more use cases show up which
would work better with a different implementation.

-- 
Jean Delvare

[Bug 46274] Reading from /sys/kernel/debug/dri/0/radeon_ring_cp* cause null-pointer dereference

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

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

--- Comment #3 from Florian Mickler  2012-02-27 
14:29:59 PST ---
A patch referencing this bug report has been merged in Linux v3.3-rc5:

commit f0d14daa6906070ca044b86f483fdde7d81f5294
Author: Michel D??nzer 
Date:   Tue Feb 21 17:39:15 2012 +0100

drm/radeon: Only create additional ring debugfs files on Cayman or newer.

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

[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes

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

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

--- Comment #5 from Harald Judt  2012-02-27 11:34:39 PST ---
This problem is still present in 3.3-rc5 (vanilla and tuxonice).

> In fact, it's a 100% chance that the screen does not get black or
> the system freezes.

I have to falsify my previous assumption. It can also happen on the second,
third etc. try. But eventually, if you keep trying long enough, it will still
succeed to resume.

Anyone got an idea what could be wrong here or how to get more info?

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

[PATCH] drm/radeon/kms: fix radeon_dp_get_modes for LVDS bridges

[alexdeuc...@gmail.com]

From: Alex Deucher 

Need to call ExternalEncoderControl to set up DDC before
trying to get an EDID for all DP bridge chipsi (including
DP to LVDS).

Also remove redundant encoder assignment.

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

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index e7cb3ab..8b3d8ed 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1117,13 +1117,23 @@ static int radeon_dp_get_modes(struct drm_connector 
*connector)
(connector->connector_type == DRM_MODE_CONNECTOR_LVDS)) {
struct drm_display_mode *mode;

-   if (!radeon_dig_connector->edp_on)
-   atombios_set_edp_panel_power(connector,
-
ATOM_TRANSMITTER_ACTION_POWER_ON);
-   ret = radeon_ddc_get_modes(radeon_connector);
-   if (!radeon_dig_connector->edp_on)
-   atombios_set_edp_panel_power(connector,
-
ATOM_TRANSMITTER_ACTION_POWER_OFF);
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   if (!radeon_dig_connector->edp_on)
+   atombios_set_edp_panel_power(connector,
+
ATOM_TRANSMITTER_ACTION_POWER_ON);
+   ret = radeon_ddc_get_modes(radeon_connector);
+   if (!radeon_dig_connector->edp_on)
+   atombios_set_edp_panel_power(connector,
+
ATOM_TRANSMITTER_ACTION_POWER_OFF);
+   } else {
+   /* need to setup ddc on the bridge */
+   if 
(radeon_connector_encoder_get_dp_bridge_encoder_id(connector) !=
+   ENCODER_OBJECT_ID_NONE) {
+   if (encoder)
+   
radeon_atom_ext_encoder_setup_ddc(encoder);
+   }
+   ret = radeon_ddc_get_modes(radeon_connector);
+   }

if (ret > 0) {
if (encoder) {
@@ -1134,7 +1144,6 @@ static int radeon_dp_get_modes(struct drm_connector 
*connector)
return ret;
}

-   encoder = radeon_best_single_encoder(connector);
if (!encoder)
return 0;

-- 
1.7.7.5

[PATCH] drm/i915: i2c: unconditionally set up gpio fallback

[Daniel Vetter]

This way we can simplify the setup and teardown a bit.

Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.

Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change any more.

v2: Chris Wilson noticed that I've mixed up && and & ...

v3: Clarify an if block as suggested by Eugeni Dodonov.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h  |3 +-
 drivers/gpu/drm/i915/intel_i2c.c |   51 +++---
 2 files changed, 22 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14b6e94..31affc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -293,7 +293,8 @@ struct intel_fbc_work;

 struct intel_gmbus {
struct i2c_adapter adapter;
-   struct i2c_adapter *force_bit;
+   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/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 6eb68b7..44d1755 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -140,8 +140,8 @@ static void set_data(void *data, int state_high)
POSTING_READ(bus->gpio_reg);
 }

-static struct i2c_adapter *
-intel_gpio_create(struct intel_gmbus *bus, u32 pin)
+static bool
+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[] = {
@@ -157,7 +157,7 @@ intel_gpio_create(struct intel_gmbus *bus, u32 pin)
struct i2c_algo_bit_data *algo;

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

algo = >bit_algo;

@@ -174,12 +174,11 @@ intel_gpio_create(struct intel_gmbus *bus, u32 pin)
algo->timeout = usecs_to_jiffies(2200);
algo->data = bus;

-   return >adapter;
+   return true;
 }

 static int
 intel_i2c_quirk_xfer(struct intel_gmbus *bus,
-struct i2c_adapter *adapter,
 struct i2c_msg *msgs,
 int num)
 {
@@ -193,7 +192,7 @@ intel_i2c_quirk_xfer(struct intel_gmbus *bus,
set_clock(bus, 1);
udelay(I2C_RISEFALL_TIME);

-   ret = i2c_bit_xfer(adapter, msgs, num);
+   ret = i2c_bit_xfer(>adapter, msgs, num);

set_data(bus, 1);
set_clock(bus, 1);
@@ -216,7 +215,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
mutex_lock(_priv->gmbus_mutex);

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

@@ -311,11 +310,12 @@ timeout:
I915_WRITE(GMBUS0 + reg_offset, 0);

/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
-   bus->force_bit = intel_gpio_create(bus, bus->reg0 & 0xff);
-   if (!bus->force_bit)
-   ret = -ENOMEM;
-   else
-   ret = intel_i2c_quirk_xfer(bus, bus->force_bit, msgs, num);
+   if (!bus->has_gpio) {
+   ret = -EIO;
+   } else {
+   bus->force_bit = true;
+   ret = intel_i2c_quirk_xfer(bus, msgs, num);
+   }
 out:
mutex_unlock(_priv->gmbus_mutex);
return ret;
@@ -323,14 +323,8 @@ out:

 static u32 gmbus_func(struct i2c_adapter *adapter)
 {
-   struct intel_gmbus *bus = container_of(adapter,
-  struct intel_gmbus,
-  adapter);
-
-   if (bus->force_bit)
-   i2c_bit_func(bus->force_bit);
-
-   return (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
+   return i2c_bit_func(adapter) &
+   (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
/* I2C_FUNC_10BIT_ADDR | */
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
I2C_FUNC_SMBUS_BLOCK_PROC_CALL);
@@ -388,8 +382,11 @@ int intel_setup_gmbus(struct drm_device *dev)
/* By default use a conservative clock rate */
bus->reg0 = i | GMBUS_RATE_100KHZ;

+   bus->has_gpio = intel_gpio_setup(bus, i);
+
/* XXX force bit banging until GMBUS is fully debugged */
-   bus->force_bit = intel_gpio_create(bus, i);
+   if (bus->has_gpio)
+   bus->force_bit = true;
}

intel_i2c_reset(dev_priv->dev);
@@ -417,16 +414,8 @@ void intel_gmbus_force_bit(struct i2c_adapter *adapter, 
bool force_bit)
 {
struct intel_gmbus *bus = to_intel_gmbus(adapter);

-   if (force_bit) {
-   if (bus->force_bit == NULL) {
-   bus->force_bit = intel_gpio_create(bus,
-

[PATCH 3/7] i2c: export bit-banging algo functions

[Daniel Vetter]

Hi Jean,

Can you please review and if you don't have any objectsion, ack this patch
for merging through drm-intel-next? Imo that's the easiest way to merge
this series.

Thanks, Daniel

On Tue, Feb 14, 2012 at 10:37:21PM +0100, Daniel Vetter wrote:
> i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
> we need to be able to fall back to the bit-banging algo on gpio pins.
> 
> The current code sets up a 2nd i2c controller for the same i2c bus using
> the bit-banging algo. This has a bunch of issues, the major one being
> that userspace can directly access this fallback i2c adaptor behind
> the drivers back.
> 
> But we need to frob a few registers before and after using fallback
> gpio bit-banging, so this horribly fails.
> 
> The new plan is to only set up one i2c adaptor and transparently fall
> back to bit-banging by directly calling the xfer function of the bit-
> banging algo in the i2c core.
> 
> To make that possible, export the 2 i2c algo functions.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/i2c/algos/i2c-algo-bit.c |   12 +++-
>  include/linux/i2c-algo-bit.h |4 
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/i2c/algos/i2c-algo-bit.c 
> b/drivers/i2c/algos/i2c-algo-bit.c
> index 525c734..ec1651a 100644
> --- a/drivers/i2c/algos/i2c-algo-bit.c
> +++ b/drivers/i2c/algos/i2c-algo-bit.c
> @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap, 
> struct i2c_msg *msg)
>   return 0;
>  }
>  
> -static int bit_xfer(struct i2c_adapter *i2c_adap,
> - struct i2c_msg msgs[], int num)
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> +  struct i2c_msg msgs[], int num)
>  {
>   struct i2c_msg *pmsg;
>   struct i2c_algo_bit_data *adap = i2c_adap->algo_data;
> @@ -598,21 +598,23 @@ bailout:
>   adap->post_xfer(i2c_adap);
>   return ret;
>  }
> +EXPORT_SYMBOL(i2c_bit_xfer);
>  
> -static u32 bit_func(struct i2c_adapter *adap)
> +u32 i2c_bit_func(struct i2c_adapter *adap)
>  {
>   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
>  I2C_FUNC_SMBUS_READ_BLOCK_DATA |
>  I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
>  I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
>  }
> +EXPORT_SYMBOL(i2c_bit_func);
>  
>  
>  /* -exported algorithm data: -   
> */
>  
>  static const struct i2c_algorithm i2c_bit_algo = {
> - .master_xfer= bit_xfer,
> - .functionality  = bit_func,
> + .master_xfer= i2c_bit_xfer,
> + .functionality  = i2c_bit_func,
>  };
>  
>  /*
> diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
> index 4f98148..cdd6336 100644
> --- a/include/linux/i2c-algo-bit.h
> +++ b/include/linux/i2c-algo-bit.h
> @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
>   int timeout;/* in jiffies */
>  };
>  
> +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
> +  struct i2c_msg msgs[], int num);
> +u32 i2c_bit_func(struct i2c_adapter *adap);
> +
>  int i2c_bit_add_bus(struct i2c_adapter *);
>  int i2c_bit_add_numbered_bus(struct i2c_adapter *);
>  
> -- 
> 1.7.7.5
> 

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

[PATCH 2/7] drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo

[Daniel Vetter]

Hi Ben,

Can you ack this patch for merging through drm-intel-next? Imo that's the
easiest way to get it in (assuming you don't have any objections).

Thanks, Daniel

On Tue, Feb 14, 2012 at 10:37:20PM +0100, Daniel Vetter wrote:
> I'd like to export the corresponding functions from the i2c core
> so that I can use them in fallback bit-banging in i915.ko
> 
> Cc: nouveau at lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/nouveau/nouveau_i2c.c |8 
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.c 
> b/drivers/gpu/drm/nouveau/nouveau_i2c.c
> index 820ae7f..7a7e751 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_i2c.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_i2c.c
> @@ -242,7 +242,7 @@ i2c_addr(struct nouveau_i2c_chan *port, struct i2c_msg 
> *msg)
>  }
>  
>  static int
> -i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> +nouveau_i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
>  {
>   struct nouveau_i2c_chan *port = (struct nouveau_i2c_chan *)adap;
>   struct i2c_msg *msg = msgs;
> @@ -272,14 +272,14 @@ i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg 
> *msgs, int num)
>  }
>  
>  static u32
> -i2c_bit_func(struct i2c_adapter *adap)
> +nouveau_i2c_bit_func(struct i2c_adapter *adap)
>  {
>   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
>  }
>  
>  const struct i2c_algorithm i2c_bit_algo = {
> - .master_xfer = i2c_bit_xfer,
> - .functionality = i2c_bit_func
> + .master_xfer = nouveau_i2c_bit_xfer,
> + .functionality = nouveau_i2c_bit_func
>  };
>  
>  static const uint32_t nv50_i2c_port[] = {
> -- 
> 1.7.7.5
> 

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

[PATCH] drm/i915: error_buffer->ring should be signed

[Daniel Vetter]

On Thu, Feb 16, 2012 at 02:16:27PM +0300, Dan Carpenter wrote:
> On Thu, Feb 16, 2012 at 11:03:29AM +0100, Daniel Vetter wrote:
> > gcc seems to get uber-anal recently about these things.
> > 
> 
> Sorry, I should have said that it's not a gcc warning, it's a
> smatch thing.  But also it's not uber-anal.  It's the exact level of
> anality which is required to make the == -1 test work.  You can
> compare unsigned int and longs to -1 and it works but for smaller
> types it doesn't.

I've picked this one here up for -next, thanks for your clarification
(added to the commit message in).
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 5/7] drm/vgem: prime export support

[Tomasz Stanislawski]

Hi Ben and Sumit,

Please refer to comments below:

On 02/22/2012 08:29 PM, Ben Widawsky wrote:
> dma-buf export implementation. Heavily influenced by Dave Airlie's proof
> of concept work.
>
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Signed-off-by: Ben Widawsky
> ---
>   drivers/gpu/drm/vgem/Makefile   |2 +-
>   drivers/gpu/drm/vgem/vgem_dma_buf.c |  128 
> +++
>   drivers/gpu/drm/vgem/vgem_drv.c |6 ++
>   drivers/gpu/drm/vgem/vgem_drv.h |7 ++
>   4 files changed, 142 insertions(+), 1 deletions(-)
>   create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
>

[snip]

> +struct sg_table *vgem_gem_map_dma_buf(struct dma_buf_attachment *attachment,
> +  enum dma_data_direction dir)
> +{
> + struct drm_vgem_gem_object *obj = attachment->dmabuf->priv;
> + struct sg_table *sg;
> + int ret;
> +
> + ret = vgem_gem_get_pages(obj);
> + if (ret) {
> + vgem_gem_put_pages(obj);

is it safe to call vgem_gem_put_pages if vgem_gem_get_pages failed (I 
mean ret < 0 was returned) ?

> + return NULL;
> + }
> +
> + BUG_ON(obj->pages == NULL);
> +
> + sg = drm_prime_pages_to_sg(obj->pages, obj->base.size / PAGE_SIZE);

if drm_prime_pages_to_sg fails then you should call vgem_gem_put_pages 
for cleanup.

> + return sg;
> +}

The documentation of DMABUF says fallowing words about map_dma_buf callback.

"It is one of the buffer operations that must be implemented by the 
exporter. It should return the sg_table containing scatterlist for this 
buffer, mapped into caller's address space."

The scatterlist returned by drm_prime_pages_to_sg is not mapped to any 
device. The map_dma_buf callback should call dma_map_sg for caller 
device, which is attachment->dev. Otherwise the implementation is not 
consistent with the DMABUF spec.

I think that it should be chosen to change implementation in map_dma_buf 
in DRM drivers or to drop mentioned sentence from the DMABUF spec.

I bear to the second solution because IMO there is no reliable way of 
mapping a scatterlist to importer device by an exporter. The dma_map_sg 
could be used but not all drivers makes use of DMA framework.

Sumit, what is your opinion about it?

> +
> +void vgem_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
> + struct sg_table *sg)
> +{
> + sg_free_table(sg);
> + kfree(sg);
> +}
> +
> +void vgem_gem_release(struct dma_buf *buf)
> +{
> + struct drm_vgem_gem_object *obj = buf->priv;
> +
> + BUG_ON(buf != obj->base.export_dma_buf);
> +
> + obj->base.prime_fd = -1;
> + obj->base.export_dma_buf = NULL;
> + drm_gem_object_unreference_unlocked(>base);
> +}
> +
> +struct dma_buf_ops vgem_dmabuf_ops = {
> + .map_dma_buf = vgem_gem_map_dma_buf,
> + .unmap_dma_buf = vgem_gem_unmap_dma_buf,
> + .release = vgem_gem_release
> +};
> +

Regards,
Tomasz Stanislawski

[Bug 42727] radeon KMS with CRT TV

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

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





--- Comment #13 from Alex Deucher   2012-02-27 
15:31:08 ---
The only difference seems to be which crtc is driving the TV.  Can you try
booting with only the DVI port connected, and then connecting the TV later once
your desktop is up with both KMS and UMS?

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

[PATCH] drm/i915: i2c: unconditionally set up gpio fallback

[Eugeni Dodonov]

On Mon, Feb 27, 2012 at 15:22, Daniel Vetter  wrote:

> This way we can simplify the setup and teardown a bit.
>
> Because we don't actually allocate anything anymore for the force_bit
> case, we can now convert that into a boolean.
>
> Also and the functionality supported by the bit-banging together with
> what gmbus can do, so that this doesn't randomly change any more.
>
> v2: Chris Wilson noticed that I've mixed up && and & ...
>
> v3: Clarify an if block as suggested by Eugeni Dodonov.
>
> Signed-Off-by: Daniel Vetter 
>

Reviewed-by: Eugeni Dodonov 

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/c9b4556f/attachment.htm>

[KORG]Help: how to submit a kernel driver to kernel.org

[Dave Airlie]

>
>
> I?m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai
> Office. We have developed a kernel driver for all our graphics chips. We
> really want to know how to submit out driver to kernel.org. Would you please
> help to find the appropriate maintainer and the procedure for how to submit
> the driver to kernel.org. Thank you very much.


http://kernel.org/doc/Documentation/SubmittingDrivers

Please see this file, and then generally you need to publish the
patches on this list, in a reviewable form.

That would mean splitting up the driver into chunks that we can
absorb, along with a detailed email
about what hardware, features and userspace interface the driver provides.

Dave.

[KORG]Help: how to submit a kernel driver to kernel.org

[Aaron.Chen 陈俊杰]

Hi,



I?m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai Office. 
We have developed a kernel driver for all our graphics chips. We really want to 
know how to submit out driver to kernel.org. Would you please help to find the 
appropriate maintainer and the procedure for how to submit the driver to 
kernel.org. Thank you very much.



Regards,

Aaron

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

[Intel-gfx] [PATCH 1/7] drm/i915: add dev_priv to intel_gmbus

[Eugeni Dodonov]

On Tue, Feb 14, 2012 at 19:37, Daniel Vetter  wrote:

> This way we can free up the bus->adaptor.algo_data pointer and make it
> available for use with the bitbanging fallback algo.
>
> Signed-Off-by: Daniel Vetter 
>

Reviewed-by: Eugeni Dodonov 

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/6cc1b3eb/attachment-0001.htm>

[PATCH 5/7] drm/vgem: prime export support

[Tomasz Stanislawski]

Hi Ben,
Please refer to comments below.

On 02/22/2012 08:29 PM, Ben Widawsky wrote:
> dma-buf export implementation. Heavily influenced by Dave Airlie's proof
> of concept work.
>
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Signed-off-by: Ben Widawsky
> ---
>   drivers/gpu/drm/vgem/Makefile   |2 +-
>   drivers/gpu/drm/vgem/vgem_dma_buf.c |  128 
> +++
>   drivers/gpu/drm/vgem/vgem_drv.c |6 ++
>   drivers/gpu/drm/vgem/vgem_drv.h |7 ++
>   4 files changed, 142 insertions(+), 1 deletions(-)
>   create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
>
[snip]
> +
> +int vgem_prime_to_fd(struct drm_device *dev, struct drm_file *file,
> +  uint32_t handle, int *prime_fd)
> +{
> + struct drm_vgem_file_private *file_priv = file->driver_priv;
> + struct drm_vgem_gem_object *obj;
> + int ret;
> +
> + DRM_DEBUG_PRIME("Request fd for handle %d\n", handle);
> +
> + obj = to_vgem_bo(drm_gem_object_lookup(dev, file, handle));
> + if (!obj)
> + return -EBADF;
> +
> + /* This means a user has already called get_fd on this */
> + if (obj->base.prime_fd != -1) {
> + DRM_DEBUG_PRIME("User requested a previously exported buffer "
> + "%d %d\n", handle, obj->base.prime_fd);
> + drm_gem_object_unreference(>base);
> + goto out_fd;

IMO, it is not safe to cache a number of file descriptor. This number 
may unexpectedly become invalid introducing a bug. Please refer to the 
scenario:
- application possess a GEM buffer called A
- call DRM_IOCTL_PRIME_HANDLE_TO_FD on A to obtain a file descriptor fd_A
- application calls fd_B = dup(fd_A). Now both fd_A and fd_B point to 
the same DMABUF instance.
- application calls close(fd_A), now fd_A is no longer a valid file 
descriptor
- application tries to export the buffer again and calls ioctl 
DRM_IOCTL_PRIME_HANDLE_TO_FD on GEM buffer. The field obj->base.prime_fd 
is already set to fd_A so value fd_A is returned to userspace. Notice 
that this is a bug because fd_A is no longer valid.

I think that field prime_fd should be removed because it is too 
unreliable. The driver should call dma_buf_fd every time when the buffer 
is exported.

> + }
> +
> + /* Make a dma buf out of our vgem object */
> + obj->base.export_dma_buf = dma_buf_export(obj,_dmabuf_ops,
> +   obj->base.size,
> +   VGEM_FD_PERMS);
> + if (IS_ERR(obj->base.export_dma_buf)) {
> + DRM_DEBUG_PRIME("export fail\n");
> + return PTR_ERR(obj->base.export_dma_buf);
> + } else
> + obj->base.prime_fd = dma_buf_fd(obj->base.export_dma_buf);
> +
> + mutex_lock(>prime_mutex);
> + ret = drm_prime_insert_fd_handle_mapping(_priv->prime,
> +  obj->base.export_dma_buf,
> +  handle);
> + WARN_ON(ret);
> + ret = drm_prime_add_dma_buf(dev,>base);
> + mutex_unlock(>prime_mutex);
> + if (ret)
> + return ret;
> +
> +out_fd:
> + *prime_fd = obj->base.prime_fd;
> +
> + return 0;
> +}
> +

Regards,
Tomasz Stanislawski

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

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

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

--- Comment #11 from Michel D?nzer  2012-02-27 06:27:36 
PST ---
(In reply to comment #7)
> Heaven does not work at all with Mesa 8.0.1. See attached logs, tested with
> Fedora 17.

Ugh yeah, that's a bug in Unigine Heaven: bug 45238

Not sure what to suggest for that. :(

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

[Bug 42727] radeon KMS with CRT TV

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

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





--- Comment #12 from Egor Y. Egorov   2012-02-27 14:26:32 
---
Created an attachment (id=72485)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72485)
with kms

-- 
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 42727] radeon KMS with CRT TV

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

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





--- Comment #11 from Egor Y. Egorov   2012-02-27 14:26:05 
---
Created an attachment (id=72484)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=72484)
without kms

-- 
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 27184] Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably

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

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

Alex Deucher  changed:

   What|Removed |Added

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

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

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

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

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

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #57716|application/octet-stream|text/plain
  mime type||

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

[Bug 42727] radeon KMS with CRT TV

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

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





--- Comment #10 from Alex Deucher   2012-02-27 
13:54:19 ---
Please grab radeonreg (http://cgit.freedesktop.org/~airlied/radeontool/) and
dump the display registers with KMS and without KMS (as root).

./radeonreg regs avivo > working.regs

and

./radeonreg regs avivo > broken.regs

And attach the outputs here.

-- 
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 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

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

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

--- Comment #10 from mikey  2012-02-27 05:48:37 
PST ---
Created attachment 57716
  --> https://bugs.freedesktop.org/attachment.cgi?id=57716
Xorg.0.log - Fedora 17 Alpha with Mesa 8.0.1

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

[Bug 46660] New: Xorg & KMS go to black screen after linux version 2.6.39

[Alexander Konotop]

? Mon, 27 Feb 2012 01:29:03 +
bugzilla-daemon at freedesktop.org ?:

> https://bugs.freedesktop.org/show_bug.cgi?id=46660
> 
>  Bug #: 46660
>Summary: Xorg & KMS go to black screen after linux version
> 2.6.39
> Classification: Unclassified
>Product: DRI
>Version: XOrg CVS
>   Platform: x86-64 (AMD64)
> OS/Version: Linux (All)
> Status: NEW
>   Severity: major
>   Priority: medium
>  Component: DRM/Radeon
> AssignedTo: dri-devel at lists.freedesktop.org
> ReportedBy: vladi at aresgate.net
> 
> 
> Created attachment 57687
>   --> https://bugs.freedesktop.org/attachment.cgi?id=57687
> Xorg config constant while doing the bisect.
> 
> Hi,
> 
> Getting an black screen after panasonic viera tc-p42x1. 
> 
> after doing an git bisect good v2.6.39 on
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> i come to this:
> 
> fe6f0bd03d697835e76dd18d232ba476c65b8282 is the first bad commit
> commit fe6f0bd03d697835e76dd18d232ba476c65b8282
> Author: Marek Ol??k 
> Date:   Sat May 7 01:09:57 2011 +0200
> 
> drm/radeon/kms: add missing Evergreen texture formats to the CS
> parser
> 
> BC6 and BC7 are described in ARB_texture_compression_bptc.
> 
> No idea what FMT_32_AS_32_32_32_32 is good for.
> 
> Signed-off-by: Marek Ol??k 
> Signed-off-by: Dave Airlie 
> 
> :04 04 bd72080004eca34dd6c17a3111d76f1b515f5e8d
> ea46d48c05fb870991f72f0d9e2ebd936e4214aa Mdrivers
> 

Can it be related to this bug?
https://bugs.freedesktop.org/show_bug.cgi?id=41569

If yes - it's fixed in latest kernels (somewhere near 3.2.5 - I'm not
sure)

hibernate random memory corruption, workaround i915.modeset=0

[Stanislaw Gruszka]

Hi.

I'm able to reproduce random memory corruption after hibernate.
Corruption is not reproducible when I disable mode setting, what
seems to blame i915 driver or generic DRM kernel code.

I'm able to reproduce bug on Fedora 11 with 2.6.30 kernel (first
fedora with KMS support) and on the latest 3.3-rc kernels. So this
issue is there from very beginning, hence it is not bisectable.

I'm attaching script to reproduce (with accompanying memory checker
program). Script is basically sequence of hibernate - reset - check
memory. Kernel should be compiled with CONFIG_DEBUG_SLAB to detect
poison/redzone overwrites.

I already tried to debug this using CONFIG_DEBUG_PAGEALLOC and new
kernel option debug_guardpage_minorder, but without any success.
Seems corruption happen behind CPU MMU, i.e. is DMA unit programming
bug. I'm not able to turn on IOMMU on that hardware.

This happen on T500 laptop with, lspci output attached.

I'm attaching also dmesg's with poison/redzone overwrites from
3.3-rc4 and 2.6.30 kernels.

Some more information can be found on:
https://bugzilla.redhat.com/show_bug.cgi?id=746169
https://bugzilla.redhat.com/show_bug.cgi?id=701857

i.e there is invalid DMA address warning that could be a good hint:
https://bugzilla.redhat.com/show_bug.cgi?id=746169#c7

I would appreciate any help with solving this issue. I think many
people are hitting this, but since corruption happens at random,
not many people notice it, or when notice, did not find out that
this could be i915/DRM issue.

Thanks
Stanislaw
-- next part --
A non-text attachment was scrubbed...
Name: hib_corruption_reproducer.tar.bz2
Type: application/x-bzip2
Size: 1468 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/0253a7bd/attachment-0001.bin>
-- next part --
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub [8086:2a40] (rev 07)
Subsystem: Lenovo Device [17aa:20e0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable+
Address: fee0200c  Data: 41b1
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller [8086:2a43] (rev 07)
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd

00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 [8086:2938] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd

00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 [8086:2939] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo Device [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd

00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 [8086:293c] (rev 03) (prog-if 20 [EHCI])
Subsystem: Lenovo Device [17aa:20f1]
Control: I/O- M

[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.

[Jerome Glisse]

On Mon, 2012-02-27 at 10:44 +0800, Chen Jie wrote:
> Hi,
> 
> For this occasional GPU lockup when returns from STR/STD, I find
> followings(when the problem happens):
> 
> The value of SRBM_STATUS is whether 0x20002040 or 0x20003040.
> Which means:
> * HI_RQ_PENDING(There is a HI/BIF request pending in the SRBM)
> * MCDW_BUSY(Memory Controller Block is Busy)
> * BIF_BUSY(Bus Interface is Busy)
> * MCDX_BUSY(Memory Controller Block is Busy) if is 0x20003040
> Are MCDW_BUSY and MCDX_BUSY two memory channels? What is the
> relationship among GART mapped memory, On-board video memory and MCDX,
> MCDW?
> 
> CP_STAT: the CSF_RING_BUSY is always set.

Once the memory controller fails to do a pci transaction the CP
will be stuck. At least if ring is in system memory, if ring is
in vram CP might be stuck too because anyway everything goes
through the MC.

> 
> There are many CP_PACKET2(0x8000) in CP ring(more than three hundreds). 
> e.g.
> r[131800]=0x00028000
> r[131801]=0xc0016800
> r[131802]=0x0140
> r[131803]=0x79c5
> r[131804]=0x304a
> r[131805] ... r[132143]=0x8000
> r[132144]=0x
> After the first reset, GPU will lockup again, this time, typically
> there are 320 dwords in CP ring -- with 319 CP_PACKET2 and 0xc0033d00
> in the end.
> Are these normal?
> 
> BTW, is there any way for X to switch to NOACCEL mode when the problem
> happens? Thus users will have a chance to save their documents and
> then reboot machine.

I have been meaning to patch the ddx to fallback to sw after GPU lockup.
But this is useless in today world, where everything is composited ie
the screen is updated using the 3D driver for which there is no easy
way to suddenly migrate to  software rendering. I will still probably
do the ddx patch at one point.

Cheers,
Jerome

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

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

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

--- Comment #9 from mikey  2012-02-27 05:38:42 PST 
---
Created attachment 57715
  --> https://bugs.freedesktop.org/attachment.cgi?id=57715
glxinfo - Fedora 17 Alpha with Mesa 8.0.1

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

[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.

[Jerome Glisse]

On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
> ? 2012?2?17? ??5:27?Chen Jie  ???
> >> One good way to test gart is to go over GPU gart table and write a
> >> dword using the GPU at end of each page something like 0xCAFEDEAD
> >> or somevalue that is unlikely to be already set. And then go over
> >> all the page and check that GPU write succeed. Abusing the scratch
> >> register write back feature is the easiest way to try that.
> > I'm planning to add a GART table check procedure when resume, which
> > will go over GPU gart table:
> > 1. read(backup) a dword at end of each GPU page
> > 2. write a mark by GPU and check it
> > 3. restore the original dword
> Attachment validateGART.patch do the job:
> * It current only works for mips64 platform.
> * To use it, apply all_in_vram.patch first, which will allocate CP
> ring, ih, ib in VRAM and hard code no_wb=1.
> 
> The gart test routine will be invoked in r600_resume. We've tried it,
> and find that when lockup happened the gart table was good before
> userspace restarting. The related dmesg follows:
> [ 1521.820312] [drm] r600_gart_table_validate(): Validate GART Table
> at 90004004, 32768 entries, Dummy
> Page[0x0e004000-0x0e007fff]
> [ 1522.019531] [drm] r600_gart_table_validate(): Sweep 32768
> entries(valid=8544, invalid=24224, total=32768).
> ...
> [ 1531.156250] PM: resume of devices complete after 9396.588 msecs
> [ 1532.152343] Restarting tasks ... done.
> [ 1544.468750] radeon :01:05.0: GPU lockup CP stall for more than 
> 10003msec
> [ 1544.472656] [ cut here ]
> [ 1544.480468] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:243
> radeon_fence_wait+0x25c/0x314()
> [ 1544.488281] GPU lockup (waiting for 0x0002136B last fence id 0x0002136A)
> ...
> [ 1544.886718] radeon :01:05.0: Wait for MC idle timedout !
> [ 1545.046875] radeon :01:05.0: Wait for MC idle timedout !
> [ 1545.062500] radeon :01:05.0: WB disabled
> [ 1545.097656] [drm] ring test succeeded in 0 usecs
> [ 1545.105468] [drm] ib test succeeded in 0 usecs
> [ 1545.109375] [drm] Enabling audio support
> [ 1545.113281] [drm] r600_gart_table_validate(): Validate GART Table
> at 90004004, 32768 entries, Dummy
> Page[0x0e004000-0x0e007fff]
> [ 1545.125000] [drm:r600_gart_table_validate] *ERROR* Iter=0:
> unexpected value 0x745aaad1(expect 0xDEADBEEF)
> entry=0x0e008067, orignal=0x745aaad1
> ...
> /* System blocked here. */
> 
> Any idea?

I know lockup are frustrating, my only idea is the memory controller
is lockup because of some failing pci <-> system ram transaction.

> 
> BTW, we find the following in r600_pcie_gart_enable()
> (drivers/gpu/drm/radeon/r600.c):
> WREG32(VM_CONTEXT0_PROTECTION_FAULT_DEFAULT_ADDR,
> (u32)(rdev->dummy_page.addr >> 12));
> 
> On our platform, PAGE_SIZE is 16K, does it have any problem?

No this should be handled properly.

> Also in radeon_gart_unbind() and radeon_gart_restore(), the logic
> should change to:
>   for (j = 0; j < (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); j++, t++) {
>   radeon_gart_set_page(rdev, t, page_base);
> - page_base += RADEON_GPU_PAGE_SIZE;
> + if (page_base != rdev->dummy_page.addr)
> + page_base += RADEON_GPU_PAGE_SIZE;
>   }
> ???

No need to do so, dummy page will be 16K too, so it's fine.

Cheers,
Jerome

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

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

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

--- Comment #8 from mikey  2012-02-27 05:37:58 PST 
---
Created attachment 57714
  --> https://bugs.freedesktop.org/attachment.cgi?id=57714
Heaven Ouput - Fedora 17 Alpha with Mesa 8.0.1

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

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

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

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

--- Comment #7 from mikey  2012-02-27 05:36:22 PST 
---
Heaven does not work at all with Mesa 8.0.1. See attached logs, tested with
Fedora 17.

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

[git pull] drm fixes

[Eugeni Dodonov]

On Mon, Feb 27, 2012 at 13:09, Jesse Barnes wrote:

> On Thu, 23 Feb 2012 21:19:20 +0100
> Torsten Kaiser  wrote:
>
> > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie  wrote:
> > > Eugeni Dodonov (4):
> > >  drm/i915: gen7: implement rczunit workaround
> > >  drm/i915: gen7: Implement an L3 caching workaround.
> > >  drm/i915: gen7: work around a system hang on IVB
> > >  drm/i915: do not enable RC6p on Sandy Bridge
> >
> > That last patch about RC6p looks wrong.
> >
> > It does:
> >  GEN6_RC_CTL_RC6_ENABLE |
> >   (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE
> : 0;
> > But I think this was meant:
> >  GEN6_RC_CTL_RC6_ENABLE |
> >   ((IS_GEN7(dev_priv->dev)) ?
> GEN6_RC_CTL_RC6p_ENABLE : 0);
> >
> > Or did I get the operator precedence wrong?
>
> You're right, no cookie for Eugeni. :)  This would have prevented RC6
> from ever getting enabled though, which should have the same effect as
> the patch intended, though at the cost of higher power consumption.
>

Actually, no, it got RC6p enabled - so it got to have all the power savings
of RC6 plus some additional ones in the range of 0.1W, but it also resulted
in the very same problem as before, when both RC6 and RC6p were enabled.

So, from what we've seen with
https://wiki.ubuntu.com/Kernel/PowerManagementRC6, the graphics corruptions
do only happen when RC6p is enabled (either together with RC6, or
individually, on its own). If we have only RC6, all the issues are gone so
far.

So this bad patch had its use after all - it served to finally isolate and
prove that the i915_enable_rc6-related issues are caused directly by RC6p.

-- 
Eugeni Dodonov
 <http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/866c7a62/attachment.htm>

[PATCH] drm/radeon/kms: give better user feedback if a VM CS fails

[Alex Deucher]

On Mon, Feb 27, 2012 at 12:24 PM, David Airlie  wrote:
>
>> ---
>> ?drivers/gpu/drm/radeon/radeon_cs.c | ? ?1 +
>> ?1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
>> b/drivers/gpu/drm/radeon/radeon_cs.c
>> index 9b4124e..f7ee2f8 100644
>> --- a/drivers/gpu/drm/radeon/radeon_cs.c
>> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
>> @@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct
>> radeon_device *rdev,
>> ? ? ? }
>> ? ? ? r = radeon_ring_ib_parse(rdev, parser->ring, parser->ib);
>> ? ? ? if (r) {
>> + ? ? ? ? ? ? DRM_ERROR("Invalid VM CS\n");
>> ? ? ? ? ? ? ? return r;
>
> Isn't this user triggerable?

If they send a bad CS, sure.  It just brings the VM CS ioctl in line
with non-VM one which warns similarly.

Alex

>
> Dave.

[PATCH] drm/radeon/kms: give better user feedback if a VM CS fails

[David Airlie]

> ---
>  drivers/gpu/drm/radeon/radeon_cs.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 9b4124e..f7ee2f8 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct
> radeon_device *rdev,
>   }
>   r = radeon_ring_ib_parse(rdev, parser->ring, parser->ib);
>   if (r) {
> + DRM_ERROR("Invalid VM CS\n");
>   return r;

Isn't this user triggerable?

Dave.

[PATCH 1/7] drm: base prime support

[InKi Dae]

2012? 2? 23? ?? 4:29, Ben Widawsky ?? ?:
> From: Dave Airlie 
>
> ---
>  drivers/gpu/drm/Makefile|2 +-
>  drivers/gpu/drm/drm_drv.c   |3 +
>  drivers/gpu/drm/drm_gem.c   |3 +-
>  drivers/gpu/drm/drm_prime.c |  126 
> +++
>  include/drm/drm.h   |   10 +++-
>  include/drm/drmP.h  |   35 
>  6 files changed, 176 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_prime.c
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 0cde1b8..202f650 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_usb.o
> +   drm_trace_points.o drm_global.o drm_usb.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 ebf7d3f..786b134 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -135,6 +135,9 @@ static struct drm_ioctl_desc drm_ioctls[] = {
>DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
>DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, 
> DRM_AUTH|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_GETRESOURCES, drm_mode_getresources, 
> DRM_MASTER|DRM_CONTROL_ALLOW|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_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index f8625e2..e19a958 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -145,6 +145,7 @@ int drm_gem_object_init(struct drm_device *dev,
>kref_init(>refcount);
>atomic_set(>handle_count, 0);
>obj->size = size;
> +   obj->prime_fd = -1;
>
>return 0;
>  }
> @@ -166,7 +167,7 @@ int drm_gem_private_object_init(struct drm_device *dev,
>kref_init(>refcount);
>atomic_set(>handle_count, 0);
>obj->size = size;
> -
> +   obj->prime_fd = -1;
>return 0;
>  }
>  EXPORT_SYMBOL(drm_gem_private_object_init);
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> new file mode 100644
> index 000..11f142f
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -0,0 +1,126 @@
> +#include 
> +#include 
> +#include "drmP.h"
> +
> +struct drm_prime_member {
> +   struct list_head entry;
> +   struct dma_buf *dma_buf;
> +   uint32_t 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;
> +
> +   if (!drm_core_check_feature(dev, DRIVER_PRIME))
> +   return -EINVAL;
> +
> +   return dev->driver->prime_handle_to_fd(dev, file_priv, args->handle, 
> >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;
> +
> +   return dev->driver->prime_fd_to_handle(dev, file_priv, args->fd, 
> >handle);
> +}
> +
> +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);
> +   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;
> +}
> +EXPORT_SYMBOL(drm_prime_pages_to_sg);
> +
> +/* helper function to cleanup a GEM/prime object */
> +void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg)
> +{
> +   struct dma_buf_attachment *attach;
> +
> +   attach = obj->import_attach;
> +   if (sg)
> +   dma_buf_unmap_attachment(attach, sg);
> +   dma_buf_detach(attach->dmabuf, attach);
> +}
> +EXPORT_SYMBOL(drm_prime_gem_destroy);
> +
> +void 

[PATCH] drm/radeon/kms: give better user feedback if a VM CS fails

[alexdeuc...@gmail.com]

From: Alex Deucher 

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

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 9b4124e..f7ee2f8 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
}
r = radeon_ring_ib_parse(rdev, parser->ring, parser->ib);
if (r) {
+   DRM_ERROR("Invalid VM CS\n");
return r;
}

-- 
1.7.7.5

[git pull] drm/exynos: sync with exynos-drm-fixes.

[Inki Dae]

Hi, Dave.

Please pull form
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next

this pull request is for synchronizing it with latest exynos-drm-fixes branch
that have already merged to mainline. after this, I will send new features
for exynos.

this branch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-next
commit-id: 019d96cb55ade38a4b4a52bba0304e8cd681f30a

Thanks.

Inki Dae (4):
  drm/exynos: added possible_clones setup function.
  drm/exynos: fixed page flip issue.
  drm/exynos: removed exynos_drm_fbdev_recreate function.
  drm/exynos: added postclose to release resource.

Joonyoung Shim (2):
  drm/exynos: changed priority of mixer layers.
  drm/exynos: removed pageflip_event_list init code when closed.

Masanari Iida (1):
  drm/exynos: Fix typo in exynos_mixer.c

 drivers/gpu/drm/exynos/exynos_drm_core.c|3 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|6 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   26 +++---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   34 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |   70 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|7 ++-
 drivers/gpu/drm/exynos/exynos_mixer.c   |   19 +---
 8 files changed, 81 insertions(+), 85 deletions(-)

-- 
1.7.4.1

[drm-next] drm/radeon/kms: use asic callback for mc idle

[alexdeuc...@gmail.com]

From: Alex Deucher 

Switch all the asic specific mc idle calls to use
the asic callback.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c |6 +++---
 drivers/gpu/drm/radeon/ni.c|3 +--
 drivers/gpu/drm/radeon/r100.c  |2 +-
 drivers/gpu/drm/radeon/r300.c  |4 ++--
 drivers/gpu/drm/radeon/r520.c  |4 ++--
 drivers/gpu/drm/radeon/r600.c  |7 +++
 drivers/gpu/drm/radeon/rs400.c |4 ++--
 drivers/gpu/drm/radeon/rs600.c |5 ++---
 drivers/gpu/drm/radeon/rs690.c |4 ++--
 drivers/gpu/drm/radeon/rv515.c |5 ++---
 drivers/gpu/drm/radeon/rv770.c |4 ++--
 11 files changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 758f04b..755a2a9 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1270,7 +1270,7 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);

evergreen_mc_stop(rdev, );
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
/* Lockout access through VGA aperture*/
@@ -1318,7 +1318,7 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
evergreen_mc_resume(rdev, );
@@ -2425,7 +2425,7 @@ static int evergreen_gpu_soft_reset(struct radeon_device 
*rdev)
dev_info(rdev->dev, "  SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
evergreen_mc_stop(rdev, );
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
/* Disable CP parsing/prefetching */
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 160799c..92f5eec 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -36,7 +36,6 @@

 extern void evergreen_mc_stop(struct radeon_device *rdev, struct 
evergreen_mc_save *save);
 extern void evergreen_mc_resume(struct radeon_device *rdev, struct 
evergreen_mc_save *save);
-extern int evergreen_mc_wait_for_idle(struct radeon_device *rdev);
 extern void evergreen_mc_program(struct radeon_device *rdev);
 extern void evergreen_irq_suspend(struct radeon_device *rdev);
 extern int evergreen_mc_init(struct radeon_device *rdev);
@@ -1385,7 +1384,7 @@ static int cayman_gpu_soft_reset(struct radeon_device 
*rdev)
 RREG32(0x14DC));

evergreen_mc_stop(rdev, );
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
/* Disable CP parsing/prefetching */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 42ae955..6dd7cf8 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3882,7 +3882,7 @@ static void r100_mc_program(struct radeon_device *rdev)
WREG32(R_00015C_AGP_BASE_2, 0);
}
/* Wait for mc idle */
-   if (r100_mc_wait_for_idle(rdev))
+   if (radeon_mc_wait_for_idle(rdev))
dev_warn(rdev->dev, "Wait for MC idle timeout.\n");
/* Program MC, should be a 32bits limited address space */
WREG32(R_000148_MC_FB_LOCATION,
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index fa14383..d10b6be 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -369,7 +369,7 @@ void r300_gpu_init(struct radeon_device *rdev)
printk(KERN_WARNING "Failed to wait GUI idle while "
   "programming pipes. Bad things might happen.\n");
}
-   if (r300_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
printk(KERN_WARNING "Failed to wait MC idle while "
   "programming pipes. Bad things might happen.\n");
}
@@ -1339,7 +1339,7 @@ void r300_mc_program(struct radeon_device *rdev)
WREG32(R_00015C_AGP_BASE_2, 0);
}
/* Wait for mc idle */
-   if (r300_mc_wait_for_idle(rdev))
+   if (radeon_mc_wait_for_idle(rdev))
DRM_INFO("Failed to wait MC idle before programming MC.\n");
/* Program MC, should be a 32bits limited address space */
WREG32(R_000148_MC_FB_LOCATION,
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index ebcc15b..0513360 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ 

Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

[Felix Kuehling]

On 12-02-24 11:38 PM, Mario Kleiner wrote:
> On Feb 24, 2012, at 10:20 PM, Felix Kuehling wrote:
>
>> On 12-02-22 11:20 AM, Felix Kuehling wrote:
>>> On 12-02-21 07:49 PM, Mario Kleiner wrote:
 On 02/21/2012 09:07 PM, Alex Deucher wrote:
>>> [snip]
> The fix looks ok to me.  Mario any thoughts?
>
> Reviewed-by: Alex Deucher
>
 Hi,

 the fix looks ok to me for that device, but could we make it
 conditional on the AMD C-50 APU and similar pieces? It is the right
 thing to do for that gpu, but for regular desktop gpus it is too
 pessimistic if it defers the pageflip timestamping and completion
 event for an already completed flip:

 1. Makes the timestamps 1 refresh too late, causing timing sensitive
 software like mine to detect false positives -- reporting skipped
 frames were there weren't any. Not as bad as missing a really skipped
 frame, but still not great.
>>> Agreed. I was going to perform some more experiments on other hardware
>>> to determine what the right threshold is for different hardware
>>> generations. I hope I'll get to that this week.
>>
>> I have a final version of my patch including an explanation of the
>> observations it's based on (attached). It's against current drm-next
>> from git://people.freedesktop.org/~airlied/linux.
>>
>
> The idea of the current logic was that it happened that the
> update_pending bit isn't read back as zero at the end of the page_flip
> programming function, immediately after clearing the graphics hardware
> update_lock, e.g., maybe because there is some delay between clearing
> that register and the double buffering taking place. But according to
> the specs, if update_pending is high, ie., the hw has "accepted" the
> request for a page flip, it will complete as long as that request
> still happened within the vblank. So on a return from the page_flip
> function with update_pending == 1 we check if we are still inside the
> vblank area, ie., if the hw will certainly complete the double
> buffering within the current vblank, because the request was made in
> time.
>
> I did all my original testing of these bits with avivo hw (rv530,
> r600) and with one radeon hd 5850, so i'm a bit surprised if the avivo
> path would unconditionally need this adjustment. Could it be that the
> observed accuracy of update_pending depends on the rest of the hw,
> e.g., bus or processor speed, or bus activity? My test machines were a
> MacBookPro with Core2Duo 2.3 Ghz for rv530 and a rather old AMD
> Athlon-64 PC for r600.

I used a few different systems:

Brazos reference board for Brazos (E-350)
Iconia Tab W500 (C-50)
PhenomII X4 for most of the discrete cards
Athlon64 X2 for RS690

The results I got were consistent across all those systems. The only
differences I saw between different generations of Avivo-based hardware
were about the exact timing of the threshold when I would start seeing
flickering. On R5xx and R6xx it would start flickering at -3. On newer
hardware at -4 (I didn't test on R7xx).

>
> I'm worried that your observed reliability of update_pending on >=
> AVIVO asics could be an artifact of the specific computer hw you used
> and that this doesn't generalize on older or different hw.

Given the number of different ASICs and systems, I think that's
unlikely. It's more likely that this depends on the exact mode timings.
I was running most of my experiments with a 19" DFP 1280x1024 at 60Hz,
connected by DVI if available, or VGA on some of the IGPs.

It's possible that different mode timings would result in a slightly
different threshold.

> If it doesn't generalize then the patch could defer a lot of perfectly
> good pageflips by 1 frame, screwing the timestamps and reducing
> framerate.

I understand your concern. But given my observations, the current
implementation potentially produces much more annoying artefacts.

>
> Here is what the rv630 register programming guide says about the
> double-buffering of the surface base address registers:
>
> D1GRPH_SURFACE_UPDATE_PENDING: "the double buffering occurs in
> vertical retrace when D1GRPH_SURFACE_UPDATE_PENDING = 1 and
> D1GRPH_UPDATE_LOCK = 0 and V_UPDATE = 1."

As far as I can tell, D1GRPH_SURFACE_UPDATE_PENDING will only be 1, if
the page flip is initiated while outside the vertical retrace. The the
actual page flip will occur when V_UPDATE changes to 1, that is, when
the next vertical retrace occurs. So if we read
D1GRPH_SURFACE_UPDATE_PENDING after initiating a page flip, it implies
that we're currently not in a vertical retrace.

>
> D1CRTC_V_UPDATE: "Current vertical position ... 1 =  within the
> V_UPDATE region (between end of vertical active display and start_line)"
>
> For us that would mean the threshold for deferred flip completion
> would need to be whatever that mentioned "start_line" is, and for the
> tested avivo hw, start_line used to be == start of active scanout, so
> the threshold of zero made sense.

In my experiments 

[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.

[Chen Jie]

Hi,

For this occasional GPU lockup when returns from STR/STD, I find
followings(when the problem happens):

The value of SRBM_STATUS is whether 0x20002040 or 0x20003040.
Which means:
* HI_RQ_PENDING(There is a HI/BIF request pending in the SRBM)
* MCDW_BUSY(Memory Controller Block is Busy)
* BIF_BUSY(Bus Interface is Busy)
* MCDX_BUSY(Memory Controller Block is Busy) if is 0x20003040
Are MCDW_BUSY and MCDX_BUSY two memory channels? What is the
relationship among GART mapped memory, On-board video memory and MCDX,
MCDW?

CP_STAT: the CSF_RING_BUSY is always set.

There are many CP_PACKET2(0x8000) in CP ring(more than three hundreds). e.g.
r[131800]=0x00028000
r[131801]=0xc0016800
r[131802]=0x0140
r[131803]=0x79c5
r[131804]=0x304a
r[131805] ... r[132143]=0x8000
r[132144]=0x
After the first reset, GPU will lockup again, this time, typically
there are 320 dwords in CP ring -- with 319 CP_PACKET2 and 0xc0033d00
in the end.
Are these normal?

BTW, is there any way for X to switch to NOACCEL mode when the problem
happens? Thus users will have a chance to save their documents and
then reboot machine.


Regards,
-- Chen Jie

[Bug 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

--- Comment #6 from Michel D?nzer  2012-02-27 01:52:22 
PST ---
(In reply to comment #4)
> [   88.579198] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
> [   88.579733] radeon :01:05.0: r600_check_texture_resource:1338 texture
> invalid format 26

It looks like the commit you bisected to was the one which fixed this problem,
not the one that caused the black screen.

You should probably ignore X for the bisect, and just call any kernel that
lights up the monitor good, otherwise bad.

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

[Bug 42716] Boot failure with KMS enabled (radeon)

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

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





--- Comment #4 from Paul Menzel   
2012-02-27 09:41:59 ---
(In reply to comment #2)
> I'm marking this as invalid.  The machine I was seeing this on has died, and 
> it
> started with all of the usb ports going bad.  From there, other parts stopped
> working over the course of several days.  I suspect a bad motherboard that was
> introducing faults, and 3.1.x was somehow working around them better than
> 3.2.x.  Who knows?  :/

Could you please document what machine and what board this was? In case others
experience problems with the same machine it is quite helpful to know of
quality issues.

-- 
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 42716] Boot failure with KMS enabled (radeon)

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

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


Paul Menzel  changed:

   What|Removed |Added

 CC||paulepanter at users.sourcefor
   ||ge.net




--- Comment #3 from Paul Menzel   
2012-02-27 09:40:14 ---
(In reply to comment #0)

[?]

> Any idea what's going on here?  I don't have the option to attach a serial
> console, for what that's worth, so that aside, any suggestions for further
> debugging?

Next time you can try netconsole. Although it has to be loaded before the
radeon module. I guess a way to come around that issue is to build the module
for the network card into the Linux kernel.

Additionally you could have started using a standard driver like vesafb(?) and
then load the radeon module manually after the system booted.

Thanks and good luck with your new system.

[1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt

-- 
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 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

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

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

Michel D?nzer  changed:

   What|Removed |Added

 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
  QAContact|xorg-team at lists.x.org   |
Product|xorg|Mesa
Version|unspecified |7.11
  Component|Driver/Radeon   |Drivers/Gallium/r600

--- Comment #6 from Michel D?nzer  2012-02-27 01:01:02 
PST ---
Could be bug 38173 ? does Mesa 8.0.1 or newer work better?

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

[git pull] Intel drm fixes

[Jesse Barnes]

On Mon, 27 Feb 2012 08:08:13 -0800
Jesse Barnes  wrote:

> The following changes since commit
> 3ac0eb6d62fde0a60a6c5c61e562af1db8fbf712:
> 
>   drm/radeon/kms/atom: dpms bios scratch reg updates (2012-02-22 10:30:06 
> +)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel 
> drm-intel-fixes
> 
> Alban Browaeys (1):
>   drm/i915: Prevent a machine hang by checking crtc->active before 
> loading lut
> 
> Dave Airlie (1):
>   drm/i915: fix mode set on load pipe. (v2)
> 
> Eugeni Dodonov (1):
>   drm/i915: fix operator precedence when enabling RC6p
> 
> Hai Lan (1):
>   drm/i915: fix a sprite watermark computation to avoid divide by zero if 
> xpos<0

Snuck one more in here that I promised earlier:


commit 5d031e5b633d910f35e6e0abce94d9d842390006
Author: Chris Wilson 
Date:   Wed Feb 8 13:34:13 2012 +

drm/i915: Remove use of the autoreported ringbuffer HEAD position

in case you haven't pulled yet.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/47b7dabf/attachment.pgp>

[git pull] drm fixes

[Jesse Barnes]

On Mon, 27 Feb 2012 13:33:53 -0300
Eugeni Dodonov  wrote:

> On Mon, Feb 27, 2012 at 13:09, Jesse Barnes  virtuousgeek.org>wrote:
> 
> > On Thu, 23 Feb 2012 21:19:20 +0100
> > Torsten Kaiser  wrote:
> >
> > > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie  wrote:
> > > > Eugeni Dodonov (4):
> > > >  drm/i915: gen7: implement rczunit workaround
> > > >  drm/i915: gen7: Implement an L3 caching workaround.
> > > >  drm/i915: gen7: work around a system hang on IVB
> > > >  drm/i915: do not enable RC6p on Sandy Bridge
> > >
> > > That last patch about RC6p looks wrong.
> > >
> > > It does:
> > >  GEN6_RC_CTL_RC6_ENABLE |
> > >   (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE
> > : 0;
> > > But I think this was meant:
> > >  GEN6_RC_CTL_RC6_ENABLE |
> > >   ((IS_GEN7(dev_priv->dev)) ?
> > GEN6_RC_CTL_RC6p_ENABLE : 0);
> > >
> > > Or did I get the operator precedence wrong?
> >
> > You're right, no cookie for Eugeni. :)  This would have prevented RC6
> > from ever getting enabled though, which should have the same effect as
> > the patch intended, though at the cost of higher power consumption.
> >
> 
> Actually, no, it got RC6p enabled - so it got to have all the power savings
> of RC6 plus some additional ones in the range of 0.1W, but it also resulted
> in the very same problem as before, when both RC6 and RC6p were enabled.
> 
> So, from what we've seen with
> https://wiki.ubuntu.com/Kernel/PowerManagementRC6, the graphics corruptions
> do only happen when RC6p is enabled (either together with RC6, or
> individually, on its own). If we have only RC6, all the issues are gone so
> far.
> 
> So this bad patch had its use after all - it served to finally isolate and
> prove that the i915_enable_rc6-related issues are caused directly by RC6p.

Oh you're right; I had the bit positions mixed up...  I thought the
higher level bit toggled all RC6 functionality, but that's kept
separate from this.

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/a2e99653/attachment-0001.pgp>

[git pull] drm fixes

[Jesse Barnes]

On Thu, 23 Feb 2012 21:19:20 +0100
Torsten Kaiser  wrote:

> On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie  wrote:
> > Eugeni Dodonov (4):
> > ? ? ?drm/i915: gen7: implement rczunit workaround
> > ? ? ?drm/i915: gen7: Implement an L3 caching workaround.
> > ? ? ?drm/i915: gen7: work around a system hang on IVB
> > ? ? ?drm/i915: do not enable RC6p on Sandy Bridge
> 
> That last patch about RC6p looks wrong.
> 
> It does:
>  GEN6_RC_CTL_RC6_ENABLE |
>   (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0;
> But I think this was meant:
>  GEN6_RC_CTL_RC6_ENABLE |
>   ((IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 
> 0);
> 
> Or did I get the operator precedence wrong?

You're right, no cookie for Eugeni. :)  This would have prevented RC6
from ever getting enabled though, which should have the same effect as
the patch intended, though at the cost of higher power consumption.

Fix just sent to Dave anyway.

-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/94db2cce/attachment.pgp>

[git pull] Intel drm fixes

[Jesse Barnes]

The following changes since commit
3ac0eb6d62fde0a60a6c5c61e562af1db8fbf712:

  drm/radeon/kms/atom: dpms bios scratch reg updates (2012-02-22 10:30:06 +)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel 
drm-intel-fixes

Alban Browaeys (1):
  drm/i915: Prevent a machine hang by checking crtc->active before loading 
lut

Dave Airlie (1):
  drm/i915: fix mode set on load pipe. (v2)

Eugeni Dodonov (1):
  drm/i915: fix operator precedence when enabling RC6p

Hai Lan (1):
  drm/i915: fix a sprite watermark computation to avoid divide by zero if 
xpos<0

 drivers/gpu/drm/i915/intel_display.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)


-- 
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120227/2342f4b1/attachment.pgp>

[Bug 27184] Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably

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

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

--- Comment #24 from tomi.orava at ncircle.nullnet.fi 2012-02-26 23:31:00 PST 
---
Created attachment 57700
  --> https://bugs.freedesktop.org/attachment.cgi?id=57700
Updated Xorg.log from pre-release Ubuntu 12.04 setup

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

[Bug 27184] Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably

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

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

--- Comment #23 from tomi.orava at ncircle.nullnet.fi 2012-02-26 23:29:12 PST 
---
I just updated to latest Ubuntu 12.04 pre-release and the combination ATI 5450
together with BenQ LCD monitor doesn't work any better than before.
The system is still running with the kernel.org 3.3-rc3+ kernel from git.

I wonder what kind of information would help in figuring out why this
particular combination doesn't wake up from standby ?


Below is some info & logs about the current configuration.

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar
PRO [Radeon HD 5450] (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 0366
Flags: bus master, fast devsel, latency 0, IRQ 47
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at fdec (64-bit, non-prefetchable) [size=128K]
I/O ports at ac00 [size=256]
Expansion ROM at fdea [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010

Capabilities: [150] Advanced Error Reporting
Kernel driver in use: radeon
Kernel modules: radeon

- xorg-server 2:1.11.4-0ubuntu4

[   105.589] (II) Module radeon: vendor="X.Org Foundation"
[   105.589]compiled for 1.11.3, module version = 6.14.99
[   105.589]Module class: X.Org Video Driver
[   105.589]ABI class: X.Org Video Driver, version 11.0

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

[Bug 42716] Boot failure with KMS enabled (radeon)

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

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


Robby Workman  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Comment #2 from Robby Workman   2012-02-27 04:05:44 ---
I'm marking this as invalid.  The machine I was seeing this on has died, and it
started with all of the usb ports going bad.  From there, other parts stopped
working over the course of several days.  I suspect a bad motherboard that was
introducing faults, and 3.1.x was somehow working around them better than
3.2.x.  Who knows?  :/

-- 
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 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

--- Comment #5 from Vladi  2012-02-26 18:41:23 PST ---
also tried reverting that commit from master. same result black screen on both
KMS and Xorg

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

[Bug 42727] radeon KMS with CRT TV

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

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





--- Comment #9 from Egor Y. Egorov   2012-02-27 02:13:36 
---
Yes. With Windosw 7 and on linux without KMS all right.

-- 
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 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

Vladi  changed:

   What|Removed |Added

  Attachment #57690|application/octet-stream|text/plain
  mime type||

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

[Bug 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

Vladi  changed:

   What|Removed |Added

  Attachment #57689|application/octet-stream|text/plain
  mime type||

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

[Bug 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

Vladi  changed:

   What|Removed |Added

  Attachment #57688|application/octet-stream|text/plain
  mime type||

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

[Bug 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

--- Comment #4 from Vladi  2012-02-26 17:39:33 PST ---
the commit i got from git bisect was deduced from an working Xorg setup. There
was an point where the KMS was working but Xorg was not untill the the commit i
mentioned. The errors in dmesg while KMS was fine and Xorg still not working
were:
[   88.579198] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[   88.579733] radeon :01:05.0: r600_check_texture_resource:1338 texture
invalid format 26

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

[Bug 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

--- Comment #3 from Vladi  2012-02-26 17:31:26 PST ---
Created attachment 57690
  --> https://bugs.freedesktop.org/attachment.cgi?id=57690
dmesg for working 2.6 kernel setup

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

[Bug 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

--- Comment #2 from Vladi  2012-02-26 17:30:34 PST ---
Created attachment 57689
  --> https://bugs.freedesktop.org/attachment.cgi?id=57689
dmesg for non working setup on kernel 3.3

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

[Bug 46660] Xorg & KMS go to black screen after linux version 2.6.39

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

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

--- Comment #1 from Vladi  2012-02-26 17:29:54 PST ---
Created attachment 57688
  --> https://bugs.freedesktop.org/attachment.cgi?id=57688
Xorg log for working setup

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

[Bug 46660] New: Xorg & KMS go to black screen after linux version 2.6.39

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

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

 Bug #: 46660
   Summary: Xorg & KMS go to black screen after linux version
2.6.39
Classification: Unclassified
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vladi at aresgate.net


Created attachment 57687
  --> https://bugs.freedesktop.org/attachment.cgi?id=57687
Xorg config constant while doing the bisect.

Hi,

Getting an black screen after panasonic viera tc-p42x1. 

after doing an git bisect good v2.6.39 on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

i come to this:

fe6f0bd03d697835e76dd18d232ba476c65b8282 is the first bad commit
commit fe6f0bd03d697835e76dd18d232ba476c65b8282
Author: Marek Ol??k 
Date:   Sat May 7 01:09:57 2011 +0200

drm/radeon/kms: add missing Evergreen texture formats to the CS parser

BC6 and BC7 are described in ARB_texture_compression_bptc.

No idea what FMT_32_AS_32_32_32_32 is good for.

Signed-off-by: Marek Ol??k 
Signed-off-by: Dave Airlie 

:04 04 bd72080004eca34dd6c17a3111d76f1b515f5e8d
ea46d48c05fb870991f72f0d9e2ebd936e4214aa Mdrivers

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

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

[bugzilla-daemon]

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

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

   What|Removed |Added

 AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
  QAContact|xorg-t...@lists.x.org   |
Product|xorg|Mesa
Version|unspecified |7.11
  Component|Driver/Radeon   |Drivers/Gallium/r600

--- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-02-27 01:01:02 PST 
---
Could be bug 38173 — does Mesa 8.0.1 or newer work better?

-- 
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 42716] Boot failure with KMS enabled (radeon)

[bugzilla-daemon]

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


Paul Menzel paulepan...@users.sourceforge.net changed:

   What|Removed |Added

 CC||paulepanter@users.sourcefor
   ||ge.net




--- Comment #3 from Paul Menzel paulepan...@users.sourceforge.net  2012-02-27 
09:40:14 ---
(In reply to comment #0)

[…]

 Any idea what's going on here?  I don't have the option to attach a serial
 console, for what that's worth, so that aside, any suggestions for further
 debugging?

Next time you can try netconsole. Although it has to be loaded before the
radeon module. I guess a way to come around that issue is to build the module
for the network card into the Linux kernel.

Additionally you could have started using a standard driver like vesafb(?) and
then load the radeon module manually after the system booted.

Thanks and good luck with your new system.

[1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt

-- 
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 46660] Xorg KMS go to black screen after linux version 2.6.39

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-02-27 01:52:22 PST 
---
(In reply to comment #4)
 [   88.579198] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [   88.579733] radeon :01:05.0: r600_check_texture_resource:1338 texture
 invalid format 26

It looks like the commit you bisected to was the one which fixed this problem,
not the one that caused the black screen.

You should probably ignore X for the bisect, and just call any kernel that
lights up the monitor good, otherwise bad.

-- 
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: [Bug 46660] New: Xorg KMS go to black screen after linux version 2.6.39

[Alexander Konotop]

В Mon, 27 Feb 2012 01:29:03 +
bugzilla-dae...@freedesktop.org пишет:

 https://bugs.freedesktop.org/show_bug.cgi?id=46660
 
  Bug #: 46660
Summary: Xorg  KMS go to black screen after linux version
 2.6.39
 Classification: Unclassified
Product: DRI
Version: XOrg CVS
   Platform: x86-64 (AMD64)
 OS/Version: Linux (All)
 Status: NEW
   Severity: major
   Priority: medium
  Component: DRM/Radeon
 AssignedTo: dri-devel@lists.freedesktop.org
 ReportedBy: vl...@aresgate.net
 
 
 Created attachment 57687
   -- https://bugs.freedesktop.org/attachment.cgi?id=57687
 Xorg config constant while doing the bisect.
 
 Hi,
 
 Getting an black screen after panasonic viera tc-p42x1. 
 
 after doing an git bisect good v2.6.39 on
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 i come to this:
 
 fe6f0bd03d697835e76dd18d232ba476c65b8282 is the first bad commit
 commit fe6f0bd03d697835e76dd18d232ba476c65b8282
 Author: Marek Olšák mar...@gmail.com
 Date:   Sat May 7 01:09:57 2011 +0200
 
 drm/radeon/kms: add missing Evergreen texture formats to the CS
 parser
 
 BC6 and BC7 are described in ARB_texture_compression_bptc.
 
 No idea what FMT_32_AS_32_32_32_32 is good for.
 
 Signed-off-by: Marek Olšák mar...@gmail.com
 Signed-off-by: Dave Airlie airl...@redhat.com
 
 :04 04 bd72080004eca34dd6c17a3111d76f1b515f5e8d
 ea46d48c05fb870991f72f0d9e2ebd936e4214aa Mdrivers
 

Can it be related to this bug?
https://bugs.freedesktop.org/show_bug.cgi?id=41569

If yes - it's fixed in latest kernels (somewhere near 3.2.5 - I'm not
sure)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

[bugzilla-daemon]

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

--- Comment #7 from mikey abc.mi...@googlemail.com 2012-02-27 05:36:22 PST ---
Heaven does not work at all with Mesa 8.0.1. See attached logs, tested with
Fedora 17.

-- 
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 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

[bugzilla-daemon]

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

--- Comment #8 from mikey abc.mi...@googlemail.com 2012-02-27 05:37:58 PST ---
Created attachment 57714
  -- https://bugs.freedesktop.org/attachment.cgi?id=57714
Heaven Ouput - Fedora 17 Alpha with Mesa 8.0.1

-- 
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 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

[bugzilla-daemon]

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

--- Comment #9 from mikey abc.mi...@googlemail.com 2012-02-27 05:38:42 PST ---
Created attachment 57715
  -- https://bugs.freedesktop.org/attachment.cgi?id=57715
glxinfo - Fedora 17 Alpha with Mesa 8.0.1

-- 
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 5/7] drm/vgem: prime export support

[Tomasz Stanislawski]

Hi Ben,
Please refer to comments below.

On 02/22/2012 08:29 PM, Ben Widawsky wrote:

dma-buf export implementation. Heavily influenced by Dave Airlie's proof
of concept work.

Cc: Daniel Vetterdaniel.vet...@ffwll.ch
Cc: Dave Airlieairl...@redhat.com
Signed-off-by: Ben Widawskyb...@bwidawsk.net
---
  drivers/gpu/drm/vgem/Makefile   |2 +-
  drivers/gpu/drm/vgem/vgem_dma_buf.c |  128 +++
  drivers/gpu/drm/vgem/vgem_drv.c |6 ++
  drivers/gpu/drm/vgem/vgem_drv.h |7 ++
  4 files changed, 142 insertions(+), 1 deletions(-)
  create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c


[snip]

+
+int vgem_prime_to_fd(struct drm_device *dev, struct drm_file *file,
+uint32_t handle, int *prime_fd)
+{
+   struct drm_vgem_file_private *file_priv = file-driver_priv;
+   struct drm_vgem_gem_object *obj;
+   int ret;
+
+   DRM_DEBUG_PRIME(Request fd for handle %d\n, handle);
+
+   obj = to_vgem_bo(drm_gem_object_lookup(dev, file, handle));
+   if (!obj)
+   return -EBADF;
+
+   /* This means a user has already called get_fd on this */
+   if (obj-base.prime_fd != -1) {
+   DRM_DEBUG_PRIME(User requested a previously exported buffer 
+   %d %d\n, handle, obj-base.prime_fd);
+   drm_gem_object_unreference(obj-base);
+   goto out_fd;


IMO, it is not safe to cache a number of file descriptor. This number 
may unexpectedly become invalid introducing a bug. Please refer to the 
scenario:

- application possess a GEM buffer called A
- call DRM_IOCTL_PRIME_HANDLE_TO_FD on A to obtain a file descriptor fd_A
- application calls fd_B = dup(fd_A). Now both fd_A and fd_B point to 
the same DMABUF instance.
- application calls close(fd_A), now fd_A is no longer a valid file 
descriptor
- application tries to export the buffer again and calls ioctl 
DRM_IOCTL_PRIME_HANDLE_TO_FD on GEM buffer. The field obj-base.prime_fd 
is already set to fd_A so value fd_A is returned to userspace. Notice 
that this is a bug because fd_A is no longer valid.


I think that field prime_fd should be removed because it is too 
unreliable. The driver should call dma_buf_fd every time when the buffer 
is exported.



+   }
+
+   /* Make a dma buf out of our vgem object */
+   obj-base.export_dma_buf = dma_buf_export(obj,vgem_dmabuf_ops,
+ obj-base.size,
+ VGEM_FD_PERMS);
+   if (IS_ERR(obj-base.export_dma_buf)) {
+   DRM_DEBUG_PRIME(export fail\n);
+   return PTR_ERR(obj-base.export_dma_buf);
+   } else
+   obj-base.prime_fd = dma_buf_fd(obj-base.export_dma_buf);
+
+   mutex_lock(dev-prime_mutex);
+   ret = drm_prime_insert_fd_handle_mapping(file_priv-prime,
+obj-base.export_dma_buf,
+handle);
+   WARN_ON(ret);
+   ret = drm_prime_add_dma_buf(dev,obj-base);
+   mutex_unlock(dev-prime_mutex);
+   if (ret)
+   return ret;
+
+out_fd:
+   *prime_fd = obj-base.prime_fd;
+
+   return 0;
+}
+


Regards,
Tomasz Stanislawski

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

[Bug 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

[bugzilla-daemon]

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

--- Comment #10 from mikey abc.mi...@googlemail.com 2012-02-27 05:48:37 PST 
---
Created attachment 57716
  -- https://bugs.freedesktop.org/attachment.cgi?id=57716
Xorg.0.log - Fedora 17 Alpha with Mesa 8.0.1

-- 
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 42727] radeon KMS with CRT TV

[bugzilla-daemon]

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





--- Comment #10 from Alex Deucher alexdeuc...@gmail.com  2012-02-27 13:54:19 
---
Please grab radeonreg (http://cgit.freedesktop.org/~airlied/radeontool/) and
dump the display registers with KMS and without KMS (as root).

./radeonreg regs avivo  working.regs

and

./radeonreg regs avivo  broken.regs

And attach the outputs here.

-- 
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 46654] Unigine Heaven benchmark only renders black on Radeon 6950 with radeon driver

[bugzilla-daemon]

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

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

   What|Removed |Added

  Attachment #57716|application/octet-stream|text/plain
  mime type||

-- 
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 27184] Radeon, KMS, 6.12.99: Sleeping screen doesn't wake up reliably

[bugzilla-daemon]

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

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

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

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

[Bug 42727] radeon KMS with CRT TV

[bugzilla-daemon]

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





--- Comment #11 from Egor Y. Egorov egorov_e...@bk.ru  2012-02-27 14:26:05 ---
Created an attachment (id=72484)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=72484)
without kms

-- 
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 42727] radeon KMS with CRT TV

[bugzilla-daemon]

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





--- Comment #12 from Egor Y. Egorov egorov_e...@bk.ru  2012-02-27 14:26:32 ---
Created an attachment (id=72485)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=72485)
with kms

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

Re: [KORG]Help: how to submit a kernel driver to kernel.org

[Dave Airlie]

 I’m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai
 Office. We have developed a kernel driver for all our graphics chips. We
 really want to know how to submit out driver to kernel.org. Would you please
 help to find the appropriate maintainer and the procedure for how to submit
 the driver to kernel.org. Thank you very much.


http://kernel.org/doc/Documentation/SubmittingDrivers

Please see this file, and then generally you need to publish the
patches on this list, in a reviewable form.

That would mean splitting up the driver into chunks that we can
absorb, along with a detailed email
about what hardware, features and userspace interface the driver provides.

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

[Bug 42727] radeon KMS with CRT TV

[bugzilla-daemon]

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





--- Comment #13 from Alex Deucher alexdeuc...@gmail.com  2012-02-27 15:31:08 
---
The only difference seems to be which crtc is driving the TV.  Can you try
booting with only the DVI port connected, and then connecting the TV later once
your desktop is up with both KMS and UMS?

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

Re: [PATCH 5/7] drm/vgem: prime export support

[Tomasz Stanislawski]

Hi Ben and Sumit,

Please refer to comments below:

On 02/22/2012 08:29 PM, Ben Widawsky wrote:

dma-buf export implementation. Heavily influenced by Dave Airlie's proof
of concept work.

Cc: Daniel Vetterdaniel.vet...@ffwll.ch
Cc: Dave Airlieairl...@redhat.com
Signed-off-by: Ben Widawskyb...@bwidawsk.net
---
  drivers/gpu/drm/vgem/Makefile   |2 +-
  drivers/gpu/drm/vgem/vgem_dma_buf.c |  128 +++
  drivers/gpu/drm/vgem/vgem_drv.c |6 ++
  drivers/gpu/drm/vgem/vgem_drv.h |7 ++
  4 files changed, 142 insertions(+), 1 deletions(-)
  create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c



[snip]


+struct sg_table *vgem_gem_map_dma_buf(struct dma_buf_attachment *attachment,
+  enum dma_data_direction dir)
+{
+   struct drm_vgem_gem_object *obj = attachment-dmabuf-priv;
+   struct sg_table *sg;
+   int ret;
+
+   ret = vgem_gem_get_pages(obj);
+   if (ret) {
+   vgem_gem_put_pages(obj);


is it safe to call vgem_gem_put_pages if vgem_gem_get_pages failed (I 
mean ret  0 was returned) ?



+   return NULL;
+   }
+
+   BUG_ON(obj-pages == NULL);
+
+   sg = drm_prime_pages_to_sg(obj-pages, obj-base.size / PAGE_SIZE);


if drm_prime_pages_to_sg fails then you should call vgem_gem_put_pages 
for cleanup.



+   return sg;
+}


The documentation of DMABUF says fallowing words about map_dma_buf callback.

It is one of the buffer operations that must be implemented by the 
exporter. It should return the sg_table containing scatterlist for this 
buffer, mapped into caller's address space.


The scatterlist returned by drm_prime_pages_to_sg is not mapped to any 
device. The map_dma_buf callback should call dma_map_sg for caller 
device, which is attachment-dev. Otherwise the implementation is not 
consistent with the DMABUF spec.


I think that it should be chosen to change implementation in map_dma_buf 
in DRM drivers or to drop mentioned sentence from the DMABUF spec.


I bear to the second solution because IMO there is no reliable way of 
mapping a scatterlist to importer device by an exporter. The dma_map_sg 
could be used but not all drivers makes use of DMA framework.


Sumit, what is your opinion about it?


+
+void vgem_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
+   struct sg_table *sg)
+{
+   sg_free_table(sg);
+   kfree(sg);
+}
+
+void vgem_gem_release(struct dma_buf *buf)
+{
+   struct drm_vgem_gem_object *obj = buf-priv;
+
+   BUG_ON(buf != obj-base.export_dma_buf);
+
+   obj-base.prime_fd = -1;
+   obj-base.export_dma_buf = NULL;
+   drm_gem_object_unreference_unlocked(obj-base);
+}
+
+struct dma_buf_ops vgem_dmabuf_ops = {
+   .map_dma_buf = vgem_gem_map_dma_buf,
+   .unmap_dma_buf = vgem_gem_unmap_dma_buf,
+   .release = vgem_gem_release
+};
+


Regards,
Tomasz Stanislawski


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

Re: Flickering with page-flipping on Acer Iconia W500 (AMD C-50 APU)

[Felix Kuehling]

On 12-02-24 11:38 PM, Mario Kleiner wrote:
 On Feb 24, 2012, at 10:20 PM, Felix Kuehling wrote:

 On 12-02-22 11:20 AM, Felix Kuehling wrote:
 On 12-02-21 07:49 PM, Mario Kleiner wrote:
 On 02/21/2012 09:07 PM, Alex Deucher wrote:
 [snip]
 The fix looks ok to me.  Mario any thoughts?

 Reviewed-by: Alex Deucheralexdeuc...@gmail.com

 Hi,

 the fix looks ok to me for that device, but could we make it
 conditional on the AMD C-50 APU and similar pieces? It is the right
 thing to do for that gpu, but for regular desktop gpus it is too
 pessimistic if it defers the pageflip timestamping and completion
 event for an already completed flip:

 1. Makes the timestamps 1 refresh too late, causing timing sensitive
 software like mine to detect false positives -- reporting skipped
 frames were there weren't any. Not as bad as missing a really skipped
 frame, but still not great.
 Agreed. I was going to perform some more experiments on other hardware
 to determine what the right threshold is for different hardware
 generations. I hope I'll get to that this week.

 I have a final version of my patch including an explanation of the
 observations it's based on (attached). It's against current drm-next
 from git://people.freedesktop.org/~airlied/linux.


 The idea of the current logic was that it happened that the
 update_pending bit isn't read back as zero at the end of the page_flip
 programming function, immediately after clearing the graphics hardware
 update_lock, e.g., maybe because there is some delay between clearing
 that register and the double buffering taking place. But according to
 the specs, if update_pending is high, ie., the hw has accepted the
 request for a page flip, it will complete as long as that request
 still happened within the vblank. So on a return from the page_flip
 function with update_pending == 1 we check if we are still inside the
 vblank area, ie., if the hw will certainly complete the double
 buffering within the current vblank, because the request was made in
 time.

 I did all my original testing of these bits with avivo hw (rv530,
 r600) and with one radeon hd 5850, so i'm a bit surprised if the avivo
 path would unconditionally need this adjustment. Could it be that the
 observed accuracy of update_pending depends on the rest of the hw,
 e.g., bus or processor speed, or bus activity? My test machines were a
 MacBookPro with Core2Duo 2.3 Ghz for rv530 and a rather old AMD
 Athlon-64 PC for r600.

I used a few different systems:

Brazos reference board for Brazos (E-350)
Iconia Tab W500 (C-50)
PhenomII X4 for most of the discrete cards
Athlon64 X2 for RS690

The results I got were consistent across all those systems. The only
differences I saw between different generations of Avivo-based hardware
were about the exact timing of the threshold when I would start seeing
flickering. On R5xx and R6xx it would start flickering at -3. On newer
hardware at -4 (I didn't test on R7xx).


 I'm worried that your observed reliability of update_pending on =
 AVIVO asics could be an artifact of the specific computer hw you used
 and that this doesn't generalize on older or different hw.

Given the number of different ASICs and systems, I think that's
unlikely. It's more likely that this depends on the exact mode timings.
I was running most of my experiments with a 19 DFP 1280x1024 at 60Hz,
connected by DVI if available, or VGA on some of the IGPs.

It's possible that different mode timings would result in a slightly
different threshold.

 If it doesn't generalize then the patch could defer a lot of perfectly
 good pageflips by 1 frame, screwing the timestamps and reducing
 framerate.

I understand your concern. But given my observations, the current
implementation potentially produces much more annoying artefacts.


 Here is what the rv630 register programming guide says about the
 double-buffering of the surface base address registers:

 D1GRPH_SURFACE_UPDATE_PENDING: the double buffering occurs in
 vertical retrace when D1GRPH_SURFACE_UPDATE_PENDING = 1 and
 D1GRPH_UPDATE_LOCK = 0 and V_UPDATE = 1.

As far as I can tell, D1GRPH_SURFACE_UPDATE_PENDING will only be 1, if
the page flip is initiated while outside the vertical retrace. The the
actual page flip will occur when V_UPDATE changes to 1, that is, when
the next vertical retrace occurs. So if we read
D1GRPH_SURFACE_UPDATE_PENDING after initiating a page flip, it implies
that we're currently not in a vertical retrace.


 D1CRTC_V_UPDATE: Current vertical position ... 1 =  within the
 V_UPDATE region (between end of vertical active display and start_line)

 For us that would mean the threshold for deferred flip completion
 would need to be whatever that mentioned start_line is, and for the
 tested avivo hw, start_line used to be == start of active scanout, so
 the threshold of zero made sense.

In my experiments the start_line seemed to be between -4 and -2. On no
ASIC did I observe a start_line == 0.


 Alex: I don't know where start_line is 

[drm-next] drm/radeon/kms: use asic callback for mc idle

[alexdeucher]

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

Switch all the asic specific mc idle calls to use
the asic callback.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/evergreen.c |6 +++---
 drivers/gpu/drm/radeon/ni.c|3 +--
 drivers/gpu/drm/radeon/r100.c  |2 +-
 drivers/gpu/drm/radeon/r300.c  |4 ++--
 drivers/gpu/drm/radeon/r520.c  |4 ++--
 drivers/gpu/drm/radeon/r600.c  |7 +++
 drivers/gpu/drm/radeon/rs400.c |4 ++--
 drivers/gpu/drm/radeon/rs600.c |5 ++---
 drivers/gpu/drm/radeon/rs690.c |4 ++--
 drivers/gpu/drm/radeon/rv515.c |5 ++---
 drivers/gpu/drm/radeon/rv770.c |4 ++--
 11 files changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 758f04b..755a2a9 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1270,7 +1270,7 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
 
evergreen_mc_stop(rdev, save);
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
/* Lockout access through VGA aperture*/
@@ -1318,7 +1318,7 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
evergreen_mc_resume(rdev, save);
@@ -2425,7 +2425,7 @@ static int evergreen_gpu_soft_reset(struct radeon_device 
*rdev)
dev_info(rdev-dev,   SRBM_STATUS=0x%08X\n,
RREG32(SRBM_STATUS));
evergreen_mc_stop(rdev, save);
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
/* Disable CP parsing/prefetching */
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 160799c..92f5eec 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -36,7 +36,6 @@
 
 extern void evergreen_mc_stop(struct radeon_device *rdev, struct 
evergreen_mc_save *save);
 extern void evergreen_mc_resume(struct radeon_device *rdev, struct 
evergreen_mc_save *save);
-extern int evergreen_mc_wait_for_idle(struct radeon_device *rdev);
 extern void evergreen_mc_program(struct radeon_device *rdev);
 extern void evergreen_irq_suspend(struct radeon_device *rdev);
 extern int evergreen_mc_init(struct radeon_device *rdev);
@@ -1385,7 +1384,7 @@ static int cayman_gpu_soft_reset(struct radeon_device 
*rdev)
 RREG32(0x14DC));
 
evergreen_mc_stop(rdev, save);
-   if (evergreen_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
dev_warn(rdev-dev, Wait for MC idle timedout !\n);
}
/* Disable CP parsing/prefetching */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 42ae955..6dd7cf8 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3882,7 +3882,7 @@ static void r100_mc_program(struct radeon_device *rdev)
WREG32(R_00015C_AGP_BASE_2, 0);
}
/* Wait for mc idle */
-   if (r100_mc_wait_for_idle(rdev))
+   if (radeon_mc_wait_for_idle(rdev))
dev_warn(rdev-dev, Wait for MC idle timeout.\n);
/* Program MC, should be a 32bits limited address space */
WREG32(R_000148_MC_FB_LOCATION,
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index fa14383..d10b6be 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -369,7 +369,7 @@ void r300_gpu_init(struct radeon_device *rdev)
printk(KERN_WARNING Failed to wait GUI idle while 
   programming pipes. Bad things might happen.\n);
}
-   if (r300_mc_wait_for_idle(rdev)) {
+   if (radeon_mc_wait_for_idle(rdev)) {
printk(KERN_WARNING Failed to wait MC idle while 
   programming pipes. Bad things might happen.\n);
}
@@ -1339,7 +1339,7 @@ void r300_mc_program(struct radeon_device *rdev)
WREG32(R_00015C_AGP_BASE_2, 0);
}
/* Wait for mc idle */
-   if (r300_mc_wait_for_idle(rdev))
+   if (radeon_mc_wait_for_idle(rdev))
DRM_INFO(Failed to wait MC idle before programming MC.\n);
/* Program MC, should be a 32bits limited address space */
WREG32(R_000148_MC_FB_LOCATION,
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index ebcc15b..0513360 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ 

[git pull] Intel drm fixes

[Jesse Barnes]

The following changes since commit
3ac0eb6d62fde0a60a6c5c61e562af1db8fbf712:

  drm/radeon/kms/atom: dpms bios scratch reg updates (2012-02-22 10:30:06 +)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel 
drm-intel-fixes

Alban Browaeys (1):
  drm/i915: Prevent a machine hang by checking crtc-active before loading 
lut

Dave Airlie (1):
  drm/i915: fix mode set on load pipe. (v2)

Eugeni Dodonov (1):
  drm/i915: fix operator precedence when enabling RC6p

Hai Lan (1):
  drm/i915: fix a sprite watermark computation to avoid divide by zero if 
xpos0

 drivers/gpu/drm/i915/intel_display.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)


-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [git pull] drm fixes

[Jesse Barnes]

On Thu, 23 Feb 2012 21:19:20 +0100
Torsten Kaiser just.for.l...@googlemail.com wrote:

 On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie airl...@linux.ie wrote:
  Eugeni Dodonov (4):
       drm/i915: gen7: implement rczunit workaround
       drm/i915: gen7: Implement an L3 caching workaround.
       drm/i915: gen7: work around a system hang on IVB
       drm/i915: do not enable RC6p on Sandy Bridge
 
 That last patch about RC6p looks wrong.
 
 It does:
  GEN6_RC_CTL_RC6_ENABLE |
   (IS_GEN7(dev_priv-dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0;
 But I think this was meant:
  GEN6_RC_CTL_RC6_ENABLE |
   ((IS_GEN7(dev_priv-dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 
 0);
 
 Or did I get the operator precedence wrong?

You're right, no cookie for Eugeni. :)  This would have prevented RC6
from ever getting enabled though, which should have the same effect as
the patch intended, though at the cost of higher power consumption.

Fix just sent to Dave anyway.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [git pull] drm fixes

[Eugeni Dodonov]

On Mon, Feb 27, 2012 at 13:09, Jesse Barnes jbar...@virtuousgeek.orgwrote:

 On Thu, 23 Feb 2012 21:19:20 +0100
 Torsten Kaiser just.for.l...@googlemail.com wrote:

  On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie airl...@linux.ie wrote:
   Eugeni Dodonov (4):
drm/i915: gen7: implement rczunit workaround
drm/i915: gen7: Implement an L3 caching workaround.
drm/i915: gen7: work around a system hang on IVB
drm/i915: do not enable RC6p on Sandy Bridge
 
  That last patch about RC6p looks wrong.
 
  It does:
   GEN6_RC_CTL_RC6_ENABLE |
(IS_GEN7(dev_priv-dev)) ? GEN6_RC_CTL_RC6p_ENABLE
 : 0;
  But I think this was meant:
   GEN6_RC_CTL_RC6_ENABLE |
((IS_GEN7(dev_priv-dev)) ?
 GEN6_RC_CTL_RC6p_ENABLE : 0);
 
  Or did I get the operator precedence wrong?

 You're right, no cookie for Eugeni. :)  This would have prevented RC6
 from ever getting enabled though, which should have the same effect as
 the patch intended, though at the cost of higher power consumption.


Actually, no, it got RC6p enabled - so it got to have all the power savings
of RC6 plus some additional ones in the range of 0.1W, but it also resulted
in the very same problem as before, when both RC6 and RC6p were enabled.

So, from what we've seen with
https://wiki.ubuntu.com/Kernel/PowerManagementRC6, the graphics corruptions
do only happen when RC6p is enabled (either together with RC6, or
individually, on its own). If we have only RC6, all the issues are gone so
far.

So this bad patch had its use after all - it served to finally isolate and
prove that the i915_enable_rc6-related issues are caused directly by RC6p.

-- 
Eugeni Dodonov
 http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: give better user feedback if a VM CS fails

[alexdeucher]

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

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon_cs.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 9b4124e..f7ee2f8 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
}
r = radeon_ring_ib_parse(rdev, parser-ring, parser-ib);
if (r) {
+   DRM_ERROR(Invalid VM CS\n);
return r;
}
 
-- 
1.7.7.5

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

Re: [git pull] drm fixes

[Jesse Barnes]

On Mon, 27 Feb 2012 13:33:53 -0300
Eugeni Dodonov eug...@dodonov.net wrote:

 On Mon, Feb 27, 2012 at 13:09, Jesse Barnes jbar...@virtuousgeek.orgwrote:
 
  On Thu, 23 Feb 2012 21:19:20 +0100
  Torsten Kaiser just.for.l...@googlemail.com wrote:
 
   On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie airl...@linux.ie wrote:
Eugeni Dodonov (4):
 drm/i915: gen7: implement rczunit workaround
 drm/i915: gen7: Implement an L3 caching workaround.
 drm/i915: gen7: work around a system hang on IVB
 drm/i915: do not enable RC6p on Sandy Bridge
  
   That last patch about RC6p looks wrong.
  
   It does:
GEN6_RC_CTL_RC6_ENABLE |
 (IS_GEN7(dev_priv-dev)) ? GEN6_RC_CTL_RC6p_ENABLE
  : 0;
   But I think this was meant:
GEN6_RC_CTL_RC6_ENABLE |
 ((IS_GEN7(dev_priv-dev)) ?
  GEN6_RC_CTL_RC6p_ENABLE : 0);
  
   Or did I get the operator precedence wrong?
 
  You're right, no cookie for Eugeni. :)  This would have prevented RC6
  from ever getting enabled though, which should have the same effect as
  the patch intended, though at the cost of higher power consumption.
 
 
 Actually, no, it got RC6p enabled - so it got to have all the power savings
 of RC6 plus some additional ones in the range of 0.1W, but it also resulted
 in the very same problem as before, when both RC6 and RC6p were enabled.
 
 So, from what we've seen with
 https://wiki.ubuntu.com/Kernel/PowerManagementRC6, the graphics corruptions
 do only happen when RC6p is enabled (either together with RC6, or
 individually, on its own). If we have only RC6, all the issues are gone so
 far.
 
 So this bad patch had its use after all - it served to finally isolate and
 prove that the i915_enable_rc6-related issues are caused directly by RC6p.

Oh you're right; I had the bit positions mixed up...  I thought the
higher level bit toggled all RC6 functionality, but that's kept
separate from this.

-- 
Jesse Barnes, Intel Open Source Technology Center


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

Re: [git pull] Intel drm fixes

[Jesse Barnes]

On Mon, 27 Feb 2012 08:08:13 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:

 The following changes since commit
 3ac0eb6d62fde0a60a6c5c61e562af1db8fbf712:
 
   drm/radeon/kms/atom: dpms bios scratch reg updates (2012-02-22 10:30:06 
 +)
 
 are available in the git repository at:
   git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel 
 drm-intel-fixes
 
 Alban Browaeys (1):
   drm/i915: Prevent a machine hang by checking crtc-active before 
 loading lut
 
 Dave Airlie (1):
   drm/i915: fix mode set on load pipe. (v2)
 
 Eugeni Dodonov (1):
   drm/i915: fix operator precedence when enabling RC6p
 
 Hai Lan (1):
   drm/i915: fix a sprite watermark computation to avoid divide by zero if 
 xpos0

Snuck one more in here that I promised earlier:


commit 5d031e5b633d910f35e6e0abce94d9d842390006
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Wed Feb 8 13:34:13 2012 +

drm/i915: Remove use of the autoreported ringbuffer HEAD position

in case you haven't pulled yet.

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


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

Re: [PATCH] drm/i915: error_buffer-ring should be signed

[Daniel Vetter]

On Thu, Feb 16, 2012 at 02:16:27PM +0300, Dan Carpenter wrote:
 On Thu, Feb 16, 2012 at 11:03:29AM +0100, Daniel Vetter wrote:
  gcc seems to get uber-anal recently about these things.
  
 
 Sorry, I should have said that it's not a gcc warning, it's a
 smatch thing.  But also it's not uber-anal.  It's the exact level of
 anality which is required to make the == -1 test work.  You can
 compare unsigned int and longs to -1 and it works but for smaller
 types it doesn't.

I've picked this one here up for -next, thanks for your clarification
(added to the commit message in).
-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/radeon/kms: give better user feedback if a VM CS fails

[David Airlie]

 ---
  drivers/gpu/drm/radeon/radeon_cs.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 9b4124e..f7ee2f8 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct
 radeon_device *rdev,
   }
   r = radeon_ring_ib_parse(rdev, parser-ring, parser-ib);
   if (r) {
 + DRM_ERROR(Invalid VM CS\n);
   return r;

Isn't this user triggerable?

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

Re: [PATCH 2/7] drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo

[Daniel Vetter]

Hi Ben,

Can you ack this patch for merging through drm-intel-next? Imo that's the
easiest way to get it in (assuming you don't have any objections).

Thanks, Daniel

On Tue, Feb 14, 2012 at 10:37:20PM +0100, Daniel Vetter wrote:
 I'd like to export the corresponding functions from the i2c core
 so that I can use them in fallback bit-banging in i915.ko
 
 Cc: nouv...@lists.freedesktop.org
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/nouveau/nouveau_i2c.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.c 
 b/drivers/gpu/drm/nouveau/nouveau_i2c.c
 index 820ae7f..7a7e751 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_i2c.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_i2c.c
 @@ -242,7 +242,7 @@ i2c_addr(struct nouveau_i2c_chan *port, struct i2c_msg 
 *msg)
  }
  
  static int
 -i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
 +nouveau_i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
  {
   struct nouveau_i2c_chan *port = (struct nouveau_i2c_chan *)adap;
   struct i2c_msg *msg = msgs;
 @@ -272,14 +272,14 @@ i2c_bit_xfer(struct i2c_adapter *adap, struct i2c_msg 
 *msgs, int num)
  }
  
  static u32
 -i2c_bit_func(struct i2c_adapter *adap)
 +nouveau_i2c_bit_func(struct i2c_adapter *adap)
  {
   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
  }
  
  const struct i2c_algorithm i2c_bit_algo = {
 - .master_xfer = i2c_bit_xfer,
 - .functionality = i2c_bit_func
 + .master_xfer = nouveau_i2c_bit_xfer,
 + .functionality = nouveau_i2c_bit_func
  };
  
  static const uint32_t nv50_i2c_port[] = {
 -- 
 1.7.7.5
 

-- 
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/radeon/kms: give better user feedback if a VM CS fails

[Alex Deucher]

On Mon, Feb 27, 2012 at 12:24 PM, David Airlie airl...@redhat.com wrote:

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

 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 9b4124e..f7ee2f8 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct
 radeon_device *rdev,
       }
       r = radeon_ring_ib_parse(rdev, parser-ring, parser-ib);
       if (r) {
 +             DRM_ERROR(Invalid VM CS\n);
               return r;

 Isn't this user triggerable?

If they send a bad CS, sure.  It just brings the VM CS ioctl in line
with non-VM one which warns similarly.

Alex


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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: add dev_priv to intel_gmbus

[Eugeni Dodonov]

On Tue, Feb 14, 2012 at 19:37, Daniel Vetter daniel.vet...@ffwll.ch wrote:

 This way we can free up the bus-adaptor.algo_data pointer and make it
 available for use with the bitbanging fallback algo.

 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch


Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: i2c: unconditionally set up gpio fallback

[Daniel Vetter]

This way we can simplify the setup and teardown a bit.

Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.

Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change any more.

v2: Chris Wilson noticed that I've mixed up  and  ...

v3: Clarify an if block as suggested by Eugeni Dodonov.

Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h  |3 +-
 drivers/gpu/drm/i915/intel_i2c.c |   51 +++---
 2 files changed, 22 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14b6e94..31affc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -293,7 +293,8 @@ struct intel_fbc_work;
 
 struct intel_gmbus {
struct i2c_adapter adapter;
-   struct i2c_adapter *force_bit;
+   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/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 6eb68b7..44d1755 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -140,8 +140,8 @@ static void set_data(void *data, int state_high)
POSTING_READ(bus-gpio_reg);
 }
 
-static struct i2c_adapter *
-intel_gpio_create(struct intel_gmbus *bus, u32 pin)
+static bool
+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[] = {
@@ -157,7 +157,7 @@ intel_gpio_create(struct intel_gmbus *bus, u32 pin)
struct i2c_algo_bit_data *algo;
 
if (pin = ARRAY_SIZE(map_pin_to_reg) || !map_pin_to_reg[pin])
-   return NULL;
+   return false;
 
algo = bus-bit_algo;
 
@@ -174,12 +174,11 @@ intel_gpio_create(struct intel_gmbus *bus, u32 pin)
algo-timeout = usecs_to_jiffies(2200);
algo-data = bus;
 
-   return bus-adapter;
+   return true;
 }
 
 static int
 intel_i2c_quirk_xfer(struct intel_gmbus *bus,
-struct i2c_adapter *adapter,
 struct i2c_msg *msgs,
 int num)
 {
@@ -193,7 +192,7 @@ intel_i2c_quirk_xfer(struct intel_gmbus *bus,
set_clock(bus, 1);
udelay(I2C_RISEFALL_TIME);
 
-   ret = i2c_bit_xfer(adapter, msgs, num);
+   ret = i2c_bit_xfer(bus-adapter, msgs, num);
 
set_data(bus, 1);
set_clock(bus, 1);
@@ -216,7 +215,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
mutex_lock(dev_priv-gmbus_mutex);
 
if (bus-force_bit) {
-   ret = intel_i2c_quirk_xfer(bus, bus-force_bit, msgs, num);
+   ret = intel_i2c_quirk_xfer(bus, msgs, num);
goto out;
}
 
@@ -311,11 +310,12 @@ timeout:
I915_WRITE(GMBUS0 + reg_offset, 0);
 
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
-   bus-force_bit = intel_gpio_create(bus, bus-reg0  0xff);
-   if (!bus-force_bit)
-   ret = -ENOMEM;
-   else
-   ret = intel_i2c_quirk_xfer(bus, bus-force_bit, msgs, num);
+   if (!bus-has_gpio) {
+   ret = -EIO;
+   } else {
+   bus-force_bit = true;
+   ret = intel_i2c_quirk_xfer(bus, msgs, num);
+   }
 out:
mutex_unlock(dev_priv-gmbus_mutex);
return ret;
@@ -323,14 +323,8 @@ out:
 
 static u32 gmbus_func(struct i2c_adapter *adapter)
 {
-   struct intel_gmbus *bus = container_of(adapter,
-  struct intel_gmbus,
-  adapter);
-
-   if (bus-force_bit)
-   i2c_bit_func(bus-force_bit);
-
-   return (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
+   return i2c_bit_func(adapter) 
+   (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
/* I2C_FUNC_10BIT_ADDR | */
I2C_FUNC_SMBUS_READ_BLOCK_DATA |
I2C_FUNC_SMBUS_BLOCK_PROC_CALL);
@@ -388,8 +382,11 @@ int intel_setup_gmbus(struct drm_device *dev)
/* By default use a conservative clock rate */
bus-reg0 = i | GMBUS_RATE_100KHZ;
 
+   bus-has_gpio = intel_gpio_setup(bus, i);
+
/* XXX force bit banging until GMBUS is fully debugged */
-   bus-force_bit = intel_gpio_create(bus, i);
+   if (bus-has_gpio)
+   bus-force_bit = true;
}
 
intel_i2c_reset(dev_priv-dev);
@@ -417,16 +414,8 @@ void intel_gmbus_force_bit(struct i2c_adapter *adapter, 
bool force_bit)
 {
struct intel_gmbus *bus = to_intel_gmbus(adapter);
 
-   if (force_bit) {
-   if (bus-force_bit == NULL) {
-   bus-force_bit = intel_gpio_create(bus,
- 

Re: [PATCH] drm/i915: i2c: unconditionally set up gpio fallback

[Eugeni Dodonov]

On Mon, Feb 27, 2012 at 15:22, Daniel Vetter daniel.vet...@ffwll.ch wrote:

 This way we can simplify the setup and teardown a bit.

 Because we don't actually allocate anything anymore for the force_bit
 case, we can now convert that into a boolean.

 Also and the functionality supported by the bit-banging together with
 what gmbus can do, so that this doesn't randomly change any more.

 v2: Chris Wilson noticed that I've mixed up  and  ...

 v3: Clarify an if block as suggested by Eugeni Dodonov.

 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch


Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [mipsel+rs780e]Occasionally GPU lockup after resuming from suspend.

[Jerome Glisse]

On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
 在 2012年2月17日 下午5:27，Chen Jie ch...@lemote.com 写道：
  One good way to test gart is to go over GPU gart table and write a
  dword using the GPU at end of each page something like 0xCAFEDEAD
  or somevalue that is unlikely to be already set. And then go over
  all the page and check that GPU write succeed. Abusing the scratch
  register write back feature is the easiest way to try that.
  I'm planning to add a GART table check procedure when resume, which
  will go over GPU gart table:
  1. read(backup) a dword at end of each GPU page
  2. write a mark by GPU and check it
  3. restore the original dword
 Attachment validateGART.patch do the job:
 * It current only works for mips64 platform.
 * To use it, apply all_in_vram.patch first, which will allocate CP
 ring, ih, ib in VRAM and hard code no_wb=1.
 
 The gart test routine will be invoked in r600_resume. We've tried it,
 and find that when lockup happened the gart table was good before
 userspace restarting. The related dmesg follows:
 [ 1521.820312] [drm] r600_gart_table_validate(): Validate GART Table
 at 90004004, 32768 entries, Dummy
 Page[0x0e004000-0x0e007fff]
 [ 1522.019531] [drm] r600_gart_table_validate(): Sweep 32768
 entries(valid=8544, invalid=24224, total=32768).
 ...
 [ 1531.156250] PM: resume of devices complete after 9396.588 msecs
 [ 1532.152343] Restarting tasks ... done.
 [ 1544.468750] radeon :01:05.0: GPU lockup CP stall for more than 
 10003msec
 [ 1544.472656] [ cut here ]
 [ 1544.480468] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:243
 radeon_fence_wait+0x25c/0x314()
 [ 1544.488281] GPU lockup (waiting for 0x0002136B last fence id 0x0002136A)
 ...
 [ 1544.886718] radeon :01:05.0: Wait for MC idle timedout !
 [ 1545.046875] radeon :01:05.0: Wait for MC idle timedout !
 [ 1545.062500] radeon :01:05.0: WB disabled
 [ 1545.097656] [drm] ring test succeeded in 0 usecs
 [ 1545.105468] [drm] ib test succeeded in 0 usecs
 [ 1545.109375] [drm] Enabling audio support
 [ 1545.113281] [drm] r600_gart_table_validate(): Validate GART Table
 at 90004004, 32768 entries, Dummy
 Page[0x0e004000-0x0e007fff]
 [ 1545.125000] [drm:r600_gart_table_validate] *ERROR* Iter=0:
 unexpected value 0x745aaad1(expect 0xDEADBEEF)
 entry=0x0e008067, orignal=0x745aaad1
 ...
 /* System blocked here. */
 
 Any idea?

I know lockup are frustrating, my only idea is the memory controller
is lockup because of some failing pci - system ram transaction.

 
 BTW, we find the following in r600_pcie_gart_enable()
 (drivers/gpu/drm/radeon/r600.c):
 WREG32(VM_CONTEXT0_PROTECTION_FAULT_DEFAULT_ADDR,
 (u32)(rdev-dummy_page.addr  12));
 
 On our platform, PAGE_SIZE is 16K, does it have any problem?

No this should be handled properly.

 Also in radeon_gart_unbind() and radeon_gart_restore(), the logic
 should change to:
   for (j = 0; j  (PAGE_SIZE / RADEON_GPU_PAGE_SIZE); j++, t++) {
   radeon_gart_set_page(rdev, t, page_base);
 - page_base += RADEON_GPU_PAGE_SIZE;
 + if (page_base != rdev-dummy_page.addr)
 + page_base += RADEON_GPU_PAGE_SIZE;
   }
 ???

No need to do so, dummy page will be 16K too, so it's fine.

Cheers,
Jerome

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

Re: [mipsel+rs780e]Occasionally GPU lockup after resuming from suspend.

[Jerome Glisse]

On Mon, 2012-02-27 at 10:44 +0800, Chen Jie wrote:
 Hi,
 
 For this occasional GPU lockup when returns from STR/STD, I find
 followings(when the problem happens):
 
 The value of SRBM_STATUS is whether 0x20002040 or 0x20003040.
 Which means:
 * HI_RQ_PENDING(There is a HI/BIF request pending in the SRBM)
 * MCDW_BUSY(Memory Controller Block is Busy)
 * BIF_BUSY(Bus Interface is Busy)
 * MCDX_BUSY(Memory Controller Block is Busy) if is 0x20003040
 Are MCDW_BUSY and MCDX_BUSY two memory channels? What is the
 relationship among GART mapped memory, On-board video memory and MCDX,
 MCDW?
 
 CP_STAT: the CSF_RING_BUSY is always set.

Once the memory controller fails to do a pci transaction the CP
will be stuck. At least if ring is in system memory, if ring is
in vram CP might be stuck too because anyway everything goes
through the MC.

 
 There are many CP_PACKET2(0x8000) in CP ring(more than three hundreds). 
 e.g.
 r[131800]=0x00028000
 r[131801]=0xc0016800
 r[131802]=0x0140
 r[131803]=0x79c5
 r[131804]=0x304a
 r[131805] ... r[132143]=0x8000
 r[132144]=0x
 After the first reset, GPU will lockup again, this time, typically
 there are 320 dwords in CP ring -- with 319 CP_PACKET2 and 0xc0033d00
 in the end.
 Are these normal?
 
 BTW, is there any way for X to switch to NOACCEL mode when the problem
 happens? Thus users will have a chance to save their documents and
 then reboot machine.

I have been meaning to patch the ddx to fallback to sw after GPU lockup.
But this is useless in today world, where everything is composited ie
the screen is updated using the 3D driver for which there is no easy
way to suddenly migrate to  software rendering. I will still probably
do the ddx patch at one point.

Cheers,
Jerome

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

[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes

[bugzilla-daemon]

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

--- Comment #5 from Harald Judt h.j...@gmx.at 2012-02-27 11:34:39 PST ---
This problem is still present in 3.3-rc5 (vanilla and tuxonice).

 In fact, it's a 100% chance that the screen does not get black or
 the system freezes.

I have to falsify my previous assumption. It can also happen on the second,
third etc. try. But eventually, if you keep trying long enough, it will still
succeed to resume.

Anyone got an idea what could be wrong here or how to get more info?

-- 
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 46274] Reading from /sys/kernel/debug/dri/0/radeon_ring_cp* cause null-pointer dereference

[bugzilla-daemon]

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

--- Comment #3 from Florian Mickler flor...@mickler.org 2012-02-27 14:29:59 
PST ---
A patch referencing this bug report has been merged in Linux v3.3-rc5:

commit f0d14daa6906070ca044b86f483fdde7d81f5294
Author: Michel Dänzer michel.daen...@amd.com
Date:   Tue Feb 21 17:39:15 2012 +0100

drm/radeon: Only create additional ring debugfs files on Cayman or newer.

-- 
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 3/7] i2c: export bit-banging algo functions

[Jean Delvare]

Hi Daniel,

Sorry for the late reply.

On Tue, 14 Feb 2012 22:37:21 +0100, Daniel Vetter wrote:
 i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
 we need to be able to fall back to the bit-banging algo on gpio pins.
 
 The current code sets up a 2nd i2c controller for the same i2c bus using
 the bit-banging algo. This has a bunch of issues, the major one being
 that userspace can directly access this fallback i2c adaptor behind
 the drivers back.
 
 But we need to frob a few registers before and after using fallback
 gpio bit-banging, so this horribly fails.

You could use the pre_xfer and post_xfer hooks together with a shared
mutex to solve the problem. But I agree its much cleaner to expose a
single adapter in the first place.

If you need to hot-switch between hardware and bit-banged I2C, I suggest
that you lock the bus while doing so, to avoid switching while a
transaction is in progress. This can be achieved with
i2c_lock_adapter() and i2c_unlock_adapter().

 The new plan is to only set up one i2c adaptor and transparently fall
 back to bit-banging by directly calling the xfer function of the bit-
 banging algo in the i2c core.
 
 To make that possible, export the 2 i2c algo functions.
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/i2c/algos/i2c-algo-bit.c |   12 +++-
  include/linux/i2c-algo-bit.h |4 
  2 files changed, 11 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/i2c/algos/i2c-algo-bit.c 
 b/drivers/i2c/algos/i2c-algo-bit.c
 index 525c734..ec1651a 100644
 --- a/drivers/i2c/algos/i2c-algo-bit.c
 +++ b/drivers/i2c/algos/i2c-algo-bit.c
 @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap, 
 struct i2c_msg *msg)
   return 0;
  }
  
 -static int bit_xfer(struct i2c_adapter *i2c_adap,
 - struct i2c_msg msgs[], int num)
 +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
 +  struct i2c_msg msgs[], int num)
  {
   struct i2c_msg *pmsg;
   struct i2c_algo_bit_data *adap = i2c_adap-algo_data;
 @@ -598,21 +598,23 @@ bailout:
   adap-post_xfer(i2c_adap);
   return ret;
  }
 +EXPORT_SYMBOL(i2c_bit_xfer);
  
 -static u32 bit_func(struct i2c_adapter *adap)
 +u32 i2c_bit_func(struct i2c_adapter *adap)
  {
   return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
  I2C_FUNC_SMBUS_READ_BLOCK_DATA |
  I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
  I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
  }
 +EXPORT_SYMBOL(i2c_bit_func);
  
  
  /* -exported algorithm data: -   
 */
  
  static const struct i2c_algorithm i2c_bit_algo = {
 - .master_xfer= bit_xfer,
 - .functionality  = bit_func,
 + .master_xfer= i2c_bit_xfer,
 + .functionality  = i2c_bit_func,
  };
  
  /*
 diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
 index 4f98148..cdd6336 100644
 --- a/include/linux/i2c-algo-bit.h
 +++ b/include/linux/i2c-algo-bit.h
 @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
   int timeout;/* in jiffies */
  };
  
 +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
 +  struct i2c_msg msgs[], int num);
 +u32 i2c_bit_func(struct i2c_adapter *adap);
 +
  int i2c_bit_add_bus(struct i2c_adapter *);
  int i2c_bit_add_numbered_bus(struct i2c_adapter *);

I have no problem with this in the principle. In the details, I don't
understand why you don't simply export i2c_bit_algo? This is one fewer
export and should serve the same purpose - even allowing faster
initializations in some cases.

Looking a bit more to the i2c-algo-bit code, I also notice that
bypassing i2c_bit_add_bus() means you'll miss some of its features,
namely bus testing, default retries value and warning on non-compliant
buses. While none of these are mandatory, it may make sense to export a
new function i2c_bit_add_numbered_bus() which would call
__i2c_bit_add_bus() with no callback function. If you do that, you may
not have to export anything else.

I leave it up to you which way you want to implement it, all are fine
with me, and we can always change later if more use cases show up which
would work better with a different implementation.

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

Re: [PATCH 3/7] i2c: export bit-banging algo functions

[Daniel Vetter]

On Mon, Feb 27, 2012 at 11:20:40PM +0100, Jean Delvare wrote:
 Hi Daniel,
 
 Sorry for the late reply.
 
 On Tue, 14 Feb 2012 22:37:21 +0100, Daniel Vetter wrote:
  i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
  we need to be able to fall back to the bit-banging algo on gpio pins.
  
  The current code sets up a 2nd i2c controller for the same i2c bus using
  the bit-banging algo. This has a bunch of issues, the major one being
  that userspace can directly access this fallback i2c adaptor behind
  the drivers back.
  
  But we need to frob a few registers before and after using fallback
  gpio bit-banging, so this horribly fails.
 
 You could use the pre_xfer and post_xfer hooks together with a shared
 mutex to solve the problem. But I agree its much cleaner to expose a
 single adapter in the first place.

Yeah, I've seen these and I think we could use them. Still it's cleaner to
only expose one algo for a single bus.

 If you need to hot-switch between hardware and bit-banged I2C, I suggest
 that you lock the bus while doing so, to avoid switching while a
 transaction is in progress. This can be achieved with
 i2c_lock_adapter() and i2c_unlock_adapter().

The drm/i915 xfer function is currently protected by a single mutex
(because the hw i2c controller can only be used on one bus at a time). So
I think we're covered. Also we do the fallback in our xfer function when
we notice that things don't quite work as they should, so we actually want
to switch while a transfer is in progress. Dunno whether that's the best
approach, but the current code is structured like this.

  The new plan is to only set up one i2c adaptor and transparently fall
  back to bit-banging by directly calling the xfer function of the bit-
  banging algo in the i2c core.
  
  To make that possible, export the 2 i2c algo functions.
  
  Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/i2c/algos/i2c-algo-bit.c |   12 +++-
   include/linux/i2c-algo-bit.h |4 
   2 files changed, 11 insertions(+), 5 deletions(-)
  
  diff --git a/drivers/i2c/algos/i2c-algo-bit.c 
  b/drivers/i2c/algos/i2c-algo-bit.c
  index 525c734..ec1651a 100644
  --- a/drivers/i2c/algos/i2c-algo-bit.c
  +++ b/drivers/i2c/algos/i2c-algo-bit.c
  @@ -531,8 +531,8 @@ static int bit_doAddress(struct i2c_adapter *i2c_adap, 
  struct i2c_msg *msg)
  return 0;
   }
   
  -static int bit_xfer(struct i2c_adapter *i2c_adap,
  -   struct i2c_msg msgs[], int num)
  +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
  +struct i2c_msg msgs[], int num)
   {
  struct i2c_msg *pmsg;
  struct i2c_algo_bit_data *adap = i2c_adap-algo_data;
  @@ -598,21 +598,23 @@ bailout:
  adap-post_xfer(i2c_adap);
  return ret;
   }
  +EXPORT_SYMBOL(i2c_bit_xfer);
   
  -static u32 bit_func(struct i2c_adapter *adap)
  +u32 i2c_bit_func(struct i2c_adapter *adap)
   {
  return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
 I2C_FUNC_SMBUS_READ_BLOCK_DATA |
 I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
 I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
   }
  +EXPORT_SYMBOL(i2c_bit_func);
   
   
   /* -exported algorithm data: - 
  */
   
   static const struct i2c_algorithm i2c_bit_algo = {
  -   .master_xfer= bit_xfer,
  -   .functionality  = bit_func,
  +   .master_xfer= i2c_bit_xfer,
  +   .functionality  = i2c_bit_func,
   };
   
   /*
  diff --git a/include/linux/i2c-algo-bit.h b/include/linux/i2c-algo-bit.h
  index 4f98148..cdd6336 100644
  --- a/include/linux/i2c-algo-bit.h
  +++ b/include/linux/i2c-algo-bit.h
  @@ -47,6 +47,10 @@ struct i2c_algo_bit_data {
  int timeout;/* in jiffies */
   };
   
  +int i2c_bit_xfer(struct i2c_adapter *i2c_adap,
  +struct i2c_msg msgs[], int num);
  +u32 i2c_bit_func(struct i2c_adapter *adap);
  +
   int i2c_bit_add_bus(struct i2c_adapter *);
   int i2c_bit_add_numbered_bus(struct i2c_adapter *);
 
 I have no problem with this in the principle. In the details, I don't
 understand why you don't simply export i2c_bit_algo? This is one fewer
 export and should serve the same purpose - even allowing faster
 initializations in some cases.

I've figured that hunting for magic functions in a struct is a bit to
intransparent and hence exported the 2 functions I needed instead of the
struct. But if you prefer me to export the vtable I'll gladly do so - that
way I can drop a patch to rename some functions in drm/nouveau that
conflict with these here.

 Looking a bit more to the i2c-algo-bit code, I also notice that
 bypassing i2c_bit_add_bus() means you'll miss some of its features,
 namely bus testing, default retries value and warning on non-compliant
 buses. While none of these are mandatory, it may make sense to export a
 new function i2c_bit_add_numbered_bus() which would call
 __i2c_bit_add_bus() with no callback function. If you do that, you may
 not have to 

[PATCH] drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo

[Daniel Vetter]

I'd like to export the corresponding functions from the i2c core
so that I can use them in fallback bit-banging in i915.ko

v2: Adapt to new i2c export patch.

Cc: nouv...@lists.freedesktop.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/nouveau/nouveau_i2c.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.c 
b/drivers/gpu/drm/nouveau/nouveau_i2c.c
index 820ae7f..8f4f914 100644
--- a/drivers/gpu/drm/nouveau/nouveau_i2c.c
+++ b/drivers/gpu/drm/nouveau/nouveau_i2c.c
@@ -277,7 +277,7 @@ i2c_bit_func(struct i2c_adapter *adap)
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
 }
 
-const struct i2c_algorithm i2c_bit_algo = {
+const struct i2c_algorithm nouveau_i2c_bit_algo = {
.master_xfer = i2c_bit_xfer,
.functionality = i2c_bit_func
 };
@@ -384,12 +384,12 @@ nouveau_i2c_init(struct drm_device *dev)
case 0: /* NV04:NV50 */
port-drive = entry[0];
port-sense = entry[1];
-   port-adapter.algo = i2c_bit_algo;
+   port-adapter.algo = nouveau_i2c_bit_algo;
break;
case 4: /* NV4E */
port-drive = 0x600800 + entry[1];
port-sense = port-drive;
-   port-adapter.algo = i2c_bit_algo;
+   port-adapter.algo = nouveau_i2c_bit_algo;
break;
case 5: /* NV50- */
port-drive = entry[0]  0x0f;
@@ -402,7 +402,7 @@ nouveau_i2c_init(struct drm_device *dev)
port-drive = 0x00d014 + (port-drive * 0x20);
port-sense = port-drive;
}
-   port-adapter.algo = i2c_bit_algo;
+   port-adapter.algo = nouveau_i2c_bit_algo;
break;
case 6: /* NV50- DP AUX */
port-drive = entry[0];
-- 
1.7.7.5

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

[PATCH] drm/radeon/kms: fix radeon_dp_get_modes for LVDS bridges

[alexdeucher]

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

Need to call ExternalEncoderControl to set up DDC before
trying to get an EDID for all DP bridge chipsi (including
DP to LVDS).

Also remove redundant encoder assignment.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/radeon_connectors.c |   25 +
 1 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index e7cb3ab..8b3d8ed 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1117,13 +1117,23 @@ static int radeon_dp_get_modes(struct drm_connector 
*connector)
(connector-connector_type == DRM_MODE_CONNECTOR_LVDS)) {
struct drm_display_mode *mode;
 
-   if (!radeon_dig_connector-edp_on)
-   atombios_set_edp_panel_power(connector,
-
ATOM_TRANSMITTER_ACTION_POWER_ON);
-   ret = radeon_ddc_get_modes(radeon_connector);
-   if (!radeon_dig_connector-edp_on)
-   atombios_set_edp_panel_power(connector,
-
ATOM_TRANSMITTER_ACTION_POWER_OFF);
+   if (connector-connector_type == DRM_MODE_CONNECTOR_eDP) {
+   if (!radeon_dig_connector-edp_on)
+   atombios_set_edp_panel_power(connector,
+
ATOM_TRANSMITTER_ACTION_POWER_ON);
+   ret = radeon_ddc_get_modes(radeon_connector);
+   if (!radeon_dig_connector-edp_on)
+   atombios_set_edp_panel_power(connector,
+
ATOM_TRANSMITTER_ACTION_POWER_OFF);
+   } else {
+   /* need to setup ddc on the bridge */
+   if 
(radeon_connector_encoder_get_dp_bridge_encoder_id(connector) !=
+   ENCODER_OBJECT_ID_NONE) {
+   if (encoder)
+   
radeon_atom_ext_encoder_setup_ddc(encoder);
+   }
+   ret = radeon_ddc_get_modes(radeon_connector);
+   }
 
if (ret  0) {
if (encoder) {
@@ -1134,7 +1144,6 @@ static int radeon_dp_get_modes(struct drm_connector 
*connector)
return ret;
}
 
-   encoder = radeon_best_single_encoder(connector);
if (!encoder)
return 0;
 
-- 
1.7.7.5

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