[Bug 72621] X crash while video playback in web browsers with enabled rendering hardware acceleration

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

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

--- Comment #2 from russianneuromancer at ya.ru ---
For the record, with disabled hardware acceleration in web-browsers, I unable
to reproduce this crash yet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6e31015d/attachment.html>

[RFC 3/4] drm: exynos: add IELCD post processor

[Ajay kumar]

cfg = exynos_ielcd_readl(IELCD_VIDCON0);
> > +   cfg &= ~(VIDCON0_VIDOUT_MASK | VIDCON0_VCLK_MASK);
> > +   cfg |= VIDCON0_VIDOUT_RGB;
> > +   cfg |= VIDCON0_VCLK_NORMAL;
> > +
> > +   exynos_ielcd_writel(IELCD_VIDCON0, cfg);
> > +}
> > +
> > +int exynos_ielcd_power_on(void *pp_ctx)
> > +{
> > +   struct ielcd_context *ielcd = pp_ctx;
> > +   unsigned int cfg;
> > +   int ret = 0;
> > +
> > +   ielcd_logic_start(ielcd);
> > +   ielcd_set_polarity(ielcd);
> > +
> > +   ielcd_set_lcd_size(ielcd);
> > +   ielcd_set_timing(ielcd);
> > +
> > +   /* window0 setting , fixed */
> > +   cfg = WINCONx_ENLOCAL | WINCON0_BPPMODE_24BPP_888 |
> WINCONx_ENWIN;
> > +   exynos_ielcd_writel(IELCD_WINCON0, cfg);
> > +
> > +   exynos_ielcd_config_rgb(ielcd);
> > +
> > +   ret = exynos_ielcd_display_on(ielcd);
> > +   if (ret) {
> > +   DRM_ERROR("IELCD failed to start\n");
> > +   return ret;
> > +   }
> > +
> > +   return 0;
>
> The above block could be simplified as:
>ret = exynos_ielcd_display_on(ielcd);
>if (ret)
>   DRM_ERROR(...);
>
>return ret;
>
Ok. I will change it.

> > +}
> > +
> > +static void exynos_ielcd_mode_set(void *pp_ctx,
> > +   const struct drm_display_mode *in_mode)
> > +{
> > +   struct ielcd_context *ielcd = pp_ctx;
> > +
> > +   ielcd->vdisplay = in_mode->crtc_vdisplay;
> > +   ielcd->vsync_len = in_mode->crtc_vsync_end -
> in_mode->crtc_vsync_start;
> > +   ielcd->vbpd = in_mode->crtc_vtotal - in_mode->crtc_vsync_end;
> > +   ielcd->vfpd = in_mode->crtc_vsync_start - in_mode->crtc_vdisplay;
> > +
> > +   ielcd->hdisplay = in_mode->crtc_hdisplay;
> > +   ielcd->hsync_len = in_mode->crtc_hsync_end -
> in_mode->crtc_hsync_start;
> > +   ielcd->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end;
> > +   ielcd->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay;
> > +}
> > +
> > +static struct exynos_fimd_pp_ops ielcd_ops = {
> > +   .power_on = exynos_ielcd_power_on,
> > +   .power_off =exynos_ielcd_display_off,
> > +   .mode_set = exynos_ielcd_mode_set,
> > +};
> > +
> > +static struct exynos_fimd_pp ielcd_pp = {
> > +   .ops =  _ops,
> > +};
> > +
> > +int exynos_ielcd_init(struct device *dev, struct exynos_fimd_pp **pp)
> > +{
> > +   struct device_node *ielcd_np;
> > +   struct ielcd_context *ielcd;
> > +   u32 addr[2];
> > +   int ret = 0;
> > +
> > +   ielcd = kzalloc(sizeof(struct ielcd_context), GFP_KERNEL);
> > +   if (!ielcd) {
> > +   DRM_ERROR("failed to allocate ielcd\n");
> > +   ret = -ENOMEM;
> > +   goto error0;
>
> return directly from here and delete the label.
>
> Ok.

> --
> With warm regards,
> Sachin
>

Will address all your comments in next patchset.

Thanks and regards,
Ajay kumar
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/3f61d4ce/attachment.html>

[PATCH 4/4] drm/radeon/dp: switch to the common i2c over aux code

[Alex Deucher]

Provides a nice cleanup in radeon.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c   | 117 +
 drivers/gpu/drm/radeon/radeon_connectors.c |  44 ++-
 drivers/gpu/drm/radeon/radeon_display.c|  11 ++-
 drivers/gpu/drm/radeon/radeon_i2c.c|  60 ---
 drivers/gpu/drm/radeon/radeon_mode.h   |  12 +--
 5 files changed, 44 insertions(+), 200 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index f143128..9f6b9af 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -205,98 +205,15 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)

 void radeon_dp_aux_init(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
-
-   dig_connector->dp_i2c_bus->aux.dev = radeon_connector->base.kdev;
-   dig_connector->dp_i2c_bus->aux.transfer = radeon_dp_aux_transfer;
-}
-
-int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
-u8 write_byte, u8 *read_byte)
-{
-   struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
-   struct radeon_i2c_chan *auxch = i2c_get_adapdata(adapter);
-   u16 address = algo_data->address;
-   u8 msg[5];
-   u8 reply[2];
-   unsigned retry;
-   int msg_bytes;
-   int reply_bytes = 1;
int ret;
-   u8 ack;
-
-   /* Set up the address */
-   msg[0] = address;
-   msg[1] = address >> 8;
-
-   /* Set up the command byte */
-   if (mode & MODE_I2C_READ) {
-   msg[2] = DP_AUX_I2C_READ << 4;
-   msg_bytes = 4;
-   msg[3] = msg_bytes << 4;
-   } else {
-   msg[2] = DP_AUX_I2C_WRITE << 4;
-   msg_bytes = 5;
-   msg[3] = msg_bytes << 4;
-   msg[4] = write_byte;
-   }

-   /* special handling for start/stop */
-   if (mode & (MODE_I2C_START | MODE_I2C_STOP))
-   msg[3] = 3 << 4;
-
-   /* Set MOT bit for all but stop */
-   if ((mode & MODE_I2C_STOP) == 0)
-   msg[2] |= DP_AUX_I2C_MOT << 4;
-
-   for (retry = 0; retry < 7; retry++) {
-   ret = radeon_process_aux_ch(auxch,
-   msg, msg_bytes, reply, reply_bytes, 
0, );
-   if (ret == -EBUSY)
-   continue;
-   else if (ret < 0) {
-   DRM_DEBUG_KMS("aux_ch failed %d\n", ret);
-   return ret;
-   }
+   radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
+   radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
+   ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);
+   if (!ret)
+   radeon_connector->ddc_bus->has_aux = true;

-   switch ((ack >> 4) & DP_AUX_NATIVE_REPLY_MASK) {
-   case DP_AUX_NATIVE_REPLY_ACK:
-   /* I2C-over-AUX Reply field is only valid
-* when paired with AUX ACK.
-*/
-   break;
-   case DP_AUX_NATIVE_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_ch native nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_NATIVE_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_ch native defer\n");
-   usleep_range(500, 600);
-   continue;
-   default:
-   DRM_ERROR("aux_ch invalid native reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-
-   switch ((ack >> 4) & DP_AUX_I2C_REPLY_MASK) {
-   case DP_AUX_I2C_REPLY_ACK:
-   if (mode == MODE_I2C_READ)
-   *read_byte = reply[0];
-   return ret;
-   case DP_AUX_I2C_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_i2c nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_I2C_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_i2c defer\n");
-   usleep_range(400, 500);
-   break;
-   default:
-   DRM_ERROR("aux_i2c invalid reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-   }
-
-   DRM_DEBUG_KMS("aux i2c too many retries, giving up\n");
-   return -EREMOTEIO;
+   WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n", ret);
 }

 /* general DP utility functions */
@@ -431,12 +348,11 @@ static u8 radeon_dp_encoder_service(struct radeon_device 
*rdev,

 u8 radeon_dp_getsinktype(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
struct drm_device *dev = 

[PATCH 3/4] drm/dp/i2c: use new BARE_ADDRESS flags in i2c over aux

[Alex Deucher]

We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions.  This mirrors what the existing dp i2c
over aux algo currently does.

This fixes EDID fetches on certain monitors especially with
dp bridges.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/drm_dp_helper.c | 56 -
 1 file changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 74724aa..ed22c6c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -664,12 +664,27 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
   int num)
 {
struct drm_dp_aux *aux = adapter->algo_data;
-   unsigned int i, j;
+   unsigned int m, b;
+   struct drm_dp_aux_msg msg;
+   int err = 0;
+   u8 buf = 0;

-   for (i = 0; i < num; i++) {
-   struct drm_dp_aux_msg msg;
-   int err;
+   memset(, 0, sizeof(msg));

+   for (m = 0; m < num; m++) {
+   msg.address = msgs[m].addr;
+   msg.request = (msgs[m].flags & I2C_M_RD) ?
+   DP_AUX_I2C_READ :
+   DP_AUX_I2C_WRITE;
+   msg.request |= DP_AUX_I2C_MOT;
+   msg.buffer = 
+   msg.size = 1;
+   msg.flags = DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS;
+   err = drm_dp_i2c_do_msg(aux, );
+   if (err < 0) {
+   printk("error %d in bare address write\n", err);
+   break;
+   }
/*
 * Many hardware implementations support FIFOs larger than a
 * single byte, but it has been empirically determined that
@@ -677,31 +692,26 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
 * decreased performance. Therefore each message is simply
 * transferred byte-by-byte.
 */
-   for (j = 0; j < msgs[i].len; j++) {
-   memset(, 0, sizeof(msg));
-   msg.address = msgs[i].addr;
-
-   msg.request = (msgs[i].flags & I2C_M_RD) ?
-   DP_AUX_I2C_READ :
-   DP_AUX_I2C_WRITE;
-
-   /*
-* All messages except the last one are middle-of-
-* transfer messages.
-*/
-   if ((i < num - 1) || (j < msgs[i].len - 1))
-   msg.request |= DP_AUX_I2C_MOT;
-
-   msg.buffer = msgs[i].buf + j;
+   for (b = 0; b < msgs[m].len; b++) {
+   msg.buffer = msgs[m].buf + b;
msg.size = 1;
+   msg.flags = 0;

err = drm_dp_i2c_do_msg(aux, );
if (err < 0)
-   return err;
+   break;
}
}
-
-   return num;
+   if (err >= 0)
+   err = num;
+   /* send a bare address packet to close out the connection */
+   msg.request &= ~DP_AUX_I2C_MOT;
+   msg.buffer = 
+   msg.size = 1;
+   msg.flags = DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS;
+   (void)drm_dp_i2c_do_msg(aux, );
+
+   return err;
 }

 static const struct i2c_algorithm drm_dp_i2c_algo = {
-- 
1.8.3.1

[PATCH 2/4] drm/radeon/dp: handle the new BARE_ADDRESS aux flag

[Alex Deucher]

Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8b0ab17..f143128 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -143,6 +143,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
 }

 #define HEADER_SIZE 4
+#define BARE_ADDRESS_SIZE 3

 static ssize_t
 radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
@@ -165,8 +166,12 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+   /* handle bare */
tx_size = HEADER_SIZE + msg->size;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->flags & DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
memcpy(tx_buf + HEADER_SIZE, msg->buffer, msg->size);
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, NULL, 0, delay, 
);
@@ -177,9 +182,15 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
tx_size = HEADER_SIZE;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->flags & DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, msg->buffer, 
msg->size, delay, );
+   /* sending just the address transfers 0 bytes */
+   if ((msg->flags & DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS) && (ret == 
0))
+   ret++;
break;
default:
ret = -EINVAL;
-- 
1.8.3.1

[PATCH 1/4] drm/dp: add flags field to drm_dp_aux_msg struct

[Alex Deucher]

This adds a flags field and a new flag, BARE_ADDRESS,
which drivers can use for special handling when they
want to set just the aux address.  This is needed
to properly reset the connection between i2c transactions.

Signed-off-by: Alex Deucher 
---
 include/drm/drm_dp_helper.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index b7488c9..a006e96 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -403,6 +403,8 @@ drm_dp_enhanced_frame_cap(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
  * DisplayPort AUX channel
  */

+#define DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS (1 << 0)
+
 /**
  * struct drm_dp_aux_msg - DisplayPort AUX channel transaction
  * @address: address of the (first) register to access
@@ -417,6 +419,7 @@ struct drm_dp_aux_msg {
u8 reply;
void *buffer;
size_t size;
+   u32 flags;
 };

 /**
-- 
1.8.3.1

[PATCH 1/3] drm/dp: make aux retries less chatty

[Christian König]

Am 21.03.2014 15:34, schrieb Alex Deucher:
> Switch to debug only to avoid flooding the logs.
> This mirrors the behavior in some other drivers.
>
> Signed-off-by: Alex Deucher 
> Reviewed-by: Daniel Vetter 

Added to my 3.15 queue 
(http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-next-3.15-wip).

Thanks,
Christian.

> ---
>   drivers/gpu/drm/drm_dp_helper.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 35251af..74724aa 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -402,7 +402,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>   }
>   }
>   
> - DRM_ERROR("too many retries, giving up\n");
> + DRM_DEBUG_KMS("too many retries, giving up\n");
>   return -EIO;
>   }
>   
> @@ -656,7 +656,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   }
>   }
>   
> - DRM_ERROR("too many retries, giving up\n");
> + DRM_DEBUG_KMS("too many retries, giving up\n");
>   return -EREMOTEIO;
>   }
>   

[RFC 2/4] drm: exynos: add MDNIE post processor

[Ajay kumar]

ANGE(ret, params->red_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->red_rgb[2], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->green_rgb[0], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->green_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->green_rgb[2], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->blue_rgb[0], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->blue_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->blue_rgb[2], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->cyan_rgb[0], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->cyan_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->cyan_rgb[2], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->magenta_rgb[0], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->magenta_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->magenta_rgb[2], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->yellow_rgb[0], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->yellow_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->yellow_rgb[2], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->white_rgb[0], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->white_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->white_rgb[2], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->black_rgb[0], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->black_rgb[1], CC_MIN, CC_MAX);
> > +   PARAM_IN_RANGE(ret, params->black_rgb[2], CC_MIN, CC_MAX);
> > +
> > +   if (ret)
> > +   return -EINVAL;
> >
> ditto
>
> Ok.

> > +   memcpy(>params.cr_params, params, sizeof(*params));
> > +   return 0;
> > +}
> > +
> > +static int mdnie_set_edge_enhancement_params(
> > +   struct mdnie_context *mdnie,
> > +   const struct drm_mode_edge_enhancement *params)
> > +{
> > +   int ret;
> > +
> > +   PARAM_IN_RANGE(ret, params->edge_th, TH_MIN, TH_MAX);
> > +   PARAM_IN_RANGE(ret, params->background_th, TH_MIN, TH_MAX);
> > +   PARAM_IN_RANGE(ret, params->pg_edge, GAIN_MIN, GAIN_MAX);
> > +   PARAM_IN_RANGE(ret, params->pg_flat, GAIN_MIN, GAIN_MAX);
> > +   PARAM_IN_RANGE(ret, params->pg_background, GAIN_MIN, GAIN_MAX);
> > +   PARAM_IN_RANGE(ret, params->ng_edge, GAIN_MIN, GAIN_MAX);
> > +   PARAM_IN_RANGE(ret, params->ng_flat, GAIN_MIN, GAIN_MAX);
> > +   PARAM_IN_RANGE(ret, params->ng_background, GAIN_MIN, GAIN_MAX);
>
> ditto
>
Ok.

>
> > +   if (ret)
> > +   return -EINVAL;
> > +
> > +   memcpy(>params.de_params, params, sizeof(*params));
> > +   return 0;
> > +}
> > +
> > +static int mdnie_set_window_params(
> > +   struct mdnie_context *mdnie,
> > +   const struct drm_exynos_mdnie_window *params)
> > +{
> > +   int ret;
> > +
> > +   PARAM_IN_RANGE(ret, params->win_x, X_MIN, X_MAX);
> > +   PARAM_IN_RANGE(ret, params->win_y, Y_MIN, Y_MAX);
> > +   PARAM_IN_RANGE(ret, params->win_w, params->win_x, X_MAX);
> > +   PARAM_IN_RANGE(ret, params->win_h, params->win_y, Y_MAX);
>
> ditto and all other places of similar usage.
>
> Ok.

>
>
>
>
>
>
> [snip]
>
> > +int exynos_mdnie_init(struct device *dev, struct exynos_fimd_pp **pp)
> > +{
> > +   struct device_node *np = dev->of_node;
> > +   struct device_node *mdnie_np;
> > +   struct mdnie_context *mdnie = NULL;
> > +   u32 disp1blk_phyaddr;
> > +   int ret = 0;
> > +   u32 buf[2];
> > +
> > +   mdnie_np = of_parse_phandle(np, "samsung,mdnie", 0);
> > +   if (!mdnie_np) {
> > +   DRM_INFO("No mdnie node present, "
> > +   "MDNIE feature will be disabled\n");
> > +   ret = -EINVAL;
> > +   goto err0;
>
> return directly from here.
>
> Ok.

> > +   }
> > +
> > +   if (of_property_read_u32_array(mdnie_np, "reg", buf, 2)) {
> > +   DRM_ERROR("failed to get base address for MDNIE\n");
> > +   ret = -ENOMEM;
> > +   goto err0;
>
> ditto
>
Ok.

>
>
> +   }
> > +
> > +   mdnie = kzalloc(sizeof(struct mdnie_context), GFP_KERNEL);
>
> nit: use sizeof(*mdnie)
>
> Ok.

> > +   if (!mdnie) {
> > +   DRM_ERROR("failed to allocate mdnie\n");
>
> This message is not needed as kzalloc prints OOM message upon failure.
>
Ok.

>
> > +   ret = -ENOMEM;
> > +   goto err0;
> > +   }
>
> return directly.

Ok.

>
> > +
> > +   mdnie->exynos_mdnie_base = ioremap(buf[0], buf[1]);
> > +   if (!mdnie->exynos_mdnie_base) {
> > +   DRM_ERROR("failed to ioremap mdnie device\n");
> > +   ret = -ENOMEM;
> > +   goto err1;
> > +   }
> > +
> > +   if (dt_parse_disp1blk_cfg(dev, _phyaddr)) {
> > +   DRM_ERROR("failed to get disp1blk property.\n");
> > +   ret = -ENODEV;
> > +   goto err1;
> > +   }
> > +
> > +   if (exynos_iomap_disp1blk(mdnie, disp1blk_phyaddr)) {
> > +   DRM_ERROR("failed to iopmap disp1blk sysreg.\n");
>
> s/iopmap/iomap
>
> Ok.

>
> --
> With warm regards,
> Sachin
>

I will address your comments in next patchset.

Thanks,
Ajay
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/067c570b/attachment-0001.html>

[PATCH 1/3] drm/dp: make aux retries less chatty

[Daniel Vetter]

On Fri, Mar 21, 2014 at 10:34:06AM -0400, Alex Deucher wrote:
> Switch to debug only to avoid flooding the logs.
> This mirrors the behavior in some other drivers.
> 
> Signed-off-by: Alex Deucher 
> Reviewed-by: Daniel Vetter 

Btw I've just noticed that we have a 2nd retry loop with 3 retries and a 1
msec delay which apparently is needed to kick suspended dp sinks out of
their sleep. See intel_dp_dpcd_read_wake in intel_dp.c. Should we maybe
move that 2nd loop into these helpers, too?
-Daniel

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 35251af..74724aa 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -402,7 +402,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>   }
>   }
>  
> - DRM_ERROR("too many retries, giving up\n");
> + DRM_DEBUG_KMS("too many retries, giving up\n");
>   return -EIO;
>  }
>  
> @@ -656,7 +656,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   }
>   }
>  
> - DRM_ERROR("too many retries, giving up\n");
> + DRM_DEBUG_KMS("too many retries, giving up\n");
>   return -EREMOTEIO;
>  }
>  
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #13 from Gregory Land  ---
Uninstalled segfalting package - Speech-Dispatcher (part of kde accessability)
- Segfault resovled system still locks up with dpm.radeon = 1.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6496c8d9/attachment.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #12 from Gregory Land  ---
Created attachment 96182
  --> https://bugs.freedesktop.org/attachment.cgi?id=96182=edit
Core Dump at insane logging level.

I enabled every debug line I could find. Got this.


Mar 21 10:00:54 endora systemd[1]: Received SIGCHLD from PID 584 (sd_cicero).
Mar 21 10:00:54 endora systemd[1]: Child 584 (sd_cicero) died (code=exited,
status=1/FAILURE)
Mar 21 10:00:54 endora kernel: [drm:r600_irq_process], r600_irq_process start:
rptr 18624, wptr 18640
Mar 21 10:00:54 endora kernel: [drm:drm_calc_vbltimestamp_from_scanoutpos],
crtc 1 : v 13 p(521,-40)@ 28.771340 -> 28.771949 [e 0 us, 0 rep]
Mar 21 10:00:54 endora kernel: [drm:r600_irq_process], IH: D2 vblank
Mar 21 10:00:54 endora kernel: sd_festival[590]: segfault at 2d0 ip
7fcc15b8d1a1 sp 779b0a10 error 4 in
libpthread-2.19.so[7fcc15b8+18000]
Mar 21 10:00:54 endora kernel: potentially unexpected fatal signal 11.
Mar 21 10:00:54 endora kernel: CPU: 7 PID: 590 Comm: sd_festival Tainted: G
 I  3.14.0-rc7-ARCH-00059-g08edb33-dirty #1
Mar 21 10:00:54 endora kernel: Hardware name:  /DX58SO, BIOS
SOX5810J.86A.5600.2013.0729.2250 07/29/2013
Mar 21 10:00:54 endora kernel: task: 8801a537cf00 ti: 8800c1f2e000
task.ti: 8800c1f2e000
Mar 21 10:00:54 endora kernel: RIP: 0033:[<7fcc15b8d1a1>] 
[<7fcc15b8d1a1>] 0x7fcc15b8d1a1
Mar 21 10:00:54 endora kernel: RSP: 002b:779b0a10  EFLAGS: 00010206
Mar 21 10:00:54 endora kernel: RAX:  RBX:  RCX:
7fcc15b7a678
Mar 21 10:00:54 endora kernel: RDX:  RSI:  RDI:

Mar 21 10:00:54 endora kernel: RBP: 779b0bb8 R08: 7fcc15b7a678 R09:
7fcc15b7a670
Mar 21 10:00:54 endora kernel: R10: 779b07e0 R11: 7fcc15b8d1a0 R12:
00405d6c
Mar 21 10:00:54 endora kernel: R13: 779b0bb0 R14:  R15:

Mar 21 10:00:54 endora kernel: FS:  7fcc16afe700()
GS:8801aece() knlGS:
Mar 21 10:00:54 endora kernel: CS:  0010 DS:  ES:  CR0:
80050033
Mar 21 10:00:54 endora kernel: CR2: 02d0 CR3: c1cf8000 CR4:
07e0
Mar 21 10:00:54 endora kernel: 
Mar 21 10:00:54 endora kernel: [drm:r600_irq_process], r600_irq_process start:
rptr 18640, wptr 18656
Mar 21 10:00:54 endora kernel: [drm:drm_calc_vbltimestamp_from_scanoutpos],
crtc 0 : v 13 p(1866,-47)@ 28.774347 -> 28.775032 [e 0 us, 0 rep]
Mar 21 10:00:54 endora kernel: [drm:r600_irq_process], IH: D1 vblank
Mar 21 10:00:54 endora systemd-coredump[591]: Process 590 (sd_festival) dumped
core.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/11344596/attachment.html>

[PATCH 2/2] drm/fb-helper: improve drm_fb_helper_initial_config locking

[Thierry Reding]

On Thu, Mar 20, 2014 at 02:26:35PM +0100, Daniel Vetter wrote:
[...]
> Hence the right fix is to grab the mode_config mutex, but only that
> and only right around the probe calls.
> 
> It seems to be sufficient to shut up all the locking WARNINGs I see on
> i915 and nouveau in drm_fb_helper_initial_config.

Fixes any of the WARNINGs remaining after patch 1/2 for me on Tegra as
well, so:

Tested-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/9be15d52/attachment.sig>

[PATCH 1/2] drm/crtc-helper: fix locking for drm_helper_disable_unused_functions

[Thierry Reding]

On Thu, Mar 20, 2014 at 02:26:34PM +0100, Daniel Vetter wrote:
[...]
> The right fix therefore is to split this helper into an internal and
> external version and add the required locking to the function exported
> to drivers.
> 
> This remedies locking inconsistencies exposed by me adding locking
> WARNs as part of the recent kerneldoc abi polishing done in

Tested-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/9c7eabd8/attachment.sig>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #11 from Gregory Land  ---
Patch did not resolve the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/f56fd1cd/attachment-0001.html>

[GIT PULL] exynos-drm-next

[Inki Dae]

Hi Dave,

   This pull request includes some features and big changes for 3.15.


Highlights
--

Re-factoring works over the exynos drm framework.
  - drm_crtc, drm_encoder/drm_connector are implemented by sub drivers
directly.
  - Removing pm interfaces from each sub driver, and implementing them
at top level of exynos drm.
Add DisplayPort Transmitter driver.
  - Just moving existing driver from drivers/vides/exynos into
drivers/gpu/drm/exynos.
Add new LVDS bridge driver, PTN3460.
  - Placed in drivers/gpu/drm/bridge, and this device is used to transfer
image signal from DP(DisplayPort) to LVDS Panel.
So this driver will be used with DP driver moved into exynos drm.
Add parallel panel support
  - With the re-factoring patch series, existing parallel panel support was
broken by moving exynos_drm_display ops into each real connector driver,
DP. So this patch series adds a new parallel panel module,
exynos_drm_dpi, for supporting parallel panel, and also adds relevant
bindings.
Some fixups and cleanups.


Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit e84c20aff1ce7493bce26b75f1db363bb3f05979:

  drm/radeon/kms: merge conflicted badly (2014-03-20 11:09:10 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-next

for you to fetch changes up to ec6f53d3115258a4af6b7f4f07173a8336bad785:

  drm/exynos: fimd: remove unused variable (2014-03-21 15:12:10 +0900)


Andrzej Hajda (7):
  drm/exynos: delay fbdev initialization until an output is connected
  drm/exynos: init kms poll after creation of connectors
  drm/exynos: correct timing porch conversion
  exynos/fimd: add parallel output related bindings
  drm/exynos: restore parallel output interface support
  ARM: dts: exynos4210-universal: add exynos/fimd node
  drm/exynos: fimd: remove unused variable

Daniel Kurtz (2):
  drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c
  drm/exynos: hdmi: remove the i2c drivers and use

Inki Dae (3):
  drm/exynos: hdmi: consider APB PHY
  drm/exynos: hdmi: use i2c_adapter instead of i2c_client
  drm/exynos: fix unnecessary resource cleanup

Sean Paul (30):
  drm/exynos: Merge overlay_ops into manager_ops
  drm/exynos: Add an initialize function to manager and display
  drm/exynos: Use manager_op initialize in fimd
  drm/exynos: hdmi: Implement initialize op for hdmi
  drm/exynos: Pass exynos_drm_manager in manager ops instead of dev
  drm/exynos: Remove apply manager callback
  drm/exynos: Remove dpms link between encoder/connector
  drm/exynos: Rename display_op power_on to dpms
  drm/exynos: Don't keep dpms state in encoder
  drm/exynos: Use unsigned long for possible_crtcs
  drm/exynos: Split manager/display/subdrv
  drm/exynos: Remove exynos_drm_hdmi shim
  drm/exynos: Use drm_mode_copy to copy modes
  drm/exynos: Disable unused crtc planes from crtc
  drm/exynos: Add mode_set manager operation
  drm/exynos: Implement mode_fixup manager operation
  drm/exynos: Use mode_set to configure fimd
  drm/exynos: Remove unused/useless fimd_context members
  drm/exynos: Move dp driver from video/ to drm/
  drm/exynos: Move display implementation into dp
  drm/exynos: Implement dpms display callback in DP
  drm/exynos: Clean up FIMD power on/off routines
  drm/exynos: Consolidate suspend/resume in drm_drv
  drm/exynos: Add create_connector callback
  drm/exynos: Implement drm_connector in hdmi directly
  drm/exynos: Implement drm_connector directly in dp driver
  drm/exynos: Implement drm_connector directly in vidi driver
  drm/bridge: Add PTN3460 bridge driver
  drm/exynos: Implement lvds bridge discovery to DP driver
  drm/exynos: Remove the exynos_drm_connector shim

Shirish S (2):
  drm/exynos: add phy settings for RB resolutions
  drm/exynos: set the active aspect ratio as per mode

Stephane Marchesin (1):
  drm/exynos: Remove useless slab.h include

 .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 +
 .../devicetree/bindings/video/exynos_dp.txt|   17 +
 .../devicetree/bindings/video/exynos_hdmi.txt  |5 +
 .../devicetree/bindings/video/samsung-fimd.txt |   17 +
 MAINTAINERS|6 -
 arch/arm/boot/dts/exynos4210-universal_c210.dts|   27 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/bridge/Kconfig |4 +
 drivers/gpu/drm/bridge/Makefile|3 +
 drivers/gpu/drm/bridge/ptn3460.c   |  349 ++
 drivers/gpu/drm/exynos/Kconfig |   15 +
 

I915: OOPSes on linux-3.14-rc7

[Peter Senna Tschudin]

On Fri, Mar 21, 2014 at 4:11 PM, Daniel Vetter  wrote:
> On Fri, Mar 21, 2014 at 12:26:51PM +0100, Peter Senna Tschudin wrote:
>> On Thu, Mar 20, 2014 at 10:17 PM, Daniel Vetter  wrote:
>> > On Thu, Mar 20, 2014 at 05:56:20PM +0100, Peter Senna Tschudin wrote:
>> >> When Fedora updated the Kernel package from 3.12 to 3.13 my notebook
>> >> stopped booting (Kernel freezes) when a 2560 x 1440 high res monitor
>> >> is attached. I have tried using 3.13.6 from kernel.org and the problem
>> >> persists. The problem can be partially solved by passing nomodeset to
>> >> Kernel which will make the Kernel to boot, but the screens never comes
>> >> to life. When using 3.14-rc7 it boots again, the screen works, but
>> >> with some oops messages.
>> >>
>> >> How can I help fixing this issue?
>> >>
>> >> I've reported te bug at:
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1072557
>> >
>> > For the oops message (well it's just a WARNING, a real oops would kill
>> > your driver for real) please file a bug report on bugs.freedesktop.org
>> > against dri -> drm (intel).
>> >
>> > The information we need is the full dmesg fore the entire boot when
>> > enabling drm.debug=0xe on the kernel cmdline.
>> It is attached.
>>
>> >
>> > For the boot hang you've reported on the redhat bz if you want to move it
>> > forward I suggest to do a reverse bisect betwen 3.13 and 3.14-rc7 to
>> > figure out which bug _fixed_ your problem and then tell me that. I'll
>> > submit it for backporting to stable kernels. Google should find you some
>> > nice howtos for reverse bisecting kerneels.
>> Thank you. I'll do that.
>
> It's an issue with our fastboot clock readout code. Please apply the below
> patch and add an updated dmesg (again with drm.debug=0xe) to your bug
> report.

The dmesg file is attached. Should I open a bug report at
bugs.freedesktop.org for this warning issue?


> -Daniel
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7be5984431bb..3c0f8f095a6b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -450,6 +450,8 @@ static void i9xx_clock(int refclk, intel_clock_t *clock)
>  {
> clock->m = i9xx_dpll_compute_m(clock);
> clock->p = clock->p1 * clock->p2;
> +   printk("p1 = %u, p2 = %u, n = %u\n", clock->p1, clock->p2,
> +  clock->n);
> if (WARN_ON(clock->n + 2 == 0 || clock->p == 0))
> return;
> clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n + 2);
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Peter
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/x-gzip
Size: 73573 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/9dcf27f3/attachment-0001.bin>

[Bug 70171] 3.13.x: kernel/time/tick-broadcast.c:668 exception, no sound, HDMI overscan issue

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

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

Andreas  changed:

   What|Removed |Added

Summary|kernel/time/tick-broadcast. |3.13.x:
   |c:668 exception and no  |kernel/time/tick-broadcast.
   |sound   |c:668 exception, no sound,
   ||HDMI overscan issue

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 70171] kernel/time/tick-broadcast.c:668 exception and no sound

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

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

Andreas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #48 from Andreas  ---
Okay, I appologize, but I?ve been _very_ busy since my last message. I just
installed kernels 3.12.14 an 3.13.6 and I am now running on 3.13.6:

1) the kernel/time/tick-broadcast.c:668 error message is gone.
2) sound works, because I switched from the gray to the green Line Out jack as
proposed by Raymond in comment #15 ? otherwise sound was still muted.

To summerize:
[SOLVED] sound issue
   +--- green jack on 3.13.x
   +--- gray/green jack on 3.12.x/earlier and 3.14-rc1/later
[SOLVED] overscan issue
   +--- disable audio for HDMI output
[SOLVED] kernel/time/tick-broadcast.c:668
   +--- gone in 3.13.6, not present in 3.12.x, unknown for 3.14-rc


Thanks for all your help!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/exynos: remove DRIVER_HAVE_IRQ feature

[Joonyoung Shim]

On 03/21/2014 03:53 PM, Daniel Kurtz wrote:
> On Fri, Mar 21, 2014 at 2:39 PM, Joonyoung Shim  
> wrote:
>> Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses
>> driver specific one instead of routine of drm framework to
>> install/uninstall irq handler.
> Wouldn't that break synchronous drm_wait_vblank()?
>   (drm_wait_vblank where _DRM_VBLANK_EVENT is not set in request.type)

Actually, i didn't consider above case. Then it seems to need code to
set dev->irq_enabled in exynos driver.

Thanks.

> -Dan
>
>> Signed-off-by: Joonyoung Shim 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_drv.c  |  3 +--
>>   drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 --
>>   drivers/gpu/drm/exynos/exynos_drm_vidi.c | 10 --
>>   3 files changed, 1 insertion(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index c204b4e..dd7d18f 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -291,8 +291,7 @@ static const struct file_operations 
>> exynos_drm_driver_fops = {
>>   };
>>
>>   static struct drm_driver exynos_drm_driver = {
>> -   .driver_features= DRIVER_HAVE_IRQ | DRIVER_MODESET |
>> -   DRIVER_GEM | DRIVER_PRIME,
>> +   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
>>  .load   = exynos_drm_load,
>>  .unload = exynos_drm_unload,
>>  .open   = exynos_drm_open,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index a20440c..37455f3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -715,16 +715,6 @@ out:
>>   static int fimd_subdrv_probe(struct drm_device *drm_dev, struct device 
>> *dev)
>>   {
>>  /*
>> -* enable drm irq mode.
>> -* - with irq_enabled = true, we can use the vblank feature.
>> -*
>> -* P.S. note that we wouldn't use drm irq handler but
>> -*  just specific driver own one instead because
>> -*  drm framework supports only one irq handler.
>> -*/
>> -   drm_dev->irq_enabled = true;
>> -
>> -   /*
>>   * with vblank_disable_allowed = true, vblank interrupt will be 
>> disabled
>>   * by drm timer once a current process gives up ownership of
>>   * vblank event.(after drm_vblank_put function is called)
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> index ddaaedd..b4c5f95 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -382,16 +382,6 @@ static void vidi_fake_vblank_handler(struct work_struct 
>> *work)
>>   static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device 
>> *dev)
>>   {
>>  /*
>> -* enable drm irq mode.
>> -* - with irq_enabled = true, we can use the vblank feature.
>> -*
>> -* P.S. note that we wouldn't use drm irq handler but
>> -*  just specific driver own one instead because
>> -*  drm framework supports only one irq handler.
>> -*/
>> -   drm_dev->irq_enabled = true;
>> -
>> -   /*
>>   * with vblank_disable_allowed = true, vblank interrupt will be 
>> disabled
>>   * by drm timer once a current process gives up ownership of
>>   * vblank event.(after drm_vblank_put function is called)
>> --
>> 1.8.1.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

I915: OOPSes on linux-3.14-rc7

[Daniel Vetter]

On Fri, Mar 21, 2014 at 12:26:51PM +0100, Peter Senna Tschudin wrote:
> On Thu, Mar 20, 2014 at 10:17 PM, Daniel Vetter  wrote:
> > On Thu, Mar 20, 2014 at 05:56:20PM +0100, Peter Senna Tschudin wrote:
> >> When Fedora updated the Kernel package from 3.12 to 3.13 my notebook
> >> stopped booting (Kernel freezes) when a 2560 x 1440 high res monitor
> >> is attached. I have tried using 3.13.6 from kernel.org and the problem
> >> persists. The problem can be partially solved by passing nomodeset to
> >> Kernel which will make the Kernel to boot, but the screens never comes
> >> to life. When using 3.14-rc7 it boots again, the screen works, but
> >> with some oops messages.
> >>
> >> How can I help fixing this issue?
> >>
> >> I've reported te bug at:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1072557
> >
> > For the oops message (well it's just a WARNING, a real oops would kill
> > your driver for real) please file a bug report on bugs.freedesktop.org
> > against dri -> drm (intel).
> >
> > The information we need is the full dmesg fore the entire boot when
> > enabling drm.debug=0xe on the kernel cmdline.
> It is attached.
> 
> >
> > For the boot hang you've reported on the redhat bz if you want to move it
> > forward I suggest to do a reverse bisect betwen 3.13 and 3.14-rc7 to
> > figure out which bug _fixed_ your problem and then tell me that. I'll
> > submit it for backporting to stable kernels. Google should find you some
> > nice howtos for reverse bisecting kerneels.
> Thank you. I'll do that.

It's an issue with our fastboot clock readout code. Please apply the below
patch and add an updated dmesg (again with drm.debug=0xe) to your bug
report.
-Daniel

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7be5984431bb..3c0f8f095a6b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -450,6 +450,8 @@ static void i9xx_clock(int refclk, intel_clock_t *clock)
 {
clock->m = i9xx_dpll_compute_m(clock);
clock->p = clock->p1 * clock->p2;
+   printk("p1 = %u, p2 = %u, n = %u\n", clock->p1, clock->p2,
+  clock->n);
if (WARN_ON(clock->n + 2 == 0 || clock->p == 0))
return;
clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n + 2);
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/exynos: remove DRIVER_HAVE_IRQ feature

[Joonyoung Shim]

Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses
driver specific one instead of routine of drm framework to
install/uninstall irq handler.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  3 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 10 --
 3 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index c204b4e..dd7d18f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -291,8 +291,7 @@ static const struct file_operations exynos_drm_driver_fops 
= {
 };

 static struct drm_driver exynos_drm_driver = {
-   .driver_features= DRIVER_HAVE_IRQ | DRIVER_MODESET |
-   DRIVER_GEM | DRIVER_PRIME,
+   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
.open   = exynos_drm_open,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a20440c..37455f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -715,16 +715,6 @@ out:
 static int fimd_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
 {
/*
-* enable drm irq mode.
-* - with irq_enabled = true, we can use the vblank feature.
-*
-* P.S. note that we wouldn't use drm irq handler but
-*  just specific driver own one instead because
-*  drm framework supports only one irq handler.
-*/
-   drm_dev->irq_enabled = true;
-
-   /*
 * with vblank_disable_allowed = true, vblank interrupt will be disabled
 * by drm timer once a current process gives up ownership of
 * vblank event.(after drm_vblank_put function is called)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index ddaaedd..b4c5f95 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -382,16 +382,6 @@ static void vidi_fake_vblank_handler(struct work_struct 
*work)
 static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
 {
/*
-* enable drm irq mode.
-* - with irq_enabled = true, we can use the vblank feature.
-*
-* P.S. note that we wouldn't use drm irq handler but
-*  just specific driver own one instead because
-*  drm framework supports only one irq handler.
-*/
-   drm_dev->irq_enabled = true;
-
-   /*
 * with vblank_disable_allowed = true, vblank interrupt will be disabled
 * by drm timer once a current process gives up ownership of
 * vblank event.(after drm_vblank_put function is called)
-- 
1.8.1.2

[PATCH 0/9] Doc/DT: DT bindings for various display components

[Grant Likely]

On Mon, 17 Mar 2014 15:55:27 +0200, Tomi Valkeinen  
wrote:
> Hi Grant,
> 
> Ping.
> 
> Are you fine with me proceeding with the current V4L2 port/endpoint
> bindings?

Sorry, this thread didn't make it past my email filters. Yes, go ahead.

g.

[PATCH] drm/exynos: remove DRIVER_HAVE_IRQ feature

[Daniel Kurtz]

On Fri, Mar 21, 2014 at 2:39 PM, Joonyoung Shim  
wrote:
> Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses
> driver specific one instead of routine of drm framework to
> install/uninstall irq handler.

Wouldn't that break synchronous drm_wait_vblank()?
 (drm_wait_vblank where _DRM_VBLANK_EVENT is not set in request.type)

-Dan

>
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  3 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 --
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c | 10 --
>  3 files changed, 1 insertion(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index c204b4e..dd7d18f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -291,8 +291,7 @@ static const struct file_operations 
> exynos_drm_driver_fops = {
>  };
>
>  static struct drm_driver exynos_drm_driver = {
> -   .driver_features= DRIVER_HAVE_IRQ | DRIVER_MODESET |
> -   DRIVER_GEM | DRIVER_PRIME,
> +   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
> .load   = exynos_drm_load,
> .unload = exynos_drm_unload,
> .open   = exynos_drm_open,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index a20440c..37455f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -715,16 +715,6 @@ out:
>  static int fimd_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
>  {
> /*
> -* enable drm irq mode.
> -* - with irq_enabled = true, we can use the vblank feature.
> -*
> -* P.S. note that we wouldn't use drm irq handler but
> -*  just specific driver own one instead because
> -*  drm framework supports only one irq handler.
> -*/
> -   drm_dev->irq_enabled = true;
> -
> -   /*
>  * with vblank_disable_allowed = true, vblank interrupt will be 
> disabled
>  * by drm timer once a current process gives up ownership of
>  * vblank event.(after drm_vblank_put function is called)
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index ddaaedd..b4c5f95 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -382,16 +382,6 @@ static void vidi_fake_vblank_handler(struct work_struct 
> *work)
>  static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
>  {
> /*
> -* enable drm irq mode.
> -* - with irq_enabled = true, we can use the vblank feature.
> -*
> -* P.S. note that we wouldn't use drm irq handler but
> -*  just specific driver own one instead because
> -*  drm framework supports only one irq handler.
> -*/
> -   drm_dev->irq_enabled = true;
> -
> -   /*
>  * with vblank_disable_allowed = true, vblank interrupt will be 
> disabled
>  * by drm timer once a current process gives up ownership of
>  * vblank event.(after drm_vblank_put function is called)
> --
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #10 from Alex Deucher  ---
Created attachment 96170
  --> https://bugs.freedesktop.org/attachment.cgi?id=96170=edit
disable some dpm features

Does the attached kernel patch help?  If so, can you narrow down what part of
it helps?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/d63cf2cc/attachment.html>

[linux-next] WARNING at drm_mode_connector_list_update

[Sergey Senozhatsky]

On (03/21/14 13:49), Sergey Senozhatsky wrote:
> On (03/21/14 13:37), Sergey Senozhatsky wrote:
> > [   18.707077] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:1030 
> > drm_mode_connector_list_update+0x2f/0xe8 [drm]()
> >
> [   18.704470] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:119 
> drm_mode_probed_add+0x2b/0x48 [drm]()
>


[   14.747677] WARNING: CPU: 2 PID: 189 at 
drivers/gpu/drm/drm_crtc_helper.c:256 drm_helper_crtc_in_use+0x2c/0x71 
[drm_kms_helper]()
[   14.748164] Modules linked in: radeon(+) i2c_algo_bit drm_kms_helper ttm 
crc32c_intel drm broadcom microcode psmouse evdev lpc_ich tg3 battery i2c_i801 
button processor ac wmi ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom sd_mod ahci
[   14.750668] CPU: 2 PID: 189 Comm: systemd-udevd Tainted: G    W 
3.14.0-rc7-next-20140321-dbg-dirty #192
[   14.751152] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[   14.751655]   8801523cba08 813ba2d7 

[   14.752424]  8801523cba40 8103a3af a0145355 
880098fbf000
[   14.753183]  88015277e800 880098fbf000  
8801523cba50
[   14.753945] Call Trace:
[   14.754237]  [] dump_stack+0x4e/0x7a
[   14.754537]  [] warn_slowpath_common+0x75/0x8e
[   14.754836]  [] ? drm_helper_crtc_in_use+0x2c/0x71 
[drm_kms_helper]
[   14.755346]  [] warn_slowpath_null+0x15/0x17
[   14.755648]  [] drm_helper_crtc_in_use+0x2c/0x71 
[drm_kms_helper]
[   14.756148]  [] 
drm_helper_disable_unused_functions+0xc1/0xfd [drm_kms_helper]
[   14.756707]  [] radeon_fbdev_init+0xad/0xca [radeon]
[   14.757056]  [] radeon_modeset_init+0x75e/0x930 [radeon]
[   14.757402]  [] radeon_driver_load_kms+0xc0/0x16c [radeon]
[   14.757721]  [] drm_dev_register+0x79/0xef [drm]
[   14.758033]  [] drm_get_pci_dev+0xfa/0x1c5 [drm]
[   14.758333]  [] ? kfree+0xc8/0x123
[   14.758687]  [] ? radeon_pci_probe+0x91/0xaa [radeon]
[   14.759029]  [] radeon_pci_probe+0xa3/0xaa [radeon]
[   14.759336]  [] pci_device_probe+0x6e/0xcf
[   14.759634]  [] driver_probe_device+0x98/0x1c2
[   14.759934]  [] __driver_attach+0x58/0x7a
[   14.760232]  [] ? __device_attach+0x38/0x38
[   14.760530]  [] bus_for_each_dev+0x76/0x80
[   14.760829]  [] driver_attach+0x19/0x1b
[   14.761123]  [] bus_add_driver+0x101/0x1cb
[   14.761422]  [] driver_register+0x89/0xc5
[   14.761718]  [] ? 0xa02aefff
[   14.762016]  [] __pci_register_driver+0x46/0x48
[   14.762330]  [] drm_pci_init+0x69/0xea [drm]
[   14.762624]  [] ? 0xa02aefff
[   14.762960]  [] radeon_init+0x97/0x1000 [radeon]
[   14.763263]  [] do_one_initcall+0x7f/0x105
[   14.763573]  [] ? set_memory_nx+0x3b/0x3d
[   14.763870]  [] load_module+0x15a1/0x1ba9
[   14.764168]  [] ? store_uevent+0x35/0x35
[   14.764469]  [] ? map_vm_area+0x29/0x3b
[   14.764767]  [] ? __vmalloc_node_range+0x143/0x1a5
[   14.765065]  [] SyS_init_module+0xa0/0xaf
[   14.765365]  [] tracesys+0xd4/0xd9
[   14.765661] ---[ end trace f5ac5b2194c7ea98 ]---
[   15.267565] [ cut here ]


[   15.267887] WARNING: CPU: 0 PID: 189 at 
drivers/gpu/drm/drm_crtc_helper.c:131 
drm_helper_probe_single_connector_modes+0x40/0x2d1 [drm_kms_helper]()
[   15.268361] Modules linked in: radeon(+) i2c_algo_bit drm_kms_helper ttm 
crc32c_intel drm broadcom microcode psmouse evdev lpc_ich tg3 battery i2c_i801 
button processor ac wmi ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom sd_mod ahci
[   15.270769] CPU: 0 PID: 189 Comm: systemd-udevd Tainted: G    W 
3.14.0-rc7-next-20140321-dbg-dirty #192
[   15.271235] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[   15.271710]   8801523cb930 813ba2d7 

[   15.272430]  8801523cb968 8103a3af a014647d 
8801527a2400
[   15.273143]   88015277e800 2000 
8801523cb978
[   15.273857] Call Trace:
[   15.274122]  [] dump_stack+0x4e/0x7a
[   15.274390]  [] warn_slowpath_common+0x75/0x8e
[   15.274659]  [] ? 
drm_helper_probe_single_connector_modes+0x40/0x2d1 [drm_kms_helper]
[   15.275122]  [] warn_slowpath_null+0x15/0x17
[   15.275391]  [] 
drm_helper_probe_single_connector_modes+0x40/0x2d1 [drm_kms_helper]
[   15.275868]  [] 
drm_fb_helper_probe_connector_modes+0x41/0x54 [drm_kms_helper]
[   15.276340]  [] drm_fb_helper_initial_config+0x1ab/0x43c 
[drm_kms_helper]
[   15.276803]  [] ? warn_slowpath_common+0x84/0x8e
[   15.277071]  [] ? drm_helper_crtc_in_use+0x2c/0x71 
[drm_kms_helper]
[   15.277531]  [] ? warn_slowpath_null+0x15/0x17
[   15.277833]  [] radeon_fbdev_init+0xb8/0xca [radeon]
[   15.278128]  [] radeon_modeset_init+0x75e/0x930 [radeon]
[   15.278417]  [] radeon_driver_load_kms+0xc0/0x16c [radeon]
[   15.278696]  [] drm_dev_register+0x79/0xef [drm]
[   15.284786]  [] drm_get_pci_dev+0xfa/0x1c5 [drm]
[   15.285063]  [] ? kfree+0xc8/0x123
[   15.28535

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

[Sebastian Hesselbarth]

On 03/21/2014 11:55 AM, Jean-Francois Moine wrote:
> The tda998x driver accepts only 3 chips from the TDA998x family.
> This patch changes the driver compatible strings to these chips.

Jean-Francois,

be careful with building a DT binding from a Linux driver. Although
we constantly struggle to define a binding independent of Linux, it
should not reflect what Linux is capable of but describe the HW in
general.

> Signed-off-by: Jean-Francois Moine 
> ---
> v2: change the subject to drm/i2c
> This patch applies after
>   drm/i2c: tda998x: Fix lack of required reg in DT documentation
> ---
>   Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 4 ++--
>   drivers/gpu/drm/i2c/tda998x_drv.c | 4 +++-
>   2 files changed, 5 insertions(+), 3 deletions(-)
> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
> b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> index fc7effa..e3f3d65 100644
> --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> @@ -1,7 +1,7 @@
>   Device-Tree bindings for the NXP TDA998x HDMI transmitter
>
>   Required properties;
> -  - compatible: must be "nxp,tda998x"
> +  - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"

There is a "DT is ABI" policy and although there is no mainline Linux
user of current compatible, the correct way would be to deprecate
"nxp,tda998x" and introduce new compatibles.

Also, as long as we don't know about any major differences between
9989, 1998[89] it is fine to just have one of them defined. As soon
as we discover any difference that cannot be solved in another way,
we can add a new compatible.

What we _know_ is that 998[134] are different from 9989,1998[89]
with respect to additional CEC feature. But we also _know_ that the
exact version/revision of 9989,1998[89] can be probed from i2c
registers.

DT maintainers will know better, but as long as we have no prove that
998[134] can also be properly distinguished by i2c registers, just add
"nxp,tda9989" (which was probably the first revision released) and
assume 1998[89] are "compatible enough". Or add all three and make
"nxp,tda9989" the mandatory compatible.

You can leave out 998[134] for now.

> - reg: I2C address
>

The line above and below reg property look like there is a tab. If
so, can you please get rid of the blank line above and fix the line
below?

> @@ -20,7 +20,7 @@ Optional properties:
>   Example:
>
>   tda998x: hdmi-encoder {
> - compatible = "nxp,tda998x";
> + compatible = "nxp,tda19988";

Depending on above decision this becomes either

compatible = "nxp,tda9989";

or

compatible = "nxp,tda19988", "nxp,tda9989";

>   reg = <0x70>;
>   interrupt-parent = <>;
>   interrupts = <27 2>;/* falling edge */
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 48af5ca..fd6751c 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1367,7 +1367,9 @@ fail:
>
>   #ifdef CONFIG_OF
>   static const struct of_device_id tda998x_dt_ids[] = {
> - { .compatible = "nxp,tda998x", },
> + { .compatible = "nxp,tda9989", },
> + { .compatible = "nxp,tda19988", },
> + { .compatible = "nxp,tda19989", },

Independent of the decision above, just "nxp,tda9989" is
sufficient.

Sebastian

>   { }
>   };
>   MODULE_DEVICE_TABLE(of, tda998x_dt_ids);
>

[PATCH] ARM: dts: exynos4210-universal: add fimd polarization settings

[Inki Dae]

Hi Andrzej,


2014-03-20 22:26 GMT+09:00 Andrzej Hajda :
> The patch adds polarization flags to fimd node.
> It fixes parallel display support.
>
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki,
>
> Since polarization patches were not merged, polarization
> settings should be provided to fimd via properties.
> This patch fixes it.
>

Just let me integrate it to old one, 'ARM: dts: exynos4210-universal:
add exynos/fimd node'.

Thanks,
Inki Dae

> Regards
> Andrzej
> ---
>  arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
> b/arch/arm/boot/dts/exynos4210-universal_c210.dts
> index 21ca0b978..477208d 100644
> --- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
> +++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
> @@ -351,6 +351,8 @@
> pinctrl-0 = <_clk>, <_data24>;
> pinctrl-names = "default";
> status = "okay";
> +   samsung,invert-vden;
> +   samsung,invert-vclk;
> display-timings {
> timing {
> clock-frequency = <23492370>;
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 76223] [radeonsi] luxmark segfault

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

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

--- Comment #1 from Tom Stellard  ---
This back trace doesn't include any symbols from LLVM or Mesa.  Were there any
errors printed to the console?  Are there debugging flags or environment
variables you can enable to get more information?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/65dc0ad5/attachment.html>

[RFC 3/4] drm: exynos: add IELCD post processor

[Sachin Kamat]

On 19 March 2014 19:52, Ajay Kumar  wrote:
> Add post processor ops for IELCD and their support functions.
> Expose an interface for the FIMD to register IELCD PP.
[snip]
> +
> +#define exynos_ielcd_readl(addr)   readl(ielcd->exynos_ielcd_base + addr)
> +#define exynos_ielcd_writel(addr, val) \

nit: The order of arguments could be retained same as writel (i.e.,
val, addr) for ease of
reading.

> +   writel(val, ielcd->exynos_ielcd_base + addr)

> +#define IELCD_TIMEOUT_CNT  1000
> +
> +struct ielcd_context {
> +   void __iomem*exynos_ielcd_base;
> +   unsignedvdisplay;
> +   unsignedvsync_len;
> +   unsignedvbpd;
> +   unsignedvfpd;
> +   unsignedhdisplay;
> +   unsignedhsync_len;
> +   unsignedhbpd;
> +   unsignedhfpd;
> +   unsignedvidcon0;
> +   unsignedvidcon1;
> +};
> +
> +static int ielcd_logic_start(struct ielcd_context *ielcd)
> +{
> +   exynos_ielcd_writel(IELCD_AUXCON, IELCD_MAGIC_KEY);
> +
> +   return 0;
> +}

The return type could be made void.

> +
> +static int exynos_ielcd_hw_trigger_check(struct ielcd_context *ielcd)
> +{
> +   unsigned int cfg;
> +   unsigned int count = 0;
> +
> +   cfg = exynos_ielcd_readl(IELCD_TRIGCON);
> +   cfg &= ~(SWTRGCMD_W0BUF | TRGMODE_W0BUF);
> +   cfg |= (SWTRGCMD_W0BUF | TRGMODE_W0BUF);
> +   exynos_ielcd_writel(IELCD_TRIGCON, cfg);
> +
> +   do {
> +   cfg = exynos_ielcd_readl(IELCD_SHADOWCON);
> +   cfg |= IELCD_W0_SW_SHADOW_UPTRIG;
> +   exynos_ielcd_writel(IELCD_SHADOWCON, cfg);
> +
> +   cfg = exynos_ielcd_readl(IELCD_VIDCON0);
> +   cfg |= IELCD_SW_SHADOW_UPTRIG;
> +   exynos_ielcd_writel(IELCD_VIDCON0, cfg);
> +
> +   count++;
> +   if (count > IELCD_TIMEOUT_CNT) {

The 2 lines could be combined as:
if (++count > IELCD_TIMEOUT_CNT) {

> +   DRM_ERROR("ielcd start fail\n");
> +   return -EBUSY;
> +   }
> +   udelay(10);
> +   } while (exynos_ielcd_readl(IELCD_WINCON0) & IELCD_TRGSTATUS);

Also this check could be moved inside the loop and break if 0 whereas this could
while (1) here.

> +
> +   return 0;
> +}
> +
> +static int exynos_ielcd_display_on(struct ielcd_context *ielcd)
> +{
> +   unsigned int cfg;
> +
> +   cfg = exynos_ielcd_readl(IELCD_VIDCON0);
> +   cfg |= (VIDCON0_ENVID | VIDCON0_ENVID_F);
> +   exynos_ielcd_writel(IELCD_VIDCON0, cfg);
> +
> +   return exynos_ielcd_hw_trigger_check(ielcd);
> +}
> +
> +int exynos_ielcd_display_off(void *pp_ctx)
> +{
> +   struct ielcd_context *ielcd = pp_ctx;
> +   unsigned int cfg, ielcd_count = 0;
> +   int ret = 0;

initialization not needed.

> +
> +   cfg = exynos_ielcd_readl(IELCD_VIDCON0);
> +   cfg &= ~(VIDCON0_ENVID | VIDCON0_ENVID_F);
> +
> +   exynos_ielcd_writel(IELCD_VIDCON0, cfg);
> +
> +   do {
> +   if (++ielcd_count > IELCD_TIMEOUT_CNT) {
> +   DRM_ERROR("ielcd off TIMEDOUT\n");
> +   ret = -ETIMEDOUT;
> +   break;
> +   }
> +
> +   if (!(exynos_ielcd_readl(IELCD_VIDCON1) &
> +   VIDCON1_LINECNT_MASK)) {
> +   ret = 0;
> +   break;
> +   }
> +   udelay(200);
> +   } while (1);
> +
> +   return ret;
> +}
> +
> +static void exynos_ielcd_config_rgb(struct ielcd_context *ielcd)
> +{
> +   unsigned int cfg;
> +
> +   cfg = exynos_ielcd_readl(IELCD_VIDCON0);
> +   cfg &= ~(VIDCON0_VIDOUT_MASK | VIDCON0_VCLK_MASK);
> +   cfg |= VIDCON0_VIDOUT_RGB;
> +   cfg |= VIDCON0_VCLK_NORMAL;
> +
> +   exynos_ielcd_writel(IELCD_VIDCON0, cfg);
> +}
> +
> +int exynos_ielcd_power_on(void *pp_ctx)
> +{
> +   struct ielcd_context *ielcd = pp_ctx;
> +   unsigned int cfg;
> +   int ret = 0;
> +
> +   ielcd_logic_start(ielcd);
> +   ielcd_set_polarity(ielcd);
> +
> +   ielcd_set_lcd_size(ielcd);
> +   ielcd_set_timing(ielcd);
> +
> +   /* window0 setting , fixed */
> +   cfg = WINCONx_ENLOCAL | WINCON0_BPPMODE_24BPP_888 | WINCONx_ENWIN;
> +   exynos_ielcd_writel(IELCD_WINCON0, cfg);
> +
> +   exynos_ielcd_config_rgb(ielcd);
> +
> +   ret = exynos_ielcd_display_on(ielcd);
> +   if (ret) {
> +   DRM_ERROR("IELCD failed to start\n");
> +   return ret;
> +   }
> +
> +   return 0;

The above block could be simplified as:
   ret = exynos_ielcd_display_on(ielcd);
   if (ret)
  DRM_ERROR(...);

   return ret;
> +}
> +
> +static 

[PATCH] drm/ttm: remove fence_lock

[Thomas Hellstrom]

On 03/21/2014 01:12 PM, Maarten Lankhorst wrote:
> Hey,
>
> op 21-03-14 09:27, Thomas Hellstrom schreef:
>> On 03/21/2014 12:55 AM, Dave Airlie wrote:
>>> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse 
>>> wrote:
 On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
>> Op 18-10-12 13:55, Thomas Hellstrom schreef:
>>> On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
 Op 18-10-12 13:02, Thomas Hellstrom schreef:
> On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 18-10-12 09:59, Thomas Hellstrom schreef:
>>> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
 Hi, Maarten,

 As you know I have been having my doubts about this change.
 To me it seems insane to be forced to read the fence
 pointer under a
 reserved lock, simply because when you take the reserve
 lock, another
 process may have it and there is a substantial chance that
 that process
 will also be waiting for idle while holding the reserve lock.
>> I think it makes perfect sense, the only times you want to
>> read the fence
>> is when you want to change the members protected by the
>> reservation.
> No, that's not true. A typical case (or the only case)
> is where you want to do a map with no_wait semantics. You will
> want
> to be able to access a buffer's results even if the eviction code
> is about to schedule an unbind from the GPU, and have the buffer
> reserved?
 Well either block on reserve or return -EBUSY if reserved,
 presumably the
 former..

 ttm_bo_vm_fault does the latter already, anyway
>>> ttm_bo_vm_fault only trylocks to avoid a deadlock with mmap_sem,
>>> it's really
>>> a waiting reserve but for different reasons. Typically a
>>> user-space app will keep
>>> asynchronous maps to TTM during a buffer lifetime, and the
>>> buffer lifetime may
>>> be long as user-space apps keep caches.
>>> That's not the same as accessing a buffer after the GPU is done
>>> with it.
>> Ah indeed.
 You don't need to hold the reservation while performing the
 wait itself though,
 you could check if ttm_bo_wait(no_wait_gpu = true) returns
 -EBUSY, and if so
 take a ref to the sync_obj member and then wait after
 unreserving. You won't
 reset sync_obj member to NULL in that case, but that should be
 harmless.
 This will allow you to keep the reservations fast and short.
 Maybe a helper
 would be appropriate for this since radeon and nouveau both
 seem to do this.

>>> The problem is that as long as other users are waiting for idle
>>> with reservation
>>> held, for example to switch GPU engine or to delete a GPU bind,
>>> waiting
>>> for reserve will in many case mean wait for GPU.
>> This example sounds inefficient, I know nouveau can do this, but
>> this essentially
>> just stalls the gpu entirely. I think guess you mean functions
>> like nouveau_gem_object_close?
>> It wouldn't surprise me if performance in nouveau could be
>> improved simply by
>> fixing those cases up instead, since it stalls the application
>> completely too for other uses.
>>
> Please see the Nouveau cpu_prep patch as well.
>
> While there are a number of cases that can be fixed up, also in
> Radeon, there's no way around that reservation
> is a heavyweight lock that, particularly on simpler hardware without
> support for fence ordering
> with barriers and / or "semaphores" and accelerated eviction will be
> held while waiting for idle.
>
> As such, it is unsuitable to protect read access to the fence
> pointer. If the intention is to keep a single fence pointer
> I think the best solution is to allow reading the fence pointer
> outside reservation, but make sure this can be done
> atomically. If the intention is to protect an array or list of fence
> pointers, I think a spinlock is the better solution.
>
> /Thomas
 Just wanted to point out that like Thomas i am concern about having to
 have object reserved when waiting on its associated fence. I fear it
 will hurt us somehow.

 I will try to spend couple days stress testing your branch on radeon
 trying to see if it hurts performance anyhow with current use case.

>>> I've been trying to figure out what to do with Maarten's patches going
>>> forward since they are essential for all kinds of SoC people,
>>>
>>> However I'm still not 100% sure I believe either the fact that the
>>> problem is anything more than a microoptimisation, and possibly a
>>> premature one 

[linux-next] WARNING at drm_mode_connector_list_update

[Sergey Senozhatsky]

On (03/21/14 13:37), Sergey Senozhatsky wrote:
> [   18.707077] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:1030 
> drm_mode_connector_list_update+0x2f/0xe8 [drm]()
>


[   18.704470] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:119 
drm_mode_probed_add+0x2b/0x48 [drm]()
[   18.704479] Modules linked in: crc32c_intel microcode radeon(+) broadcom 
i2c_algo_bit psmouse drm_kms_helper tg3 ttm drm evdev wmi button battery 
processor ac lpc_ich i2c_i801 ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom 
sd_mod ahci
[   18.704480] CPU: 2 PID: 175 Comm: systemd-udevd Tainted: GW 
3.14.0-rc7-next-20140321-dbg-dirty #189
[   18.704481] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[   18.704482]   88015217f830 813ba2d7 

[   18.704484]  88015217f868 8103a3af a0157186 
880037475400
[   18.704485]  8801521e2000 a01669d0 0008 
88015217f878
[   18.704485] Call Trace:
[   18.704487]  [] dump_stack+0x4e/0x7a
[   18.704489]  [] warn_slowpath_common+0x75/0x8e
[   18.704499]  [] ? drm_mode_probed_add+0x2b/0x48 [drm]
[   18.704501]  [] warn_slowpath_null+0x15/0x17
[   18.704511]  [] drm_mode_probed_add+0x2b/0x48 [drm]
[   18.704521]  [] drm_add_edid_modes+0x270/0xc8d [drm]
[   18.704548]  [] radeon_ddc_get_modes+0xdd/0xf0 [radeon]
[   18.704573]  [] radeon_vga_get_modes+0x9/0xb [radeon]
[   18.704576]  [] 
drm_helper_probe_single_connector_modes+0x137/0x2d1 [drm_kms_helper]
[   18.704580]  [] 
drm_fb_helper_probe_connector_modes+0x41/0x54 [drm_kms_helper]
[   18.704583]  [] drm_fb_helper_initial_config+0x1ab/0x43c 
[drm_kms_helper]
[   18.704585]  [] ? warn_slowpath_common+0x84/0x8e
[   18.704588]  [] ? drm_helper_crtc_in_use+0x2c/0x71 
[drm_kms_helper]
[   18.704589]  [] ? warn_slowpath_null+0x15/0x17
[   18.704616]  [] radeon_fbdev_init+0xb8/0xca [radeon]
[   18.704645]  [] radeon_modeset_init+0x75e/0x930 [radeon]
[   18.704668]  [] radeon_driver_load_kms+0xc0/0x16c [radeon]
[   18.704675]  [] drm_dev_register+0x79/0xef [drm]
[   18.704684]  [] drm_get_pci_dev+0xfa/0x1c5 [drm]
[   18.704685]  [] ? kfree+0xc8/0x123
[   18.704707]  [] ? radeon_pci_probe+0x91/0xaa [radeon]
[   18.704728]  [] radeon_pci_probe+0xa3/0xaa [radeon]
[   18.704730]  [] pci_device_probe+0x6e/0xcf
[   18.704732]  [] driver_probe_device+0x98/0x1c2
[   18.704733]  [] __driver_attach+0x58/0x7a
[   18.704735]  [] ? __device_attach+0x38/0x38
[   18.704736]  [] bus_for_each_dev+0x76/0x80
[   18.704738]  [] driver_attach+0x19/0x1b
[   18.704739]  [] bus_add_driver+0x101/0x1cb
[   18.704741]  [] driver_register+0x89/0xc5
[   18.704742]  [] ? 0xa02c1fff
[   18.704744]  [] __pci_register_driver+0x46/0x48
[   18.704752]  [] drm_pci_init+0x69/0xea [drm]
[   18.704753]  [] ? 0xa02c1fff
[   18.704772]  [] radeon_init+0x97/0x1000 [radeon]
[   18.704774]  [] do_one_initcall+0x7f/0x105
[   18.704776]  [] ? set_memory_nx+0x3b/0x3d
[   18.704778]  [] load_module+0x15a1/0x1ba9
[   18.704780]  [] ? store_uevent+0x35/0x35
[   18.704782]  [] ? map_vm_area+0x29/0x3b
[   18.704783]  [] ? __vmalloc_node_range+0x143/0x1a5
[   18.704785]  [] SyS_init_module+0xa0/0xaf
[   18.704787]  [] tracesys+0xd4/0xd9
[   18.704788] ---[ end trace e3f98afba7245f4f ]---


-ss

[linux-next] WARNING at drm_mode_connector_list_update

[Sergey Senozhatsky]

Hello,

[   18.707077] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:1030 
drm_mode_connector_list_update+0x2f/0xe8 [drm]()
[   18.707086] Modules linked in: crc32c_intel microcode radeon(+) broadcom 
i2c_algo_bit psmouse drm_kms_helper tg3 ttm drm evdev wmi button battery 
processor ac lpc_ich i2c_i801 ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom 
sd_mod ahci
[   18.707087] CPU: 2 PID: 175 Comm: systemd-udevd Tainted: GW 
3.14.0-rc7-next-20140321-dbg-dirty #189
[   18.707088] Hardware name: Acer Aspire 5741G/Aspire 5741G
, BIOS V1.20 02/08/2011
[   18.707090]   88015217f8f0 813ba2d7 

[   18.707091]  88015217f928 8103a3af a0157ca1 
8801521e2000
[   18.707093]  8801521e2048 88003747e000 8801521e2000 
88015217f938
[   18.707093] Call Trace:
[   18.707095]  [] dump_stack+0x4e/0x7a
[   18.707097]  [] warn_slowpath_common+0x75/0x8e
[   18.707107]  [] ? drm_mode_connector_list_update+0x2f/0xe8 
[drm]
[   18.707109]  [] warn_slowpath_null+0x15/0x17
[   18.707119]  [] drm_mode_connector_list_update+0x2f/0xe8 
[drm]
[   18.707122]  [] 
drm_helper_probe_single_connector_modes+0x16d/0x2d1 [drm_kms_helper]
[   18.707125]  [] 
drm_fb_helper_probe_connector_modes+0x41/0x54 [drm_kms_helper]
[   18.707129]  [] drm_fb_helper_initial_config+0x1ab/0x43c 
[drm_kms_helper]
[   18.707131]  [] ? warn_slowpath_common+0x84/0x8e
[   18.707133]  [] ? drm_helper_crtc_in_use+0x2c/0x71 
[drm_kms_helper]
[   18.707135]  [] ? warn_slowpath_null+0x15/0x17
[   18.707162]  [] radeon_fbdev_init+0xb8/0xca [radeon]
[   18.707188]  [] radeon_modeset_init+0x75e/0x930 [radeon]
[   18.707211]  [] radeon_driver_load_kms+0xc0/0x16c [radeon]
[   18.707219]  [] drm_dev_register+0x79/0xef [drm]
[   18.707227]  [] drm_get_pci_dev+0xfa/0x1c5 [drm]
[   18.707228]  [] ? kfree+0xc8/0x123
[   18.707250]  [] ? radeon_pci_probe+0x91/0xaa [radeon]
[   18.707272]  [] radeon_pci_probe+0xa3/0xaa [radeon]
[   18.707274]  [] pci_device_probe+0x6e/0xcf
[   18.707275]  [] driver_probe_device+0x98/0x1c2
[   18.707277]  [] __driver_attach+0x58/0x7a
[   18.707278]  [] ? __device_attach+0x38/0x38
[   18.707280]  [] bus_for_each_dev+0x76/0x80
[   18.707281]  [] driver_attach+0x19/0x1b
[   18.707283]  [] bus_add_driver+0x101/0x1cb
[   18.707284]  [] driver_register+0x89/0xc5
[   18.707286]  [] ? 0xa02c1fff
[   18.707287]  [] __pci_register_driver+0x46/0x48
[   18.707295]  [] drm_pci_init+0x69/0xea [drm]
[   18.707296]  [] ? 0xa02c1fff
[   18.707316]  [] radeon_init+0x97/0x1000 [radeon]
[   18.707318]  [] do_one_initcall+0x7f/0x105
[   18.707319]  [] ? set_memory_nx+0x3b/0x3d
[   18.707321]  [] load_module+0x15a1/0x1ba9
[   18.707322]  [] ? store_uevent+0x35/0x35
[   18.707324]  [] ? map_vm_area+0x29/0x3b
[   18.707326]  [] ? __vmalloc_node_range+0x143/0x1a5
[   18.707328]  [] SyS_init_module+0xa0/0xaf
[   18.707330]  [] tracesys+0xd4/0xd9
[   18.707331] ---[ end trace e3f98afba7245f57 ]---



-ss

[PATCH] drm/ttm: remove fence_lock

[Maarten Lankhorst]

Hey,

op 21-03-14 09:27, Thomas Hellstrom schreef:
> On 03/21/2014 12:55 AM, Dave Airlie wrote:
>> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse  wrote:
>>> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
 On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
> Op 18-10-12 13:55, Thomas Hellstrom schreef:
>> On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
>>> Op 18-10-12 13:02, Thomas Hellstrom schreef:
 On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 18-10-12 09:59, Thomas Hellstrom schreef:
>> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
>>> Hi, Maarten,
>>>
>>> As you know I have been having my doubts about this change.
>>> To me it seems insane to be forced to read the fence pointer under a
>>> reserved lock, simply because when you take the reserve lock, 
>>> another
>>> process may have it and there is a substantial chance that that 
>>> process
>>> will also be waiting for idle while holding the reserve lock.
> I think it makes perfect sense, the only times you want to read the 
> fence
> is when you want to change the members protected by the reservation.
 No, that's not true. A typical case (or the only case)
 is where you want to do a map with no_wait semantics. You will want
 to be able to access a buffer's results even if the eviction code
 is about to schedule an unbind from the GPU, and have the buffer
 reserved?
>>> Well either block on reserve or return -EBUSY if reserved, presumably 
>>> the
>>> former..
>>>
>>> ttm_bo_vm_fault does the latter already, anyway
>> ttm_bo_vm_fault only trylocks to avoid a deadlock with mmap_sem, it's 
>> really
>> a waiting reserve but for different reasons. Typically a user-space app 
>> will keep
>> asynchronous maps to TTM during a buffer lifetime, and the buffer 
>> lifetime may
>> be long as user-space apps keep caches.
>> That's not the same as accessing a buffer after the GPU is done with it.
> Ah indeed.
>>> You don't need to hold the reservation while performing the wait itself 
>>> though,
>>> you could check if ttm_bo_wait(no_wait_gpu = true) returns -EBUSY, and 
>>> if so
>>> take a ref to the sync_obj member and then wait after unreserving. You 
>>> won't
>>> reset sync_obj member to NULL in that case, but that should be harmless.
>>> This will allow you to keep the reservations fast and short. Maybe a 
>>> helper
>>> would be appropriate for this since radeon and nouveau both seem to do 
>>> this.
>>>
>> The problem is that as long as other users are waiting for idle with 
>> reservation
>> held, for example to switch GPU engine or to delete a GPU bind, waiting
>> for reserve will in many case mean wait for GPU.
> This example sounds inefficient, I know nouveau can do this, but this 
> essentially
> just stalls the gpu entirely. I think guess you mean functions like 
> nouveau_gem_object_close?
> It wouldn't surprise me if performance in nouveau could be improved 
> simply by
> fixing those cases up instead, since it stalls the application completely 
> too for other uses.
>
 Please see the Nouveau cpu_prep patch as well.

 While there are a number of cases that can be fixed up, also in
 Radeon, there's no way around that reservation
 is a heavyweight lock that, particularly on simpler hardware without
 support for fence ordering
 with barriers and / or "semaphores" and accelerated eviction will be
 held while waiting for idle.

 As such, it is unsuitable to protect read access to the fence
 pointer. If the intention is to keep a single fence pointer
 I think the best solution is to allow reading the fence pointer
 outside reservation, but make sure this can be done
 atomically. If the intention is to protect an array or list of fence
 pointers, I think a spinlock is the better solution.

 /Thomas
>>> Just wanted to point out that like Thomas i am concern about having to
>>> have object reserved when waiting on its associated fence. I fear it
>>> will hurt us somehow.
>>>
>>> I will try to spend couple days stress testing your branch on radeon
>>> trying to see if it hurts performance anyhow with current use case.
>>>
>> I've been trying to figure out what to do with Maarten's patches going
>> forward since they are essential for all kinds of SoC people,
>>
>> However I'm still not 100% sure I believe either the fact that the
>> problem is anything more than a microoptimisation, and possibly a
>> premature one at that, this needs someone to start suggesting
>> benchmarks we can run and a driver set to run them on, otherwise I'm
>> starting to tend towards we are taking about an optimisation we can
>> fix 

[pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked()

[Bjorn Helgaas]

On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu  wrote:
> // CC Stephane for RAPL related bug
>
> Bjorn, sorry this bug report is mis-titled. The only new bug that show
> up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so
> it's hard to reproduce and the bisect is likely not accurate.  I'll
> retry the bisect with more repeat count. Sorry for the disturbing!

This testing is potentially very useful, but only if we don't have
many false positives.  I spent a lot of time trying to figure this
out, and it turned out not to be a problem at all.

As a procedural question, can you help me figure out how to handle a
report like this?  What I *hoped* for would be:

  - the config you used
  - the dmesg log from the newest good commit
  - the dmesg log from the oldest bad commit (the one you bisected to)
  - maybe a hint about how I can reproduce the problem, e.g., the qemu
config I need

You did supply the config, which is good.  But you only supplied one
dmesg log, and it doesn't seem to be from the oldest bad commit.  In
fact, it seems to be from some commit that isn't actually in either
Linus' tree or in linux-next.  So I don't know what the connection is
with the bad commit.

What should I do to try to debug a report like this?  Where should I start?

Bjorn

> [2.812392] Unpacking initramfs...
> [2.812392] Unpacking initramfs...
> [4.937582] Freeing initrd memory: 3276K (93cbd000 - 93ff)
> [4.937582] Freeing initrd memory: 3276K (93cbd000 - 93ff)
> [4.952113] BUG: unable to handle kernel
> [4.952113] BUG: unable to handle kernel NULL pointer dereferenceNULL 
> pointer dereference at 003c
>  at 003c
> [4.952871] IP:
> [4.952871] IP: [<81c439fb>] rapl_pmu_init+0xed/0x165
>  [<81c439fb>] rapl_pmu_init+0xed/0x165
> [4.954190] *pde = 
> [4.954190] *pde = 
>
> [4.954619] Oops:  [#1]
> [4.954619] Oops:  [#1]
>
> [4.955440] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 3.14.0-rc1-00023-gaa11fc5 #1
> [4.955440] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 3.14.0-rc1-00023-gaa11fc5 #1
> [4.956050] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [4.956050] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [4.956672] task: 80030c20 ti: 80032000 task.ti: 80032000
> [4.956672] task: 80030c20 ti: 80032000 task.ti: 80032000
> [4.957295] EIP: 0060:[<81c439fb>] EFLAGS: 0246 CPU: 0
> [4.957295] EIP: 0060:[<81c439fb>] EFLAGS: 0246 CPU: 0
> [4.957831] EIP is at rapl_pmu_init+0xed/0x165
> [4.957831] EIP is at rapl_pmu_init+0xed/0x165
>
> Full dmesg attached.
>
> Thanks,
> Fengguang
>
> On Thu, Mar 20, 2014 at 04:50:08PM -0600, Bjorn Helgaas wrote:
>> On Thu, Mar 20, 2014 at 6:41 AM, Fengguang Wu  
>> wrote:
>> > Greetings,
>> >
>> > I got the below dmesg and the first bad commit is
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/resource
>> >
>> > commit aa11fc58dc71c27701b1f9a529a36a38d4337722
>> > Author: Bjorn Helgaas 
>> > AuthorDate: Fri Mar 7 13:39:01 2014 -0700
>> > Commit: Bjorn Helgaas 
>> > CommitDate: Wed Mar 19 15:00:16 2014 -0600
>> >
>> > PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region()
>> >
>> > When allocating space from a bus resource, i.e., from apertures 
>> > leading to
>> > this bus, make sure the entire resource type matches.  The previous 
>> > code
>> > assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a 
>> > single bit
>> > set, but this is not true.  IORESOURCE_TYPE_BITS is really an 
>> > enumeration,
>> > and we have to check all the bits.
>> >
>> > See 72dcb1197228 ("resources: Add register address resource type").
>> >
>> > No functional change.  If we used this path for allocating IRQs, DMA
>> > channels, or bus numbers, this would fix a bug because those types are
>> > indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM.  But 
>> > we
>> > don't, so this shouldn't make any difference.
>> >
>> > Signed-off-by: Bjorn Helgaas 
>>
>> Thanks (I think).  I'm afraid I'm going to need some more help to
>> debug this.  I built aa11fc58dc with the config you supplied and
>> booted it on qemu with no real issues (it didn't boot all the way
>> because the config doesn't include a driver for my root disk, but
>> that's to be expected).
>>
>> The dmesg you supplied is for some other commit 2d18516 that I don't
>> have, so I'm confused about why it's not from aa11fc58dc.
>>
>> I did reproduce what appears to be basically the same problem with
>> a654dc797f3e, which is the 20140320 linux-next tree.  I backed up to
>> 93ecdc077282, which is where pci/next was merged (this includes
>> aa11fc58dc), but I could not reproduce the problem there.
>>
>> So bottom line, I'm confused because your bisection doesn't match what
>> I'm seeing, and I don't want to spend more time flailing around.
>>
>> Bjorn
>>
>>
>> > 

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

[Russell King - ARM Linux]

On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote:
> However, we (as in the V4L2 community, and me personally) would have 
> appreciated to be CC'ed on the proposal. As you might know we already had a 
> solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
> core/v4l2-async.c.

There's a lot of people who would have liked to be on the Cc, but there's
two problems: 1. the Cc list would be too big for mailing lists to accept
the message, and 2. finding everyone who should be on the Cc list is quite
an impossible task.

> The topic is particularly hot given that a similar solution was also
> proposed as part of the now defunct (or at least hibernating) common
> display framework. 

Yes, I am aware of CDF.  However, the annoying thing is that it's another
case of the bigger picture not being looked at - which is that we don't
need yet another subsystem specific solution to a problem which is not
subsystem specific.

The fact of the matter is that /anyone/ has the opportunity to come up
with a generic solution to this problem, and no one did... instead,
more solutions were generated - the proof is "we solved this in CDF
with a CDF specific solution". :p

> If I had replied to this mail thread without sleeping on it first I
> might not have known better and have got half-paranoid, wondereding
> whether there had been a deliberate attempt to fast-track this API
> before the V4L2 developers noticed. To be perfectly clear, there is
> *NO* implicit or explicit such accusation here, as I know better.

What would have happened is that CDF would have been raised, and there
would be a big long discussion with no real resolution.  The problem
would not have been solved (even partially).  We'd be sitting here right
now still without any kind of solution that anyone can use.

Instead, what we have right now is the opportunity for people to start
making use of this and solving the real problems they have with driver
initialisation.

For example, the IPU on iMX locks up after a number of mode changes, and
it's useful to be able to unload the driver, poke about in the hardware,
and reload it.  Without this problem fixed, that's impossible without
rebooting the kernel, because removing the driver oopses the kernel due
to the broken work-arounds that it has to do - and it has to do those
because this problem has not been solved, despite it being known about
for /years/.

> Accordingly, I would like to comment on the component API, despite the fact 
> that it has been merged in mainline already. The first thing that I believe 
> is 
> missing is documentation. Do you have any pending patch for that, either as 
> kerneldoc or as a text file for Documentation/ ? As I've read the code to 
> understand it I might have missed so design goals, so please bear with the 
> stupid questions that may follow.

There's lots of things in the kernel which you just have to read the code
for - and this is one of them at the moment. :)  (Another is PM domains...)

What I know is that this will not satisfy all your requirements - I don't
want it to initially satisfy everyone's requirements, because that's just
far too big a job, but it satisfies the common problem that most people
are suffering from and have already implemented many badly written driver
specific solutions.

In other words - this is designed to _improve_ the current situation where
we have lots of buggy implementions trying to work around this problem,
factor that code out, and fix up those problems.

Briefly, the idea is:

- there is a master device - lots of these subsystems doing this already
  have that, whether that be ALSA or DRM based stuff.
- then there are the individual component devices and their drivers.

Subsystems like ALSA and DRM are not component based subsystems.  These
subsystems have two states - either they're initialised and the entire
"card system" is known about, or they're not initialised.  There is no
possibility of a piecemeal approach, where they partially come up and
additional stuff gets added later.  With DRM, that's especially true
because of how the userspace API works - to change that probably means
changing stuff all the way through things like the X server and its
xrandr application interface.  This is probably the reason why David said
at KS that DRM isn't going to do the hotplugging of components.

The master device has a privileged position - it gets to make the decision
about which component devices are relevant to it, and when the "card system"
is fully known.  As far as DT goes, we've had a long discussion about this
approach in the past, and we've accepted this approach - we have the
"sound" node which doesn't actually refer to any hardware block, it's a
node which describes how the hardware blocks are connected together, which
gets translated into a platform device.

When a master device gets added, it gets added to the list of master
devices, and then it's asked whether all the components that it needs

I915: OOPSes on linux-3.14-rc7

[Peter Senna Tschudin]

0x6c [i915]
>>  [] do_one_initcall+0xd2/0x180
>>  [] ? set_memory_nx+0x43/0x50
>>  [] load_module+0x1bb6/0x2580
>>  [] ? store_uevent+0x40/0x40
>>  [] ? copy_module_from_fd.isra.47+0x121/0x180
>>  [] SyS_finit_module+0x86/0xb0
>>  [] system_call_fastpath+0x16/0x1b
>> ---[ end trace 628c8f95ba351f1a ]---
>>
>> WARNING: CPU: 3 PID: 124 at drivers/gpu/drm/i915/intel_display.c:450
>> i9xx_clock+0x81/0xb0 [i915]()
>> Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video
>> CPU: 3 PID: 124 Comm: systemd-udevd Tainted: GW3.14.0-rc7 #1
>> Hardware name: TOSHIBA PORTEGE R830/Portable PC, BIOS Version 4.10   
>> 01/08/2013
>>  0009 8804345f7500 8168e6d2 
>>  8804345f7538 8108199d 8804345f7608 0100
>>  0001d4c0  880434076b18 8804345f7548
>> Call Trace:
>>  [] dump_stack+0x45/0x56
>>  [] warn_slowpath_common+0x7d/0xa0
>>  [] warn_slowpath_null+0x1a/0x20
>>  [] i9xx_clock+0x81/0xb0 [i915]
>>  [] i9xx_crtc_clock_get.isra.31+0x1d0/0x2c0 [i915]
>>  [] ironlake_get_pipe_config+0x209/0x2f0 [i915]
>>  [] check_crtc_state+0x11e/0xc60 [i915]
>>  [] intel_modeset_check_state+0x2bb/0x7b0 [i915]
>>  [] ? ilk_wm_get_hw_state+0x1bc/0x2b0 [i915]
>>  [] intel_modeset_setup_hw_state+0x97e/0xc20 [i915]
>>  [] intel_modeset_gem_init+0x3d/0x50 [i915]
>>  [] i915_driver_load+0xc98/0xe10 [i915]
>>  [] drm_dev_register+0x7b/0x160 [drm]
>>  [] drm_get_pci_dev+0xa0/0x220 [drm]
>>  [] i915_pci_probe+0x3b/0x60 [i915]
>>  [] local_pci_probe+0x45/0xa0
>>  [] pci_device_probe+0xd1/0x130
>>  [] driver_probe_device+0x125/0x3a0
>>  [] __driver_attach+0x93/0xa0
>>  [] ? __device_attach+0x40/0x40
>>  [] bus_for_each_dev+0x63/0xa0
>>  [] driver_attach+0x1e/0x20
>>  [] bus_add_driver+0x180/0x250
>>  [] ? 0xa0146fff
>>  [] driver_register+0x64/0xf0
>>  [] ? 0xa0146fff
>>  [] __pci_register_driver+0x4b/0x50
>>  [] drm_pci_init+0x11a/0x130 [drm]
>>  [] ? 0xa0146fff
>>  [] i915_init+0x6a/0x6c [i915]
>>  [] do_one_initcall+0xd2/0x180
>>  [] ? set_memory_nx+0x43/0x50
>>  [] load_module+0x1bb6/0x2580
>>  [] ? store_uevent+0x40/0x40
>>  [] ? copy_module_from_fd.isra.47+0x121/0x180
>>  [] SyS_finit_module+0x86/0xb0
>>  [] system_call_fastpath+0x16/0x1b
>> ---[ end trace 628c8f95ba351f1b ]---
>>
>> WARNING: CPU: 1 PID: 124 at drivers/gpu/drm/i915/intel_display.c:857
>> intel_wait_for_pipe_off+0x1db/0x1f0 [i915]()
>> pipe_off wait timed out
>> Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video
>> CPU: 1 PID: 124 Comm: systemd-udevd Tainted: GW3.14.0-rc7 #1
>> Hardware name: TOSHIBA PORTEGE R830/Portable PC, BIOS Version 4.10   
>> 01/08/2013
>>  0009 8804345f7318 8168e6d2 8804345f7360
>>  8804345f7350 8108199d 880433404000 00070008
>>  fffb746b  880434076b10 8804345f73b0
>> Call Trace:
>>  [] dump_stack+0x45/0x56
>>  [] warn_slowpath_common+0x7d/0xa0
>>  [] warn_slowpath_fmt+0x4c/0x50
>>  [] intel_wait_for_pipe_off+0x1db/0x1f0 [i915]
>>  [] intel_disable_pipe+0xa0/0xb0 [i915]
>>  [] ironlake_crtc_disable+0xe4/0x950 [i915]
>>  [] ? intel_dump_pipe_config.isra.45+0x35e/0x370 [i915]
>>  [] __intel_set_mode+0x884/0x1600 [i915]
>>  [] intel_set_mode+0x16/0x30 [i915]
>>  [] intel_crtc_set_config+0x7bb/0x990 [i915]
>>  [] drm_mode_set_config_internal+0x5d/0xe0 [drm]
>>  [] drm_fb_helper_set_par+0x71/0xf0 [drm_kms_helper]
>>  [] fbcon_init+0x4f4/0x570
>>  [] visual_init+0xb8/0x120
>>  [] do_bind_con_driver+0x163/0x330
>>  [] do_take_over_console+0x114/0x1c0
>>  [] do_fbcon_takeover+0x63/0xd0
>>  [] fbcon_event_notify+0x60d/0x720
>>  [] notifier_call_chain+0x4c/0x70
>>  [] __blocking_notifier_call_chain+0x4d/0x70
>>  [] blocking_notifier_call_chain+0x16/0x20
>>  [] fb_notifier_call_chain+0x1b/0x20
>>  [] register_framebuffer+0x1e6/0x320
>>  [] drm_fb_helper_initial_config+0x32f/0x500 
>> [drm_kms_helper]
>>  [] ? gen6_read32+0x52/0x110 [i915]
>>  [] intel_fbdev_initial_config+0x21/0x30 [i915]
>>  [] i915_driver_load+0xdde/0xe10 [i915]
>>  [] drm_dev_register+0x7b/0x160 [drm]
>>  [] drm_get_pci_dev+0xa0/0x220 [drm]
>>  [] i915_pci_probe+0x3b/0x60 [i915]
>>  [] local_pci_probe+0x45/0xa0
>>  [] pci_device_probe+0xd1/0x130
>>  [] driver_probe_device+0x125/0x3a0
>>  [] __driver_attach+0x93/0xa0
>>  [] ? __device_attach+0x40/0x40
>>  [] bus_for_each_dev+0x63/0xa0
>>  [] driver_attach+0x1e/0x20
>>  [] bus_add_driver+0x180/0x250
>>  [] ? 0xa0146fff
>>  [] driver_register+0x64/0xf0
>>  [] ? 0xa0146fff
>>  [] __pci_register_driver+0x4b/0x50
>>  [] drm_pci_init+0x11a/0x130 [drm]
>>  [] ? 0xa0146fff
>>  [] i915_init+0x6a/0x6c [i915]
>>  [] do_one_initcall+0xd2/0x180
>>  [] ? set_memory_nx+0x43/0x50
>>  [] load_module+0x1bb6/0x2580
>>  [] ? store_uevent+0x40/0x40
>>  [] ? copy_module_from_fd.isra.47+0x121/0x180
>>  [] SyS_finit_module+0x86/0xb0
>>  [] system_call_fastpath+0x16/0x1b
>> ---[ end trace 628c8f95ba351f1c ]---
>>
>>
>> --
>> Peter
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Peter
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/x-gzip
Size: 48442 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/0e0d5387/attachment-0001.bin>

Intel G41 doesn't see any screens connected after suspend/resume

[Chris Wilson]

On Thu, Mar 20, 2014 at 07:17:00PM -0400, Nikolay Martynov wrote:
>   Yes, that seem to help. It didn't freeze anymore in 15 mins I used it. 
> Thanks!

Thanks indeed,

commit 3f5e0f06a3355a77ace053b4ffc0ac1c413cf2d0
Author: Chris Wilson 
Date:   Fri Mar 21 07:40:56 2014 +

drm/i915: Fix unsafe loop iteration over vma whilst unbinding them

On non-LLC platforms, when changing the cache level of an object, we may
need to unbind it so that prefetching across page boundaries does not
cross into a different memory domain. This requires us to unbind
conflicting vma, but we did so iterating over the objects vma in an
unsafe manner (as the list was being modified as we iterated).

The regression was introduced in
commit 3089c6f239d7d2c4cb2dd5c353e8984cf79af1d7
Author: Ben Widawsky 
Date:   Wed Jul 31 17:00:03 2013 -0700

drm/i915: make caching operate on all address spaces
apparently as far back as v3.12-rc1, but it has only just begun to
trigger real world bug reports.

Reported-and-tested-by: Nikolay Martynov 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384
Signed-off-by: Chris Wilson 
Cc: Ben Widawsky 
Signed-off-by: Daniel Vetter 

Now you can get back to your original bug :(
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

[Jean-Francois Moine]

The tda998x driver accepts only 3 chips from the TDA998x family.
This patch changes the driver compatible strings to these chips.

Signed-off-by: Jean-Francois Moine 
---
v2: change the subject to drm/i2c
This patch applies after
drm/i2c: tda998x: Fix lack of required reg in DT documentation
---
 Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 4 ++--
 drivers/gpu/drm/i2c/tda998x_drv.c | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index fc7effa..e3f3d65 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -1,7 +1,7 @@
 Device-Tree bindings for the NXP TDA998x HDMI transmitter

 Required properties;
-  - compatible: must be "nxp,tda998x"
+  - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"

   - reg: I2C address

@@ -20,7 +20,7 @@ Optional properties:
 Example:

tda998x: hdmi-encoder {
-   compatible = "nxp,tda998x";
+   compatible = "nxp,tda19988";
reg = <0x70>;
interrupt-parent = <>;
interrupts = <27 2>;/* falling edge */
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 48af5ca..fd6751c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1367,7 +1367,9 @@ fail:

 #ifdef CONFIG_OF
 static const struct of_device_id tda998x_dt_ids[] = {
-   { .compatible = "nxp,tda998x", },
+   { .compatible = "nxp,tda9989", },
+   { .compatible = "nxp,tda19988", },
+   { .compatible = "nxp,tda19989", },
{ }
 };
 MODULE_DEVICE_TABLE(of, tda998x_dt_ids);
-- 
1.9.1

[PATCH v3] drm/i2c: tda998x: Fix lack of required reg in DT documentation

[Jean-Francois Moine]

The I2C address (reg) is required for the TDA998x driver to be loaded
and initialized.

Signed-off-by: Jean-Francois Moine 
---
- v3
- change subject to drm/i2c
- v2
- don't force the I2C address to be 0x70
This patch applies to linux-next.
---
 Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index d7df01c..fc7effa 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter
 Required properties;
   - compatible: must be "nxp,tda998x"

+  - reg: I2C address
+
 Optional properties:
   - interrupts: interrupt number and trigger type
default: polling
-- 
1.9.1


-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] Circular locking dependency - DRM/CMA/MM/hotplug/...

[Laura Abbott]

On 2/18/2014 9:44 AM, Michal Nazarewicz wrote:
>> On 2014-02-12 17:33, Russell King - ARM Linux wrote:
>>> What if we did these changes:
>>>
>>> struct page *dma_alloc_from_contiguous(struct device *dev, int count,
>>> unsigned int align)
>>> {
>>> ...
>>>  mutex_lock(_mutex);
>>> ...
>>>  for (;;) {
>>>  pageno = bitmap_find_next_zero_area(cma->bitmap, 
>>> cma->count,
>>>  start, count, mask);
>>>  if (pageno >= cma->count)
>>>  break;
>>>
>>>  pfn = cma->base_pfn + pageno;
>>> +   bitmap_set(cma->bitmap, pageno, count);
>>> +   mutex_unlock(_mutex);
>>>  ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA);
>>> +   mutex_lock(_mutex);
>>>  if (ret == 0) {
>>> -   bitmap_set(cma->bitmap, pageno, count);
>>>  page = pfn_to_page(pfn);
>>>  break;
>>> -   } else if (ret != -EBUSY) {
>>> +   }
>>> +   bitmap_clear(cma->bitmap, pageno, count);
>>> +   if (ret != -EBUSY) {
>>>  break;
>>>  }
>>> ...
>>>  mutex_unlock(_mutex);
>>>  pr_debug("%s(): returned %p\n", __func__, page);
>>>  return page;
>>> }
> 
> Like Marek said, this will fail if two concurrent calls to
> alloc_contig_range are made such that they operate on the same pageblock
> (which is possible as the allocated regions do not need to be pageblock
> aligned).
> 
> Another mutex could be added just for this one call, but as I understand
> this would not solve the problem.
> 
>>> bool dma_release_from_contiguous(struct device *dev, struct page *pages,
>>>   int count)
>>> {
>>> ...
>>> +   free_contig_range(pfn, count);
>>>  mutex_lock(_mutex);
>>>  bitmap_clear(cma->bitmap, pfn - cma->base_pfn, count);
>>> -   free_contig_range(pfn, count);
>>>  mutex_unlock(_mutex);
>>> ...
>>> }
> 
> This *should* be fine.  Didn't test it.
> 

I managed to hit a different deadlock that had a similar root cause.
I also managed to independently come up with a similar solution. This
has been tested somewhat but not in wide distribution.

Thanks,
Laura

- 8< --
>From 2aa000fbd4189d967c45c4f1ac5aee812ed83082 Mon Sep 17 00:00:00 2001
From: Laura Abbott 
Date: Tue, 25 Feb 2014 11:01:19 -0800
Subject: [PATCH] cma: Remove potential deadlock situation

CMA locking is currently very coarse. The cma_mutex protects both
the bitmap and avoids concurrency with alloc_contig_range. There
are several situations which may result in a deadlock on the CMA
mutex currently, mostly involving AB/BA situations with alloc and
free. Fix this issue by protecting the bitmap with a mutex per CMA
region and use the existing mutex for protecting against concurrency
with alloc_contig_range.

Signed-off-by: Laura Abbott 
---
 drivers/base/dma-contiguous.c | 32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 165c2c2..dfb48ef 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -37,6 +37,7 @@ struct cma {
unsigned long   base_pfn;
unsigned long   count;
unsigned long   *bitmap;
+   struct mutexlock;
 };

 struct cma *dma_contiguous_default_area;
@@ -161,6 +162,7 @@ static int __init cma_activate_area(struct cma *cma)
init_cma_reserved_pageblock(pfn_to_page(base_pfn));
} while (--i);

+   mutex_init(>lock);
return 0;
 }

@@ -261,6 +263,13 @@ err:
return ret;
 }

+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
+{
+   mutex_lock(>lock);
+   bitmap_clear(cma->bitmap, pfn - cma->base_pfn, count);
+   mutex_unlock(>lock);
+}
+
 /**
  * dma_alloc_from_contiguous() - allocate pages from contiguous area
  * @dev:   Pointer to device for which the allocation is performed.
@@ -294,30 +303,41 @@ struct page *dma_alloc_from_contiguous(struct device 
*dev, int count,

mask = (1 << align) - 1;

-   mutex_lock(_mutex);

for (;;) {
+   mutex_lock(>lock);
pageno = bitmap_find_next_zero_area(cma->bitmap, cma->count,
start, count, mask);
-   if (pageno >= cma->count)
+   if (pageno >= cma->count) {
+   mutex_unlock(_mutex);
break;
+   }
+   bitmap_set(cma->bitmap, pageno, count);
+   /*
+* It's safe to drop the lock here. We've marked this region for
+* our exclusive use. If the migration fails we will take the
+

[PATCH RFC v2 0/6] drm/i2c: Move tda998x to a couple encoder/connector

[Jean-Francois Moine]

The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.

Changing the tda998x driver to a simple encoder/connector simplifies
the code of the tilcdc driver. This change is permitted by
Russell's infrastructure for componentised subsystems.

The proposed patch set does not include changes to the Armada DRM driver.
These changes should already have been prepared by Russell King, as
told in the message
  https://www.mail-archive.com/linux-media at vger.kernel.org/msg71202.html

The tilcdc part of this patch set has not been tested.

This patch set applies after the patchs:
drm/i2c: tda998x: Fix lack of required reg in DT documentation
drm/i2c: tda998x: Change the compatible strings

- v2
- fix lack of call to component_bind_all() in tilcdc_drv.c
- add tda998x configuration for non-DT systems

Jean-Francois Moine (6):
  drm/i2c: tda998x: Add the required port property
  drm/i2c: tda998x: Move tda998x to a couple encoder/connector
  drm/tilcd: dts: Add the video output port
  drm/tilcdc: Change the interface with the tda998x driver
  drm/tilcd: dts: Remove unused slave description
  ARM: AM33XX: dts: Change the tda998x description

 .../devicetree/bindings/drm/i2c/tda998x.txt|  11 +-
 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  14 +
 arch/arm/boot/dts/am335x-base0033.dts  |  28 +-
 arch/arm/boot/dts/am335x-boneblack.dts |  21 +-
 drivers/gpu/drm/i2c/tda998x_drv.c  | 323 +---
 drivers/gpu/drm/tilcdc/Makefile|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  85 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 406 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 10 files changed, 315 insertions(+), 618 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

-- 
1.9.1

[PATCH RFC v2 0/6] drm/i2c: Move tda998x to a couple encoder/connector

[Russell King - ARM Linux]

On Fri, Mar 21, 2014 at 11:27:45AM +0100, Jean-Francois Moine wrote:
> The 'slave encoder' structure of the tda998x driver asks for glue
> between the DRM driver and the encoder/connector structures.

Given how close we are to the coming merge window, that the discussion
about the of-graph bindings is still going on without concensus being
reached, and that this driver is not in staging, this needs to be
delayed until the following merge window when hopefully we have a
clearer picture about the DT side of this.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

more locking fail...

[Dave Airlie]

On Fri, Mar 21, 2014 at 9:25 AM, Dave Airlie  wrote:
> There's one in i915 lvds on ironlake, and one in nouveau later.
>
> drm_mode_probed_add locking?
>
> but also others in suspend/resume paths.
>

So I've been nice, and fixes the suspend/resume one, but the edid one
looks like a bit more auditing/typing, so I'm leaving it for you to
look at :-)

Dave.

[PATCH RFC v2 1/6] drm/i2c: tda998x: Add the required port property

[Jean-Francois Moine]

According to the media video interface, the video source and sink
ports must be identified by mutual phandles.

This patch adds the 'port' property of the tda998x (sink side).

Signed-off-by: Jean-Francois Moine 
---
 Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt 
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e3f3d65..10c5b5e 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -17,13 +17,22 @@ Optional properties:
   - video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>

+Required nodes:
+  - port: reference of the video source as described in media/video-interfaces
+
 Example:

-   tda998x: hdmi-encoder {
+   hdmi: hdmi-encoder {
compatible = "nxp,tda19988";
reg = <0x70>;
interrupt-parent = <>;
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <_camera>;
pinctrl-names = "default";
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
};
-- 
1.9.1

[PATCH] drm/helper: lock all around force mode restore

[Dave Airlie]

From: Dave Airlie 

Since Daniel documented things with a sledge hammer, we got lots of
nice backtraces in suspend/resume operations, I've check the callers
of this and they all seems safe to me,

This fixes one set of warns I reported.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc_helper.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 5d2b7a5..c0f2d62 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -983,6 +983,7 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
int encoder_dpms;
bool ret;

+   drm_modeset_lock_all(dev);
list_for_each_entry(crtc, >mode_config.crtc_list, head) {

if (!crtc->enabled)
@@ -1017,6 +1018,7 @@ void drm_helper_resume_force_mode(struct drm_device *dev)

/* disable the unused connectors while restoring the modesetting */
__drm_helper_disable_unused_functions(dev);
+   drm_modeset_unlock_all(dev);
 }
 EXPORT_SYMBOL(drm_helper_resume_force_mode);

-- 
1.8.3.1

3.14 radeon regression: radeon is broken (pci bug?)

[Alex Deucher]

On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski  
wrote:
> My system works on a 3.13 Fedora kernel.  It does not work on a
> more-or-less identically configured 3.14-rc7+ kernel.  The symptom is
> that the Plymouth password prompt flashes and them the screen goes
> blank.  Hitting escape brings back the text console, and all is well
> until X tries to start.  Then I get a blank screen.  killall -9 Xorg
> from ssh causes these errors to be logged:
>
>
> [  226.239747] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  226.239751] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD34 (len 55, WS 0, PS 0) @ 0xCD57
> [  231.241492] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  231.241496] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
> [  236.243111] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  236.243115] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
> [  241.244625] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
> more than 5secs aborting
> [  241.244628] [drm:atom_execute_table_locked] *ERROR* atombios stuck
> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>
>
> lspci -vvvxxxnn on 3.14-rc7+ says:
>
> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
> (rev ff) (prog-if ff)
> !!! Unknown header type 7f
> Kernel driver in use: radeon
> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98] (rev ff)
> (prog-if ff)
> !!! Unknown header type 7f
> Kernel driver in use: snd_hda_intel
> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> (oops!)
>
> On 3.13, it says:
>
> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
> (prog-if 00 [VGA controller])
> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
> 6450 1 GB DDR3 [174b:e164]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 92
> Region 0: Memory at e000 (64-bit, prefetchable) [size=256M]
> Region 2: Memory at f4a2 (64-bit, non-prefetchable) [size=128K]
> Region 4: I/O ports at c000 [size=256]
> Expansion ROM at f4a0 [disabled] [size=128K]
> Capabilities: 
> Kernel driver in use: radeon
> 00: 02 10 79 67 07 04 10 00 00 00 00 03 10 00 80 00
> 10: 0c 00 00 e0 00 00 00 00 04 00 a2 f4 00 00 00 00
> 20: 01 c0 00 00 00 00 00 00 00 00 00 00 4b 17 64 e1
> 30: 00 00 a0 f4 50 00 00 00 00 00 00 00 0a 01 00 00
>
> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98]
> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
> 6450 1GB DDR3 [174b:aa98]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 96
> Region 0: Memory at f4a4 (64-bit, non-prefetchable) [size=16K]
> Capabilities: 
> Kernel driver in use: snd_hda_intel
> 00: 02 10 98 aa 06 04 10 00 00 00 03 04 10 00 80 00
> 10: 04 00 a4 f4 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 98 aa
> 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 02 00 00
>
> Logs attached.
>
> Unfortunately, I'll be away from this computer until Wednesday.

Can you bisect?

Alex

3.14 radeon regression: radeon is broken (pci bug?)

[Bjorn Helgaas]

On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski  wrote:
> On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher  
> wrote:
>> On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski  
>> wrote:
>>> My system works on a 3.13 Fedora kernel.  It does not work on a
>>> more-or-less identically configured 3.14-rc7+ kernel.  The symptom is
>>> that the Plymouth password prompt flashes and them the screen goes
>>> blank.  Hitting escape brings back the text console, and all is well
>>> until X tries to start.  Then I get a blank screen.  killall -9 Xorg
>>> from ssh causes these errors to be logged:
>>>
>>>
>>> [  226.239747] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>>> more than 5secs aborting
>>> [  226.239751] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>>> executing CD34 (len 55, WS 0, PS 0) @ 0xCD57
>>> [  231.241492] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>>> more than 5secs aborting
>>> [  231.241496] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>>> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>>> [  236.243111] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>>> more than 5secs aborting
>>> [  236.243115] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>>> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>>> [  241.244625] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>>> more than 5secs aborting
>>> [  241.244628] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>>> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>>>
>>>
>>> lspci -vvvxxxnn on 3.14-rc7+ says:
>>>
>>> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
>>> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
>>> (rev ff) (prog-if ff)
>>> !!! Unknown header type 7f
>>> Kernel driver in use: radeon
>>> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>
>>> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>>> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98] (rev ff)
>>> (prog-if ff)
>>> !!! Unknown header type 7f
>>> Kernel driver in use: snd_hda_intel
>>> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>
>>> (oops!)
>>>
>>> On 3.13, it says:
>>>
>>> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
>>> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
>>> (prog-if 00 [VGA controller])
>>> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
>>> 6450 1 GB DDR3 [174b:e164]
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> SERR- >> Latency: 0, Cache Line Size: 64 bytes
>>> Interrupt: pin A routed to IRQ 92
>>> Region 0: Memory at e000 (64-bit, prefetchable) [size=256M]
>>> Region 2: Memory at f4a2 (64-bit, non-prefetchable) [size=128K]
>>> Region 4: I/O ports at c000 [size=256]
>>> Expansion ROM at f4a0 [disabled] [size=128K]
>>> Capabilities: 
>>> Kernel driver in use: radeon
>>> 00: 02 10 79 67 07 04 10 00 00 00 00 03 10 00 80 00
>>> 10: 0c 00 00 e0 00 00 00 00 04 00 a2 f4 00 00 00 00
>>> 20: 01 c0 00 00 00 00 00 00 00 00 00 00 4b 17 64 e1
>>> 30: 00 00 a0 f4 50 00 00 00 00 00 00 00 0a 01 00 00
>>>
>>> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>>> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98]
>>> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
>>> 6450 1GB DDR3 [174b:aa98]
>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> SERR- >> Latency: 0, Cache Line Size: 64 bytes
>>> Interrupt: pin B routed to IRQ 96
>>> Region 0: Memory at f4a4 (64-bit, non-prefetchable) [size=16K]
>>> Capabilities: 
>>> Kernel driver in use: snd_hda_intel
>>> 00: 02 10 98 aa 06 04 10 00 00 00 03 04 10 00 80 00
>>> 10: 04 00 a4 f4 00 00 00 00 00 00 00 00 00 00 00 00
>>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 98 aa
>>> 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 02 00 00
>>>
>>> Logs attached.

Hi Andy,

I'm really sorry that you tripped over this, but thanks a lot for the
report.  Is there any chance the box is currently running v3.13, and
you could collect the dmesg log from it?  I don't see anything unusual
from a PCI perspective in the v3.14-rc7 dmesg; all the PCI device
resources look fine, and we didn't reassign anything.  It seems like
the :09:00.x devices just 

[PATCH 3/3] drm/radeon: use drm_dp_dpcd_read_link_status()

[Alex Deucher]

Replace the radeon specific version with the generic version.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 30 +-
 1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8d8f846..8b0ab17 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -549,32 +549,12 @@ int radeon_dp_mode_valid_helper(struct drm_connector 
*connector,
return MODE_OK;
 }

-static bool radeon_dp_get_link_status(struct radeon_connector 
*radeon_connector,
- u8 link_status[DP_LINK_STATUS_SIZE])
-{
-   struct radeon_connector_atom_dig *dig_connector;
-   int ret;
-
-   if (!radeon_connector->con_priv)
-   return false;
-   dig_connector = radeon_connector->con_priv;
-
-   ret = drm_dp_dpcd_read(_connector->dp_i2c_bus->aux, 
DP_LANE0_1_STATUS,
-  link_status, DP_LINK_STATUS_SIZE);
-   if (ret <= 0) {
-   return false;
-   }
-
-   DRM_DEBUG_KMS("link status %6ph\n", link_status);
-   return true;
-}
-
 bool radeon_dp_needs_link_train(struct radeon_connector *radeon_connector)
 {
u8 link_status[DP_LINK_STATUS_SIZE];
struct radeon_connector_atom_dig *dig = radeon_connector->con_priv;

-   if (!radeon_dp_get_link_status(radeon_connector, link_status))
+   if (drm_dp_dpcd_read_link_status(>dp_i2c_bus->aux, link_status) <= 
0)
return false;
if (drm_dp_channel_eq_ok(link_status, dig->dp_lane_count))
return false;
@@ -605,7 +585,6 @@ struct radeon_dp_link_train_info {
struct radeon_device *rdev;
struct drm_encoder *encoder;
struct drm_connector *connector;
-   struct radeon_connector *radeon_connector;
int enc_id;
int dp_clock;
int dp_lane_count;
@@ -752,7 +731,8 @@ static int radeon_dp_link_train_cr(struct 
radeon_dp_link_train_info *dp_info)
while (1) {
drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);

-   if (!radeon_dp_get_link_status(dp_info->radeon_connector, 
dp_info->link_status)) {
+   if (drm_dp_dpcd_read_link_status(dp_info->aux,
+dp_info->link_status) <= 0) {
DRM_ERROR("displayport link status failed\n");
break;
}
@@ -814,7 +794,8 @@ static int radeon_dp_link_train_ce(struct 
radeon_dp_link_train_info *dp_info)
while (1) {
drm_dp_link_train_channel_eq_delay(dp_info->dpcd);

-   if (!radeon_dp_get_link_status(dp_info->radeon_connector, 
dp_info->link_status)) {
+   if (drm_dp_dpcd_read_link_status(dp_info->aux,
+dp_info->link_status) <= 0) {
DRM_ERROR("displayport link status failed\n");
break;
}
@@ -907,7 +888,6 @@ void radeon_dp_link_train(struct drm_encoder *encoder,
dp_info.rdev = rdev;
dp_info.encoder = encoder;
dp_info.connector = connector;
-   dp_info.radeon_connector = radeon_connector;
dp_info.dp_lane_count = dig_connector->dp_lane_count;
dp_info.dp_clock = dig_connector->dp_clock;
dp_info.aux = _connector->dp_i2c_bus->aux;
-- 
1.8.3.1

[PATCH 2/3] drm/radeon: use the new drm helpers for dp aux

[Alex Deucher]

Switch to the new dp helpers.  The main difference is
that the DP helpers don't allow an adjustable delay in
the aux transaction, but I don't know that this is
necessary.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c   | 192 +
 drivers/gpu/drm/radeon/radeon_connectors.c |  17 ++-
 drivers/gpu/drm/radeon/radeon_mode.h   |   2 +
 3 files changed, 104 insertions(+), 107 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 23189b7..8d8f846 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -142,94 +142,62 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
return recv_bytes;
 }

-static int radeon_dp_aux_native_write(struct radeon_connector 
*radeon_connector,
- u16 address, u8 *send, u8 send_bytes, u8 
delay)
-{
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
-   int ret;
-   u8 msg[20];
-   int msg_bytes = send_bytes + 4;
-   u8 ack;
-   unsigned retry;
-
-   if (send_bytes > 16)
-   return -1;
+#define HEADER_SIZE 4

-   msg[0] = address;
-   msg[1] = address >> 8;
-   msg[2] = DP_AUX_NATIVE_WRITE << 4;
-   msg[3] = (msg_bytes << 4) | (send_bytes - 1);
-   memcpy([4], send, send_bytes);
-
-   for (retry = 0; retry < 7; retry++) {
-   ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus,
-   msg, msg_bytes, NULL, 0, delay, 
);
-   if (ret == -EBUSY)
-   continue;
-   else if (ret < 0)
-   return ret;
-   ack >>= 4;
-   if ((ack & DP_AUX_NATIVE_REPLY_MASK) == DP_AUX_NATIVE_REPLY_ACK)
-   return send_bytes;
-   else if ((ack & DP_AUX_NATIVE_REPLY_MASK) == 
DP_AUX_NATIVE_REPLY_DEFER)
-   usleep_range(400, 500);
-   else
-   return -EIO;
-   }
-
-   return -EIO;
-}
-
-static int radeon_dp_aux_native_read(struct radeon_connector *radeon_connector,
-u16 address, u8 *recv, int recv_bytes, u8 
delay)
+static ssize_t
+radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
-   u8 msg[4];
-   int msg_bytes = 4;
-   u8 ack;
+   struct radeon_i2c_chan *chan =
+   container_of(aux, struct radeon_i2c_chan, aux);
int ret;
-   unsigned retry;
-
-   msg[0] = address;
-   msg[1] = address >> 8;
-   msg[2] = DP_AUX_NATIVE_READ << 4;
-   msg[3] = (msg_bytes << 4) | (recv_bytes - 1);
-
-   for (retry = 0; retry < 7; retry++) {
-   ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus,
-   msg, msg_bytes, recv, recv_bytes, 
delay, );
-   if (ret == -EBUSY)
-   continue;
-   else if (ret < 0)
-   return ret;
-   ack >>= 4;
-   if ((ack & DP_AUX_NATIVE_REPLY_MASK) == DP_AUX_NATIVE_REPLY_ACK)
-   return ret;
-   else if ((ack & DP_AUX_NATIVE_REPLY_MASK) == 
DP_AUX_NATIVE_REPLY_DEFER)
-   usleep_range(400, 500);
-   else if (ret == 0)
-   return -EPROTO;
-   else
-   return -EIO;
+   u8 tx_buf[20];
+   size_t tx_size;
+   u8 ack, delay = 0;
+
+   if (WARN_ON(msg->size > 16))
+   return -E2BIG;
+
+   tx_buf[0] = msg->address & 0xff;
+   tx_buf[1] = msg->address >> 8;
+   tx_buf[2] = msg->request << 4;
+   tx_buf[3] = msg->size - 1;
+
+   switch (msg->request & ~DP_AUX_I2C_MOT) {
+   case DP_AUX_NATIVE_WRITE:
+   case DP_AUX_I2C_WRITE:
+   tx_size = HEADER_SIZE + msg->size;
+   tx_buf[3] |= tx_size << 4;
+   memcpy(tx_buf + HEADER_SIZE, msg->buffer, msg->size);
+   ret = radeon_process_aux_ch(chan,
+   tx_buf, tx_size, NULL, 0, delay, 
);
+   if (ret >= 0)
+   /* Return payload size. */
+   ret = msg->size;
+   break;
+   case DP_AUX_NATIVE_READ:
+   case DP_AUX_I2C_READ:
+   tx_size = HEADER_SIZE;
+   tx_buf[3] |= tx_size << 4;
+   ret = radeon_process_aux_ch(chan,
+   tx_buf, tx_size, msg->buffer, 
msg->size, delay, );
+   break;
+   default:
+   ret = -EINVAL;
+   break;
}

-   return -EIO;
-}
+   if (ret > 0)
+   msg->reply = ack >> 4;

-static void radeon_write_dpcd_reg(struct 

[PATCH 1/3] drm/dp: make aux retries less chatty

[Alex Deucher]

Switch to debug only to avoid flooding the logs.
This mirrors the behavior in some other drivers.

Signed-off-by: Alex Deucher 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 35251af..74724aa 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -402,7 +402,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
}
}

-   DRM_ERROR("too many retries, giving up\n");
+   DRM_DEBUG_KMS("too many retries, giving up\n");
return -EIO;
 }

@@ -656,7 +656,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
}
}

-   DRM_ERROR("too many retries, giving up\n");
+   DRM_DEBUG_KMS("too many retries, giving up\n");
return -EREMOTEIO;
 }

-- 
1.8.3.1

[PATCH RFC v2 3/6] drm/tilcd: dts: Add the video output port

[Jean-Francois Moine]

The connection between the video source and sink must follow
the media video interface.

Signed-off-by: Jean-Francois Moine 
---
 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..d0de848 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
  - max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.

+Optional nodes:
+
+ - port: reference of the video sink as described in media/video-interfaces.
+   This reference is required when the video sink is the TDA19988 HDMI
+   transmitter.
+
 Example:

fb: fb at 4830e000 {
@@ -27,3 +33,11 @@ Example:
interrupts = <36>;
ti,hwmods = "lcdc";
};
+
+{
+   port {
+   lcd_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH RFC v2 5/6] drm/tilcd: dts: Remove unused slave description

[Jean-Francois Moine]

The tda998x being converted to a normal DRM encoder/connector,
there is no slave notion anymore.

Signed-off-by: Jean-Francois Moine 
---
 Documentation/devicetree/bindings/drm/tilcdc/slave.txt | 18 --
 1 file changed, 18 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be "ti,tilcdc,slave".
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
-   muxing properly for pins that connect to TFP410 device
-
-Example:
-
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_hdmi_bonelt_pins>;
-   };
-- 
1.9.1

[pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked()

[Fengguang Wu]

// CC Stephane for RAPL related bug

Bjorn, sorry this bug report is mis-titled. The only new bug that show
up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so
it's hard to reproduce and the bisect is likely not accurate.  I'll
retry the bisect with more repeat count. Sorry for the disturbing!

[2.812392] Unpacking initramfs...
[2.812392] Unpacking initramfs...
[4.937582] Freeing initrd memory: 3276K (93cbd000 - 93ff)
[4.937582] Freeing initrd memory: 3276K (93cbd000 - 93ff)
[4.952113] BUG: unable to handle kernel
[4.952113] BUG: unable to handle kernel NULL pointer dereferenceNULL 
pointer dereference at 003c
 at 003c
[4.952871] IP:
[4.952871] IP: [<81c439fb>] rapl_pmu_init+0xed/0x165
 [<81c439fb>] rapl_pmu_init+0xed/0x165
[4.954190] *pde = 
[4.954190] *pde = 

[4.954619] Oops:  [#1]
[4.954619] Oops:  [#1]

[4.955440] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.14.0-rc1-00023-gaa11fc5 #1
[4.955440] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.14.0-rc1-00023-gaa11fc5 #1
[4.956050] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
   
[4.956050] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[4.956672] task: 80030c20 ti: 80032000 task.ti: 80032000
[4.956672] task: 80030c20 ti: 80032000 task.ti: 80032000
[4.957295] EIP: 0060:[<81c439fb>] EFLAGS: 0246 CPU: 0
[4.957295] EIP: 0060:[<81c439fb>] EFLAGS: 0246 CPU: 0
[4.957831] EIP is at rapl_pmu_init+0xed/0x165
[4.957831] EIP is at rapl_pmu_init+0xed/0x165

Full dmesg attached.

Thanks,
Fengguang

On Thu, Mar 20, 2014 at 04:50:08PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 20, 2014 at 6:41 AM, Fengguang Wu  
> wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/resource
> >
> > commit aa11fc58dc71c27701b1f9a529a36a38d4337722
> > Author: Bjorn Helgaas 
> > AuthorDate: Fri Mar 7 13:39:01 2014 -0700
> > Commit: Bjorn Helgaas 
> > CommitDate: Wed Mar 19 15:00:16 2014 -0600
> >
> > PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region()
> >
> > When allocating space from a bus resource, i.e., from apertures leading 
> > to
> > this bus, make sure the entire resource type matches.  The previous code
> > assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single 
> > bit
> > set, but this is not true.  IORESOURCE_TYPE_BITS is really an 
> > enumeration,
> > and we have to check all the bits.
> >
> > See 72dcb1197228 ("resources: Add register address resource type").
> >
> > No functional change.  If we used this path for allocating IRQs, DMA
> > channels, or bus numbers, this would fix a bug because those types are
> > indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM.  But we
> > don't, so this shouldn't make any difference.
> >
> > Signed-off-by: Bjorn Helgaas 
> 
> Thanks (I think).  I'm afraid I'm going to need some more help to
> debug this.  I built aa11fc58dc with the config you supplied and
> booted it on qemu with no real issues (it didn't boot all the way
> because the config doesn't include a driver for my root disk, but
> that's to be expected).
> 
> The dmesg you supplied is for some other commit 2d18516 that I don't
> have, so I'm confused about why it's not from aa11fc58dc.
> 
> I did reproduce what appears to be basically the same problem with
> a654dc797f3e, which is the 20140320 linux-next tree.  I backed up to
> 93ecdc077282, which is where pci/next was merged (this includes
> aa11fc58dc), but I could not reproduce the problem there.
> 
> So bottom line, I'm confused because your bisection doesn't match what
> I'm seeing, and I don't want to spend more time flailing around.
> 
> Bjorn
> 
> 
> > ++++
> > |   
> >  | aa11fc58dc | 2d18516523 |
> > ++++
> > | boot_successes
> >  | 19 | 0  |
> > | boot_failures 
> >  | 1  | 19 |
> > | BUG:unable_to_handle_kernel_NULL_pointer_dereference  
> >  | 1  | 1  |
> > | Oops  
> >  | 1  | 1  |
> > | EIP_is_at_rapl_pmu_init   
> >  | 1  | 1  |
> > | 

[PATCH] drm/ttm: remove fence_lock

[Dave Airlie]

On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse  wrote:
> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
>> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
>> >Op 18-10-12 13:55, Thomas Hellstrom schreef:
>> >>On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
>> >>>Op 18-10-12 13:02, Thomas Hellstrom schreef:
>> On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
>> >Hey,
>> >
>> >Op 18-10-12 09:59, Thomas Hellstrom schreef:
>> >>On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
>> >>>Hi, Maarten,
>> >>>
>> >>>As you know I have been having my doubts about this change.
>> >>>To me it seems insane to be forced to read the fence pointer under a
>> >>>reserved lock, simply because when you take the reserve lock, another
>> >>>process may have it and there is a substantial chance that that 
>> >>>process
>> >>>will also be waiting for idle while holding the reserve lock.
>> >I think it makes perfect sense, the only times you want to read the 
>> >fence
>> >is when you want to change the members protected by the reservation.
>> No, that's not true. A typical case (or the only case)
>> is where you want to do a map with no_wait semantics. You will want
>> to be able to access a buffer's results even if the eviction code
>> is about to schedule an unbind from the GPU, and have the buffer
>> reserved?
>> >>>Well either block on reserve or return -EBUSY if reserved, presumably the
>> >>>former..
>> >>>
>> >>>ttm_bo_vm_fault does the latter already, anyway
>> >>ttm_bo_vm_fault only trylocks to avoid a deadlock with mmap_sem, it's 
>> >>really
>> >>a waiting reserve but for different reasons. Typically a user-space app 
>> >>will keep
>> >>asynchronous maps to TTM during a buffer lifetime, and the buffer lifetime 
>> >>may
>> >>be long as user-space apps keep caches.
>> >>That's not the same as accessing a buffer after the GPU is done with it.
>> >Ah indeed.
>> >>>You don't need to hold the reservation while performing the wait itself 
>> >>>though,
>> >>>you could check if ttm_bo_wait(no_wait_gpu = true) returns -EBUSY, and if 
>> >>>so
>> >>>take a ref to the sync_obj member and then wait after unreserving. You 
>> >>>won't
>> >>>reset sync_obj member to NULL in that case, but that should be harmless.
>> >>>This will allow you to keep the reservations fast and short. Maybe a 
>> >>>helper
>> >>>would be appropriate for this since radeon and nouveau both seem to do 
>> >>>this.
>> >>>
>> >>The problem is that as long as other users are waiting for idle with 
>> >>reservation
>> >>held, for example to switch GPU engine or to delete a GPU bind, waiting
>> >>for reserve will in many case mean wait for GPU.
>> >This example sounds inefficient, I know nouveau can do this, but this 
>> >essentially
>> >just stalls the gpu entirely. I think guess you mean functions like 
>> >nouveau_gem_object_close?
>> >It wouldn't surprise me if performance in nouveau could be improved simply 
>> >by
>> >fixing those cases up instead, since it stalls the application completely 
>> >too for other uses.
>> >
>> Please see the Nouveau cpu_prep patch as well.
>>
>> While there are a number of cases that can be fixed up, also in
>> Radeon, there's no way around that reservation
>> is a heavyweight lock that, particularly on simpler hardware without
>> support for fence ordering
>> with barriers and / or "semaphores" and accelerated eviction will be
>> held while waiting for idle.
>>
>> As such, it is unsuitable to protect read access to the fence
>> pointer. If the intention is to keep a single fence pointer
>> I think the best solution is to allow reading the fence pointer
>> outside reservation, but make sure this can be done
>> atomically. If the intention is to protect an array or list of fence
>> pointers, I think a spinlock is the better solution.
>>
>> /Thomas
>
> Just wanted to point out that like Thomas i am concern about having to
> have object reserved when waiting on its associated fence. I fear it
> will hurt us somehow.
>
> I will try to spend couple days stress testing your branch on radeon
> trying to see if it hurts performance anyhow with current use case.
>

I've been trying to figure out what to do with Maarten's patches going
forward since they are essential for all kinds of SoC people,

However I'm still not 100% sure I believe either the fact that the
problem is anything more than a microoptimisation, and possibly a
premature one at that, this needs someone to start suggesting
benchmarks we can run and a driver set to run them on, otherwise I'm
starting to tend towards we are taking about an optimisation we can
fix later,

The other option is to somehow merge this stuff under an option that
allows us to test it using a command line option, but I don't think
that is sane either,

So Maarten, Jerome, Thomas, please start discussing actual real world
tests you think merging this code will affect and then I can make a
better 

[PATCH RFC v2 6/6] ARM: AM33XX: dts: Change the tda998x description

[Jean-Francois Moine]

The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector and the tilcdc_slave glue being removed, the
declaration of the HDMI transmitter description must be changed in
the associated DTs.

Signed-off-by: Jean-Francois Moine 
---
 arch/arm/boot/dts/am335x-base0033.dts  | 28 +++-
 arch/arm/boot/dts/am335x-boneblack.dts | 21 -
 2 files changed, 35 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-base0033.dts 
b/arch/arm/boot/dts/am335x-base0033.dts
index 72a9b3f..05f2b8f 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -14,15 +14,6 @@
model = "IGEP COM AM335x on AQUILA Expansion";
compatible = "isee,am335x-base0033", "isee,am335x-igep0033", 
"ti,am33xx";

-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <>;
-   pinctrl-names = "default", "off";
-   pinctrl-0 = <_hdmi_pins>;
-   pinctrl-1 = <_hdmi_off_pins>;
-   status = "okay";
-   };
-
leds_base {
pinctrl-names = "default";
pinctrl-0 = <_base_pins>;
@@ -85,6 +76,11 @@

  {
status = "okay";
+   port {
+   lcd_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
 };

  {
@@ -92,4 +88,18 @@
compatible = "at,24c256";
reg = <0x50>;
};
+   hdmi: hdmi-encoder {
+   compatible = "nxp,tda19988";
+   reg = <0x70>;
+
+   pinctrl-names = "default", "off";
+   pinctrl-0 = <_hdmi_pins>;
+   pinctrl-1 = <_hdmi_off_pins>;
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
+   };
 };
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..b94d8bd 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -64,15 +64,26 @@

  {
status = "okay";
+   port {
+   lcd_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
 };

-/ {
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <>;
+ {
+   hdmi: hdmi-encoder {
+   compatible = "nxp,tda19988";
+   reg = <0x70>;
+
pinctrl-names = "default", "off";
pinctrl-0 = <_hdmi_bonelt_pins>;
pinctrl-1 = <_hdmi_bonelt_off_pins>;
-   status = "okay";
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <_0>;
+   };
+   };
};
 };
-- 
1.9.1

[PATCH RFC v2 4/6] drm/tilcdc: Change the interface with the tda998x driver

[Jean-Francois Moine]

The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector, the tilcdc_slave glue is not needed anymore.

This patch uses the infrastructure for componentised subsystems
for waiting to the tda998x full start and to give it the pointer
to the DRM device.

Signed-off-by: Jean-Francois Moine 
---
 drivers/gpu/drm/tilcdc/Makefile   |   1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |  85 +--
 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 406 --
 drivers/gpu/drm/tilcdc/tilcdc_slave.h |  26 ---
 4 files changed, 68 insertions(+), 450 deletions(-)
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
-   tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 171a820..dd6ebd3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -17,16 +17,16 @@

 /* LCDC DRM driver, based on da8xx-fb */

+#include 
+
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
-#include "tilcdc_slave.h"
 #include "tilcdc_panel.h"

 #include "drm_fb_helper.h"

 static LIST_HEAD(module_list);
-static bool slave_probing;

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +42,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(>list);
 }

-void tilcdc_slave_probedefer(bool defered)
-{
-   slave_probing = defered;
-}
-
 static struct of_device_id tilcdc_of_match[];

 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -277,6 +272,10 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)

platform_set_drvdata(pdev, dev);

+   /* initialize the subdevices */
+   ret = component_bind_all(>dev, dev);
+   if (ret < 0)
+   goto fail;

list_for_each_entry(mod, _list, list) {
DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
@@ -577,6 +576,66 @@ static const struct dev_pm_ops tilcdc_pm_ops = {
  * Platform driver:
  */

+/* component stuff */
+static int of_dev_node_match(struct device *dev, void *data)
+{
+   return dev->of_node == data;
+}
+
+static int tilcdc_add_components(struct device *master, struct master *m)
+{
+   struct device_node *np = master->of_node, *child;
+   int ret;
+
+   /* scan the video ports */
+   child = NULL;
+   for (;;) {
+   struct device_node *endpoint, *port, *i2c_node;
+
+   child = of_get_next_child(np, child);
+   if (!child)
+   break;
+   if (strcmp(child->name, "port") != 0)
+   continue;
+
+   endpoint = of_get_next_child(child, NULL);
+   if (!endpoint) {
+   dev_err(master, "tilcdc: no port endpoint\n");
+   return -EINVAL;
+   }
+   port = of_parse_phandle(endpoint, "remote-endpoint", 0);
+   of_node_put(endpoint);
+   if (!port) {
+   dev_err(master, "ticldc: no remote-endpoint\n");
+   return -EINVAL;
+   }
+   i2c_node = of_get_parent(of_get_parent(port));
+   of_node_put(port);
+   ret = component_master_add_child(m, of_dev_node_match,
+i2c_node);
+   of_node_put(i2c_node);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+static int tilcdc_bind(struct device *dev)
+{
+   return drm_platform_init(_driver, to_platform_device(dev));
+}
+
+static void tilcdc_unbind(struct device *dev)
+{
+   drm_put_dev(dev_get_drvdata(dev));
+}
+
+static const struct component_master_ops tilcdc_comp_ops = {
+   .add_components = tilcdc_add_components,
+   .bind = tilcdc_bind,
+   .unbind = tilcdc_unbind,
+};
+
 static int tilcdc_pdev_probe(struct platform_device *pdev)
 {
/* bail out early if no DT data: */
@@ -584,18 +643,12 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
dev_err(>dev, "device-tree data is missing\n");
return -ENXIO;
}
-
-   /* defer probing if slave is in deferred probing */
-   if (slave_probing == true)
-   return -EPROBE_DEFER;
-
-   return drm_platform_init(_driver, pdev);
+   return component_master_add(>dev, _comp_ops);
 }

 static int tilcdc_pdev_remove(struct platform_device *pdev)
 {
-   

[PATCH v2] drm: enable render-nodes by default

[Thomas Hellstrom]

On 03/21/2014 08:10 AM, Daniel Vetter wrote:
> On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark  wrote:
 Ie. an app that was using the gpu for something secure could
 simply choose not to if the hw/driver could not guarantee that another
 process using the gpu could not get access to the buffers..
>>> IMO that should work fine, but we need to provide a way for user-space
>>> to determine whether
>>> the render node is secure or not. Perhaps a sysfs attribute and / or a
>>> drm getparam() parameter?
>> I'd *assume* that that sort of thing would just be some sort of CL extension?
>>
>> But no objection to exposing it in a more common way.
>>
>> I guess it is also an option to keep the bootarg to override default
>> (with the default being 'enabled' for hw w/ per-context/process vm and
>> 'disabled' otherwise).
> Imo if we expose this through sysfs we should always enable
> rendernodes. The udev scripts can then decide what permissions to set
> on them.

Agreed.
Thomas


> -Daniel

[PATCH] drm/ttm: remove fence_lock

[Thomas Hellstrom]

On 03/21/2014 12:55 AM, Dave Airlie wrote:
> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse  wrote:
>> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote:
>>> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote:
 Op 18-10-12 13:55, Thomas Hellstrom schreef:
> On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
>> Op 18-10-12 13:02, Thomas Hellstrom schreef:
>>> On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
 Hey,

 Op 18-10-12 09:59, Thomas Hellstrom schreef:
> On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
>> Hi, Maarten,
>>
>> As you know I have been having my doubts about this change.
>> To me it seems insane to be forced to read the fence pointer under a
>> reserved lock, simply because when you take the reserve lock, another
>> process may have it and there is a substantial chance that that 
>> process
>> will also be waiting for idle while holding the reserve lock.
 I think it makes perfect sense, the only times you want to read the 
 fence
 is when you want to change the members protected by the reservation.
>>> No, that's not true. A typical case (or the only case)
>>> is where you want to do a map with no_wait semantics. You will want
>>> to be able to access a buffer's results even if the eviction code
>>> is about to schedule an unbind from the GPU, and have the buffer
>>> reserved?
>> Well either block on reserve or return -EBUSY if reserved, presumably the
>> former..
>>
>> ttm_bo_vm_fault does the latter already, anyway
> ttm_bo_vm_fault only trylocks to avoid a deadlock with mmap_sem, it's 
> really
> a waiting reserve but for different reasons. Typically a user-space app 
> will keep
> asynchronous maps to TTM during a buffer lifetime, and the buffer 
> lifetime may
> be long as user-space apps keep caches.
> That's not the same as accessing a buffer after the GPU is done with it.
 Ah indeed.
>> You don't need to hold the reservation while performing the wait itself 
>> though,
>> you could check if ttm_bo_wait(no_wait_gpu = true) returns -EBUSY, and 
>> if so
>> take a ref to the sync_obj member and then wait after unreserving. You 
>> won't
>> reset sync_obj member to NULL in that case, but that should be harmless.
>> This will allow you to keep the reservations fast and short. Maybe a 
>> helper
>> would be appropriate for this since radeon and nouveau both seem to do 
>> this.
>>
> The problem is that as long as other users are waiting for idle with 
> reservation
> held, for example to switch GPU engine or to delete a GPU bind, waiting
> for reserve will in many case mean wait for GPU.
 This example sounds inefficient, I know nouveau can do this, but this 
 essentially
 just stalls the gpu entirely. I think guess you mean functions like 
 nouveau_gem_object_close?
 It wouldn't surprise me if performance in nouveau could be improved simply 
 by
 fixing those cases up instead, since it stalls the application completely 
 too for other uses.

>>> Please see the Nouveau cpu_prep patch as well.
>>>
>>> While there are a number of cases that can be fixed up, also in
>>> Radeon, there's no way around that reservation
>>> is a heavyweight lock that, particularly on simpler hardware without
>>> support for fence ordering
>>> with barriers and / or "semaphores" and accelerated eviction will be
>>> held while waiting for idle.
>>>
>>> As such, it is unsuitable to protect read access to the fence
>>> pointer. If the intention is to keep a single fence pointer
>>> I think the best solution is to allow reading the fence pointer
>>> outside reservation, but make sure this can be done
>>> atomically. If the intention is to protect an array or list of fence
>>> pointers, I think a spinlock is the better solution.
>>>
>>> /Thomas
>> Just wanted to point out that like Thomas i am concern about having to
>> have object reserved when waiting on its associated fence. I fear it
>> will hurt us somehow.
>>
>> I will try to spend couple days stress testing your branch on radeon
>> trying to see if it hurts performance anyhow with current use case.
>>
> I've been trying to figure out what to do with Maarten's patches going
> forward since they are essential for all kinds of SoC people,
>
> However I'm still not 100% sure I believe either the fact that the
> problem is anything more than a microoptimisation, and possibly a
> premature one at that, this needs someone to start suggesting
> benchmarks we can run and a driver set to run them on, otherwise I'm
> starting to tend towards we are taking about an optimisation we can
> fix later,
>
> The other option is to somehow merge this stuff under an option that
> allows us to test it using a command line option, but I don't think
> that is sane either,

more locking fail...

[Dave Airlie]

There's one in i915 lvds on ironlake, and one in nouveau later.

drm_mode_probed_add locking?

but also others in suspend/resume paths.

Dave.
-- next part --
A non-text attachment was scrubbed...
Name: fails
Type: application/octet-stream
Size: 126462 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/ed52f194/attachment-0001.obj>

more locking fail...

[Daniel Vetter]

On Fri, Mar 21, 2014 at 1:53 AM, Dave Airlie  wrote:
> So I've been nice, and fixes the suspend/resume one, but the edid one
> looks like a bit more auditing/typing, so I'm leaving it for you to
> look at :-)

With my two patches from yesterday and your resume patch, what's still
missing? Atm I don't see backtrace any more here ... probably me not
looking hard enough.

Also can you please push out what we have already to drm-next (if
you're ok with my patches ofc), our QA here is starting to file these
;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

[Jean-Francois Moine]

The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.

This patch changes the driver to a normal DRM encoder/connector
thanks to the infrastructure for componentised subsystems.

Signed-off-by: Jean-Francois Moine 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 323 ++
 1 file changed, 188 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index fd6751c..1c25e40 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,11 +20,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 

 #include 
 #include 
-#include 
 #include 
 #include 

@@ -44,10 +45,14 @@ struct tda998x_priv {

wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
-   struct drm_encoder *encoder;
+   struct drm_encoder encoder;
+   struct drm_connector connector;
 };

-#define to_tda998x_priv(x)  ((struct tda998x_priv 
*)to_encoder_slave(x)->slave_priv)
+#define connector_priv(e) \
+   container_of(connector, struct tda998x_priv, connector)
+#define encoder_priv(e) \
+   container_of(encoder, struct tda998x_priv, encoder)

 /* The TDA9988 series of devices use a paged register scheme.. to simplify
  * things we encode the page # in upper bits of the register #.  To read/
@@ -559,9 +564,8 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
priv->wq_edid_wait = 0;
wake_up(>wq_edid);
-   } else if (cec != 0) {  /* HPD change */
-   if (priv->encoder && priv->encoder->dev)
-   drm_helper_hpd_irq_event(priv->encoder->dev);
+   } else if (cec != 0 && priv->encoder.dev) { /* HPD change */
+   drm_helper_hpd_irq_event(priv->encoder.dev);
}
return IRQ_HANDLED;
 }
@@ -731,9 +735,8 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 /* DRM encoder functions */

 static void
-tda998x_encoder_set_config(struct drm_encoder *encoder, void *params)
+tda998x_encoder_set_config(struct tda998x_priv *priv, void *params)
 {
-   struct tda998x_priv *priv = to_tda998x_priv(encoder);
struct tda998x_encoder_params *p = params;

priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(p->swap_a) |
@@ -755,7 +758,7 @@ tda998x_encoder_set_config(struct drm_encoder *encoder, 
void *params)
 static void
 tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
-   struct tda998x_priv *priv = to_tda998x_priv(encoder);
+   struct tda998x_priv *priv = encoder_priv(encoder);

/* we only care about on or off: */
if (mode != DRM_MODE_DPMS_ON)
@@ -786,18 +789,6 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
priv->dpms = mode;
 }

-static void
-tda998x_encoder_save(struct drm_encoder *encoder)
-{
-   DBG("");
-}
-
-static void
-tda998x_encoder_restore(struct drm_encoder *encoder)
-{
-   DBG("");
-}
-
 static bool
 tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
  const struct drm_display_mode *mode,
@@ -806,11 +797,14 @@ tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
 }

-static int
-tda998x_encoder_mode_valid(struct drm_encoder *encoder,
- struct drm_display_mode *mode)
+static void tda998x_encoder_prepare(struct drm_encoder *encoder)
 {
-   return MODE_OK;
+   tda998x_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
+}
+
+static void tda998x_encoder_commit(struct drm_encoder *encoder)
+{
+   tda998x_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
 }

 static void
@@ -818,7 +812,7 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
-   struct tda998x_priv *priv = to_tda998x_priv(encoder);
+   struct tda998x_priv *priv = encoder_priv(encoder);
uint16_t ref_pix, ref_line, n_pix, n_line;
uint16_t hs_pix_s, hs_pix_e;
uint16_t vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
@@ -1006,10 +1000,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
 }

 static enum drm_connector_status
-tda998x_encoder_detect(struct drm_encoder *encoder,
- struct drm_connector *connector)
+tda998x_connector_detect(struct drm_connector *connector, bool force)
 {
-   struct tda998x_priv *priv = to_tda998x_priv(encoder);
+   struct tda998x_priv *priv = connector_priv(connector);
uint8_t val = cec_read(priv, REG_CEC_RXSHPDLEV);

return (val & CEC_RXSHPDLEV_HPD) ? connector_status_connected :
@@ -1017,9 +1010,8 @@ tda998x_encoder_detect(struct drm_encoder *encoder,
 }

 static int
-read_edid_block(struct drm_encoder *encoder, uint8_t *buf, int blk)
+read_edid_block(struct tda998x_priv 

3.14 radeon regression: radeon is broken (pci bug?)

[Andy Lutomirski]

On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher  wrote:
> On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski  
> wrote:
>> My system works on a 3.13 Fedora kernel.  It does not work on a
>> more-or-less identically configured 3.14-rc7+ kernel.  The symptom is
>> that the Plymouth password prompt flashes and them the screen goes
>> blank.  Hitting escape brings back the text console, and all is well
>> until X tries to start.  Then I get a blank screen.  killall -9 Xorg
>> from ssh causes these errors to be logged:
>>
>>
>> [  226.239747] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>> more than 5secs aborting
>> [  226.239751] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>> executing CD34 (len 55, WS 0, PS 0) @ 0xCD57
>> [  231.241492] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>> more than 5secs aborting
>> [  231.241496] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>> [  236.243111] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>> more than 5secs aborting
>> [  236.243115] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>> [  241.244625] [drm:atom_op_jump] *ERROR* atombios stuck in loop for
>> more than 5secs aborting
>> [  241.244628] [drm:atom_execute_table_locked] *ERROR* atombios stuck
>> executing CD6C (len 62, WS 0, PS 0) @ 0xCD88
>>
>>
>> lspci -vvvxxxnn on 3.14-rc7+ says:
>>
>> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
>> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
>> (rev ff) (prog-if ff)
>> !!! Unknown header type 7f
>> Kernel driver in use: radeon
>> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>
>> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98] (rev ff)
>> (prog-if ff)
>> !!! Unknown header type 7f
>> Kernel driver in use: snd_hda_intel
>> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>
>> (oops!)
>>
>> On 3.13, it says:
>>
>> 09:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
>> [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] [1002:6779]
>> (prog-if 00 [VGA controller])
>> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
>> 6450 1 GB DDR3 [174b:e164]
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- > Latency: 0, Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 92
>> Region 0: Memory at e000 (64-bit, prefetchable) [size=256M]
>> Region 2: Memory at f4a2 (64-bit, non-prefetchable) [size=128K]
>> Region 4: I/O ports at c000 [size=256]
>> Expansion ROM at f4a0 [disabled] [size=128K]
>> Capabilities: 
>> Kernel driver in use: radeon
>> 00: 02 10 79 67 07 04 10 00 00 00 00 03 10 00 80 00
>> 10: 0c 00 00 e0 00 00 00 00 04 00 a2 f4 00 00 00 00
>> 20: 01 c0 00 00 00 00 00 00 00 00 00 00 4b 17 64 e1
>> 30: 00 00 a0 f4 50 00 00 00 00 00 00 00 0a 01 00 00
>>
>> 09:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98]
>> Subsystem: PC Partner Limited / Sapphire Technology Radeon HD
>> 6450 1GB DDR3 [174b:aa98]
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- > Latency: 0, Cache Line Size: 64 bytes
>> Interrupt: pin B routed to IRQ 96
>> Region 0: Memory at f4a4 (64-bit, non-prefetchable) [size=16K]
>> Capabilities: 
>> Kernel driver in use: snd_hda_intel
>> 00: 02 10 98 aa 06 04 10 00 00 00 03 04 10 00 80 00
>> 10: 04 00 a4 f4 00 00 00 00 00 00 00 00 00 00 00 00
>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 98 aa
>> 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 02 00 00
>>
>> Logs attached.
>>
>> Unfortunately, I'll be away from this computer until Wednesday.
>
> Can you bisect?

Not until Wednesday -- I don't have any way to test this remotely.  I
can do tests that don't involve rebooting, though.

>
> Alex



-- 
Andy Lutomirski
AMA Capital Management, LLC

[PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

[Vandana Kannan]

Populate PAR in infoframe structure. If there is a user setting for PAR, then
that value is set. Else, value is taken from CEA mode list if VIC is found.
Else, PAR is calculated from resolution. If none of these conditions are
satisfied, PAR is NONE as per initialization.

As a next step, create a property that would enable a user space app to set
aspect ratio. (will be pushed as a separate patch)

Signed-off-by: Vandana Kannan 
Cc: Jesse Barnes 
Cc: Vijay Purushothaman 
Cc: Ville Syrj?l? 
Cc: intel-gfx at lists.freedesktop.org
---
 drivers/gpu/drm/drm_edid.c |   34 ++
 include/drm/drm_crtc.h |1 +
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d4e3f9d..3db693f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2452,6 +2452,21 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);

+/**
+ * drm_get_cea_aspect_ratio - get the picture aspect ratio corresponding to
+ * the input VIC from the CEA mode list
+ *
+ * Returns picture aspect ratio
+ */
+enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code)
+{
+   /* return picture aspect ratio for video_code - 1 to access the
+* right array element
+   */
+   return edid_cea_modes[video_code-1].picture_aspect_ratio;
+}
+EXPORT_SYMBOL(drm_get_cea_aspect_ratio);
+
 /*
  * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
  * specific block).
@@ -3613,6 +3628,25 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
frame->video_code = drm_match_cea_mode(mode);

frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+
+   /* Populate picture aspect ratio from either CEA mode list or
+*  user input
+   */
+   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
+   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
+   frame->picture_aspect = mode->picture_aspect_ratio;
+   else if (frame->video_code > 0)
+   frame->picture_aspect = drm_get_cea_aspect_ratio(
+   frame->video_code);
+   else {
+   if (!(mode->vdisplay % 3) &&
+   (((mode->vdisplay * 4) / 3) == mode->hdisplay))
+   frame->picture_aspect = HDMI_PICTURE_ASPECT_4_3;
+   else if (!(mode->vdisplay % 9) &&
+   (((mode->vdisplay * 16) / 9) == mode->hdisplay))
+   frame->picture_aspect = HDMI_PICTURE_ASPECT_16_9;
+   }
+
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 27f828c..50dc55a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -983,6 +983,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device *dev,
 extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
+extern enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
 extern bool drm_detect_hdmi_monitor(struct edid *edid);
 extern bool drm_detect_monitor_audio(struct edid *edid);
 extern bool drm_rgb_quant_range_selectable(struct edid *edid);
-- 
1.7.9.5

[PATCH v2] drm: enable render-nodes by default

[Daniel Vetter]

On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark  wrote:
>>> Ie. an app that was using the gpu for something secure could
>>> simply choose not to if the hw/driver could not guarantee that another
>>> process using the gpu could not get access to the buffers..
>>
>> IMO that should work fine, but we need to provide a way for user-space
>> to determine whether
>> the render node is secure or not. Perhaps a sysfs attribute and / or a
>> drm getparam() parameter?
>
> I'd *assume* that that sort of thing would just be some sort of CL extension?
>
> But no objection to exposing it in a more common way.
>
> I guess it is also an option to keep the bootarg to override default
> (with the default being 'enabled' for hw w/ per-context/process vm and
> 'disabled' otherwise).

Imo if we expose this through sysfs we should always enable
rendernodes. The udev scripts can then decide what permissions to set
on them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/helper: lock all around force mode restore

[Daniel Vetter]

On Fri, Mar 21, 2014 at 10:46:59AM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Since Daniel documented things with a sledge hammer, we got lots of
> nice backtraces in suspend/resume operations, I've check the callers
> of this and they all seems safe to me,
> 
> This fixes one set of warns I reported.
> 
> Signed-off-by: Dave Airlie 

Some drivers have some other modeset gunk around the call to this helper
(like cursor frobbing or dpms frobbing) which probably should be moved
either to their crtc enable hook or into the core crtc helpers. So I don't
think pushing the locking out intro drivers is that useful

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_crtc_helper.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 5d2b7a5..c0f2d62 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -983,6 +983,7 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
>   int encoder_dpms;
>   bool ret;
>  
> + drm_modeset_lock_all(dev);
>   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
>  
>   if (!crtc->enabled)
> @@ -1017,6 +1018,7 @@ void drm_helper_resume_force_mode(struct drm_device 
> *dev)
>  
>   /* disable the unused connectors while restoring the modesetting */
>   __drm_helper_disable_unused_functions(dev);
> + drm_modeset_unlock_all(dev);
>  }
>  EXPORT_SYMBOL(drm_helper_resume_force_mode);
>  
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

How to check the HDMI TMDS clock frequency and DP link symbol clock frequency, on HSW/BDW/VLV?

[Lin, Mengdong]

Hi,

Could someone clarify how to check HDMI TMDS clock frequency and DisplayPort 
link symbol clock frequency?

-  Is there some registers which can dump the clock frequency?

-  Is 'clock' field in 'struct drm_display_mode' reflect the this clock?

My platform is Haswell, Broadwell and Baytrail (Valleyview).

I want to check

-  TMDS clock frequency for HDMI

-  Link Symbol clock for DP

One test monitor has problem to play 48khz audio. So I want to make sure 
N/M/CTS values are right for the display clock and audio sample rate.

Thanks
Mengdong

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/e101d1ad/attachment-0001.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #9 from Gregory Land  ---
Created attachment 96141
  --> https://bugs.freedesktop.org/attachment.cgi?id=96141=edit
Image of kernel panic with single core only

Image of kernel panic with single core only

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/c1ff7627/attachment-0001.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #8 from Gregory Land  ---
Created attachment 96140
  --> https://bugs.freedesktop.org/attachment.cgi?id=96140=edit
Disabled all but one core and hyper-threading.  Helped with log loss

  Log with more info.  Disabled hyper-threading and all but one core.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/b29f49fa/attachment.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #7 from Gregory Land  ---
Created attachment 96139
  --> https://bugs.freedesktop.org/attachment.cgi?id=96139=edit
Kernel Panic Displayed after waiting out the lockup very rare

  If I wait around long enough the system might kernel panic and display a few
messages that don't seem to get added to the logs.  I have a photo of them
taken from my phone to attach.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6afa323e/attachment-0001.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #6 from Gregory Land  ---
Created attachment 96138
  --> https://bugs.freedesktop.org/attachment.cgi?id=96138=edit
Greg: Log where i managed to get system to boot to terminal session before
crash happened.

  Log from kernel created from bisected copy of Linus's github on an linux
machine.  I added a few DRM_INFO() outputs in an attempt to find where the
lockup is occurring.  From what I can tell the crash is preventing the logs
from being written out,

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6de1c5ef/attachment.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

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

--- Comment #5 from Gregory Land  ---
I am having a similar problem with my 4870.  If i disconnect my second monitor
I can boot with radeon.dmp = 1.  If I reconnect the monitor again it will lock
up shortly after boot.

A bisect brings up this commit
https://github.com/torvalds/linux/commit/ab70b1dde73ff4525c3cd51090c233482c50f21
Which makes sense since this commit enabled dpm by default on radeon x7xx
series cards.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/5f326457/attachment.html>

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

Some final few intel fixes, all regressions, all stable cc, and one exynos 
oops fixer, the biggest is probably the intel display error irqs one, but 
it seems to fix a few crashes on startup, and one use after free in drm 
core.

Dave.

The following changes since commit dcb99fd9b08cfe1afe426af4d8d3cbc429190f15:

  Linux 3.14-rc7 (2014-03-16 18:51:24 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 004e5cf743086990e5fc04a14437b3966d7fa9a2:

  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes 
(2014-03-20 13:20:00 +1000)



Ben Widawsky (1):
  drm/i915: Fix PSR programming

Chris Wilson (1):
  drm/i915: Disable stolen memory when DMAR is active

Daniel Kurtz (1):
  drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c

Daniel Vetter (2):
  drm/i915: Don't enable display error interrupts from the start
  drm: Fix use-after-free in the shadow-attache exit code

Dave Airlie (3):
  Merge tag 'drm-intel-fixes-2014-03-17' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge tag 'drm-intel-fixes-2014-03-19' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'exynos-drm-fixes' of 
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Jani Nikula (1):
  Revert "drm/i915: don't touch the VDD when disabling the panel"

Ville Syrj?l? (2):
  drm/i915: Add a workaround for HSW scanline counter weirdness
  drm/i915: Fix scanline counter fixup on BDW

 drivers/gpu/drm/drm_pci.c   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 +++--
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  7 
 drivers/gpu/drm/i915/i915_irq.c | 71 +++--
 drivers/gpu/drm/i915/intel_ddi.c|  1 +
 drivers/gpu/drm/i915/intel_dp.c | 12 +-
 6 files changed, 67 insertions(+), 36 deletions(-)

[Bug 76382] Mesa Gallium egllog _eglLog

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

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

--- Comment #5 from Chris  ---
Created attachment 96130
  --> https://bugs.freedesktop.org/attachment.cgi?id=96130=edit
Build log for mesa 10.0.4 followup for Matt Turner

As promised here is the build log for the build fail on the include
dependencies _eglLog and a few others which seem related to the same condition
or failt.

thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/54b6fcca/attachment.html>

[Bug 76382] Mesa Gallium egllog _eglLog

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

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

--- Comment #4 from Chris  ---
As predicted.

Trying to compile the new version bunked out on the same compile failure.


Here is a short snippet while ill attach the main buildlog file to the
attachments.


../../../../src/gallium/state_trackers/egl/.libs/libegl.a(egl_g3d_sync.o): In
function `_eglGetSync':
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/../../../../src/egl/main/eglsync.h:68:
undefined reference to `_eglGetResource'
../../../../src/gallium/state_trackers/egl/.libs/libegl.a(egl_g3d_sync.o): In
function `_eglPutSync':
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/../../../../src/egl/main/eglsync.h:79:
undefined reference to `_eglPutResource'
../../../../src/gallium/state_trackers/egl/.libs/libegl.a(egl_g3d_sync.o): In
function `egl_g3d_client_wait_sync':
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/common/egl_g3d_sync.c:230:
undefined reference to `_eglGetCurrentContext'
../../../../src/gallium/state_trackers/egl/.libs/libegl.a(egl_g3d_sync.o): In
function `egl_g3d_signal_sync':
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/common/egl_g3d_sync.c:269:
undefined reference to `_eglError'
../../../../src/gallium/state_trackers/egl/.libs/libegl.a(native_dri2.o): In
function `dri2_surface_process_drawable_buffers':
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/x11/native_dri2.c:171:
undefined reference to `_eglLog'
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/x11/native_dri2.c:169:
undefined reference to `_eglLog'
../../../../src/gallium/state_trackers/egl/.libs/libegl.a(native_dri2.o): In
function `dri2_display_init_screen':
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/x11/native_dri2.c:824:
undefined reference to `_eglLog'
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/x11/native_dri2.c:840:
undefined reference to `_eglLog'
../../../../src/gallium/state_trackers/egl/.libs/libegl.a(native_x11.o): In
function `native_create_display':
/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/x11/native_x11.c:43:
undefined reference to `_eglLog'
../../../../src/gallium/state_trackers/egl/.libs/libegl.a(x11_screen.o):/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/state_trackers/egl/x11/x11_screen.c:274:
more undefined references to `_eglLog' follow
collect2: error: ld returned 1 exit status
libtool: install: error: relink `egl_gallium.la' with the above command before
installing it
gmake[4]: *** [install-eglLTLIBRARIES] Error 1
gmake[4]: Leaving directory
`/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/targets/egl-static'
gmake[3]: *** [install-am] Error 2
gmake[3]: Leaving directory
`/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/targets/egl-static'
gmake[2]: *** [install-recursive] Error 1
gmake[2]: Leaving directory
`/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src/gallium/targets'
gmake[1]: *** [install-recursive] Error 1
gmake[1]: Leaving directory
`/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64/src'
make: *** [install-recursive] Error 1
 * ERROR: media-libs/mesa-10.0.4::gentoo failed (install phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info
'=media-libs/mesa-10.0.4::gentoo'`,
 * the complete build log and the output of `emerge -pqv
'=media-libs/mesa-10.0.4::gentoo'`.
 * The complete build log is located at
'/var/tmp/portage/media-libs/mesa-10.0.4/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/media-libs/mesa-10.0.4/temp/environment'.
 * Working directory:
'/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4-amd64'
 * S: '/var/tmp/portage/media-libs/mesa-10.0.4/work/Mesa-10.0.4'

>>> Failed to emerge media-libs/mesa-10.0.4, Log file:

>>>  '/var/tmp/portage/media-libs/mesa-10.0.4/temp/build.log'



I am almost certain this has something to do with the compile/build process
locating its include files folder.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/a5ea4101/attachment.html>

[Bug 76382] Mesa Gallium egllog _eglLog

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

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

--- Comment #3 from Chris  ---
(In reply to comment #2)
> Post a build log.

I would love to but now it compiles fine.

It seems that when you compile and install it first with -gallium -opnvg -xa
disabled it compiles and installs.

After that if you recompile it with the above 3 enabled it compiles fine. i
guess it pulls the ellog header from the location it is installed to in the
system.

I shall run a build on the 10.1 version and see if it still compiles fine and
see if i can output the buildlog at the same time.

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