[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #59 from Alex Deucher  ---
(In reply to Chernovsky Oleg from comment #58)
> Can you elaborate on what each bit of this control register means? Maybe I
> just can't into abbreviations :)

TMIN - temp at which the fan would be turned on
FDO_PWM_MODE - which PWM mode to use:
0 - static PWM based on fuse value
1 - static PWM based on CG_FDO_CTRL0.FDO_STATIC_DUTY value
2 - dynamic PWM
5 - static PWM based on RPM CG_TACH_CTRL.TARGET_PERIOD value
TACH_PWM_RESP_RATE - amount to adjust PWM in tach mode

As far as I know, only values 1 and 5 are used for FDO_PWM_MODE in the driver
for manual control.  I'm not sure what dynamic PWM (2) means or how it works. 
It might be used by the smc for fan control.

I also noticed a minor error in the RPM control setup, and I've pushed a patch
to my 3.19-wip branch.

-- 
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/20141201/c44f85a3/attachment.html>

[PATCH v5 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

[Boris Brezillon]

Foxlink's fl500wvr00-a0t supports RGB888 format.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 66838a5..695f406 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.width = 108,
.height = 65,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

 static const struct drm_display_mode innolux_n116bge_mode = {
-- 
1.9.1

[PATCH v5 2/3] drm: panel: simple-panel: add support for bus_format retrieval

[Boris Brezillon]

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 23de22f..66838a5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -61,6 +61,8 @@ struct panel_desc {
unsigned int disable;
unsigned int unprepare;
} delay;
+
+   u32 bus_format;
 };

 struct panel_simple {
@@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
connector->display_info.bpc = panel->desc->bpc;
connector->display_info.width_mm = panel->desc->size.width;
connector->display_info.height_mm = panel->desc->size.height;
+   if (panel->desc->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+>desc->bus_format, 1);

return num;
 }
-- 
1.9.1

[PATCH v5 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris Brezillon 
Acked-by: Laurent Pinchart 
Acked-by: Philipp Zabel 
---
 drivers/gpu/drm/drm_crtc.c | 35 +++
 include/drm/drm_crtc.h |  8 
 2 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..1295863 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -764,6 +764,40 @@ static void drm_mode_remove(struct drm_connector 
*connector,
 }

 /**
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the supported bus formats in display info structure.
+ * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
+ * a full list of available formats.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info,
+const u32 *formats,
+unsigned int num_formats)
+{
+   u32 *fmts = NULL;
+
+   if (!formats && num_formats)
+   return -EINVAL;
+
+   if (formats && num_formats) {
+   fmts = kmemdup(formats, sizeof(*formats) * num_formats,
+  GFP_KERNEL);
+   if (!formats)
+   return -ENOMEM;
+   }
+
+   kfree(info->bus_formats);
+   info->bus_formats = fmts;
+   info->num_bus_formats = num_formats;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
+/**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
  * @mode: returned mode
@@ -914,6 +948,7 @@ void drm_connector_cleanup(struct drm_connector *connector)
ida_remove(_connector_enum_list[connector->connector_type].ida,
   connector->connector_type_id);

+   kfree(connector->display_info.bus_formats);
drm_mode_object_put(dev, >base);
kfree(connector->name);
connector->name = NULL;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..5d351f5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;

+   const u32 *bus_formats;
+   unsigned int num_bus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;

@@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);

+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+   const u32 *formats,
+   unsigned int num_formats);
+
 static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
 {
-- 
1.9.1

[PATCH v5 0/3] drm: describe display bus format

[Boris Brezillon]

Hello,

This series makes use of the MEDIA_BUS_FMT definition to describe how
the data are transmitted to the display.

This will allow drivers to configure their output display bus according
to the display capabilities.
For example some display controllers support DPI (or raw RGB) connectors
and need to specify which format will be transmitted on the DPI bus
(RGB444, RGB565, RGB888, ...).

This series also adds a field to the panel_desc struct so that one
can specify which format is natevely supported by a panel.

Regards,

Boris

Changes since v4:
 - fix typo
 - fix 'line over 80 characters' warnings
 - fix leak of formats array

Changes since v3:
 - store num_bus_formats on an unsigned int
 - clearly state that fmts argument (in drm_display_info_set_bus_formats
   function) should be an array of MEDIA_BUS_FMT_* values.

Changes since v2:
 - use the MEDIA_BUS_FMT macros

Changes since v1:
 - rename nformats into num_formats
 - declare num_formats as an unsigned int

Boris Brezillon (3):
  drm: add bus_formats and num_bus_formats fields to drm_display_info
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: panel: simple-panel: add bus format information for foxlink panel

 drivers/gpu/drm/drm_crtc.c   | 35 +++
 drivers/gpu/drm/panel/panel-simple.c |  6 ++
 include/drm/drm_crtc.h   |  8 
 3 files changed, 49 insertions(+)

-- 
1.9.1

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Hi Thierry,

On Mon, 1 Dec 2014 16:42:58 +0100
Thierry Reding  wrote:

> On Mon, Dec 01, 2014 at 09:20:59AM +0100, Boris Brezillon wrote:
> > Add bus_formats and num_bus_formats fields and
> > drm_display_info_set_bus_formats helper function to specify the bus
> > formats supported by a given display.
> > 
> > This information can be used by display controller drivers to configure
> > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
> > RGB or LVDS busses).
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 32 
> >  include/drm/drm_crtc.h |  7 +++
> >  2 files changed, 39 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index e79c8d3..d3b7ed0 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector 
> > *connector,
> > drm_mode_destroy(connector->dev, mode);
> >  }
> >  
> > +/*
> 
> This needs a /** marker to make it a valid kerneldoc comment.

Yep, I'll fix that.

> 
> > + * drm_display_info_set_bus_formats - set the supported bus formats
> > + * @info: display info to store bus formats in
> > + * @fmts: array containing the supported bus formats
> > + * @nfmts: the number of entries in the fmts array
> > + *
> > + * Store the suppported bus formats in display info structure.
> > + * See MEDIA_BUS_FMT_* definitions in 
> > include/uapi/linux/media-bus-format.h for
> > + * a full list of available formats.
> > + */
> > +int drm_display_info_set_bus_formats(struct drm_display_info *info, const 
> > u32 *fmts,
> 
> This one still exceeds 80-characters per line, but perhaps I'm reviewing
> the wrong patch? Also I think fmts should be formats here.
> 
> > +unsigned int num_fmts)
> 
> And this should be num_formats, for consistency. Also make sure to keep
> this consistent with the kerneldoc.
> 
> > +{
> > +   u32 *formats = NULL;
> 
> If you name the parameter formats, maybe bus_formats would be a good
> alternative for this local variable. Or fmts here. I think it's most
> important that the public API gets the more idiomatic name.

Okay, I'll rework the argument and variable names.

> 
> > +
> > +   if (!fmts && num_fmts)
> > +   return -EINVAL;
> > +
> > +   if (fmts && num_fmts) {
> > +   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
> > +   if (!formats)
> > +   return -ENOMEM;
> > +   }
> > +
> > +   kfree(info->bus_formats);
> > +   info->bus_formats = formats;
> > +   info->num_bus_formats = num_fmts;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_display_info_set_bus_formats);
> 
> I think you'll want to call kfree() on the bus_formats array from
> drm_connector_cleanup() as well to make sure you don't leak this on
> driver unload.

Indeed, I'll fix that memory leak.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH] drm/gma500: add support for atom e6xx lpc lvds i2c

[Patrik Jakobsson]

On Fri, Sep 26, 2014 at 10:40 AM, Jan Safrata  
wrote:
> add gpio bitbanging i2c adapter on LPC device of atom e6xx
> gpu chipset to access lvds EDID
> tested on SECO QuadMo747-E6xx-EXTREME Qseven platform
>
> Cc: Patrik Jakobsson 
> Signed-off-by: Jan Safrata 
> ---
>  drivers/gpu/drm/gma500/Makefile|   1 +
>  drivers/gpu/drm/gma500/oaktrail_lvds.c |  31 --
>  drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c | 170 
> +
>  drivers/gpu/drm/gma500/psb_drv.c   |  20 
>  drivers/gpu/drm/gma500/psb_drv.h   |   3 +
>  drivers/gpu/drm/gma500/psb_intel_drv.h |   1 +
>  6 files changed, 214 insertions(+), 12 deletions(-)
>  create mode 100644 drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
>
> diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
> index b153155..190e55f 100644
> --- a/drivers/gpu/drm/gma500/Makefile
> +++ b/drivers/gpu/drm/gma500/Makefile
> @@ -39,6 +39,7 @@ gma500_gfx-$(CONFIG_DRM_GMA3600) +=  cdv_device.o \
>  gma500_gfx-$(CONFIG_DRM_GMA600) += oaktrail_device.o \
>   oaktrail_crtc.o \
>   oaktrail_lvds.o \
> + oaktrail_lvds_i2c.o \
>   oaktrail_hdmi.o \
>   oaktrail_hdmi_i2c.o
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index 0d39da6..83bbc27 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -359,22 +359,26 @@ void oaktrail_lvds_init(struct drm_device *dev,
>  *if closed, act like it's not there for now
>  */
>
> +   edid = NULL;
> mutex_lock(>mode_config.mutex);
> i2c_adap = i2c_get_adapter(dev_priv->ops->i2c_bus);
> -   if (i2c_adap == NULL)
> -   dev_err(dev->dev, "No ddc adapter available!\n");
> +   if (i2c_adap)
> +   edid = drm_get_edid(connector, i2c_adap);
> +   if (edid == NULL && dev_priv->lpc_gpio_base) {
> +   oaktrail_lvds_i2c_init(encoder);
> +   if (gma_encoder->ddc_bus != NULL) {
> +   i2c_adap = _encoder->ddc_bus->adapter;
> +   edid = drm_get_edid(connector, i2c_adap);
> +   }
> +   }
> /*
>  * Attempt to get the fixed panel mode from DDC.  Assume that the
>  * preferred mode is the right one.
>  */
> -   if (i2c_adap) {
> -   edid = drm_get_edid(connector, i2c_adap);
> -   if (edid) {
> -   drm_mode_connector_update_edid_property(connector,
> -   edid);
> -   drm_add_edid_modes(connector, edid);
> -   kfree(edid);
> -   }
> +   if (edid) {
> +   drm_mode_connector_update_edid_property(connector, edid);
> +   drm_add_edid_modes(connector, edid);
> +   kfree(edid);
>
> list_for_each_entry(scan, >probed_modes, head) {
> if (scan->type & DRM_MODE_TYPE_PREFERRED) {
> @@ -383,7 +387,8 @@ void oaktrail_lvds_init(struct drm_device *dev,
> goto out;   /* FIXME: check for quirks */
> }
> }
> -   }
> +   } else
> +   dev_err(dev->dev, "No ddc adapter available!\n");
> /*
>  * If we didn't get EDID, try geting panel timing
>  * from configuration data
> @@ -411,8 +416,10 @@ failed_find:
> mutex_unlock(>mode_config.mutex);
>
> dev_dbg(dev->dev, "No LVDS modes found, disabling.\n");
> -   if (gma_encoder->ddc_bus)
> +   if (gma_encoder->ddc_bus) {
> psb_intel_i2c_destroy(gma_encoder->ddc_bus);
> +   gma_encoder->ddc_bus = NULL;
> +   }
>
>  /* failed_ddc: */
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
> new file mode 100644
> index 000..f913a62
> --- /dev/null
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c
> @@ -0,0 +1,170 @@
> +/*
> + * Copyright (c) 2002-2010, Intel Corporation.
> + * Copyright (c) 2014 ATRON electronic GmbH
> + *   Author: Jan Safrata 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to 
> deal
> + * in the Software without restriction, including without limitation the 
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING 

[PATCH v13 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access

[Andy Yan]

Hi Philipp:
On 2014年12月01日 20:04, Philipp Zabel wrote:
> Am Freitag, den 28.11.2014, 17:43 +0800 schrieb Andy Yan:
>> Hi Zabel:
>> On 2014年11月27日 00:34, Philipp Zabel wrote:
>>> Am Mittwoch, den 26.11.2014, 21:32 +0800 schrieb Andy Yan:
 On rockchip rk3288, only word(32-bit) accesses are
 permitted for hdmi registers.  Byte width accesses (writeb,
 readb) generate an imprecise external abort.

 Signed-off-by: Andy Yan 

 ---

 Changes in v13: None
 Changes in v12: None
 Changes in v11: None
 Changes in v10: None
 Changes in v9: None
 Changes in v8: None
 Changes in v7: None
 Changes in v6:
 - refactor register access without reg_shift

 Changes in v5:
 - refactor reg-io-width

 Changes in v4: None
 Changes in v3:
 - split multi-register access to one indepent patch

drivers/gpu/drm/bridge/dw_hdmi.c | 57 
 +++-
1 file changed, 51 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
 b/drivers/gpu/drm/bridge/dw_hdmi.c
 index a53bf63..5e88c8d 100644
 --- a/drivers/gpu/drm/bridge/dw_hdmi.c
 +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
 @@ -100,6 +100,11 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
};

 +union dw_reg_ptr {
 +  u32 __iomem *p32;
 +  u8 __iomem *p8;
 +};
>>> I see no need to introduce this. Just explicitly multiply the offset in
>>> dw_hdmi_writel.
>>>
>>   Is there any disadvantage to do like this?
>>   The compiler can help us do the explicitly multiply by this way.
> Four additional lines, a new defined type, a few more changes to struct
> dw_hdmi and dw_hdmi_bind necessary.
>
> Technically I see no problem to let the compiler do the multiplication,
> my issue is that it ever so slightly obfuscates the code. Instead of
> just writing "* 4" in two functions, we get a new union that you need to
> know about when looking at struct dw_hdmi and dw_hdmi_bind, regs.p8 is
> used but never assigned directly, it's just a tiny bit of additional
> effort needed to understand the code. But when the cost to avoid that is
> so small...
>
> regards
> Philipp
>

   What you said is right, I will change it in PATCH V15
thanks .
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

[Andy Yan]

Hi Philipp:

On 2014年12月01日 19:42, Philipp Zabel wrote:
> Hi Andy,
>
> Am Montag, den 01.12.2014, 19:24 +0800 schrieb Andy Yan:
> [...]
>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>> new file mode 100644
>> index 000..1bbf3ca
>> --- /dev/null
>> +++ b/include/drm/bridge/dw_hdmi.h
>> @@ -0,0 +1,57 @@
>> +/*
>> + * Copyright (C) 2011 Freescale Semiconductor, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#ifndef __DW_HDMI__
>> +#define __DW_HDMI__
>> +
>> +#include 
>> +
>> +enum {
>> +RES_8,
>> +RES_10,
>> +RES_12,
>> +RES_MAX,
>> +};
>> +
>> +enum dw_hdmi_devtype {
>> +IMX6Q_HDMI,
>> +IMX6DL_HDMI,
>> +};
>> +
>> +struct mpll_config {
>> +unsigned long mpixelclock;
>> +struct {
>> +u16 cpce;
>> +u16 gmp;
>> +} res[RES_MAX];
>> +};
>> +
>> +struct curr_ctrl {
>> +unsigned long mpixelclock;
>> +u16 curr[RES_MAX];
>> +};
>> +
>> +struct sym_term {
>> +unsigned long mpixelclock;
>> +u16 sym_ctr;/*clock symbol and transmitter control*/
>> +u16 term;   /*transmission termination value*/
>> +};
> since this is going to be used by multiple drivers, the enums and
> structs should all be properly namespaced. How about DW_HDMI_RES_x,
> struct dw_hdmi_mpll_config, struct dw_hdmi_curr_ctrl, and struct
> dw_hdmi_sym_term?

   That sounds good, I will take your advice in PATCH V15.
   Thanks
>> +struct dw_hdmi_plat_data {
>> +enum dw_hdmi_devtype dev_type;
>> +const struct mpll_config *mpll_cfg;
>> +const struct curr_ctrl *cur_ctr;
>> +const struct sym_term *sym_term;
>> +};
>> +
>> +void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
>> +int dw_hdmi_bind(struct device *dev, struct device *master,
>> + void *data, struct drm_encoder *encoder,
>> + const struct dw_hdmi_plat_data *plat_data);
>> +#endif /* __IMX_HDMI_H__ */
> regards
> Philipp
>
>
> ___
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>

omapdrm/pvr kernel crash with camera capture and display application

[Vikas Patil]

88 ef0a5e58 80060018
 
[  114.062591] 9fa0:  ef0b9fb0 8000ee18 80060024  
 
[  114.062591] 9fc0:      
 
[  114.062591] 9fe0:     0013 
40c04a08 00412274
[  114.062591] Backtrace:
[  114.062591] [<800605b0>] (kthread_data+0x0/0x20) from [<80058a54>]
(wq_worker_sleeping+0x1c/0xac)
[  114.062622] [<80058a38>] (wq_worker_sleeping+0x0/0xac) from [<804c5b68>]
(__schedule+0x104/0x678)
[  114.062622]  r6:ef0b8000 r5:8901a740 r4:ef0a1680 r3:0420806c
[  114.062622] [<804c5a64>] (__schedule+0x0/0x678) from [<804c6280>]
(schedule+0x94/0x98)
[  114.062622] [<804c61ec>] (schedule+0x0/0x98) from [<80040998>]
(do_exit+0x868/0x8d8)
[  114.062652] [<80040130>] (do_exit+0x0/0x8d8) from [<80013b58>]
(die+0x360/0x3d8)
[  114.062652]  r7:804c4ff0
[  114.062652] [<800137f8>] (die+0x0/0x3d8) from [<804bfa08>]
(__do_kernel_fault.part.9+0x64/0x84)
[  114.062652] [<804bf9a4>] (__do_kernel_fault.part.9+0x0/0x84) from
[<8001bf34>] (do_page_fault+0x2f8/0x340)
[  114.062683]  r7:ef0a1680 r3:ef0b9dc8
[  114.062683] [<8001bc3c>] (do_page_fault+0x0/0x340) from [<80008524>]
(do_DataAbort+0x44/0xa8)
[  114.062683] [<800084e0>] (do_DataAbort+0x0/0xa8) from [<8000e8d8>]
(__dabt_svc+0x38/0x60)
[  114.062683] Exception stack(0xef0b9dc8 to 0xef0b9e10)
[  114.062683] 9dc0:   0014 6013 0001d838 f000
0014 
[  114.062713] 9de0:  ee9653c0 8073ef0c   ef0b9e24
ef0b9e28 ef0b9e10
[  114.062713] 9e00: 80324a80 804c4ff0 0013 
[  114.062713]  r7:ef0b9dfc r6: r5:0013 r4:804c4ff0
[  114.062713] [<804c4fd4>] (mutex_lock+0x0/0x58) from [<80324a80>]
(omap_gem_put_paddr+0x24/0xb8)
[  114.062744]  r4:ecfe5300 r3:f000
[  114.062774] [<80324a5c>] (omap_gem_put_paddr+0x0/0xb8) from [<7f009e44>]
(UnwrapExtMemoryCallBack+0x64/0x74 [omapdrm_pvr])
[  114.062774]  r5: r4:ecfe5300
[  114.062805] [<7f009de0>] (UnwrapExtMemoryCallBack+0x0/0x74
[omapdrm_pvr]) from [<7f014d88>] (FreeResourceByPtr+0x48/0xe8 [omapdrm_pvr])
[  114.062805]  r6: r5:0001 r4:ee965b00 r3:7f009de0
[  114.062866] [<7f014d40>] (FreeResourceByPtr+0x0/0xe8 [omapdrm_pvr]) from
[<7f0155b4>] (ResManFreeResByPtr+0x64/0x80 [omapdrm_pvr])
[  114.062866]  r6:ecf68880 r5: r4:ee965b00
[  114.062927] [<7f015550>] (ResManFreeResByPtr+0x0/0x80 [omapdrm_pvr])
from [<7f009314>] (async_unmap+0x34/0x54 [omapdrm_pvr])
[  114.062927]  r5:7f0268a0 r4:ee9653c0
[  114.062957] [<7f0092e0>] (async_unmap+0x0/0x54 [omapdrm_pvr]) from
[<803244e0>] (notify_worker+0x40/0x48)
[  114.062957]  r6:7f0092e0 r5:807bbaa4 r4:ee965420 r3:
[  114.062957] [<803244a0>] (notify_worker+0x0/0x48) from [<80058198>]
(process_one_work+0x278/0x488)
[  114.062988]  r7:ef2aca00 r6:8073ee00 r5:ee965420 r4:ef0661c0
[  114.062988] [<80057f20>] (process_one_work+0x0/0x488) from [<80058808>]
(worker_thread+0x278/0x398)
[  114.062988] [<80058590>] (worker_thread+0x0/0x398) from [<800600d4>]
(kthread+0xbc/0xcc)
[  114.062988] [<80060018>] (kthread+0x0/0xcc) from [<8000ee18>]
(ret_from_fork+0x14/0x20)
[  114.063018]  r7: r6: r5:80060018 r4:ef0a5e58
[  114.063018] Code: e24cb004 e52de004 e8bd4000 e59031cc (e5130014)
[  114.063018] ---[ end trace 2441b1bbdffd41f0 ]---
[  114.063018] Fixing recursive fault but reboot is needed!
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/1ea00b3a/attachment-0001.html>

[PATCH v14 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support

[Andy Yan]

Rockchip RK3288 hdmi is compatible with dw_hdmi

this patch is depend on patch by Mark Yao Add drm
driver for Rockchip Socs

see https://lkml.org/lkml/2014/11/19/1153

Signed-off-by: Andy Yan 

---

Changes in v14: None
Changes in v13: None
Changes in v12:
- add comment for the depend on patch

Changes in v11: None
Changes in v10:
- add more display mode support mpll configuration for rk3288

Changes in v9:
- move some phy configuration to platform driver

Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/bridge/dw_hdmi.c|   3 +
 drivers/gpu/drm/rockchip/Kconfig|  10 +
 drivers/gpu/drm/rockchip/Makefile   |   2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 355 
 include/drm/bridge/dw_hdmi.h|   1 +
 5 files changed, 370 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index df52347..326bffb 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -853,6 +853,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);

+   if (hdmi->dev_type == RK3288_HDMI)
+   dw_hdmi_phy_enable_spare(hdmi, 1);
+
/*Wait for PHY PLL lock */
msec = 5;
do {
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0ff6682..06371ae 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -15,3 +15,13 @@ config DRM_ROCKCHIP
  management to userspace. This driver does not provide
  2D or 3D acceleration; acceleration is performed by other
  IP found on the SoC.
+
+config ROCKCHIP_DW_HDMI
+bool "Rockchip specific extensions for Synopsys DW HDMI"
+depends on DRM_ROCKCHIP
+select DRM_DW_HDMI
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Synopsys DesignWare HDMI driver. If you want to
+ enable HDMI on RK3288 based SoC, you should selet this
+ option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index b3a5193..347e65c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -4,5 +4,5 @@

 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_drm_gem.o rockchip_drm_vop.o
-
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
new file mode 100644
index 000..16cad75
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -0,0 +1,355 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define GRF_SOC_CON60x025c
+#define HDMI_SEL_VOP_LIT(1 << 4)
+
+struct rockchip_hdmi {
+   struct device *dev;
+   struct clk *clk;
+   struct clk *hdcp_clk;
+   struct regmap *regmap;
+   struct drm_encoder encoder;
+};
+
+#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
+
+static const struct mpll_config rockchip_mpll_cfg[] = {
+   {
+   2700, {
+   { 0x00b3, 0x},
+   { 0x2153, 0x},
+   { 0x40f3, 0x}
+   },
+   }, {
+   3600, {
+   { 0x00b3, 0x},
+   { 0x2153, 0x},
+   { 0x40f3, 0x}
+   },
+   }, {
+   4000, {
+   { 0x00b3, 0x},
+   { 0x2153, 0x},
+   { 0x40f3, 0x}
+   },
+   }, {
+   5400, {
+   { 0x0072, 0x0001},
+   { 0x2142, 0x0001},
+   { 0x40a2, 0x0001},
+   },
+   }, {
+   6500, {
+   { 0x0072, 0x0001},
+   { 0x2142, 0x0001},
+   { 0x40a2, 0x0001},
+   },
+   }, {
+   6600, {
+   { 0x013e, 0x0003},
+   { 0x217e, 0x0002},
+   

[PATCH v14 11/12] dt-bindings: Add documentation for rockchip dw hdmi

[Andy Yan]

Signed-off-by: Andy Yan 

---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- Add documentation for rockchip dw hdmi

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt

diff --git a/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
new file mode 100644
index 000..0735464
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
@@ -0,0 +1,43 @@
+Rockchip specific extensions to the Synopsys Designware HDMI
+
+
+Required properties:
+- compatible: "rockchip,rk3288-dw-hdmi";
+- reg: Physical base address and length of the controller's registers.
+- ddc-i2c-bus:  phandle of an I2C controller used for DDC EDID probing
+- clocks: from common clock binding: handle to hdmi clock.
+- clock-names: should be "clk" "hdcp_clk"
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- interrupts: HDMI interrupt number
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt. For
+  vopb,set the reg = <0> and set the reg = <1> for vopl.
+- reg-io-width: the width of the reg:1,4, the value should be 4 on
+  rk3288 platform
+
+Example:
+hdmi: hdmi at ff98 {
+   compatible = "rockchip,rk3288-dw-hdmi";
+   reg = <0xff98 0x2>;
+   reg-io-width = <4>;
+   ddc-i2c-bus = <>;
+   rockchip,grf = <>;
+   interrupts = ;
+   clocks = <  PCLK_HDMI_CTRL>, < SCLK_HDMI_HDCP>;
+   clock-names = "clk", "hdcp_clk";
+   status = "disabled";
+   ports {
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   hdmi_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH v14 10/12] drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare

[Andy Yan]

RK3288 HDMI will not work without the spare bit of
HDMI_PHY_CONF0 enable

Signed-off-by: Andy Yan 
---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 7 +++
 drivers/gpu/drm/bridge/dw_hdmi.h | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 5be643c..df52347 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -715,6 +715,13 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi *hdmi, 
u8 enable)
 HDMI_PHY_CONF0_ENTMDS_MASK);
 }

+static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
+{
+   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
+HDMI_PHY_CONF0_SPARECTRL_OFFSET,
+HDMI_PHY_CONF0_SPARECTRL_MASK);
+}
+
 static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
 {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.h b/drivers/gpu/drm/bridge/dw_hdmi.h
index baa7849..175dbc8 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.h
+++ b/drivers/gpu/drm/bridge/dw_hdmi.h
@@ -837,7 +837,8 @@ enum {
HDMI_PHY_CONF0_PDZ_OFFSET = 7,
HDMI_PHY_CONF0_ENTMDS_MASK = 0x40,
HDMI_PHY_CONF0_ENTMDS_OFFSET = 6,
-   HDMI_PHY_CONF0_SPARECTRL = 0x20,
+   HDMI_PHY_CONF0_SPARECTRL_MASK = 0x20,
+   HDMI_PHY_CONF0_SPARECTRL_OFFSET = 5,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK = 0x10,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET = 4,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK = 0x8,
-- 
1.9.1

[PATCH v14 09/12] drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done

[Andy Yan]

HDMI_IH_I2CMPHY_STAT0 is a clear on write register, which indicates i2cm
operation status(i2c transfer done or error), every hdmi phy register
configuration must check this register to make sure the configuration
has complete. But the indication bit should be cleared after check, otherwise
the corresponding bit will hold on forever, this may give a wrong signal for
next check.

Signed-off-by: Andy Yan 
---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index a95a553..5be643c 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -668,11 +668,15 @@ static inline void hdmi_phy_test_dout(struct dw_hdmi 
*hdmi,

 static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
 {
-   while ((hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
+   u32 val;
+
+   while ((val = hdmi_readb(hdmi, HDMI_IH_I2CMPHY_STAT0) & 0x3) == 0) {
if (msec-- == 0)
return false;
udelay(1000);
}
+   hdmi_writeb(hdmi, val, HDMI_IH_I2CMPHY_STAT0);
+
return true;
 }

-- 
1.9.1

[PATCH v14 08/12] drm: bridge/dw_hdmi: add mode_valid support

[Andy Yan]

some platform may not support all the display mode,
add mode_valid interface check it

Signed-off-by: Andy Yan 

---

Changes in v14:
- remove drm_connector_register, because imx-drm core has registered
connector

Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/bridge/dw_hdmi.c | 15 +++
 include/drm/bridge/dw_hdmi.h |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 5e88c8d..a95a553 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1406,6 +1406,20 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
return 0;
 }

+static enum drm_mode_status
+dw_hdmi_connector_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = container_of(connector,
+  struct dw_hdmi, connector);
+   enum drm_mode_status mode_status = MODE_OK;
+
+   if (hdmi->plat_data->mode_valid)
+   mode_status = hdmi->plat_data->mode_valid(connector, mode);
+
+   return mode_status;
+}
+
 static struct drm_encoder *dw_hdmi_connector_best_encoder(struct drm_connector
   *connector)
 {
@@ -1430,6 +1444,7 @@ static struct drm_connector_funcs dw_hdmi_connector_funcs 
= {

 static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
.get_modes = dw_hdmi_connector_get_modes,
+   .mode_valid = dw_hdmi_connector_mode_valid,
.best_encoder = dw_hdmi_connector_best_encoder,
 };

diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 1bbf3ca..1777ab4 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -48,6 +48,8 @@ struct dw_hdmi_plat_data {
const struct mpll_config *mpll_cfg;
const struct curr_ctrl *cur_ctr;
const struct sym_term *sym_term;
+   enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
+ struct drm_display_mode *mode);
 };

 void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
-- 
1.9.1

[PATCH v14 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access

[Andy Yan]

On rockchip rk3288, only word(32-bit) accesses are
permitted for hdmi registers.  Byte width accesses (writeb,
readb) generate an imprecise external abort.

Signed-off-by: Andy Yan 

---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- refactor register access without reg_shift

Changes in v5:
- refactor reg-io-width

Changes in v4: None
Changes in v3:
- split multi-register access to one indepent patch

 drivers/gpu/drm/bridge/dw_hdmi.c | 57 +++-
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index a53bf63..5e88c8d 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -100,6 +100,11 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

+union dw_reg_ptr {
+   u32 __iomem *p32;
+   u8 __iomem *p8;
+};
+
 struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
@@ -121,20 +126,43 @@ struct dw_hdmi {

struct regmap *regmap;
struct i2c_adapter *ddc;
-   void __iomem *regs;
+   union dw_reg_ptr regs;

unsigned int sample_rate;
int ratio;
+
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
 };

+static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+   writel(val, hdmi->regs.p32 + offset);
+}
+
+static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
+{
+   return readl(hdmi->regs.p32 + offset);
+}
+
+static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
+{
+   writeb(val, hdmi->regs.p8 + offset);
+}
+
+static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
+{
+   return readb(hdmi->regs.p8 + offset);
+}
+
 static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
-   writeb(val, hdmi->regs + offset);
+   hdmi->write(hdmi, val, offset);
 }

 static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
-   return readb(hdmi->regs + offset);
+   return hdmi->read(hdmi, offset);
 }

 static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
@@ -1508,6 +1536,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
struct dw_hdmi *hdmi;
struct resource *iores;
int ret, irq;
+   u32 val = 1;

hdmi = devm_kzalloc(>dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
@@ -1520,6 +1549,22 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
hdmi->ratio = 100;
hdmi->encoder = encoder;

+   of_property_read_u32(np, "reg-io-width", );
+
+   switch (val) {
+   case 4:
+   hdmi->write = dw_hdmi_writel;
+   hdmi->read = dw_hdmi_readl;
+   break;
+   case 1:
+   hdmi->write = dw_hdmi_writeb;
+   hdmi->read = dw_hdmi_readb;
+   break;
+   default:
+   dev_err(dev, "reg-io-width must be 1 or 4\n");
+   return -EINVAL;
+   }
+
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
@@ -1544,9 +1589,9 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
return ret;

iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   hdmi->regs = devm_ioremap_resource(dev, iores);
-   if (IS_ERR(hdmi->regs))
-   return PTR_ERR(hdmi->regs);
+   hdmi->regs.p32 = devm_ioremap_resource(dev, iores);
+   if (IS_ERR(hdmi->regs.p32))
+   return PTR_ERR(hdmi->regs.p32);

/* Product and revision IDs */
dev_info(dev,
-- 
1.9.1

[PATCH v14 06/12] dt-bindings: add document for dw_hdmi

[Andy Yan]

Signed-off-by: Andy Yan 

---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
new file mode 100644
index 000..107c1ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
@@ -0,0 +1,40 @@
+DesignWare HDMI bridge bindings
+
+Required properities:
+- compatible: platform specific such as:
+   * "fsl,imx6q-hdmi"
+   * "fsl,imx6dl-hdmi"
+   * "rockchip,rk3288-dw-hdmi"
+- reg: Physical base address and length of the controller's registers.
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- interrupts: The HDMI interrupt number
+
+Optional properties
+- reg-io-width: the width of the reg:1,4, default set to 1 if not present
+
+Example:
+   hdmi: hdmi at 012 {
+   compatible = "fsl,imx6q-hdmi";
+   reg = <0x0012 0x9000>;
+   interrupts = <0 115 0x04>;
+   gpr = <>;
+   clocks = < 123>, < 124>;
+   clock-names = "iahb", "isfr";
+   ddc-i2c-bus = <>;
+
+   port at 0 {
+   reg = <0>;
+
+   hdmi_mux_0: endpoint {
+   remote-endpoint = <_di0_hdmi>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+
+   hdmi_mux_1: endpoint {
+   remote-endpoint = <_di1_hdmi>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

[Andy Yan]

the original imx hdmi driver is under drm/imx/,
which depends on imx-drm, so move the imx hdmi
driver out to drm/bridge and rename it to dw_hdmi

Signed-off-by: Andy Yan 
---

Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c}   | 269 +++--
 .../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h}   |  42 
 drivers/gpu/drm/imx/Kconfig|   1 +
 drivers/gpu/drm/imx/Makefile   |   2 +-
 .../drm/imx/{imx-hdmi_pltfm.c => dw_hdmi-imx.c}| 122 +-
 include/drm/bridge/dw_hdmi.h   |  57 +
 8 files changed, 260 insertions(+), 239 deletions(-)
 rename drivers/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (84%)
 rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (98%)
 rename drivers/gpu/drm/imx/{imx-hdmi_pltfm.c => dw_hdmi-imx.c} (61%)
 create mode 100644 include/drm/bridge/dw_hdmi.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..26162ef 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,3 +3,8 @@ config DRM_PTN3460
depends on DRM
select DRM_KMS_HELPER
---help---
+
+config DRM_DW_HDMI
+   bool "Synopsys DesignWare High-Definition Multimedia Interface"
+   depends on DRM
+   select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..d8a8cfd 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
 ccflags-y := -Iinclude/drm

 obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
similarity index 84%
rename from drivers/gpu/drm/imx/imx-hdmi.c
rename to drivers/gpu/drm/bridge/dw_hdmi.c
index 99c2966..a53bf63 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -6,12 +6,11 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  *
- * SH-Mobile High-Definition Multimedia Interface (HDMI) driver
- * for SLISHDMI13T and SLIPHDMIT IP cores
+ * Designware High-Definition Multimedia Interface (HDMI) driver
  *
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */
-
+#include 
 #include 
 #include 
 #include 
@@ -23,8 +22,9 @@
 #include 
 #include 
 #include 
+#include 

-#include "imx-hdmi.h"
+#include "dw_hdmi.h"

 #define HDMI_EDID_LEN  512

@@ -100,16 +100,17 @@ struct hdmi_data_info {
struct hdmi_vmode video_mode;
 };

-struct imx_hdmi {
+struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
struct drm_bridge *bridge;

-   enum imx_hdmi_devtype dev_type;
+   enum dw_hdmi_devtype dev_type;
struct device *dev;

struct hdmi_data_info hdmi_data;
-   const struct imx_hdmi_plat_data *plat_data;
+   const struct dw_hdmi_plat_data *plat_data;
+
int vic;

u8 edid[HDMI_EDID_LEN];
@@ -126,17 +127,17 @@ struct imx_hdmi {
int ratio;
 };

-static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
+static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
writeb(val, hdmi->regs + offset);
 }

-static inline u8 hdmi_readb(struct imx_hdmi *hdmi, int offset)
+static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
return readb(hdmi->regs + offset);
 }

-static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
+static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
 {
u8 val = hdmi_readb(hdmi, reg) & ~mask;

@@ -144,13 +145,13 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 
mask, unsigned reg)
hdmi_writeb(hdmi, val, reg);
 }

-static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
+static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
 u8 shift, u8 mask)
 {
hdmi_modb(hdmi, data << shift, mask, reg);
 }

-static void hdmi_set_clock_regenerator_n(struct imx_hdmi *hdmi,
+static void hdmi_set_clock_regenerator_n(struct dw_hdmi *hdmi,
 unsigned int value)
 {
hdmi_writeb(hdmi, value & 0xff, HDMI_AUD_N1);
@@ -161,7 +162,7 @@ static void hdmi_set_clock_regenerator_n(struct imx_hdmi 
*hdmi,
hdmi_modb(hdmi, 0, HDMI_AUD_CTS3_N_SHIFT_MASK, HDMI_AUD_CTS3);
 }

-static void hdmi_regenerate_cts(struct imx_hdmi *hdmi, unsigned int cts)
+static void hdmi_regenerate_cts(struct dw_hdmi *hdmi, unsigned int cts)
 {

[PATCH v14 04/12] drm: imx: imx-hdmi: split phy configuration to platform driver

[Andy Yan]

hdmi phy configuration is platform specific, which can be adusted
according to the board to get the best SI

Signed-off-by: Andy Yan 

---

Changes in v14: None
Changes in v13:
- split phy configuration from patch#4

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/imx/imx-hdmi.c   | 85 +++-
 drivers/gpu/drm/imx/imx-hdmi.h   | 29 
 drivers/gpu/drm/imx/imx-hdmi_pltfm.c | 57 
 3 files changed, 101 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index f05b404..99c2966 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -710,76 +710,14 @@ static void imx_hdmi_phy_sel_interface_control(struct 
imx_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }

-enum {
-   RES_8,
-   RES_10,
-   RES_12,
-   RES_MAX,
-};
-
-struct mpll_config {
-   unsigned long mpixelclock;
-   struct {
-   u16 cpce;
-   u16 gmp;
-   } res[RES_MAX];
-};
-
-static const struct mpll_config mpll_config[] = {
-   {
-   4525, {
-   { 0x01e0, 0x },
-   { 0x21e1, 0x },
-   { 0x41e2, 0x }
-   },
-   }, {
-   9250, {
-   { 0x0140, 0x0005 },
-   { 0x2141, 0x0005 },
-   { 0x4142, 0x0005 },
-   },
-   }, {
-   14850, {
-   { 0x00a0, 0x000a },
-   { 0x20a1, 0x000a },
-   { 0x40a2, 0x000a },
-   },
-   }, {
-   ~0UL, {
-   { 0x00a0, 0x000a },
-   { 0x2001, 0x000f },
-   { 0x4002, 0x000f },
-   },
-   }
-};
-
-struct curr_ctrl {
-   unsigned long mpixelclock;
-   u16 curr[RES_MAX];
-};
-
-static const struct curr_ctrl curr_ctrl[] = {
-   /*  pixelclk bpp8bpp10   bpp12 */
-   {
-5400, { 0x091c, 0x091c, 0x06dc },
-   }, {
-5840, { 0x091c, 0x06dc, 0x06dc },
-   }, {
-7200, { 0x06dc, 0x06dc, 0x091c },
-   }, {
-7425, { 0x06dc, 0x0b5c, 0x091c },
-   }, {
-   11880, { 0x091c, 0x091c, 0x06dc },
-   }, {
-   21600, { 0x06dc, 0x0b5c, 0x091c },
-   }
-};
-
 static int hdmi_phy_configure(struct imx_hdmi *hdmi, unsigned char prep,
  unsigned char res, int cscon)
 {
unsigned res_idx, i;
u8 val, msec;
+   const struct mpll_config *mpll_config = hdmi->plat_data->mpll_cfg;
+   const struct curr_ctrl   *curr_ctrl = hdmi->plat_data->cur_ctr;
+   const struct sym_term *sym_term =  hdmi->plat_data->sym_term;

if (prep)
return -EINVAL;
@@ -825,7 +763,7 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi, 
unsigned char prep,
hdmi_phy_test_clear(hdmi, 0);

/* PLL/MPLL Cfg - always match on final entry */
-   for (i = 0; i < ARRAY_SIZE(mpll_config) - 1; i++)
+   for (i = 0; mpll_config[i].mpixelclock != (~0UL); i++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
mpll_config[i].mpixelclock)
break;
@@ -833,12 +771,12 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi, 
unsigned char prep,
hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].cpce, 0x06);
hdmi_phy_i2c_write(hdmi, mpll_config[i].res[res_idx].gmp, 0x15);

-   for (i = 0; i < ARRAY_SIZE(curr_ctrl); i++)
+   for (i = 0; curr_ctrl[i].mpixelclock != (~0UL); i++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
curr_ctrl[i].mpixelclock)
break;

-   if (i >= ARRAY_SIZE(curr_ctrl)) {
+   if (curr_ctrl[i].mpixelclock == (~0UL)) {
dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
hdmi->hdmi_data.video_mode.mpixelclock);
return -EINVAL;
@@ -849,10 +787,17 @@ static int hdmi_phy_configure(struct imx_hdmi *hdmi, 
unsigned char prep,

hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
+
+   for (i = 0; sym_term[i].mpixelclock != (~0UL); i++)
+   if (hdmi->hdmi_data.video_mode.mpixelclock <=
+   sym_term[i].mpixelclock)
+   break;
+
/* RESISTANCE TERM 133Ohm Cfg */
-   hdmi_phy_i2c_write(hdmi, 0x0005, 0x19);  /* TXTERM */
+   hdmi_phy_i2c_write(hdmi, sym_term[i].term, 0x19);  /* TXTERM */
/* PREEMP Cgf 0.00 */
-   

[PATCH v14 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode

[Andy Yan]

IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.

To reuse the imx hdmi driver, convert it to drm_bridge

handle encoder in imx-hdmi_pltfm.c, as most of the encoder
operation are platform specific such as crtc select and
panel format set

This patch depends on Russell King's patch:
 drm: imx: convert imx-drm to use the generic DRM OF helper
 
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-July/053484.html

Signed-off-by: Andy Yan 
Signed-off-by: Yakir Yang 

---

Changes in v14:
- add defer probing, adviced by Philipp Zabel

Changes in v13:
- split platform specific phy configuration

Changes in v12:
- squash patch 

Changes in v11:
- squash patch  

Changes in v10:
- split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)

Changes in v9: None
Changes in v8: None
Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/imx/Makefile |   2 +-
 drivers/gpu/drm/imx/imx-hdmi.c   | 298 ---
 drivers/gpu/drm/imx/imx-hdmi.h   |  14 ++
 drivers/gpu/drm/imx/imx-hdmi_pltfm.c | 226 ++
 4 files changed, 339 insertions(+), 201 deletions(-)
 create mode 100644 drivers/gpu/drm/imx/imx-hdmi_pltfm.c

diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 582c438..63cf56a 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -9,4 +9,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o

 imx-ipuv3-crtc-objs  := ipuv3-crtc.o ipuv3-plane.o
 obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
-obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o imx-hdmi_pltfm.o
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index 8029a07..f05b404 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -12,25 +12,19 @@
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */

-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 

+#include 
 #include 
 #include 
 #include 
 #include 
-#include 

 #include "imx-hdmi.h"
-#include "imx-drm.h"

 #define HDMI_EDID_LEN  512

@@ -54,11 +48,6 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
 };

-enum imx_hdmi_devtype {
-   IMX6Q_HDMI,
-   IMX6DL_HDMI,
-};
-
 static const u16 csc_coeff_default[3][4] = {
{ 0x2000, 0x, 0x, 0x },
{ 0x, 0x2000, 0x, 0x },
@@ -113,14 +102,14 @@ struct hdmi_data_info {

 struct imx_hdmi {
struct drm_connector connector;
-   struct drm_encoder encoder;
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;

enum imx_hdmi_devtype dev_type;
struct device *dev;
-   struct clk *isfr_clk;
-   struct clk *iahb_clk;

struct hdmi_data_info hdmi_data;
+   const struct imx_hdmi_plat_data *plat_data;
int vic;

u8 edid[HDMI_EDID_LEN];
@@ -137,13 +126,6 @@ struct imx_hdmi {
int ratio;
 };

-static void imx_hdmi_set_ipu_di_mux(struct imx_hdmi *hdmi, int ipu_di)
-{
-   regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
-  IMX6Q_GPR3_HDMI_MUX_CTL_MASK,
-  ipu_di << IMX6Q_GPR3_HDMI_MUX_CTL_SHIFT);
-}
-
 static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
 {
writeb(val, hdmi->regs + offset);
@@ -1371,6 +1353,50 @@ static void imx_hdmi_poweroff(struct imx_hdmi *hdmi)
imx_hdmi_phy_disable(hdmi);
 }

+static void imx_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+   struct imx_hdmi *hdmi = bridge->driver_private;
+
+   imx_hdmi_setup(hdmi, mode);
+
+   /* Store the display mode for plugin/DKMS poweron events */
+   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
+}
+
+static bool imx_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void imx_hdmi_bridge_disable(struct drm_bridge *bridge)
+{
+   struct imx_hdmi *hdmi = bridge->driver_private;
+
+   imx_hdmi_poweroff(hdmi);
+}
+
+static void imx_hdmi_bridge_enable(struct drm_bridge *bridge)
+{
+   struct imx_hdmi *hdmi = bridge->driver_private;
+
+   imx_hdmi_poweron(hdmi);
+}
+
+static void imx_hdmi_bridge_destroy(struct drm_bridge *bridge)
+{
+   

[PATCH v14 02/12] drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter

[Andy Yan]

drm driver may probe before the i2c bus, so the driver should
defer probing until it is available

Signed-off-by: Andy Yan 
Reviewed-by: Daniel Kurtz 

---

Changes in v14: None
Changes in v13: None
Changes in v12:
- refactor of_node_put(ddc_node)

Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- defer probe ddc i2c adapter

Changes in v3: None

 drivers/gpu/drm/imx/imx-hdmi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index 79daec4..8029a07 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -1611,10 +1611,12 @@ static int imx_hdmi_bind(struct device *dev, struct 
device *master, void *data)
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
-   if (!hdmi->ddc)
+   of_node_put(ddc_node);
+   if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
+   return -EPROBE_DEFER;
+   }

-   of_node_put(ddc_node);
} else {
dev_dbg(hdmi->dev, "no ddc property found\n");
}
-- 
1.9.1

[PATCH v14 01/12] drm: imx: imx-hdmi: make checkpatch happy

[Andy Yan]

CHECK: Alignment should match open parenthesis
+   if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
+   (hdmi->vic == 12) || (hdmi->vic == 13) ||

CHECK: braces {} should be used on all arms of this statement
+   if (hdmi->hdmi_data.video_mode.mdvi)
[...]
+   else {
[...]

Signed-off-by: Andy Yan 
Reviewed-by: Daniel Kurtz 

---

Changes in v14: None
Changes in v13:
- patch against drm-next

Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- rearrange the patch order

Changes in v5: None
Changes in v4:
- fix checkpatch CHECK

Changes in v3: None

 drivers/gpu/drm/imx/imx-hdmi.c | 97 +-
 1 file changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index aaec6b2..79daec4 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -163,7 +163,7 @@ static void hdmi_modb(struct imx_hdmi *hdmi, u8 data, u8 
mask, unsigned reg)
 }

 static void hdmi_mask_writeb(struct imx_hdmi *hdmi, u8 data, unsigned int reg,
- u8 shift, u8 mask)
+u8 shift, u8 mask)
 {
hdmi_modb(hdmi, data << shift, mask, reg);
 }
@@ -327,7 +327,7 @@ static unsigned int hdmi_compute_cts(unsigned int freq, 
unsigned long pixel_clk,
 }

 static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,
-   unsigned long pixel_clk)
+unsigned long pixel_clk)
 {
unsigned int clk_n, clk_cts;

@@ -338,7 +338,7 @@ static void hdmi_set_clk_regenerator(struct imx_hdmi *hdmi,

if (!clk_cts) {
dev_dbg(hdmi->dev, "%s: pixel clock not supported: %lu\n",
-__func__, pixel_clk);
+   __func__, pixel_clk);
return;
}

@@ -477,13 +477,11 @@ static void imx_hdmi_update_csc_coeffs(struct imx_hdmi 
*hdmi)
u16 coeff_b = (*csc_coeff)[1][i];
u16 coeff_c = (*csc_coeff)[2][i];

-   hdmi_writeb(hdmi, coeff_a & 0xff,
-   HDMI_CSC_COEF_A1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_a & 0xff, HDMI_CSC_COEF_A1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_a >> 8, HDMI_CSC_COEF_A1_MSB + i * 2);
hdmi_writeb(hdmi, coeff_b & 0xff, HDMI_CSC_COEF_B1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_b >> 8, HDMI_CSC_COEF_B1_MSB + i * 2);
-   hdmi_writeb(hdmi, coeff_c & 0xff,
-   HDMI_CSC_COEF_C1_LSB + i * 2);
+   hdmi_writeb(hdmi, coeff_c & 0xff, HDMI_CSC_COEF_C1_LSB + i * 2);
hdmi_writeb(hdmi, coeff_c >> 8, HDMI_CSC_COEF_C1_MSB + i * 2);
}

@@ -535,21 +533,22 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
struct hdmi_data_info *hdmi_data = >hdmi_data;
u8 val, vp_conf;

-   if (hdmi_data->enc_out_format == RGB
-   || hdmi_data->enc_out_format == YCBCR444) {
-   if (!hdmi_data->enc_color_depth)
+   if (hdmi_data->enc_out_format == RGB ||
+   hdmi_data->enc_out_format == YCBCR444) {
+   if (!hdmi_data->enc_color_depth) {
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   else if (hdmi_data->enc_color_depth == 8) {
+   } else if (hdmi_data->enc_color_depth == 8) {
color_depth = 4;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_BYPASS;
-   } else if (hdmi_data->enc_color_depth == 10)
+   } else if (hdmi_data->enc_color_depth == 10) {
color_depth = 5;
-   else if (hdmi_data->enc_color_depth == 12)
+   } else if (hdmi_data->enc_color_depth == 12) {
color_depth = 6;
-   else if (hdmi_data->enc_color_depth == 16)
+   } else if (hdmi_data->enc_color_depth == 16) {
color_depth = 7;
-   else
+   } else {
return;
+   }
} else if (hdmi_data->enc_out_format == YCBCR422_8BITS) {
if (!hdmi_data->enc_color_depth ||
hdmi_data->enc_color_depth == 8)
@@ -561,8 +560,9 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
else
return;
output_select = HDMI_VP_CONF_OUTPUT_SELECTOR_YCC422;
-   } else
+   } else {
return;
+   }

/* set the packetizer registers */
val = ((color_depth << HDMI_VP_PR_CD_COLOR_DEPTH_OFFSET) &
@@ -623,34 +623,34 @@ static void hdmi_video_packetize(struct imx_hdmi *hdmi)
 }

 static inline void hdmi_phy_test_clear(struct imx_hdmi *hdmi,
-   unsigned char bit)
+  unsigned char bit)
 {

[PATCH v14 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

[Andy Yan]

We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly differences, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can only be accessed
by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0
support.

To reuse the imx-hdmi driver, we make this patch set:
(1): fix some CodingStyle warning to make checkpatch happy
(2): convert imx-hdmi to drm_bridge
(3): split platform specific code
(4): move imx-hdmi to bridge/dw_hdmi
(5): extend dw_hdmi.c to support rk3288 hdmi
(6): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c

Changes in v14:
- add defer probing, adviced by Philipp Zabel
- remove drm_connector_register, because imx-drm core has registered
connector

Changes in v13:
- patch against drm-next
- split platform specific phy configuration
- split phy configuration from patch#4

Changes in v12:
- refactor of_node_put(ddc_node)
- squash patch 
- add comment for the depend on patch

Changes in v11:
- squash patch  

Changes in v10:
- split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)
- add more display mode support mpll configuration for rk3288

Changes in v9:
- move some phy configuration to platform driver

Changes in v8:
- correct some spelling mistake
- modify ddc-i2c-bus and interrupt description
- Add documentation for rockchip dw hdmi

Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c

Changes in v6:
- rearrange the patch order
- refactor register access without reg_shift

Changes in v5:
- refactor reg-io-width

Changes in v4:
- fix checkpatch CHECK
- defer probe ddc i2c adapter

Changes in v3:
- split multi-register access to one indepent patch

Andy Yan (12):
  drm: imx: imx-hdmi: make checkpatch happy
  drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter
  drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
  drm: imx: imx-hdmi: split phy configuration to platform driver
  drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
  dt-bindings: add document for dw_hdmi
  drm: bridge/dw_hdmi: add support for multi-byte register width access
  drm: bridge/dw_hdmi: add mode_valid support
  drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done
  drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
  dt-bindings: Add documentation for rockchip dw hdmi
  drm: bridge/dw_hdmi: add rockchip rk3288 support

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt |  40 ++
 .../devicetree/bindings/video/dw_hdmi-rockchip.txt |  43 ++
 drivers/gpu/drm/bridge/Kconfig |   5 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c}   | 755 +
 .../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h}   |   4 +-
 drivers/gpu/drm/imx/Kconfig|   1 +
 drivers/gpu/drm/imx/Makefile   |   2 +-
 drivers/gpu/drm/imx/dw_hdmi-imx.c  | 281 
 drivers/gpu/drm/rockchip/Kconfig   |  10 +
 drivers/gpu/drm/rockchip/Makefile  |   2 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 355 ++
 include/drm/bridge/dw_hdmi.h   |  60 ++
 13 files changed, 1138 insertions(+), 421 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
 rename drivers/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (71%)
 rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (99%)
 create mode 100644 drivers/gpu/drm/imx/dw_hdmi-imx.c
 create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
 create mode 100644 include/drm/bridge/dw_hdmi.h

-- 
1.9.1

[PATCH] drm/i915 Trouble with minimum brightness

[Jay Aurabind]

On 12/01/2014 03:04 PM, Jani Nikula wrote:
> On Fri, 28 Nov 2014, Jay Aurabind  wrote:
>> Hello all,
>>
>> I notice that some activity has been going on with the minimum value
>> of display brightness recently (e1c412e7575).
>>
>> But the minimum value thats currently chosen is not at all acceptable
>> for my eyes. My display is working perfectly without that restriction
>> on minimum intensity.  I tend to stare at the screen a lot and the
>> current minimum settings is straining my eyes.
>>
>> Even if you say that it may not be good for the devices, I still
>> insist, because I want my *display* to fail first, not my eyes.  So
>> please try providing a way for the needy users to override this
>> minimum settings. I hope adding a module parameter would be easy fix.
>>
>> Something like this: ? (I dont call myself a kernel programmer yet,
>> just scratching the surface)
>>
>>
>> Provide provision for users to disable restriction on minimum brightness
>> value introduced in:
>>
>> commit e1c412e75754ab7b7002f3e18a2652d999c40d4b
>> Author: Jani Nikula 
>> Date:   Wed Nov 5 14:46:31 2014 +0200
>>
>> drm/i915: safeguard against too high minimum brightness
>>
>> There are systems which work reliably without restriction on minimum
>> value of display brightness. Also the arbitrary value may be too high
>> for many users as well.
> 
> Please file a new bug at [1], reference this mail, and attach
> /sys/kernel/debug/dri/0/i915_opregion.

Thank you for the response. But the file you mentioned to attach seems to be
a binary file, because I'm getting lot of junk characters. Is this normal ?

> 
> The minimum value is chosen and provided by the OEM. There's still some
> open questions about the interpretation of the value though (which lead
> to the commit you referenced), so I'm hesitant to make changes before we
> have those cleared up.

[PATCH 3/6] drm/edid: new drm_edid_block_checksum helper function V3

[Daniel Vetter]

On Sun, Nov 30, 2014 at 07:57:43PM +0100, Stefan Brüns wrote:
> The function will also be used by a later patch, so factor it out.
> 
> V2: make raw_edid const, define/declare before first use
> V3: fix erroneuos removal of csum variable
> 
> Signed-off-by: Stefan Brüns 
> Reviewed-by: Jani Nikula 

Ok, merged the first three patches from this series to my drm patch pile
branch. I'll send a pull for that to Dave for 3.19 I think, but might miss
for 3.20.

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

drm: exynos: mixer: fix using usleep() in atomic context

[Tobias Jakobi]

On 2014-12-01 16:54, Thierry Reding wrote:
> On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjakobi at math.uni-bielefeld.de 
> wrote:
>> From: Tomasz Stanislawski 
>> 
>> This patch fixes calling usleep_range() after taking reg_slock
>> using spin_lock_irqsave(). The mdelay() is used instead.
>> Waiting in atomic context is not the best idea in general.
>> Hopefully, waiting occurs only when Video Processor fails
>> to reset correctly.
>> 
>> Signed-off-by: Tomasz Stanislawski 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index a41c84e..cc7 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -632,7 +632,7 @@ static void vp_win_reset(struct mixer_context 
>> *ctx)
>>  /* waiting until VP_SRESET_PROCESSING is 0 */
>>  if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING)
>>  break;
>> -usleep_range(1, 12000);
>> +mdelay(10);
>>  }
>>  WARN(tries == 0, "failed to reset Video Processor\n");
>>  }
> 
> I can't see a reason why you would need to hold the lock around this
> code. Perhaps a better way to fix this would be to drop the lock before
> calling vp_win_reset()?
> 
> Thierry

Hmm, I'm pretty new to spinlocks (only have worked with the usual mutex 
stuff in userspace), but wouldn't that mean that it is then possible for 
mixer_win_reset to execute while a (previous) vp_win_reset is still 
running?

With best wishes,
Tobias

[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls

[Thierry Reding]

On Tue, Nov 25, 2014 at 02:33:53PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 25 Nov 2014 14:30:28 +0100
> 
> The functions framebuffer_release() and vunmap() perform also input
> parameter validation. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
>  drivers/gpu/drm/msm/msm_gem.c   | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)

This needs the same fix for the subject prefix that I mentioned for your
other patch, otherwise:

Reviewed-by: Thierry Reding 

Perhaps a good idea would be to send all of these patches with the
subject prefix fixed up as a second version and threaded in a series.
That makes it easier for people to pick them up (assuming Dave will take
them directly).

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/11f42aa7/attachment.sig>

[PATCH 1/1] GPU-DRM-MSM-Adreno: Deletion of unnecessary checks before the function call "release_firmware"

[Thierry Reding]

On Tue, Nov 25, 2014 at 01:50:25PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring 

You can probably get rid of this if you configure your emailer properly.

> Date: Tue, 25 Nov 2014 13:44:20 +0100

This is odd. I've never seen git send-email generate these.

I didn't notice with your earlier patches, but the subject prefix is
wrong. Please use something more consistent with existing patches, in
this case: "drm/msm: ..." or "drm/msm/adreno: ..."

> The release_firmware() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 655ce5b..757052c 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -404,9 +404,7 @@ void adreno_gpu_cleanup(struct adreno_gpu *gpu)
>   msm_gem_put_iova(gpu->memptrs_bo, gpu->base.id);
>   drm_gem_object_unreference(gpu->memptrs_bo);
>   }
> - if (gpu->pm4)
> - release_firmware(gpu->pm4);
> - if (gpu->pfp)
> - release_firmware(gpu->pfp);
> + release_firmware(gpu->pm4);
> + release_firmware(gpu->pfp);
>   msm_gpu_cleanup(>base);
>  }

Besides the subject prefix,

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/10bc8e41/attachment.sig>

[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

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

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

Ismael  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)
   Severity|normal  |major

--- Comment #6 from Ismael  ---
I get the error every time I suspend the machine. And 3D acceleration is
disabled until I reboot.
I am using a HD5770 running 3.17.4-1-ck. Both Mesa and X are in the last stable
version (I use Arch).

Nov 30 14:49:32 boreal kernel: [drm] PCIE GART of 1024M enabled (table at
0x0025D000).
Nov 30 14:49:32 boreal kernel: radeon :01:00.0: WB enabled
Nov 30 14:49:32 boreal kernel: radeon :01:00.0: fence driver on ring 0 use
gpu addr 0x4c00 and cpu addr 
Nov 30 14:49:32 boreal kernel: radeon :01:00.0: fence driver on ring 3 use
gpu addr 0x4c0c and cpu addr 
Nov 30 14:49:32 boreal kernel: radeon :01:00.0: fence driver on ring 5 use
gpu addr 0x0005c418 and cpu addr 
Nov 30 14:49:32 boreal kernel: [drm:r600_ring_test] *ERROR* radeon: ring 0 test
failed (scratch(0x8504)=0xCAFEDEAD)
Nov 30 14:49:32 boreal kernel: [drm:evergreen_resume] *ERROR* evergreen startup
failed on resume

-- 
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/20141201/3cb50a09/attachment.html>

[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support

[Jilai Wang]

Add HDMI HDCP support including HDCP PartI/II/III authentication.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/Makefile  |1 +
 drivers/gpu/drm/msm/hdmi/hdmi.c   |   44 +
 drivers/gpu/drm/msm/hdmi/hdmi.h   |   31 +
 drivers/gpu/drm/msm/hdmi/hdmi_audio.c |1 -
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c|3 +-
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c |7 +-
 drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c  | 1600 +
 7 files changed, 1682 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 6283dcb..9d88ff3 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -11,6 +11,7 @@ msm-y := \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
hdmi/hdmi_connector.o \
+   hdmi/hdmi_hdcp.o \
hdmi/hdmi_i2c.o \
hdmi/hdmi_phy_8960.o \
hdmi/hdmi_phy_8x60.o \
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 9d00dcb..f0111c0 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -20,7 +20,9 @@
 void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
 {
uint32_t ctrl = 0;
+   unsigned long flags;

+   spin_lock_irqsave(>reg_lock, flags);
if (power_on) {
ctrl |= HDMI_CTRL_ENABLE;
if (!hdmi->hdmi_mode) {
@@ -35,6 +37,7 @@ void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
}

hdmi_write(hdmi, REG_HDMI_CTRL, ctrl);
+   spin_unlock_irqrestore(>reg_lock, flags);
DBG("HDMI Core: %s, HDMI_CTRL=0x%08x",
power_on ? "Enable" : "Disable", ctrl);
 }
@@ -49,6 +52,9 @@ irqreturn_t hdmi_irq(int irq, void *dev_id)
/* Process DDC: */
hdmi_i2c_irq(hdmi->i2c);

+   /* Process HDCP: */
+   hdmi_hdcp_irq(hdmi->hdcp_ctrl);
+
/* TODO audio.. */

return IRQ_HANDLED;
@@ -59,6 +65,16 @@ void hdmi_destroy(struct kref *kref)
struct hdmi *hdmi = container_of(kref, struct hdmi, refcount);
struct hdmi_phy *phy = hdmi->phy;

+   /*
+* at this point, hpd has been disabled,
+* after flush workq, it's safe to deinit hdcp
+*/
+   if (hdmi->workq) {
+   flush_workqueue(hdmi->workq);
+   destroy_workqueue(hdmi->workq);
+   }
+   hdmi_hdcp_destroy(hdmi);
+
if (phy)
phy->funcs->destroy(phy);

@@ -75,6 +91,7 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct 
drm_encoder *encoder)
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->hdmi_pdev;
struct hdmi_platform_config *config;
+   struct resource *res;
int i, ret;

if (!pdev) {
@@ -97,6 +114,7 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct 
drm_encoder *encoder)
hdmi->pdev = pdev;
hdmi->config = config;
hdmi->encoder = encoder;
+   spin_lock_init(>reg_lock);

hdmi_audio_infoframe_init(>audio.infoframe);

@@ -119,6 +137,22 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct 
drm_encoder *encoder)
goto fail;
}

+   /* HDCP needs physical address of hdmi register */
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+   config->mmio_name);
+   hdmi->mmio_phy_addr = res->start;
+
+   if (config->qfprom_mmio_name) {
+   hdmi->qfprom_mmio = msm_ioremap(pdev,
+   config->qfprom_mmio_name, "HDMI_QFPROM");
+   if (IS_ERR(hdmi->qfprom_mmio)) {
+   dev_info(>dev, "can't find qfprom resource\n");
+   hdmi->qfprom_mmio = NULL;
+   }
+   } else {
+   hdmi->qfprom_mmio = NULL;
+   }
+
BUG_ON(config->hpd_reg_cnt > ARRAY_SIZE(hdmi->hpd_regs));
for (i = 0; i < config->hpd_reg_cnt; i++) {
struct regulator *reg;
@@ -181,6 +215,8 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct 
drm_encoder *encoder)
hdmi->pwr_clks[i] = clk;
}

+   hdmi->workq = alloc_ordered_workqueue("msm_hdmi", 0);
+
hdmi->i2c = hdmi_i2c_init(hdmi);
if (IS_ERR(hdmi->i2c)) {
ret = PTR_ERR(hdmi->i2c);
@@ -205,6 +241,13 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct 
drm_encoder *encoder)
goto fail;
}

+   hdmi->hdcp_ctrl = hdmi_hdcp_init(hdmi);
+   if (IS_ERR(hdmi->hdcp_ctrl)) {
+   ret = PTR_ERR(hdmi->hdcp_ctrl);
+   dev_warn(dev->dev, "failed to init hdcp: %d(disabled)\n", ret);
+   hdmi->hdcp_ctrl = NULL;
+   }
+
if (!config->shared_irq) {
hdmi->irq = platform_get_irq(pdev, 0);
if (hdmi->irq < 0) {
@@ -314,6 +357,7 @@ static int hdmi_bind(struct device *dev, struct device 

drm: exynos: mixer: fix using usleep() in atomic context

[Thierry Reding]

On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjakobi at math.uni-bielefeld.de 
wrote:
> From: Tomasz Stanislawski 
> 
> This patch fixes calling usleep_range() after taking reg_slock
> using spin_lock_irqsave(). The mdelay() is used instead.
> Waiting in atomic context is not the best idea in general.
> Hopefully, waiting occurs only when Video Processor fails
> to reset correctly.
> 
> Signed-off-by: Tomasz Stanislawski 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index a41c84e..cc7 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -632,7 +632,7 @@ static void vp_win_reset(struct mixer_context *ctx)
>   /* waiting until VP_SRESET_PROCESSING is 0 */
>   if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING)
>   break;
> - usleep_range(1, 12000);
> + mdelay(10);
>   }
>   WARN(tries == 0, "failed to reset Video Processor\n");
>  }

I can't see a reason why you would need to hold the lock around this
code. Perhaps a better way to fix this would be to drop the lock before
calling vp_win_reset()?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/e30b9bbe/attachment.sig>

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Thierry Reding]

On Mon, Dec 01, 2014 at 09:20:59AM +0100, Boris Brezillon wrote:
> Add bus_formats and num_bus_formats fields and
> drm_display_info_set_bus_formats helper function to specify the bus
> formats supported by a given display.
> 
> This information can be used by display controller drivers to configure
> the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
> RGB or LVDS busses).
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/gpu/drm/drm_crtc.c | 32 
>  include/drm/drm_crtc.h |  7 +++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e79c8d3..d3b7ed0 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector 
> *connector,
>   drm_mode_destroy(connector->dev, mode);
>  }
>  
> +/*

This needs a /** marker to make it a valid kerneldoc comment.

> + * drm_display_info_set_bus_formats - set the supported bus formats
> + * @info: display info to store bus formats in
> + * @fmts: array containing the supported bus formats
> + * @nfmts: the number of entries in the fmts array
> + *
> + * Store the suppported bus formats in display info structure.
> + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h 
> for
> + * a full list of available formats.
> + */
> +int drm_display_info_set_bus_formats(struct drm_display_info *info, const 
> u32 *fmts,

This one still exceeds 80-characters per line, but perhaps I'm reviewing
the wrong patch? Also I think fmts should be formats here.

> +  unsigned int num_fmts)

And this should be num_formats, for consistency. Also make sure to keep
this consistent with the kerneldoc.

> +{
> + u32 *formats = NULL;

If you name the parameter formats, maybe bus_formats would be a good
alternative for this local variable. Or fmts here. I think it's most
important that the public API gets the more idiomatic name.

> +
> + if (!fmts && num_fmts)
> + return -EINVAL;
> +
> + if (fmts && num_fmts) {
> + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
> + if (!formats)
> + return -ENOMEM;
> + }
> +
> + kfree(info->bus_formats);
> + info->bus_formats = formats;
> + info->num_bus_formats = num_fmts;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_display_info_set_bus_formats);

I think you'll want to call kfree() on the bus_formats array from
drm_connector_cleanup() as well to make sure you don't leak this on
driver unload.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/ec921883/attachment.sig>

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

[Daniel Vetter]

On Mon, Dec 01, 2014 at 04:33:31PM +0100, Thierry Reding wrote:
> On Mon, Dec 01, 2014 at 02:48:47PM +0100, Hans Verkuil wrote:
> > Hi Thierry,
> > 
> > Thanks for the review, see my comments below.
> > 
> > On 12/01/2014 02:15 PM, Thierry Reding wrote:
> > > On Fri, Nov 28, 2014 at 03:50:50PM +0100, Hans Verkuil wrote:
> [...]
> > >> +{
> > >> +switch (type) {
> > >> +case HDMI_INFOFRAME_TYPE_VENDOR: return "Vendor";
> > >> +case HDMI_INFOFRAME_TYPE_AVI: return "Auxiliary Video 
> > >> Information (AVI)";
> > >> +case HDMI_INFOFRAME_TYPE_SPD: return "Source Product 
> > >> Description (SPD)";
> > >> +case HDMI_INFOFRAME_TYPE_AUDIO: return "Audio";
> > > 
> > > I'd prefer "case ...:" and "return ...;" on separate lines for
> > > readability.
> > 
> > I actually think that makes it *less* readable. If you really want that, 
> > then I'll
> > change it, but I would suggest that you try it yourself first to see if it 
> > is
> > really more readable for you. It isn't for me, so I'll keep this for the 
> > next
> > version.
> 
> I did, and I still think separate lines are more readable, especially if
> you throw in a blank line after the "return ...;". Anyway, I could keep
> my OCD in check if it weren't for the fact that half of these are the
> cause for checkpatch to complain. And then if you change the ones that
> checkpatch wants you to change, all the others would be inconsistent and
> then I'd complain about the inconsistency...

Throwing in my own unasked-for bikshed opinion ;-)

I agree with Thierry that it's more readable since this way the key and
the value can be lined up easily. That's also possible with the
single-line case/return like you do with some more tabs, but usually means
all the lines overflow the 80 limit badly. So only really works for small
defines/values. So my rule of thumb is
- go with single-line case/return and align them
- but break the lines if they would be too long.

Now back to doing useful stuff for me.

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

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

[Thierry Reding]

On Mon, Dec 01, 2014 at 02:48:47PM +0100, Hans Verkuil wrote:
> Hi Thierry,
> 
> Thanks for the review, see my comments below.
> 
> On 12/01/2014 02:15 PM, Thierry Reding wrote:
> > On Fri, Nov 28, 2014 at 03:50:50PM +0100, Hans Verkuil wrote:
[...]
> >> +{
> >> +  switch (type) {
> >> +  case HDMI_INFOFRAME_TYPE_VENDOR: return "Vendor";
> >> +  case HDMI_INFOFRAME_TYPE_AVI: return "Auxiliary Video Information 
> >> (AVI)";
> >> +  case HDMI_INFOFRAME_TYPE_SPD: return "Source Product Description (SPD)";
> >> +  case HDMI_INFOFRAME_TYPE_AUDIO: return "Audio";
> > 
> > I'd prefer "case ...:" and "return ...;" on separate lines for
> > readability.
> 
> I actually think that makes it *less* readable. If you really want that, then 
> I'll
> change it, but I would suggest that you try it yourself first to see if it is
> really more readable for you. It isn't for me, so I'll keep this for the next
> version.

I did, and I still think separate lines are more readable, especially if
you throw in a blank line after the "return ...;". Anyway, I could keep
my OCD in check if it weren't for the fact that half of these are the
cause for checkpatch to complain. And then if you change the ones that
checkpatch wants you to change, all the others would be inconsistent and
then I'd complain about the inconsistency...

checkpatch flagged a couple other issues, please make sure to address
those as well.

> > Maybe include the numerical value here? Of course that either means that
> > callers must pass in a buffer or we sacrifice thread-safety. The buffer
> > could be optional, somewhat like this:
> > 
> > const char *hdmi_infoframe_get_name(char *buffer, size_t length,
> > enum hdmi_infoframe_type type)
> > {
> > const char *name = NULL;
> > 
> > switch (type) {
> > case HDMI_INFOFRAME_TYPE_VENDOR:
> > name = "Vendor";
> > break;
> > ...
> > }
> > 
> > if (buffer) {
> > if (!name)
> > snprintf(buffer, length, "unknown (%d)", type);
> > else
> > snprintf(buffer, length, name);
> > 
> > name = buffer;
> > }
> > 
> > return name;
> > }
> > 
> > That way the function would be generally useful and could even be made
> > publicly available.
> 
> I would do this only where it makes sense. Some of these fields have only one 
> or
> two reserved bits left, and in that case is it easier to just say something
> like "Reserved (3)" and do that for each reserved value.

Okay.

> >> +/**
> >> + * hdmi_infoframe_log() - log info of HDMI infoframe
> >> + * @dev: device
> >> + * @frame: HDMI infoframe
> >> + */
> >> +void hdmi_infoframe_log(struct device *dev, union hdmi_infoframe *frame)
> >> +{
> >> +  switch (frame->any.type) {
> >> +  case HDMI_INFOFRAME_TYPE_AVI:
> >> +  hdmi_avi_infoframe_log(dev, >avi);
> >> +  break;
> >> +  case HDMI_INFOFRAME_TYPE_SPD:
> >> +  hdmi_spd_infoframe_log(dev, >spd);
> >> +  break;
> >> +  case HDMI_INFOFRAME_TYPE_AUDIO:
> >> +  hdmi_audio_infoframe_log(dev, >audio);
> >> +  break;
> >> +  case HDMI_INFOFRAME_TYPE_VENDOR:
> >> +  hdmi_vendor_any_infoframe_log(dev, >vendor);
> >> +  break;
> >> +  default:
> >> +  WARN(1, "Bad infoframe type %d\n", frame->any.type);
> > 
> > Does it make sense for this to be WARN? It's perfectly legal for future
> > devices to expose new types of infoframes. Perhaps even expected. But if
> > we want to keep this here to help get bug reports so that we don't
> > forget to update this code, then maybe we should do the same wherever we
> > query the name of enum values above.
> 
> I'll drop the WARN from the log function. I think it should also be dropped
> from the unpack. The only place it makes sense is for pack() since there the
> data comes from the driver, not from an external source.

Sounds good.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/df0abddb/attachment-0001.sig>

[PATCH libdrm] drm: Avoid out of bound write in drmOpenByName()

[Daniel Vetter]

On Mon, Dec 01, 2014 at 02:07:03PM +, Damien Lespiau wrote:
> In the fallback code that looks for devices in /proc, the read() may
> return with -1 in case of error (interruption from a signal for
> instance). We'll then happily write '\0' to buf[-2].
> 
> As we didn't really care about the signal interruption before, I kept it
> the same way, just making sure that retcode is > 0 to avoid that case.
> 
> This was found by static analysis.
> 
> Signed-off-by: Damien Lespiau 

procfs support is dead, absolutely no point imo to fix it. From the
kernel:

commit cb6458f97b53d7f73043206c18014b3ca63ac345
Author: Daniel Vetter 
Date:   Thu Aug 8 15:41:34 2013 +0200

drm: remove procfs code, take 2

So almost two years ago I've tried to nuke the procfs code already
once before:

http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html

The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging it turned out that the drmstat tool in libdrm is still using
those files (but only when certain options are set). So we've decided
to keep profcs.

But I when I've started to dig around again what exactly this tool
does I've noticed that it tries to read the "mem", "vm", and "vma"
files from procfs. Now as far my git history digging shows "mem" never
did anything useful (at least in the version that first showed up in
upstream history in 2004) and the file was remove in

commit 955b12def42e83287c1bdb1411d99451753c1391
Author: Ben Gamari 
Date:   Tue Feb 17 20:08:49 2009 -0500

drm: Convert proc files to seq_file and introduce debugfs

Which means that for over 4 years drmstat has been broken, and no one
cared. In my opinion that's proof enough that no one is actually using
drmstat, and so that we can savely nuke the procfs support from drm.

While at it fix up the error case cleanup for debugfs in drm_get_minor.

v2: Fix dates, libdrm stopped relying on procfs for drm node detection
in 2001.

v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by
Fengguang Wu.

Cc: kbuild test robot 
Cc: Dave Airlie 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie 


Instead I think we should just rip this fallback code out. Volunteered?
You can reuse the digging I've done for the kernel side.

Cheers, Daniel
> ---
>  xf86drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index d900b4b..106b8ab 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -579,7 +579,7 @@ static int drmOpenByName(const char *name)
>   if ((fd = open(proc_name, 0, 0)) >= 0) {
>   retcode = read(fd, buf, sizeof(buf)-1);
>   close(fd);
> - if (retcode) {
> + if (retcode > 0) {
>   buf[retcode-1] = '\0';
>   for (driver = pt = buf; *pt && *pt != ' '; ++pt)
>   ;
> -- 
> 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

RFC on upstreaming of a Mediatek DRM modesetting driver

[Daniel Vetter]

On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote:
> Hi,
> 
> We are currently in negotiations with one of our customers (Mediatek) on
> a strategy that will allow them to push a DRM modesetting driver into
> the upstream kernel. We are writing to get people's opinions and
> feedback on our proposed approach.
> 
> Currently, our driver is structured in such a way that the display
> driver is more tightly integrated with the GPU driver than we would
> like. Although our kernel driver has been shipped with a GPL license for
> a long time, it is not in a form that would be considered acceptable
> upstream. Unfortunately, it is going to be a long process to get this
> part of the driver into a reasonable state. However, in the meantime, we
> don't want to prevent customer portions of the driver from being
> upstreamed. With the work done on recent kernels, and with a willing
> partner in Mediatek, we now think that we can restructure our driver in
> such a way as to allow this to happen.
> 
> We see two basic approaches to achieving this:
> 1) Two independent DRM drivers, i.e. modesetting and render node drivers
> 2) A single componentised DRM driver
> 
> Our (IMG's) preferred approach is to have a single componentised DRM
> driver. This is due to the following reasons:
> 
> - Existing user space is not fully prepared to handle render nodes.
> 
> - There is concern that any IMG DRM render node driver will need
> knowledge about multiple SoCs, each one being from a different vendor.
> Would this be deemed acceptable?
> 
> - There is a trend, at least for DRM SoC drivers, towards using the
> component interface. Although there appears to be very few (one?)
> examples of GPU component drivers.
> 
> To give some high level details on how we expect the componentised DRM
> driver model to work, each vendor (in this case Mediatek) will write
> their own DRM driver (supporting modesetting, dumb buffers, GEM, prime,
> etc) and IMG will provide an almost entirely independent component
> driver that adds in GPU support. Until our GPU driver is in a suitable
> state this will most likely necessitate a small kernel patch to wire up
> support, e.g. GPU specific ioctls.
> 
> Cross-device and cross-process memory allocations will be made using the
> DRM driver. In order for this memory to be shared with the GPU component
> driver it will be necessary, at least for the time being, to export it
> via prime and import it via a GPU ioctl. Synchronisation between the
> display and GPU will be performed via reservation objects.
> 
> Does this sound like a sane approach? Questions and/or feedback is very
> welcome.

Rule of thumb is that if it's an externally licensed IP block it should be
a separate driver. Which is the case here. The idea is that the mostly
generic IMG driver could be reused on other platforms that ship the same
IP-block, while linking up with the respective display controller driver.
The end result is 2 drm drivers:
- Display block drm driver which expose KMS objects for modesetting, but
  only very basic gem (just enough to allocate dumb framebuffers and
  import/export dma-bufs).
- Full-blown gem driver for the img render IP block.

For an example look at the tegra/nouveau combo which can run on TK1.

Plugggin in an IMG driver into each display block like it's currently done
with all the armsoc stuff on android is imo completely no-go.

Note that the component interface is completely irrelevant wrt the
interface you expose to userspace. It's just an driver-internal helper
library useful in certain situation. Not even the drm core really cares
whether you use component helpers or not.

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

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Philipp Zabel]

Am Montag, den 01.12.2014, 09:42 +0100 schrieb Boris Brezillon:
> Add bus_formats and num_bus_formats fields and
> drm_display_info_set_bus_formats helper function to specify the bus
> formats supported by a given display.
> 
> This information can be used by display controller drivers to configure
> the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
> RGB or LVDS busses).
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Philipp Zabel 

> ---
> Hi,
> 
> Sorry for the noise: I ran checkpatch after sending the series and it found
> a typo and two "line over 80 characters" warnings.
> 
> This version fixes those warnings.
> 
> Regards,
> 
> Boris
> 
>  drivers/gpu/drm/drm_crtc.c | 33 +
>  include/drm/drm_crtc.h |  8 
>  2 files changed, 41 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e79c8d3..20030ec 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -763,6 +763,39 @@ static void drm_mode_remove(struct drm_connector 
> *connector,
>   drm_mode_destroy(connector->dev, mode);
>  }
>  
> +/*
> + * drm_display_info_set_bus_formats - set the supported bus formats
> + * @info: display info to store bus formats in
> + * @fmts: array containing the supported bus formats
> + * @nfmts: the number of entries in the fmts array
> + *
> + * Store the supported bus formats in display info structure.
> + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h 
> for
> + * a full list of available formats.
> + */
> +int drm_display_info_set_bus_formats(struct drm_display_info *info,
> +  const u32 *fmts,
> +  unsigned int num_fmts)
> +{
> + u32 *formats = NULL;
> +
> + if (!fmts && num_fmts)
> + return -EINVAL;
> +
> + if (fmts && num_fmts) {
> + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
> + if (!formats)
> + return -ENOMEM;
> + }
> +
> + kfree(info->bus_formats);
> + info->bus_formats = formats;
> + info->num_bus_formats = num_fmts;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_display_info_set_bus_formats);
> +
>  /**
>   * drm_connector_get_cmdline_mode - reads the user's cmdline mode
>   * @connector: connector to quwery
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index c40070a..65dd08a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -130,6 +131,9 @@ struct drm_display_info {
>   enum subpixel_order subpixel_order;
>   u32 color_formats;
>  
> + const u32 *bus_formats;
> + unsigned int num_bus_formats;
> +
>   /* Mask of supported hdmi deep color modes */
>   u8 edid_hdmi_dc_modes;
>  
> @@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct 
> drm_connector *connector,
>  extern int drm_mode_connector_update_edid_property(struct drm_connector 
> *connector,
>   struct edid *edid);
>  
> +extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
> + const u32 *fmts,
> + unsigned int nfmts);
> +
>  static inline bool drm_property_type_is(struct drm_property *property,
>   uint32_t type)
>  {

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Hi Philipp,

On Mon, 01 Dec 2014 16:06:26 +0100
Philipp Zabel  wrote:

> Am Montag, den 01.12.2014, 09:20 +0100 schrieb Boris Brezillon:
> > Add bus_formats and num_bus_formats fields and
> > drm_display_info_set_bus_formats helper function to specify the bus
> > formats supported by a given display.
> > 
> > This information can be used by display controller drivers to configure
> > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
> > RGB or LVDS busses).
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 32 
> >  include/drm/drm_crtc.h |  7 +++
> >  2 files changed, 39 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index e79c8d3..d3b7ed0 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector 
> > *connector,
> > drm_mode_destroy(connector->dev, mode);
> >  }
> >  
> > +/*
> > + * drm_display_info_set_bus_formats - set the supported bus formats
> > + * @info: display info to store bus formats in
> > + * @fmts: array containing the supported bus formats
> > + * @nfmts: the number of entries in the fmts array
> > + *
> > + * Store the suppported bus formats in display info structure.
> > + * See MEDIA_BUS_FMT_* definitions in 
> > include/uapi/linux/media-bus-format.h for
> > + * a full list of available formats.
> > + */
> > +int drm_display_info_set_bus_formats(struct drm_display_info *info, const 
> > u32 *fmts,
> > +unsigned int num_fmts)
> > +{
> > +   u32 *formats = NULL;
> > +
> > +   if (!fmts && num_fmts)
> > +   return -EINVAL;
> > +
> > +   if (fmts && num_fmts) {
> > +   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
> > +   if (!formats)
> > +   return -ENOMEM;
> > +   }
> > +
> > +   kfree(info->bus_formats);
> > +   info->bus_formats = formats;
> > +   info->num_bus_formats = num_fmts;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_display_info_set_bus_formats);
> > +
> >  /**
> >   * drm_connector_get_cmdline_mode - reads the user's cmdline mode
> >   * @connector: connector to quwery
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index c40070a..a35844f 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -31,6 +31,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> 
> Nothing in drm_crtc.h uses MEDIA_BUS_FMT_*, is media-bus-format.h
> included here for the convenience of the user of
> drm_display_info_set_bus_formats?

Yes it is. Actually in the first versions MEDIA_BUS_FMT_* values were
part of an enum.
Still, I think keeping this include will help people finding where
those MEDIA_BUS_FMT_* macros are defined.

Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

build regression with "rcar-du: Remove platform data support"

[Arnd Bergmann]

On Monday 01 December 2014 15:25:06 Laurent Pinchart wrote:
> On Monday 01 December 2014 14:09:36 Arnd Bergmann wrote:
> > Hi Laurent,
> > 
> > linux-next has failed to build with lager_defconfig and marzen_defconfig for
> > a while, with this error:
> > 
> > arch/arm/mach-shmobile/board-lager.c:35:41: fatal error:
> > linux/platform_data/rcar-du.h: No such file or directory #include
> > 
> > 
> > which is evidently the result of your patch
> > 
> > commit 2378ad1228d2cdae0ea5448beb4fb2b42ebaf99c
> > Author: Laurent Pinchart 
> > Date:   Wed Sep 17 02:07:52 2014 +0300
> > 
> > drm: rcar-du: Remove platform data support
> > 
> > All platforms now instantiate the DU through DT, platform data support
> > isn't needed anymore.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > 
> > that removes the header files. I assume some dependency wasn't tracked
> > right, since linux-next still has these.
> > 
> > $ git grep rcar_du_ arch/arm
> > arch/arm/mach-shmobile/board-lager.c:static struct rcar_du_encoder_data
> > lager_du_encoders[] = { arch/arm/mach-shmobile/board-lager.c:static const
> > struct rcar_du_platform_data lager_du_pdata __initconst = {
> > arch/arm/mach-shmobile/board-marzen.c:static struct rcar_du_encoder_data
> > du_encoders[] = { arch/arm/mach-shmobile/board-marzen.c:static const struct
> > rcar_du_platform_data du_pdata __initconst = {
> > 
> > Can we please fix this before the merge window? Should the platform
> > device registration just get removed from the two board files?
> 
> That's what I've proposed in
> 
> http://www.spinics.net/lists/dri-devel/msg72750.html

Ok, I actually saw that mail the other day but then forgot about
it when I looked at the build logs.

Arnd

[PATCH 0/2] Fix legacy boards compilation breakage with DU

[Arnd Bergmann]

On Friday 28 November 2014 10:17:33 Laurent Pinchart wrote:
> On Friday 28 November 2014 09:18:46 Simon Horman wrote:
> > [CCed Magnus, ARM SoC maintainers]
> > 
> > On Thu, Nov 27, 2014 at 05:19:11PM +0200, Laurent Pinchart wrote:
> > > Hello,
> > > 
> > > The DU driver has lost support for platform data, resulting in a
> > > compilation breakage for the legacy Marzen and Lager board files that
> > > managed to keep under the radar until now.
> > > 
> > > As the multiplatform boards should be used instead, drop support for DU in
> > > the legacy Marzen and Lager boards.
> > > 
> > > Simon, this is required to fix a compilation breakage in the drm-next
> > > branch. I'm sorry for not catching it earlier :-/ How would you like this
> > > to go in ? Could the patches be applied to the DRM tree ? They seem to
> > > apply cleanly to both drm-next and your latest devel branch.
> > > 
> > > Laurent Pinchart (2):
> > >   ARM: shmobile: lager: Remove DU platform device
> > >   ARM: shmobile: marzen: Remove DU platform device
> > >  
> > >  arch/arm/mach-shmobile/board-lager.c  | 58 --
> > >  arch/arm/mach-shmobile/board-marzen.c | 58 --
> >
> > Yes, I think that should be fine as these fines are in maintenance mode and
> > the only recent change I see to them is to modify the FSF address, which
> > seems far away from the hunks in this patch-set.
> > 
> > In other words, I think the chance of conflicts is small and I am fine with
> > these changes going through the DRM tree if that is where the breakage
> > manifests.
> > 
> > Acked-by: Simon Horman 
> > 
> > I am of course, happy to take them if the DRM maintainer(s) prefer me to.
> 
> Dave, how would you prefer to handle this ?

If you want to pick it up, you can also add my 

Acked-by: Arnd Bergmann 

Otherwise we can merge it through arm-soc, but that would cause a
larger bisection problem.

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Philipp Zabel]

Am Montag, den 01.12.2014, 09:20 +0100 schrieb Boris Brezillon:
> Add bus_formats and num_bus_formats fields and
> drm_display_info_set_bus_formats helper function to specify the bus
> formats supported by a given display.
> 
> This information can be used by display controller drivers to configure
> the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
> RGB or LVDS busses).
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/gpu/drm/drm_crtc.c | 32 
>  include/drm/drm_crtc.h |  7 +++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e79c8d3..d3b7ed0 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector 
> *connector,
>   drm_mode_destroy(connector->dev, mode);
>  }
>  
> +/*
> + * drm_display_info_set_bus_formats - set the supported bus formats
> + * @info: display info to store bus formats in
> + * @fmts: array containing the supported bus formats
> + * @nfmts: the number of entries in the fmts array
> + *
> + * Store the suppported bus formats in display info structure.
> + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h 
> for
> + * a full list of available formats.
> + */
> +int drm_display_info_set_bus_formats(struct drm_display_info *info, const 
> u32 *fmts,
> +  unsigned int num_fmts)
> +{
> + u32 *formats = NULL;
> +
> + if (!fmts && num_fmts)
> + return -EINVAL;
> +
> + if (fmts && num_fmts) {
> + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
> + if (!formats)
> + return -ENOMEM;
> + }
> +
> + kfree(info->bus_formats);
> + info->bus_formats = formats;
> + info->num_bus_formats = num_fmts;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_display_info_set_bus_formats);
> +
>  /**
>   * drm_connector_get_cmdline_mode - reads the user's cmdline mode
>   * @connector: connector to quwery
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index c40070a..a35844f 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Nothing in drm_crtc.h uses MEDIA_BUS_FMT_*, is media-bus-format.h
included here for the convenience of the user of
drm_display_info_set_bus_formats?

>  #include 
>  #include 
>  #include 
> @@ -130,6 +131,9 @@ struct drm_display_info {
>   enum subpixel_order subpixel_order;
>   u32 color_formats;
>  
> + const u32 *bus_formats;
> + unsigned int num_bus_formats;
> +
>   /* Mask of supported hdmi deep color modes */
>   u8 edid_hdmi_dc_modes;
>  
> @@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct 
> drm_connector *connector,
>  extern int drm_mode_connector_update_edid_property(struct drm_connector 
> *connector,
>   struct edid *edid);
>  
> +extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
> + const u32 *fmts, unsigned int 
> nfmts);
> +
>  static inline bool drm_property_type_is(struct drm_property *property,
>   uint32_t type)
>  {

regards
Philipp

[PATCH 1/2] drm/msm/hdmi: add register description for HDMI HDCP support

[Jilai Wang]

Add HDCP related register description.

Signed-off-by: Jiali Wang 
---
 drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 76 +
 1 file changed, 60 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.xml.h 
b/drivers/gpu/drm/msm/hdmi/hdmi.xml.h
index 76fd0cf..6dd6168 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.xml.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.xml.h
@@ -8,16 +8,8 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
647 bytes, from 2013-11-30 14:45:35)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2013-03-31 16:51:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20457 bytes, from 2014-08-01 12:22:48)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
1615 bytes, from 2014-07-17 15:34:33)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
22517 bytes, from 2014-07-17 15:34:33)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
11712 bytes, from 2013-08-17 17:13:43)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2014-08-01 12:23:53)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
23613 bytes, from 2014-07-17 15:33:30)
+- 
/local/mnt2/workspace2/jilaiw/chromeos/envytools/envytools/rnndb/hdmi/hdmi.xml  
 (  25125 bytes, from 2014-11-24 23:30:39)
+- 
/local/mnt2/workspace2/jilaiw/chromeos/envytools/envytools/rnndb/freedreno_copyright.xml
 (   1453 bytes, from 2014-11-24 22:27:21)

 Copyright (C) 2013-2014 by the following authors:
 - Rob Clark  (robclark)
@@ -45,12 +37,14 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.


 enum hdmi_hdcp_key_state {
-   NO_KEYS = 0,
-   NOT_CHECKED = 1,
-   CHECKING = 2,
-   KEYS_VALID = 3,
-   AKSV_INVALID = 4,
-   CHECKSUM_MISMATCH = 5,
+   HDCP_KEYS_STATE_NO_KEYS = 0,
+   HDCP_KEYS_STATE_NOT_CHECKED = 1,
+   HDCP_KEYS_STATE_CHECKING = 2,
+   HDCP_KEYS_STATE_VALID = 3,
+   HDCP_KEYS_STATE_AKSV_NOT_VALID = 4,
+   HDCP_KEYS_STATE_CHKSUM_MISMATCH = 5,
+   HDCP_KEYS_STATE_PROD_AKSV = 6,
+   HDCP_KEYS_STATE_RESERVED = 7,
 };

 enum hdmi_ddc_read_write {
@@ -199,6 +193,8 @@ static inline uint32_t HDMI_AUDIO_INFO1_LSV(uint32_t val)
 #define HDMI_HDCP_CTRL_ENABLE  0x0001
 #define HDMI_HDCP_CTRL_ENCRYPTION_ENABLE   0x0100

+#define REG_HDMI_HDCP_DEBUG_CTRL   0x0114
+
 #define REG_HDMI_HDCP_INT_CTRL 0x0118

 #define REG_HDMI_HDCP_LINK0_STATUS 0x011c
@@ -211,9 +207,47 @@ static inline uint32_t 
HDMI_HDCP_LINK0_STATUS_KEY_STATE(enum hdmi_hdcp_key_state
return ((val) << HDMI_HDCP_LINK0_STATUS_KEY_STATE__SHIFT) & 
HDMI_HDCP_LINK0_STATUS_KEY_STATE__MASK;
 }

+#define REG_HDMI_HDCP_DDC_CTRL_0   0x0120
+
+#define REG_HDMI_HDCP_DDC_CTRL_1   0x0124
+
+#define REG_HDMI_HDCP_DDC_STATUS   0x0128
+
+#define REG_HDMI_HDCP_ENTROPY_CTRL00x012c
+
+#define REG_HDMI_HDCP_ENTROPY_CTRL10x025c
+
 #define REG_HDMI_HDCP_RESET0x0130
 #define HDMI_HDCP_RESET_LINK0_DEAUTHENTICATE   0x0001

+#define REG_HDMI_HDCP_RCVPORT_DATA00x0134
+
+#define REG_HDMI_HDCP_RCVPORT_DATA10x0138
+
+#define REG_HDMI_HDCP_RCVPORT_DATA2_0  0x013c
+
+#define REG_HDMI_HDCP_RCVPORT_DATA2_1  0x0140
+
+#define REG_HDMI_HDCP_RCVPORT_DATA30x0144
+
+#define REG_HDMI_HDCP_RCVPORT_DATA40x0148
+
+#define REG_HDMI_HDCP_RCVPORT_DATA50x014c
+
+#define REG_HDMI_HDCP_RCVPORT_DATA60x0150
+
+#define REG_HDMI_HDCP_RCVPORT_DATA70x0154
+
+#define REG_HDMI_HDCP_RCVPORT_DATA80x0158
+
+#define REG_HDMI_HDCP_RCVPORT_DATA90x015c
+
+#define REG_HDMI_HDCP_RCVPORT_DATA10   0x0160
+
+#define REG_HDMI_HDCP_RCVPORT_DATA11   0x0164
+
+#define REG_HDMI_HDCP_RCVPORT_DATA12   0x0168
+
 #define 

[PATCH] rnndb: Add register fields for msm/hdmi HDCP support

[Jilai Wang]

This patch adds the field description for HDMI HDCP registers.

Signed-off-by: Jilai Wang 
---
 rnndb/hdmi/hdmi.xml | 46 --
 1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/hdmi.xml
index 64393b4..c67e6c1 100644
--- a/rnndb/hdmi/hdmi.xml
+++ b/rnndb/hdmi/hdmi.xml
@@ -12,12 +12,14 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 

-   
-   
-   
-   
-   
-   
+   
+   
+   
+   
+   
+   
+   
+   



@@ -168,15 +170,39 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   






+   
+   
+   
+
+   
+   
+



+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+



@@ -319,6 +345,11 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+
+   
+   
+   
+

  

@@ -374,6 +405,9 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   
+   
+



-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 01/10] drm: add helper to get crtc timings (v5)

[Matt Roper]

From: Gustavo Padovan 

We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.

Note that drm_crtc_check_viewport() and intel_modeset_pipe_config() were
previously making adjustments for doublescan modes and vscan > 1 modes,
which was incorrect.  Using our new helper fixes this mistake.

v2 (by Matt): Use new stereo doubling function (suggested by Ville)

v3 (by Matt):
 - Add missing kerneldoc (Daniel)
 - Use drm_mode_copy() (Jani)

v4 (by Matt):
 - Drop stereo doubling function again; add 'stereo only' flag
   to drm_mode_set_crtcinfo() instead (Ville)

v5 (by Matt):
 - Note behavioral change in drm_crtc_check_viewport() and
   intel_modeset_pipe_config(). (Ander)
 - Describe new adjustment flags in drm_mode_set_crtcinfo()'s
   kerneldoc. (Ander)

Cc: dri-devel at lists.freedesktop.org
Suggested-by: Ville Syrjälä 
Signed-off-by: Gustavo Padovan 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_crtc.c   | 32 ++--
 drivers/gpu/drm/drm_modes.c  | 26 --
 drivers/gpu/drm/i915/intel_display.c |  6 +++---
 include/drm/drm_crtc.h   |  2 ++
 include/drm/drm_modes.h  |  3 +++
 5 files changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index de79283..2985e3f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2550,6 +2550,27 @@ int drm_mode_set_config_internal(struct drm_mode_set 
*set)
 EXPORT_SYMBOL(drm_mode_set_config_internal);

 /**
+ * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
+ * @mode: mode to query
+ * @hdisplay: hdisplay value to fill in
+ * @vdisplay: vdisplay value to fill in
+ *
+ * The vdisplay value will be doubled if the specified mode is a stereo mode of
+ * the appropriate layout.
+ */
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+   int *hdisplay, int *vdisplay)
+{
+   struct drm_display_mode adjusted;
+
+   drm_mode_copy(, mode);
+   drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE_ONLY);
+   *hdisplay = adjusted.crtc_hdisplay;
+   *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
+/**
  * drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
  * CRTC viewport
  * @crtc: CRTC that framebuffer will be displayed on
@@ -2566,16 +2587,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
 {
int hdisplay, vdisplay;

-   hdisplay = mode->hdisplay;
-   vdisplay = mode->vdisplay;
-
-   if (drm_mode_is_stereo(mode)) {
-   struct drm_display_mode adjusted = *mode;
-
-   drm_mode_set_crtcinfo(, CRTC_STEREO_DOUBLE);
-   hdisplay = adjusted.crtc_hdisplay;
-   vdisplay = adjusted.crtc_vdisplay;
-   }
+   drm_crtc_get_hv_timing(mode, , );

if (crtc->invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6d8b941..7689c14 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -739,6 +739,8 @@ EXPORT_SYMBOL(drm_mode_vrefresh);
  * - The CRTC_STEREO_DOUBLE flag can be used to compute the timings for
  *   buffers containing two eyes (only adjust the timings when needed, eg. for
  *   "frame packing" or "side by side full").
+ * - The CRTC_NO_DBLSCAN and CRTC_NO_VSCAN flags request that adjustment *not*
+ *   be performed for doublescan and vscan > 1 modes respectively.
  */
 void drm_mode_set_crtcinfo(struct drm_display_mode *p, int adjust_flags)
 {
@@ -765,18 +767,22 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, 
int adjust_flags)
}
}

-   if (p->flags & DRM_MODE_FLAG_DBLSCAN) {
-   p->crtc_vdisplay *= 2;
-   p->crtc_vsync_start *= 2;
-   p->crtc_vsync_end *= 2;
-   p->crtc_vtotal *= 2;
+   if (!(adjust_flags & CRTC_NO_DBLSCAN)) {
+   if (p->flags & DRM_MODE_FLAG_DBLSCAN) {
+   p->crtc_vdisplay *= 2;
+   p->crtc_vsync_start *= 2;
+   p->crtc_vsync_end *= 2;
+   p->crtc_vtotal *= 2;
+   }
}

-   if (p->vscan > 1) {
-   p->crtc_vdisplay *= p->vscan;
-   p->crtc_vsync_start *= p->vscan;
-   p->crtc_vsync_end *= p->vscan;
-   p->crtc_vtotal *= p->vscan;
+   if (!(adjust_flags & CRTC_NO_VSCAN)) {
+   if (p->vscan > 1) {
+   p->crtc_vdisplay *= p->vscan;
+   p->crtc_vsync_start *= p->vscan;
+   p->crtc_vsync_end *= p->vscan;
+   p->crtc_vtotal *= p->vscan;
+   }
}

if (adjust_flags & CRTC_STEREO_DOUBLE) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 

build regression with "rcar-du: Remove platform data support"

[Laurent Pinchart]

Hi Arnd,

On Monday 01 December 2014 14:09:36 Arnd Bergmann wrote:
> Hi Laurent,
> 
> linux-next has failed to build with lager_defconfig and marzen_defconfig for
> a while, with this error:
> 
> arch/arm/mach-shmobile/board-lager.c:35:41: fatal error:
> linux/platform_data/rcar-du.h: No such file or directory #include
> 
> 
> which is evidently the result of your patch
> 
> commit 2378ad1228d2cdae0ea5448beb4fb2b42ebaf99c
> Author: Laurent Pinchart 
> Date:   Wed Sep 17 02:07:52 2014 +0300
> 
> drm: rcar-du: Remove platform data support
> 
> All platforms now instantiate the DU through DT, platform data support
> isn't needed anymore.
> 
> Signed-off-by: Laurent Pinchart
> 
> 
> that removes the header files. I assume some dependency wasn't tracked
> right, since linux-next still has these.
> 
> $ git grep rcar_du_ arch/arm
> arch/arm/mach-shmobile/board-lager.c:static struct rcar_du_encoder_data
> lager_du_encoders[] = { arch/arm/mach-shmobile/board-lager.c:static const
> struct rcar_du_platform_data lager_du_pdata __initconst = {
> arch/arm/mach-shmobile/board-marzen.c:static struct rcar_du_encoder_data
> du_encoders[] = { arch/arm/mach-shmobile/board-marzen.c:static const struct
> rcar_du_platform_data du_pdata __initconst = {
> 
> Can we please fix this before the merge window? Should the platform
> device registration just get removed from the two board files?

That's what I've proposed in

http://www.spinics.net/lists/dri-devel/msg72750.html

Dave, could you please reply to that ?

-- 
Regards,

Laurent Pinchart

[PATCH 4/4] drm/msm/hdmi: don't call clk_round_rate to check hdmi pclk for MDP5

[Jilai Wang]

clock driver can support dynamic rate settings for HDMI
pixelclock, so don't need to use clk_round_rate to check if the
clockrate for specific mode is supported therefore more display
modes can be supported.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index c458348..cf18896 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -355,8 +355,6 @@ static int hdmi_connector_mode_valid(struct drm_connector 
*connector,
 struct drm_display_mode *mode)
 {
struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
-   struct hdmi *hdmi = hdmi_connector->hdmi;
-   const struct hdmi_platform_config *config = hdmi->config;
struct msm_drm_private *priv = connector->dev->dev_private;
struct msm_kms *kms = priv->kms;
long actual, requested;
@@ -365,13 +363,6 @@ static int hdmi_connector_mode_valid(struct drm_connector 
*connector,
actual = kms->funcs->round_pixclk(kms,
requested, hdmi_connector->hdmi->encoder);

-   /* for mdp5/apq8074, we manage our own pixel clk (as opposed to
-* mdp4/dtv stuff where pixel clk is assigned to mdp/encoder
-* instead):
-*/
-   if (config->pwr_clk_cnt > 0)
-   actual = clk_round_rate(hdmi->pwr_clks[0], actual);
-
DBG("requested=%ld, actual=%ld", requested, actual);

if (actual != requested)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 3/4] drm/msm/hdmi: rework HDMI IRQ hanlder

[Jilai Wang]

Disable the HPD interrupt when acking it, to avoid spurious
interrupt.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index caa1301..c458348 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -251,11 +251,11 @@ void hdmi_connector_irq(struct drm_connector *connector)
(hpd_int_status & HDMI_HPD_INT_STATUS_INT)) {
bool detected = !!(hpd_int_status & 
HDMI_HPD_INT_STATUS_CABLE_DETECTED);

-   DBG("status=%04x, ctrl=%04x", hpd_int_status, hpd_int_ctrl);
-
-   /* ack the irq: */
+   /* ack & disable (temporarily) HPD events: */
hdmi_write(hdmi, REG_HDMI_HPD_INT_CTRL,
-   hpd_int_ctrl | HDMI_HPD_INT_CTRL_INT_ACK);
+   HDMI_HPD_INT_CTRL_INT_ACK);
+
+   DBG("status=%04x, ctrl=%04x", hpd_int_status, hpd_int_ctrl);

/* detect disconnect if we are connected or visa versa: */
hpd_int_ctrl = HDMI_HPD_INT_CTRL_INT_EN;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/4] drm/msm/hdmi: enable regulators before clocks to avoid warnings

[Jilai Wang]

HPD regulators need to be enabled before clocks, otherwise clock
driver will report warning.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 45 +--
 1 file changed, 18 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index 92fddd8..caa1301 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -141,6 +141,15 @@ static int hpd_enable(struct hdmi_connector 
*hdmi_connector)
uint32_t hpd_ctrl;
int i, ret;

+   for (i = 0; i < config->hpd_reg_cnt; i++) {
+   ret = regulator_enable(hdmi->hpd_regs[i]);
+   if (ret) {
+   dev_err(dev->dev, "failed to enable hpd regulator: %s 
(%d)\n",
+   config->hpd_reg_names[i], ret);
+   goto fail;
+   }
+   }
+
ret = gpio_config(hdmi, true);
if (ret) {
dev_err(dev->dev, "failed to configure GPIOs: %d\n", ret);
@@ -164,15 +173,6 @@ static int hpd_enable(struct hdmi_connector 
*hdmi_connector)
}
}

-   for (i = 0; i < config->hpd_reg_cnt; i++) {
-   ret = regulator_enable(hdmi->hpd_regs[i]);
-   if (ret) {
-   dev_err(dev->dev, "failed to enable hpd regulator: %s 
(%d)\n",
-   config->hpd_reg_names[i], ret);
-   goto fail;
-   }
-   }
-
hdmi_set_mode(hdmi, false);
phy->funcs->reset(phy);
hdmi_set_mode(hdmi, true);
@@ -200,7 +200,7 @@ fail:
return ret;
 }

-static int hdp_disable(struct hdmi_connector *hdmi_connector)
+static void hdp_disable(struct hdmi_connector *hdmi_connector)
 {
struct hdmi *hdmi = hdmi_connector->hdmi;
const struct hdmi_platform_config *config = hdmi->config;
@@ -212,28 +212,19 @@ static int hdp_disable(struct hdmi_connector 
*hdmi_connector)

hdmi_set_mode(hdmi, false);

-   for (i = 0; i < config->hpd_reg_cnt; i++) {
-   ret = regulator_disable(hdmi->hpd_regs[i]);
-   if (ret) {
-   dev_err(dev->dev, "failed to disable hpd regulator: %s 
(%d)\n",
-   config->hpd_reg_names[i], ret);
-   goto fail;
-   }
-   }
-
for (i = 0; i < config->hpd_clk_cnt; i++)
clk_disable_unprepare(hdmi->hpd_clks[i]);

ret = gpio_config(hdmi, false);
-   if (ret) {
-   dev_err(dev->dev, "failed to unconfigure GPIOs: %d\n", ret);
-   goto fail;
-   }
-
-   return 0;
+   if (ret)
+   dev_warn(dev->dev, "failed to unconfigure GPIOs: %d\n", ret);

-fail:
-   return ret;
+   for (i = 0; i < config->hpd_reg_cnt; i++) {
+   ret = regulator_disable(hdmi->hpd_regs[i]);
+   if (ret)
+   dev_warn(dev->dev, "failed to disable hpd regulator: %s 
(%d)\n",
+   config->hpd_reg_names[i], ret);
+   }
 }

 static void
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/4] drm/msm/hdmi: use HPD interrupt to track connector status change

[Jilai Wang]

HPD interrupt can be tracked for each connector, so don't need
to poll the connector status for state change.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index 4aca2a3..92fddd8 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -242,7 +242,7 @@ hotplug_work(struct work_struct *work)
struct hdmi_connector *hdmi_connector =
container_of(work, struct hdmi_connector, hpd_work);
struct drm_connector *connector = _connector->base;
-   drm_helper_hpd_irq_event(connector->dev);
+   drm_kms_helper_hotplug_event(connector->dev);
 }

 void hdmi_connector_irq(struct drm_connector *connector)
@@ -431,9 +431,6 @@ struct drm_connector *hdmi_connector_init(struct hdmi *hdmi)
DRM_MODE_CONNECTOR_HDMIA);
drm_connector_helper_add(connector, _connector_helper_funcs);

-   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
-   DRM_CONNECTOR_POLL_DISCONNECT;
-
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Laurent Pinchart]

Hi Boris,

Thank you for the patch.

On Monday 01 December 2014 09:42:15 Boris Brezillon wrote:
> Add bus_formats and num_bus_formats fields and
> drm_display_info_set_bus_formats helper function to specify the bus
> formats supported by a given display.
> 
> This information can be used by display controller drivers to configure
> the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
> RGB or LVDS busses).
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Laurent Pinchart 

> ---
> Hi,
> 
> Sorry for the noise: I ran checkpatch after sending the series and it found
> a typo and two "line over 80 characters" warnings.
> 
> This version fixes those warnings.

Please remember to increment the version number next time, it gets confusing 
otherwise when people start asking questions such as "which v4 ?".

>  drivers/gpu/drm/drm_crtc.c | 33 +
>  include/drm/drm_crtc.h |  8 
>  2 files changed, 41 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e79c8d3..20030ec 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -763,6 +763,39 @@ static void drm_mode_remove(struct drm_connector
> *connector, drm_mode_destroy(connector->dev, mode);
>  }
> 
> +/*
> + * drm_display_info_set_bus_formats - set the supported bus formats
> + * @info: display info to store bus formats in
> + * @fmts: array containing the supported bus formats
> + * @nfmts: the number of entries in the fmts array
> + *
> + * Store the supported bus formats in display info structure.
> + * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h
> for
> + * a full list of available formats.
> + */
> +int drm_display_info_set_bus_formats(struct drm_display_info *info,
> +  const u32 *fmts,
> +  unsigned int num_fmts)
> +{
> + u32 *formats = NULL;
> +
> + if (!fmts && num_fmts)
> + return -EINVAL;
> +
> + if (fmts && num_fmts) {
> + formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
> + if (!formats)
> + return -ENOMEM;
> + }
> +
> + kfree(info->bus_formats);
> + info->bus_formats = formats;
> + info->num_bus_formats = num_fmts;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_display_info_set_bus_formats);
> +
>  /**
>   * drm_connector_get_cmdline_mode - reads the user's cmdline mode
>   * @connector: connector to quwery
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index c40070a..65dd08a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -130,6 +131,9 @@ struct drm_display_info {
>   enum subpixel_order subpixel_order;
>   u32 color_formats;
> 
> + const u32 *bus_formats;
> + unsigned int num_bus_formats;
> +
>   /* Mask of supported hdmi deep color modes */
>   u8 edid_hdmi_dc_modes;
> 
> @@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct
> drm_connector *connector, extern int
> drm_mode_connector_update_edid_property(struct drm_connector *connector,
> struct edid *edid);
> 
> +extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
> + const u32 *fmts,
> + unsigned int nfmts);
> +
>  static inline bool drm_property_type_is(struct drm_property *property,
>   uint32_t type)
>  {

-- 
Regards,

Laurent Pinchart

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

[Hans Verkuil]

Hi Thierry,

Thanks for the review, see my comments below.

On 12/01/2014 02:15 PM, Thierry Reding wrote:
> On Fri, Nov 28, 2014 at 03:50:50PM +0100, Hans Verkuil wrote:
>> From: Martin Bugge 
>>
>> When receiving video it is very useful to be able to unpack the InfoFrames.
>> Logging is useful as well, both for transmitters and receivers.
>>
>> Especially when implementing the VIDIOC_LOG_STATUS ioctl (supported by many
>> V4L2 drivers) for a receiver it is important to be able to easily log what
>> the InfoFrame contains. This greatly simplifies debugging.
>>
>> Signed-off-by: Martin Bugge 
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/video/hdmi.c | 622 
>> ++-
>>  include/linux/hdmi.h |   3 +
>>  2 files changed, 618 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>> index 9e758a8..9f0f554 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -27,10 +27,10 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>> -static void hdmi_infoframe_checksum(void *buffer, size_t size)
>> +static u8 hdmi_infoframe_calc_checksum(u8 *ptr, size_t size)
> 
> I'd personally keep the name here.

I'll do that.

> 
>> @@ -434,3 +441,604 @@ hdmi_infoframe_pack(union hdmi_infoframe *frame, void 
>> *buffer, size_t size)
>>  return length;
>>  }
>>  EXPORT_SYMBOL(hdmi_infoframe_pack);
>> +
>> +static const char *hdmi_infoframe_type_txt(enum hdmi_infoframe_type type)
> 
> Perhaps: hdmi_infoframe_type_get_name()?

I think that's better as well, I'll change it.

> 
>> +{
>> +switch (type) {
>> +case HDMI_INFOFRAME_TYPE_VENDOR: return "Vendor";
>> +case HDMI_INFOFRAME_TYPE_AVI: return "Auxiliary Video Information 
>> (AVI)";
>> +case HDMI_INFOFRAME_TYPE_SPD: return "Source Product Description (SPD)";
>> +case HDMI_INFOFRAME_TYPE_AUDIO: return "Audio";
> 
> I'd prefer "case ...:" and "return ...;" on separate lines for
> readability.

I actually think that makes it *less* readable. If you really want that, then 
I'll
change it, but I would suggest that you try it yourself first to see if it is
really more readable for you. It isn't for me, so I'll keep this for the next
version.

> 
>> +}
>> +return "Invalid/Unknown";
>> +}
> 
> Maybe include the numerical value here? Of course that either means that
> callers must pass in a buffer or we sacrifice thread-safety. The buffer
> could be optional, somewhat like this:
> 
>   const char *hdmi_infoframe_get_name(char *buffer, size_t length,
>   enum hdmi_infoframe_type type)
>   {
>   const char *name = NULL;
> 
>   switch (type) {
>   case HDMI_INFOFRAME_TYPE_VENDOR:
>   name = "Vendor";
>   break;
>   ...
>   }
> 
>   if (buffer) {
>   if (!name)
>   snprintf(buffer, length, "unknown (%d)", type);
>   else
>   snprintf(buffer, length, name);
> 
>   name = buffer;
>   }
> 
>   return name;
>   }
> 
> That way the function would be generally useful and could even be made
> publicly available.

I would do this only where it makes sense. Some of these fields have only one or
two reserved bits left, and in that case is it easier to just say something
like "Reserved (3)" and do that for each reserved value.

> 
>> +static void hdmi_infoframe_log_header(struct device *dev, void *f)
>> +{
>> +struct hdmi_any_infoframe *frame = f;
>> +dev_info(dev, "HDMI infoframe: %s, version %d, length %d\n",
>> +hdmi_infoframe_type_txt(frame->type), frame->version, 
>> frame->length);
>> +}
>> +
>> +static const char *hdmi_colorspace_txt(enum hdmi_colorspace colorspace)
>> +{
>> +switch (colorspace) {
>> +case HDMI_COLORSPACE_RGB: return "RGB";
>> +case HDMI_COLORSPACE_YUV422: return "YCbCr 4:2:2";
>> +case HDMI_COLORSPACE_YUV444: return "YCbCr 4:4:4";
>> +case HDMI_COLORSPACE_YUV420: return "YCbCr 4:2:0";
>> +case HDMI_COLORSPACE_IDO_DEFINED: return "IDO Defined";
>> +}
>> +return "Future";
>> +}
> 
> Similar comments as for the above.
> 
>> +static const char *hdmi_scan_mode_txt(enum hdmi_scan_mode scan_mode)
>> +{
>> +switch(scan_mode) {
>> +case HDMI_SCAN_MODE_NONE: return "No Data";
>> +case HDMI_SCAN_MODE_OVERSCAN: return "Composed for overscanned display";
>> +case HDMI_SCAN_MODE_UNDERSCAN: return "Composed for underscanned 
>> display";
>> +}
>> +return "Future";
>> +}
> 
> This isn't really a name any more, I think it should either stick to
> names like "None", "Overscan", "Underscan"

I agree with that, I'll change it.

> or it should return a
> description, in which case hdmi_scan_mode_get_description() might be
> more accurate for a name.
> 
>> +static const char 

[PATCH v2] drm/cirrus: fix leaky driver load error handling

[Sean Paul]

On Mon, Dec 1, 2014 at 2:15 PM, Zach Reizner  wrote:
> Before this patch, cirrus_mm_init could have failed while
> cirrus_modeset_init succeeded and the driver would have reported overall
> success on load. This patch causes cirrus_driver_load to return on the
> first error encountered.
>
> Reviewed-by: Stéphane Marchesin 


Thanks for updating this, looks good to me.

Reviewed-by: Sean Paul 

> Signed-off-by: Zach Reizner 
> ---
>  drivers/gpu/drm/cirrus/cirrus_main.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 99c1983..ab7cb54 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -179,17 +179,22 @@ int cirrus_driver_load(struct drm_device *dev, unsigned 
> long flags)
> }
>
> r = cirrus_mm_init(cdev);
> -   if (r)
> +   if (r) {
> dev_err(>pdev->dev, "fatal err on mm init\n");
> +   goto out;
> +   }
>
> r = cirrus_modeset_init(cdev);
> -   if (r)
> +   if (r) {
> dev_err(>pdev->dev, "Fatal error during modeset init: 
> %d\n", r);
> +   goto out;
> +   }
>
> dev->mode_config.funcs = (void *)_mode_funcs;
> +
> +   return 0;
>  out:
> -   if (r)
> -   cirrus_driver_unload(dev);
> +   cirrus_driver_unload(dev);
> return r;
>  }
>
> --
> 2.2.0.rc0.207.ga3a616c
>

[PATCH] drm/i915 Trouble with minimum brightness

[Jani Nikula]

On Mon, 01 Dec 2014, Jay Aurabind  wrote:
>> Please file a new bug at [1], reference this mail, and attach
>> /sys/kernel/debug/dri/0/i915_opregion.
>
> Thank you for the response. But the file you mentioned to attach seems to be
> a binary file, because I'm getting lot of junk characters. Is this normal ?

Yes, it's binary.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v2] drm/cirrus: fix leaky driver load error handling

[Zach Reizner]

Before this patch, cirrus_mm_init could have failed while
cirrus_modeset_init succeeded and the driver would have reported overall
success on load. This patch causes cirrus_driver_load to return on the
first error encountered.

Reviewed-by: Stéphane Marchesin 
Signed-off-by: Zach Reizner 
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 99c1983..ab7cb54 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -179,17 +179,22 @@ int cirrus_driver_load(struct drm_device *dev, unsigned 
long flags)
}

r = cirrus_mm_init(cdev);
-   if (r)
+   if (r) {
dev_err(>pdev->dev, "fatal err on mm init\n");
+   goto out;
+   }

r = cirrus_modeset_init(cdev);
-   if (r)
+   if (r) {
dev_err(>pdev->dev, "Fatal error during modeset init: 
%d\n", r);
+   goto out;
+   }

dev->mode_config.funcs = (void *)_mode_funcs;
+
+   return 0;
 out:
-   if (r)
-   cirrus_driver_unload(dev);
+   cirrus_driver_unload(dev);
return r;
 }

-- 
2.2.0.rc0.207.ga3a616c

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

[Thierry Reding]

 + case HDMI_COLORIMETRY_EXTENDED: return "Extended";
> + }
> + return "Invalid/Unknown";
> +}

These are names again, so same comments as for the infoframe type. And
perhaps "No Data" -> "None" in that case.

> +
> +static const char *hdmi_picture_aspect_txt(enum hdmi_picture_aspect 
> picture_aspect)
> +{
> + switch (picture_aspect) {
> + case HDMI_PICTURE_ASPECT_NONE: return "No Data";
> + case HDMI_PICTURE_ASPECT_4_3: return "4:3";
> + case HDMI_PICTURE_ASPECT_16_9: return "16:9";
> + }
> + return "Future";
> +}

Same here.

> +static const char *hdmi_quantization_range_txt(enum hdmi_quantization_range 
> quantization_range)
> +{
> + switch (quantization_range) {
> + case HDMI_QUANTIZATION_RANGE_DEFAULT: return "Default (depends on video 
> format)";

I think "Default" would do here ("depends on video format" can be
derived from the reading of the specification). Generally I think these
should focus on providing a human-readable version of the infoframes,
not be a replacement for reading the specification.

> +/**
> + * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe
> + * @dev: device
> + * @frame: HDMI AVI infoframe
> + */
> +static void hdmi_avi_infoframe_log(struct device *dev, struct 
> hdmi_avi_infoframe *frame)

Perhaps allow this to take a log level? I can imagine drivers wanting to
use this with dev_dbg() instead.

> +/**
> + * hdmi_vendor_infoframe_log() - log info of HDMI VENDOR infoframe
> + * @dev: device
> + * @frame: HDMI VENDOR infoframe
> + */
> +static void hdmi_vendor_any_infoframe_log(struct device *dev, union 
> hdmi_vendor_any_infoframe *frame)
> +{
> + struct hdmi_vendor_infoframe *hvf = >hdmi;
> +
> + hdmi_infoframe_log_header(dev, frame);
> +
> + if (frame->any.oui != HDMI_IEEE_OUI) {
> + dev_info(dev, "not a HDMI vendor infoframe\n");
> + return;
> + }
> + if (hvf->vic == 0 && hvf->s3d_struct == HDMI_3D_STRUCTURE_INVALID) {
> + dev_info(dev, "empty frame\n");
> + return;
> + }
> +
> + if (hvf->vic) {
> + dev_info(dev, "Hdmi Vic: %d\n", hvf->vic);

"HDMI VIC"?

> + }

No need for these braces.

> +/**
> + * hdmi_infoframe_log() - log info of HDMI infoframe
> + * @dev: device
> + * @frame: HDMI infoframe
> + */
> +void hdmi_infoframe_log(struct device *dev, union hdmi_infoframe *frame)
> +{
> + switch (frame->any.type) {
> + case HDMI_INFOFRAME_TYPE_AVI:
> + hdmi_avi_infoframe_log(dev, >avi);
> + break;
> + case HDMI_INFOFRAME_TYPE_SPD:
> + hdmi_spd_infoframe_log(dev, >spd);
> + break;
> + case HDMI_INFOFRAME_TYPE_AUDIO:
> + hdmi_audio_infoframe_log(dev, >audio);
> + break;
> + case HDMI_INFOFRAME_TYPE_VENDOR:
> + hdmi_vendor_any_infoframe_log(dev, >vendor);
> + break;
> + default:
> + WARN(1, "Bad infoframe type %d\n", frame->any.type);

Does it make sense for this to be WARN? It's perfectly legal for future
devices to expose new types of infoframes. Perhaps even expected. But if
we want to keep this here to help get bug reports so that we don't
forget to update this code, then maybe we should do the same wherever we
query the name of enum values above.

> +/**
> + * hdmi_avi_infoframe_unpack() - unpack binary buffer to a HDMI AVI infoframe
> + * @buffer: source buffer
> + * @frame: HDMI AVI infoframe
> + *
> + * Unpacks the information contained in binary @buffer into a structured
> + * @frame of the HDMI Auxiliary Video (AVI) information frame.
> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4 
> specification.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +static int hdmi_avi_infoframe_unpack(void *buffer, struct hdmi_avi_infoframe 
> *frame)

I'm on the fence about ordering of arguments here. I think I'd slightly
prefer the infoframe to be the first, to make the API more object-
oriented.

> +{
> + u8 *ptr = buffer;
> + int ret;
> +
> + if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI ||
> + ptr[1] != 2 ||
> + ptr[2] != HDMI_AVI_INFOFRAME_SIZE) {
> + return -EINVAL;
> + }

No need for the braces.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/b49d69f2/attachment.sig>

build regression with "rcar-du: Remove platform data support"

[Arnd Bergmann]

Hi Laurent,

linux-next has failed to build with lager_defconfig and marzen_defconfig for a 
while,
with this error:

arch/arm/mach-shmobile/board-lager.c:35:41: fatal error: 
linux/platform_data/rcar-du.h: No such file or directory
 #include 

which is evidently the result of your patch

commit 2378ad1228d2cdae0ea5448beb4fb2b42ebaf99c
Author: Laurent Pinchart 
Date:   Wed Sep 17 02:07:52 2014 +0300

drm: rcar-du: Remove platform data support

All platforms now instantiate the DU through DT, platform data support
isn't needed anymore.

Signed-off-by: Laurent Pinchart 

that removes the header files. I assume some dependency wasn't tracked
right, since linux-next still has these.

$ git grep rcar_du_ arch/arm
arch/arm/mach-shmobile/board-lager.c:static struct rcar_du_encoder_data 
lager_du_encoders[] = {
arch/arm/mach-shmobile/board-lager.c:static const struct rcar_du_platform_data 
lager_du_pdata __initconst = {
arch/arm/mach-shmobile/board-marzen.c:static struct rcar_du_encoder_data 
du_encoders[] = {
arch/arm/mach-shmobile/board-marzen.c:static const struct rcar_du_platform_data 
du_pdata __initconst = {

Can we please fix this before the merge window? Should the platform
device registration just get removed from the two board files?

Arnd

[PATCH 2/4] drm/msm/hdmi: enable regulators before clocks to avoid warnings

[Christopher Covington]

Hi Jilai,

On 11/26/2014 03:16 PM, Jilai Wang wrote:
> HPD regulators need to be enabled before clocks, otherwise clock
> driver will report warning.
> 
> Change-Id: Ieca41722ae3b15873e6290649a21bbd13e1a4278

Nit: The upstream preference is to omit Change-Id lines. You should be able to
move .git/hooks/commit-msg to an alternate location and amend the patch to
remove it. Upstream checkpatch should warn about this--let me know if it's not
working properly.

Regards,
Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

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

--- Comment #7 from Andy Furniss  ---
Created attachment 110298
  --> https://bugs.freedesktop.org/attachment.cgi?id=110298=edit
different trace with newer kernel

This is getting harder to trigger, started to think it was fixed.

Haven't triggered with mpv yet, but can still just with mplayer.

On third attempt, 115 starts in CPUs set to perf (may help trigger, but not
sure).

Uploading because current drm-next-219-wip has some fence changes and the trace
starts with -

radeon_fence_signaled

-- 
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/20141201/718d64cb/attachment.html>

[PATCH libdrm] drm: Avoid out of bound write in drmOpenByName()

[Damien Lespiau]

In the fallback code that looks for devices in /proc, the read() may
return with -1 in case of error (interruption from a signal for
instance). We'll then happily write '\0' to buf[-2].

As we didn't really care about the signal interruption before, I kept it
the same way, just making sure that retcode is > 0 to avoid that case.

This was found by static analysis.

Signed-off-by: Damien Lespiau 
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index d900b4b..106b8ab 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -579,7 +579,7 @@ static int drmOpenByName(const char *name)
if ((fd = open(proc_name, 0, 0)) >= 0) {
retcode = read(fd, buf, sizeof(buf)-1);
close(fd);
-   if (retcode) {
+   if (retcode > 0) {
buf[retcode-1] = '\0';
for (driver = pt = buf; *pt && *pt != ' '; ++pt)
;
-- 
1.8.3.1

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Hi Laurent,

On Mon, 01 Dec 2014 15:00:15 +0200
Laurent Pinchart  wrote:

> Hi Boris,
> 
> Thank you for the patch.
> 
> On Monday 01 December 2014 09:42:15 Boris Brezillon wrote:
> > Add bus_formats and num_bus_formats fields and
> > drm_display_info_set_bus_formats helper function to specify the bus
> > formats supported by a given display.
> > 
> > This information can be used by display controller drivers to configure
> > the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
> > RGB or LVDS busses).
> > 
> > Signed-off-by: Boris Brezillon 
> 
> Acked-by: Laurent Pinchart 
> 
> > ---
> > Hi,
> > 
> > Sorry for the noise: I ran checkpatch after sending the series and it found
> > a typo and two "line over 80 characters" warnings.
> > 
> > This version fixes those warnings.
> 
> Please remember to increment the version number next time, it gets confusing 
> otherwise when people start asking questions such as "which v4 ?".

Okay. I wasn't sure, and eventually decided to just prefix the version
with RESEND because these were only cosmetic changes, and I fixed them
right after sending the v4.

I'll know for next time ;-).

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen

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

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

--- Comment #4 from Sylvain BERTRAND  ---
up-to-date fedora rawhide, but dota2 is a 32 bits app:
Name: mesa-libGL
Arch: i686
Version : 10.5.0
Release : 0.devel.2.3d9c1a9.fc22
Size: 783 k
Repo: installed
>From repo   : rawhide
Summary : Mesa libGL runtime libraries and DRI drivers
URL : http://www.mesa3d.org
License : MIT
Description : Mesa libGL runtime library.

-- 
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/20141201/b410079d/attachment.html>

[PATCH] drm/cirrus: fix leaky driver load error handling

[Sean Paul]

On Mon, Nov 17, 2014 at 5:19 PM, Zach Reizner  wrote:
> Before this patch, cirrus_device_init could have failed while
> cirrus_mm_init succeeded and the driver would have reported overall
> success on load. This patch causes cirrus_device_init to return on
> the first error encountered.
>
> Reviewed-by: Stéphane Marchesin 


The code itself looks good, just a few nits with the commit message.

I think you mean to s/cirrus_mm_init/cirrus_modeset_init/ and
s/cirrus_device_init/cirrus_mm_init/. You should also have a
Signed-off-by line (see section 12 of [1])

Sean

[1]- https://www.kernel.org/doc/Documentation/SubmittingPatches



> ---
>  drivers/gpu/drm/cirrus/cirrus_main.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 99c1983..ab7cb54 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -179,17 +179,22 @@ int cirrus_driver_load(struct drm_device *dev, unsigned 
> long flags)
> }
>
> r = cirrus_mm_init(cdev);
> -   if (r)
> +   if (r) {
> dev_err(>pdev->dev, "fatal err on mm init\n");
> +   goto out;
> +   }
>
> r = cirrus_modeset_init(cdev);
> -   if (r)
> +   if (r) {
> dev_err(>pdev->dev, "Fatal error during modeset init: 
> %d\n", r);
> +   goto out;
> +   }
>
> dev->mode_config.funcs = (void *)_mode_funcs;
> +
> +   return 0;
>  out:
> -   if (r)
> -   cirrus_driver_unload(dev);
> +   cirrus_driver_unload(dev);
> return r;
>  }
>
> --
> 2.1.0.rc2.206.gedb03e5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2] drm/exynos: Add DECON driver

[Pankaj Dubey]

Hi Ajay,

On 28 November 2014 at 16:45, Ajay Kumar  wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals using pixel data.
>
> DECON driver can be used to drive 2 different interfaces on Exynos7:
> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>
> The existing FIMD driver code was used as a template to create
> DECON driver. Only DECON-INT is supported as of now, and
> DECON-EXT support will be added later.
>
> Signed-off-by: Akshu Agrawal 
> Signed-off-by: Ajay Kumar 
> ---
> Changes since V1:
> -- Address comments from Pankaj and do few cleanups.
>

Thanks, but still I can see this needs modification, please see my comments:

>  .../devicetree/bindings/video/exynos7-decon.txt|   67 ++
>  drivers/gpu/drm/exynos/Kconfig |   13 +-
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1037 
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
>  include/video/exynos7_decon.h  |  346 +++
>  7 files changed, 1466 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
>  create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
>  create mode 100644 include/video/exynos7_decon.h
>

[snip]

> +static int decon_mgr_initialize(struct exynos_drm_manager *mgr,
> +   struct drm_device *drm_dev)
> +{
> +   struct decon_context *ctx = mgr_to_decon(mgr);
> +   struct exynos_drm_private *priv = drm_dev->dev_private;
> +   int ret;
> +
> +   mgr->drm_dev = drm_dev;
> +   mgr->pipe = ctx->pipe = priv->pipe++;
> +

Do we really need 'pipe' in exynos_drm_manager and decon_context both?

> +   /* attach this sub driver to iommu mapping if supported. */
> +   if (is_drm_iommu_supported(mgr->drm_dev)) {

[snip]

> +static void decon_win_mode_set(struct exynos_drm_manager *mgr,
> +   struct exynos_drm_overlay *overlay)
> +{
> +   struct decon_context *ctx = mgr_to_decon(mgr);
> +   struct decon_win_data *win_data;
> +   int win, padding;
> +
> +   if (!overlay) {
> +   DRM_ERROR("overlay is NULL\n");
> +   return;
> +   }
> +
> +   win = overlay->zpos;
> +   if (win == DEFAULT_ZPOS)
> +   win = ctx->default_win;
> +
> +   if (win < 0 || win >= WINDOWS_NR)
> +   return;
> +
> +
> +   win_data = >win_data[win];
> +

As I mentioned in V1, since these 5 lines are getting repeating better
we move it in one static function. It will help in reducing code
footprint.


[snip]

> +
> +/**
> + * shadow_protect_win() - disable updating values from shadow registers at 
> vsync
> + *
> + * @win: window to protect registers for
> + * @protect: 1 to protect (disable updates)
> + */
> +static void decon_shadow_protect_win(struct decon_context *ctx,
> +   int win, bool protect)
> +{
> +   u32 reg, bits, val;
> +
> +   reg = SHADOWCON;

How about using SHADOWCON directly instead of using local variable?

> +   bits = SHADOWCON_WINx_PROTECT(win);
> +
> +   val = readl(ctx->regs + reg);
> +   if (protect)
> +   val |= bits;
> +   else
> +   val &= ~bits;
> +   writel(val, ctx->regs + reg);
> +}
> +
> +static void decon_win_commit(struct exynos_drm_manager *mgr, int zpos)
> +{
> +   struct decon_context *ctx = mgr_to_decon(mgr);
> +   struct decon_win_data *win_data;
> +   int win = zpos;
> +   unsigned long val, alpha, blendeq;
> +   unsigned int last_x;
> +   unsigned int last_y;
> +
> +   if (ctx->suspended)
> +   return;
> +
> +   if (win == DEFAULT_ZPOS)
> +   win = ctx->default_win;
> +
> +   if (win < 0 || win >= WINDOWS_NR)
> +   return;
> +
> +   win_data = >win_data[win];
> +
> +   /* If suspended, enable this on resume */
> +   if (ctx->suspended) {
> +   win_data->resume = true;
> +   return;
> +   }
> +
> +   /*

[snip]

> +static int decon_probe(struct platform_device *pdev)
> +{
> +   struct device *dev = >dev;
> +   struct decon_context *ctx;
> +   struct resource *res;
> +   int ret = -EINVAL;
> +
> +   if (!dev->of_node)
> +   return -ENODEV;
> +
> +   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> +   if (!ctx)
> +   return -ENOMEM;
> +
> +   ctx->manager.type = EXYNOS_DISPLAY_TYPE_LCD;
> +   ctx->manager.ops = _manager_ops;
> +
> +   ret = exynos_drm_component_add(dev, EXYNOS_DEVICE_TYPE_CRTC,
> +   

[PATCH] drm: i2c: tda998x: Retry fetching the EDID if it fails first time.

[Andrew Jackson]

On 11/29/14 10:41, Jean-Francois Moine wrote:
> On Fri, 28 Nov 2014 09:02:39 +
> Andrew Jackson  wrote:
> 
>>> It seems that your patch is deprecated by Laurent Pinchart's
>>> [PATCH] drm: tda998x: Use drm_do_get_edid()
>>> http://lists.freedesktop.org/archives/dri-devel/2014-November/072906.html
>>>   
>>
>> Thank you for the heads-up, I'd not seen that.  I'll consider how my patch 
>> might be modified to suit the new infrastructure.
> 
> You don't need any patch: drm_do_get_edid() already loops on reading
> the EDID.
> 

Thank you again: that saves me work!

   Andrew

[PATCH v13 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access

[Philipp Zabel]

Am Freitag, den 28.11.2014, 17:43 +0800 schrieb Andy Yan:
> Hi Zabel:
> On 2014年11月27日 00:34, Philipp Zabel wrote:
> > Am Mittwoch, den 26.11.2014, 21:32 +0800 schrieb Andy Yan:
> >> On rockchip rk3288, only word(32-bit) accesses are
> >> permitted for hdmi registers.  Byte width accesses (writeb,
> >> readb) generate an imprecise external abort.
> >>
> >> Signed-off-by: Andy Yan 
> >>
> >> ---
> >>
> >> Changes in v13: None
> >> Changes in v12: None
> >> Changes in v11: None
> >> Changes in v10: None
> >> Changes in v9: None
> >> Changes in v8: None
> >> Changes in v7: None
> >> Changes in v6:
> >> - refactor register access without reg_shift
> >>
> >> Changes in v5:
> >> - refactor reg-io-width
> >>
> >> Changes in v4: None
> >> Changes in v3:
> >> - split multi-register access to one indepent patch
> >>
> >>   drivers/gpu/drm/bridge/dw_hdmi.c | 57 
> >> +++-
> >>   1 file changed, 51 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> >> b/drivers/gpu/drm/bridge/dw_hdmi.c
> >> index a53bf63..5e88c8d 100644
> >> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> >> @@ -100,6 +100,11 @@ struct hdmi_data_info {
> >>struct hdmi_vmode video_mode;
> >>   };
> >>   
> >> +union dw_reg_ptr {
> >> +  u32 __iomem *p32;
> >> +  u8 __iomem *p8;
> >> +};
> > I see no need to introduce this. Just explicitly multiply the offset in
> > dw_hdmi_writel.
> >
>  Is there any disadvantage to do like this?
>  The compiler can help us do the explicitly multiply by this way.

Four additional lines, a new defined type, a few more changes to struct
dw_hdmi and dw_hdmi_bind necessary.

Technically I see no problem to let the compiler do the multiplication,
my issue is that it ever so slightly obfuscates the code. Instead of
just writing "* 4" in two functions, we get a new union that you need to
know about when looking at struct dw_hdmi and dw_hdmi_bind, regs.p8 is
used but never assigned directly, it's just a tiny bit of additional
effort needed to understand the code. But when the cost to avoid that is
so small...

regards
Philipp

[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

[Philipp Zabel]

Hi Andy,

Am Montag, den 01.12.2014, 19:24 +0800 schrieb Andy Yan:
[...]
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> new file mode 100644
> index 000..1bbf3ca
> --- /dev/null
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (C) 2011 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __DW_HDMI__
> +#define __DW_HDMI__
> +
> +#include 
> +
> +enum {
> + RES_8,
> + RES_10,
> + RES_12,
> + RES_MAX,
> +};
> +
> +enum dw_hdmi_devtype {
> + IMX6Q_HDMI,
> + IMX6DL_HDMI,
> +};
> +
> +struct mpll_config {
> + unsigned long mpixelclock;
> + struct {
> + u16 cpce;
> + u16 gmp;
> + } res[RES_MAX];
> +};
> +
> +struct curr_ctrl {
> + unsigned long mpixelclock;
> + u16 curr[RES_MAX];
> +};
> +
> +struct sym_term {
> + unsigned long mpixelclock;
> + u16 sym_ctr;/*clock symbol and transmitter control*/
> + u16 term;   /*transmission termination value*/
> +};

since this is going to be used by multiple drivers, the enums and
structs should all be properly namespaced. How about DW_HDMI_RES_x,
struct dw_hdmi_mpll_config, struct dw_hdmi_curr_ctrl, and struct
dw_hdmi_sym_term?

> +struct dw_hdmi_plat_data {
> + enum dw_hdmi_devtype dev_type;
> + const struct mpll_config *mpll_cfg;
> + const struct curr_ctrl *cur_ctr;
> + const struct sym_term *sym_term;
> +};
> +
> +void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
> +int dw_hdmi_bind(struct device *dev, struct device *master,
> +  void *data, struct drm_encoder *encoder,
> +  const struct dw_hdmi_plat_data *plat_data);
> +#endif /* __IMX_HDMI_H__ */

regards
Philipp

[PATCH] drm/radeon: Hide cursor on CRTCs used by fbdev

[Michel Dänzer]

On 28.11.2014 22:38, Daniel Vetter wrote:
> On Fri, Nov 28, 2014 at 11:48:48AM +0900, Michel Dänzer wrote:
>> From: Michel Dänzer 
>>
>> Since we are now preserving the cursor across modesets, the cursor could
>> be left over in console if e.g. X crashed.
>
> I'd add a fixme for this since if you implement universal plane support
> fbdev will automatically disable all non-primary planes (and so the
> cursor).

Thanks Daniel for the suggestion, and Alex for merging the patch.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 1/3] hdmi: add new HDMI 2.0 defines

[Hans Verkuil]

On 12/01/2014 12:03 PM, Thierry Reding wrote:
> On Fri, Nov 28, 2014 at 03:50:49PM +0100, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Add new Video InfoFrame colorspace information introduced in HDMI 2.0
>> and new Audio Coding Extension Types, also from HDMI 2.0.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  include/linux/hdmi.h | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
>> index 11c0182..38fd2a0 100644
>> --- a/include/linux/hdmi.h
>> +++ b/include/linux/hdmi.h
>> @@ -37,6 +37,8 @@ enum hdmi_colorspace {
>>  HDMI_COLORSPACE_RGB,
>>  HDMI_COLORSPACE_YUV422,
>>  HDMI_COLORSPACE_YUV444,
>> +HDMI_COLORSPACE_YUV420,
>> +HDMI_COLORSPACE_IDO_DEFINED = 7,
>>  };
>>  
>>  enum hdmi_scan_mode {
>> @@ -77,6 +79,10 @@ enum hdmi_extended_colorimetry {
>>  HDMI_EXTENDED_COLORIMETRY_S_YCC_601,
>>  HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601,
>>  HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB,
>> +
>> +/* The following EC values are only defined in CEA-861-F. */
>> +HDMI_EXTENDED_COLORIMETRY_BT2020_CONST_LUM,
>> +HDMI_EXTENDED_COLORIMETRY_BT2020,
>>  };
>>  
>>  enum hdmi_quantization_range {
>> @@ -201,9 +207,23 @@ enum hdmi_audio_sample_frequency {
>>  
>>  enum hdmi_audio_coding_type_ext {
>>  HDMI_AUDIO_CODING_TYPE_EXT_STREAM,
>> +
>> +/*
>> + * The next three CXT values are defined in CEA-861-E only.
>> + * They do not exist in older versions, and in CEA-861-F they are
>> + * defined as 'Not in use'.
>> + */
>>  HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC,
>>  HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC_V2,
>>  HDMI_AUDIO_CODING_TYPE_EXT_MPEG_SURROUND,
>> +
>> +/* The following CXT values are only defined in CEA-861-F. */
>> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC,
>> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC_V2,
>> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_AAC_LC,
>> +HDMI_AUDIO_CODING_TYPE_EXT_DRA,
>> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG_HE_AAC_SURROUND,
>> +HDMI_AUDIO_CODING_TYPE_EXT_MPEG_AAC_LC_SURROUND = 10,
> 
> I think the last two should be MPEG4_{HE_AAC,AAC}_SURROUND, and with
> that fixed:
> 
> Reviewed-by: Thierry Reding 
> 

You are correct, I will correct that.

Thanks,

Hans

[PATCH 2/2] drm/panel: Add support for Giantplus GPG482739QS5 panel

[Lucas Stach]

Hi Thierry,

just a gentle ping for those 2 patches. It would be nice if you could
pick them up, so they can go into the next mergewindow.

Regards,
Lucas

Am Mittwoch, den 19.11.2014, 10:29 +0100 schrieb Lucas Stach:
> From: Philipp Zabel 
> 
> This patch adds support for the GiantPlus GPG48273QS5 4.3" WQVGA TFT LCD panel
> to the simple-panel driver.
> 
> This panel is connected via a parallel bus and uses both HSYNC and VSYNC,
> whose lengths are unfortunately not clearly defined. The datasheet only
> specifies the front- and backporch length, but the timing diagram suggests
> that both sync signals should be asserted for exactly one clock cycle.
> 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Lucas Stach 
> ---
> [lst]: rebased on top of drm/panel/for-next + added commit message
> ---
>  .../bindings/panel/giantplus,gpg482739qs5.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt 
> b/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt
> new file mode 100644
> index ..24b0b624434b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt
> @@ -0,0 +1,7 @@
> +GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "giantplus,gpg48273qs5"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index c4b6167a8bf3..1d8ed2062841 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -560,6 +560,29 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
>   },
>  };
>  
> +static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
> + .clock = 9000,
> + .hdisplay = 480,
> + .hsync_start = 480 + 5,
> + .hsync_end = 480 + 5 + 1,
> + .htotal = 480 + 5 + 1 + 40,
> + .vdisplay = 272,
> + .vsync_start = 272 + 8,
> + .vsync_end = 272 + 8 + 1,
> + .vtotal = 272 + 8 + 1 + 8,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc giantplus_gpg482739qs5 = {
> + .modes = _gpg482739qs5_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 95,
> + .height = 54,
> + },
> +};
> +
>  static const struct drm_display_mode hannstar_hsd070pww1_mode = {
>   .clock = 71100,
>   .hdisplay = 1280,
> @@ -757,6 +780,9 @@ static const struct of_device_id platform_of_match[] = {
>   .compatible = "foxlink,fl500wvr00-a0t",
>   .data = _fl500wvr00_a0t,
>   }, {
> + .compatible = "giantplus,gpg482739qs5",
> + .data = _gpg482739qs5
> + }, {
>   .compatible = "hannstar,hsd070pww1",
>   .data = _hsd070pww1,
>   }, {

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH 1/3] hdmi: add new HDMI 2.0 defines

[Thierry Reding]

On Fri, Nov 28, 2014 at 03:50:49PM +0100, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add new Video InfoFrame colorspace information introduced in HDMI 2.0
> and new Audio Coding Extension Types, also from HDMI 2.0.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  include/linux/hdmi.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 11c0182..38fd2a0 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -37,6 +37,8 @@ enum hdmi_colorspace {
>   HDMI_COLORSPACE_RGB,
>   HDMI_COLORSPACE_YUV422,
>   HDMI_COLORSPACE_YUV444,
> + HDMI_COLORSPACE_YUV420,
> + HDMI_COLORSPACE_IDO_DEFINED = 7,
>  };
>  
>  enum hdmi_scan_mode {
> @@ -77,6 +79,10 @@ enum hdmi_extended_colorimetry {
>   HDMI_EXTENDED_COLORIMETRY_S_YCC_601,
>   HDMI_EXTENDED_COLORIMETRY_ADOBE_YCC_601,
>   HDMI_EXTENDED_COLORIMETRY_ADOBE_RGB,
> +
> + /* The following EC values are only defined in CEA-861-F. */
> + HDMI_EXTENDED_COLORIMETRY_BT2020_CONST_LUM,
> + HDMI_EXTENDED_COLORIMETRY_BT2020,
>  };
>  
>  enum hdmi_quantization_range {
> @@ -201,9 +207,23 @@ enum hdmi_audio_sample_frequency {
>  
>  enum hdmi_audio_coding_type_ext {
>   HDMI_AUDIO_CODING_TYPE_EXT_STREAM,
> +
> + /*
> +  * The next three CXT values are defined in CEA-861-E only.
> +  * They do not exist in older versions, and in CEA-861-F they are
> +  * defined as 'Not in use'.
> +  */
>   HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC,
>   HDMI_AUDIO_CODING_TYPE_EXT_HE_AAC_V2,
>   HDMI_AUDIO_CODING_TYPE_EXT_MPEG_SURROUND,
> +
> + /* The following CXT values are only defined in CEA-861-F. */
> + HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC,
> + HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_HE_AAC_V2,
> + HDMI_AUDIO_CODING_TYPE_EXT_MPEG4_AAC_LC,
> + HDMI_AUDIO_CODING_TYPE_EXT_DRA,
> + HDMI_AUDIO_CODING_TYPE_EXT_MPEG_HE_AAC_SURROUND,
> + HDMI_AUDIO_CODING_TYPE_EXT_MPEG_AAC_LC_SURROUND = 10,

I think the last two should be MPEG4_{HE_AAC,AAC}_SURROUND, and with
that fixed:

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

[Bug 83461] hdmi screen flicker/unusable

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

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

--- Comment #27 from Christian König  ---
Created attachment 159331
  --> https://bugzilla.kernel.org/attachment.cgi?id=159331=edit
Testing patch.

(In reply to kb from comment #26)
> (In reply to Christian König from comment #25)
> > You could try to artificially limit ref_div_max or fb_div_max until you get
> > a stable signal once more. Maybe this will yield some more light on the root
> > cause of the issue.
> 
> Can you give me some details - how to do this?

Attached is a testing patch which adds an artificially upper limit to 400.0 for
the feedback divider (normal range 17.0-2048.0) and an upper limit of 13 for
the reference divider (normal range 2-15).

I suggest you start playing with the feedback divider values until you can
figure out the limits for your hardware. E.g. try 400 as in my patch first, if
that works raise it to 800 if that doesn't work go down to 600 again etc..

> 
> > > Do you think change of graphics card would resolve the issue?
> > 
> > Well, most likely yes.
> > 
> > But the new kernel seems to work better for some people, but has regressed
> > for you. So I would really like to create a solution that works for
> > everybody.
> 
> Right now I switched to catalyst which seems to work and allows me to use
> new kernel. But since apparently my card is "legacy" I had to downgrade to
> xorg server 1.12 :-|

Yeah, that's the problem I've got as well. The hardware isn't supported any
more so the whole documentation is not available.

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

[PATCH 2/3] drm/panel: add s6e63j0x03 LCD Panel driver

[Thierry Reding]

; + ret = ctx->error;
> +
> + if (ret < 0)
> + return s6e63j0x03_disable(panel);

No, you can't do this. While there's nothing enforcing this (yet), the
panel can't be disabled before it's been prepared.

> +
> + ctx->power = FB_BLANK_UNBLANK;
> +
> + return ret;
> +}
> +
> +static int s6e63j0x03_unprepare(struct drm_panel *panel)
> +{
> + struct s6e63j0x03 *ctx = panel_to_s6e63j0x03(panel);
> + int ret;
> +
> + s6e63j0x03_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF);

Use mipi_dsi_dcs_set_display_off().

> + s6e63j0x03_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE);

Use mipi_dsi_dcs_enter_sleep_mode().

> +
> + s6e63j0x03_clear_error(ctx);
> +
> + usleep_range(ctx->power_off_delay * 1000,
> + (ctx->power_off_delay + 1) * 1000);
> +
> + ret = s6e63j0x03_power_off(ctx);
> + if (ret < 0)
> + return s6e63j0x03_prepare(panel);

Huh? Why?

> +
> + ctx->power = FB_BLANK_POWERDOWN;
> +
> + return ret;
> +}
> +
> +static const struct drm_panel_funcs s6e63j0x03_drm_funcs = {

No need for "_drm" in the variable name here.

> + .enable = s6e63j0x03_enable,
> + .disable = s6e63j0x03_disable,
> + .prepare= s6e63j0x03_prepare,

Missing space between '.prepare' and '='.

> + .unprepare = s6e63j0x03_unprepare,
> + .get_modes = s6e63j0x03_get_modes,

Please order these in the same way as they are declared in the
structure.

> +static int s6e63j0x03_parse_dt(struct s6e63j0x03 *ctx)
> +{
> + struct device *dev = ctx->dev;
> + struct device_node *np = dev->of_node;
> + int ret;
> +
> + ret = of_get_videomode(np, >vm, 0);
> + if (ret < 0)
> + return ret;
> +
> + of_property_read_u32(np, "power-on-delay", >power_on_delay);
> + of_property_read_u32(np, "power-off-delay", >power_off_delay);
> + of_property_read_u32(np, "reset-delay", >reset_delay);
> + of_property_read_u32(np, "init-delay", >init_delay);

I take it that these are optional (I can't tell because you haven't
provided a DT binding for this panel)?

> +static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = >dev;
> + struct s6e63j0x03 *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(struct s6e63j0x03), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + mipi_dsi_set_drvdata(dsi, ctx);
> +
> + ctx->dev = dev;
> +
> + dsi->lanes = 1;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_BURST;
> +
> + ret = s6e63j0x03_parse_dt(ctx);
> + if (ret < 0)
> + return ret;
> +
> + ctx->supplies[0].supply = "vdd3";
> + ctx->supplies[1].supply = "vci";
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
> +   ctx->supplies);
> + if (ret < 0) {
> + dev_err(dev, "failed to get regulators: %d\n", ret);
> + return ret;
> + }
> +
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ctx->reset_gpio)) {
> + dev_err(dev, "cannot get reset-gpios %ld\n",
> + PTR_ERR(ctx->reset_gpio));

"reset GPIO" since it's only one. Also please separate the error code
from the rest of the message using a colon to make it more obvious that
the number isn't the GPIO that could be gotten.

> + ctx->bl_dev->props.max_brightness = MAX_BRIGHTNESS;
> + ctx->bl_dev->props.brightness = DEFAULT_BRIGHTNESS;
> +
> + ret = drm_panel_add(>panel);
> + if (ret < 0)
> + goto err_unregister_backlight;
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0)
> + goto err_remove_panel;
> +
> + return ret;
> +
> +err_remove_panel:
> + drm_panel_remove(>panel);
> +
> +err_unregister_backlight:

No need for the err_ prefix here.

> + backlight_device_unregister(ctx->bl_dev);
> +
> + return ret;
> +}
> +
> +static int s6e63j0x03_remove(struct mipi_dsi_device *dsi)
> +{
> + struct s6e63j0x03 *ctx = mipi_dsi_get_drvdata(dsi);
> +
> + mipi_dsi_detach(dsi);
> + drm_panel_remove(>panel);
> +
> + backlight_device_unregister(ctx->bl_dev);
> +
> + return 0;
> +}
> +
> +static struct of_device_id s6e63j0x03_of_match[] = {

static const please.

> + { .compatible = "samsung,s6e63j0x03" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, s6e63j0x03_of_match);
> +
> +static struct mipi_dsi_driver s6e63j0x03_driver = {
> + .probe = s6e63j0x03_probe,
> + .remove = s6e63j0x03_remove,
> + .driver = {
> + .name = "panel_s6e63j0x03",
> + .owner = THIS_MODULE,

It is no longer necessary to specify this explicitly.

> + .of_match_table = s6e63j0x03_of_match,
> + },
> +};
> +module_mipi_dsi_driver(s6e63j0x03_driver);

You're missing MODULE_AUTHOR, MODULE_DESCRIPTION and MODULE_LICENSE
here.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/56994439/attachment.sig>

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

[Konrad Rzeszutek Wilk]

On Wed, Nov 12, 2014 at 06:03:49PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > dma_alloc_coherent() returns a kernel virtual address that is part of
> > > the linear range. Passing such an address to virt_to_page() is illegal
> > > on non-coherent architectures. This causes the kernel to oops on 64-bit
> > > ARM because the struct page * obtained from virt_to_page() points to
> > > unmapped memory.
> > 
> > Oh! That is not good!
> >
> I think what Thierry meant is that the returned pointer is /not/ in the
> linear range.
>  
> > > Until that time, this temporary fix will allow TTM to work on 32-bit
> > > and 64-bit ARM as well, provided that no IOMMU translations are enabled
> > > for the GPU.
> > 
> > Is there a way to query the 'struct device' to see if the IOMMU translation
> > is enabled/disabled for said device?

?
> > 
> > Now your patch looks to get the 'struct page' by doing some  form of
> > translation. Could you explain to me which type of memory have a 'struct 
> > page'
> > and which ones do not ?
> > 
> > It is OK if you explain this in nauseating details 
> 
> Basically there are two types of memory that have a struct page:
> 
> - directly mapped cacheable memory, i.e. anything that can be accessed
>   through a kernel pointer without having to go though ioremap/vmalloc/...
> 
> - highmem pages on 32-bit system.
> 
> On noncoherent ARM systems, dma_alloc_coherent will return memory that
> is was unmapped from the linear range to avoid having both cacheable and
> noncachable mappings for the same page.
> 
>   Arnd

[PATCH] drm/i915 Trouble with minimum brightness

[Jani Nikula]

On Fri, 28 Nov 2014, Jay Aurabind  wrote:
> Hello all,
>
> I notice that some activity has been going on with the minimum value
> of display brightness recently (e1c412e7575).
>
> But the minimum value thats currently chosen is not at all acceptable
> for my eyes. My display is working perfectly without that restriction
> on minimum intensity.  I tend to stare at the screen a lot and the
> current minimum settings is straining my eyes.
>
> Even if you say that it may not be good for the devices, I still
> insist, because I want my *display* to fail first, not my eyes.  So
> please try providing a way for the needy users to override this
> minimum settings. I hope adding a module parameter would be easy fix.
>
> Something like this: ? (I dont call myself a kernel programmer yet,
> just scratching the surface)
>
>
> Provide provision for users to disable restriction on minimum brightness
> value introduced in:
>
> commit e1c412e75754ab7b7002f3e18a2652d999c40d4b
> Author: Jani Nikula 
> Date:   Wed Nov 5 14:46:31 2014 +0200
>
> drm/i915: safeguard against too high minimum brightness
>
> There are systems which work reliably without restriction on minimum
> value of display brightness. Also the arbitrary value may be too high
> for many users as well.

Please file a new bug at [1], reference this mail, and attach
/sys/kernel/debug/dri/0/i915_opregion.

The minimum value is chosen and provided by the OEM. There's still some
open questions about the interpretation of the value though (which lead
to the commit you referenced), so I'm hesitant to make changes before we
have those cleared up.

In general I am not fond of adding new module parameters for tuning
things. Every new knob is another point of failure that we need to test,
and they are pretty much part of the ABI we can't easily drop or change.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


>
> Signed-off-by: Aurabindo J 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  1 +
>  drivers/gpu/drm/i915/i915_params.c |  6 ++
>  drivers/gpu/drm/i915/intel_panel.c | 14 ++
>  3 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 16a6f6d..55d2ead 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2213,6 +2213,7 @@ struct i915_params {
>   int disable_power_well;
>   int enable_ips;
>   int invert_brightness;
> + int restrict_min_brightness;
>   int enable_cmd_parser;
>   /* leave bools at the end to not create holes */
>   bool enable_hangcheck;
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index c91cb20..0601c2a 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -46,6 +46,7 @@ struct i915_params i915 __read_mostly = {
>   .prefault_disable = 0,
>   .reset = true,
>   .invert_brightness = 0,
> + .restrict_min_brightness = 1,
>   .disable_display = 0,
>   .enable_cmd_parser = 1,
>   .disable_vtd_wa = 0,
> @@ -155,6 +156,11 @@ MODULE_PARM_DESC(invert_brightness,
>   "to dri-devel at lists.freedesktop.org, if your machine needs it. "
>   "It will then be included in an upcoming module version.");
>
> +module_param_named(restrict_min_brightness, i915.restrict_min_brightness, 
> int, 0600);
> +MODULE_PARM_DESC(restrict_min_brightness,
> + "Restrict minimum brightness "
> + "(-1 disable restriction, 0 value from VBT, 1 arbitrary value )");
> +
>  module_param_named(disable_display, i915.disable_display, bool, 0600);
>  MODULE_PARM_DESC(disable_display, "Disable display (default: false)");
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index 41b3be2..def9f4e 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1109,10 +1109,16 @@ static u32 get_backlight_min_vbt(struct 
> intel_connector *connector)
>* against this by letting the minimum be at most (arbitrarily chosen)
>* 25% of the max.
>*/
> - min = clamp_t(int, dev_priv->vbt.backlight.min_brightness, 0, 64);
> - if (min != dev_priv->vbt.backlight.min_brightness) {
> - DRM_DEBUG_KMS("clamping VBT min backlight %d/255 to %d/255\n",
> -   dev_priv->vbt.backlight.min_brightness, min);
> + if (i915.restrict_min_brightness < 0)
> + min = 0;
> + else if (i915.restrict_min_brightness == 0)
> + min = dev_priv->vbt.backlight.min_brightness;
> + else {
> + min = clamp_t(int, dev_priv->vbt.backlight.min_brightness, 0, 
> 64);
> + if (min != dev_priv->vbt.backlight.min_brightness) {
> + DRM_DEBUG_KMS("clamping VBT min backlight %d/255 to 
> %d/255\n",
> + dev_priv->vbt.backlight.min_brightness, 
> min);

RFC on upstreaming of a Mediatek DRM modesetting driver

[Rob Clark]

On Mon, Dec 1, 2014 at 5:01 AM, Frank Binns  wrote:
> Hi,
>
> We are currently in negotiations with one of our customers (Mediatek) on a 
> strategy that will allow them to push a DRM modesetting driver into the 
> upstream kernel. We are writing to get people's opinions and feedback on our 
> proposed approach.
>
> Currently, our driver is structured in such a way that the display driver is 
> more tightly integrated with the GPU driver than we would like. Although our 
> kernel driver has been shipped with a GPL license for a long time, it is not 
> in a form that would be considered acceptable upstream. Unfortunately, it is 
> going to be a long process to get this part of the driver into a reasonable 
> state. However, in the meantime, we don't want to prevent customer portions 
> of the driver from being upstreamed. With the work done on recent kernels, 
> and with a willing partner in Mediatek, we now think that we can restructure 
> our driver in such a way as to allow this to happen.
>
> We see two basic approaches to achieving this:
> 1) Two independent DRM drivers, i.e. modesetting and render node drivers
> 2) A single componentised DRM driver

As others have said, a render-node kms driver is the way to go, so
that the various KMS drivers it works with can be themselves
upstreamed.

In the past, I had gone (more or less) the second approach w/ omapdrm
but that required carrying some downstream omapdrm patches for the
integration with gpu.  This was, because at the time there was really
no alternative.  But now that we have dmabuf/prime and fence stuff in
place, there is no more a need to do that.  So the best approach is
one that allows the display/kms drivers to be used without downstream
patches.

Ofc, it would be nice to see an upstream-worthy driver for the gpu
side of things, but as others have noted, upstream kernel drivers
require *some* form of open source userspace so that we actually have
a proper way to review and test the code.

BR,
-R

> Our (IMG's) preferred approach is to have a single componentised DRM driver. 
> This is due to the following reasons:
>
> - Existing user space is not fully prepared to handle render nodes.
>
> - There is concern that any IMG DRM render node driver will need knowledge 
> about multiple SoCs, each one being from a different vendor. Would this be 
> deemed acceptable?
>
> - There is a trend, at least for DRM SoC drivers, towards using the component 
> interface. Although there appears to be very few (one?) examples of GPU 
> component drivers.
>
> To give some high level details on how we expect the componentised DRM driver 
> model to work, each vendor (in this case Mediatek) will write their own DRM 
> driver (supporting modesetting, dumb buffers, GEM, prime, etc) and IMG will 
> provide an almost entirely independent component driver that adds in GPU 
> support. Until our GPU driver is in a suitable
> state this will most likely necessitate a small kernel patch to wire up 
> support, e.g. GPU specific ioctls.
>
> Cross-device and cross-process memory allocations will be made using the DRM 
> driver. In order for this memory to be shared with the GPU component driver 
> it will be necessary, at least for the time being, to export it via prime and 
> import it via a GPU ioctl. Synchronisation between the display and GPU will 
> be performed via reservation objects.
>
> Does this sound like a sane approach? Questions and/or feedback is very 
> welcome.
>
> Thanks
> Frank
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls

[Rob Clark]

btw, I have these two queued up on msm-next, thanks

BR,
-R

On Tue, Nov 25, 2014 at 8:33 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Tue, 25 Nov 2014 14:30:28 +0100
>
> The functions framebuffer_release() and vunmap() perform also input
> parameter validation. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
>  drivers/gpu/drm/msm/msm_gem.c   | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
> index ab5bfd2..fd5a6f3 100644
> --- a/drivers/gpu/drm/msm/msm_fbdev.c
> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
> @@ -193,8 +193,7 @@ fail_unlock:
>  fail:
>
> if (ret) {
> -   if (fbi)
> -   framebuffer_release(fbi);
> +   framebuffer_release(fbi);
> if (fb) {
> drm_framebuffer_unregister_private(fb);
> drm_framebuffer_remove(fb);
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 4b1b82a..157cf21 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -543,8 +543,7 @@ void msm_gem_free_object(struct drm_gem_object *obj)
> drm_free_large(msm_obj->pages);
>
> } else {
> -   if (msm_obj->vaddr)
> -   vunmap(msm_obj->vaddr);
> +   vunmap(msm_obj->vaddr);
> put_pages(obj);
> }
>
> --
> 2.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls

[Rob Clark]

On Mon, Dec 1, 2014 at 11:04 AM, Thierry Reding
 wrote:
> On Tue, Nov 25, 2014 at 02:33:53PM +0100, SF Markus Elfring wrote:
>> From: Markus Elfring 
>> Date: Tue, 25 Nov 2014 14:30:28 +0100
>>
>> The functions framebuffer_release() and vunmap() perform also input
>> parameter validation. Thus the test around the call is not needed.
>>
>> This issue was detected by using the Coccinelle software.
>>
>> Signed-off-by: Markus Elfring 
>> ---
>>  drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
>>  drivers/gpu/drm/msm/msm_gem.c   | 3 +--
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>
> This needs the same fix for the subject prefix that I mentioned for your
> other patch, otherwise:
>
> Reviewed-by: Thierry Reding 
>
> Perhaps a good idea would be to send all of these patches with the
> subject prefix fixed up as a second version and threaded in a series.
> That makes it easier for people to pick them up (assuming Dave will take
> them directly).
>

no worries, I'll fix up the subject lines when I apply..

BR,
-R

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

[PATCH 0/2] drm: tda998x: Fix a couple of problems

[Russell King - ARM Linux]

On Sat, Nov 29, 2014 at 09:12:51AM +0100, Jean-Francois Moine wrote:
> 1)
> The HDMI registers of the tda998x chips are accessed by pages.
> As these HDMI registers may be accessed from different tasks
> (video, irq/workqueue, and soon audio), the page register setting
> must be protected.
> 
> 2)
> On HDMI reconnect (cable plug-in), the EDID is read too early and
> this raises a EDID read timeout. Delaying a bit the connect event
> fixes the problem.

Both patches applied, thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

RFC on upstreaming of a Mediatek DRM modesetting driver

[Jerome Glisse]

On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote:
> Hi,
> 
> We are currently in negotiations with one of our customers (Mediatek) on a
> strategy that will allow them to push a DRM modesetting driver into the
> upstream kernel. We are writing to get people's opinions and feedback on
> our proposed approach.
> 
> Currently, our driver is structured in such a way that the display driver
> is more tightly integrated with the GPU driver than we would like. Although
> our kernel driver has been shipped with a GPL license for a long time, it
> is not in a form that would be considered acceptable upstream. Unfortunately,
> it is going to be a long process to get this part of the driver into a
> reasonable state. However, in the meantime, we don't want to prevent customer
> portions of the driver from being upstreamed. With the work done on recent
> kernels, and with a willing partner in Mediatek, we now think that we can
> restructure our driver in such a way as to allow this to happen.
> 
> We see two basic approaches to achieving this:
> 1) Two independent DRM drivers, i.e. modesetting and render node drivers
> 2) A single componentised DRM driver
> 
> Our (IMG's) preferred approach is to have a single componentised DRM driver.
> This is due to the following reasons:
> 
> - Existing user space is not fully prepared to handle render nodes.
> 
> - There is concern that any IMG DRM render node driver will need knowledge
>   about multiple SoCs, each one being from a different vendor. Would this
>   be deemed acceptable?
> 
> - There is a trend, at least for DRM SoC drivers, towards using the component
>   interface. Although there appears to be very few (one?) examples of GPU
>   component drivers.
> 
> To give some high level details on how we expect the componentised DRM driver
> model to work, each vendor (in this case Mediatek) will write their own DRM
> driver (supporting modesetting, dumb buffers, GEM, prime, etc) and IMG will
> provide an almost entirely independent component driver that adds in GPU
> support. Until our GPU driver is in a suitable state this will most likely
> necessitate a small kernel patch to wire up support, e.g. GPU specific ioctls.
> 
> Cross-device and cross-process memory allocations will be made using the DRM
> driver. In order for this memory to be shared with the GPU component driver
> it will be necessary, at least for the time being, to export it via prime and
> import it via a GPU ioctl. Synchronisation between the display and GPU will be
> performed via reservation objects.
> 
> Does this sound like a sane approach? Questions and/or feedback is very 
> welcome.

Writting a standalone KMS only drm driver for the whole modesetting side is 
fine.
So is using DMA buffer to export/import buffer btw your KMS driver and your
accel providing driver (two separate standalone driver). As long as you do not 
do
anything as ugly as IMG have done in the past in which they hook up inside each
drm driver and add there own set of ioctl on top.

A side note is that any IMG driver can not be accepted without open source user
space and also a proper design. AFAICT current IMG driver design is unsuited for
upstream given how unsecure it is. My understanding of it is that it's very easy
for userspace to use IMG to read/write to any system memory.

So frankly i do not expect anything on the IMG side to be worth troubling us 
with
as long as there is no open source userspace and proper secure driver design.

Cheers,
Jérôme

> 
> Thanks
> Frank 

RFC on upstreaming of a Mediatek DRM modesetting driver

[Frank Binns]

Hi,

We are currently in negotiations with one of our customers (Mediatek) on a 
strategy that will allow them to push a DRM modesetting driver into the 
upstream kernel. We are writing to get people's opinions and feedback on our 
proposed approach.

Currently, our driver is structured in such a way that the display driver is 
more tightly integrated with the GPU driver than we would like. Although our 
kernel driver has been shipped with a GPL license for a long time, it is not in 
a form that would be considered acceptable upstream. Unfortunately, it is going 
to be a long process to get this part of the driver into a reasonable state. 
However, in the meantime, we don't want to prevent customer portions of the 
driver from being upstreamed. With the work done on recent kernels, and with a 
willing partner in Mediatek, we now think that we can restructure our driver in 
such a way as to allow this to happen.

We see two basic approaches to achieving this:
1) Two independent DRM drivers, i.e. modesetting and render node drivers
2) A single componentised DRM driver

Our (IMG's) preferred approach is to have a single componentised DRM driver. 
This is due to the following reasons:

- Existing user space is not fully prepared to handle render nodes.

- There is concern that any IMG DRM render node driver will need knowledge 
about multiple SoCs, each one being from a different vendor. Would this be 
deemed acceptable?

- There is a trend, at least for DRM SoC drivers, towards using the component 
interface. Although there appears to be very few (one?) examples of GPU 
component drivers.

To give some high level details on how we expect the componentised DRM driver 
model to work, each vendor (in this case Mediatek) will write their own DRM 
driver (supporting modesetting, dumb buffers, GEM, prime, etc) and IMG will 
provide an almost entirely independent component driver that adds in GPU 
support. Until our GPU driver is in a suitable
state this will most likely necessitate a small kernel patch to wire up 
support, e.g. GPU specific ioctls.

Cross-device and cross-process memory allocations will be made using the DRM 
driver. In order for this memory to be shared with the GPU component driver it 
will be necessary, at least for the time being, to export it via prime and 
import it via a GPU ioctl. Synchronisation between the display and GPU will be 
performed via reservation objects.

Does this sound like a sane approach? Questions and/or feedback is very welcome.

Thanks
Frank 

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris Brezillon 
---
Hi,

Sorry for the noise: I ran checkpatch after sending the series and it found
a typo and two "line over 80 characters" warnings.

This version fixes those warnings.

Regards,

Boris

 drivers/gpu/drm/drm_crtc.c | 33 +
 include/drm/drm_crtc.h |  8 
 2 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..20030ec 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -763,6 +763,39 @@ static void drm_mode_remove(struct drm_connector 
*connector,
drm_mode_destroy(connector->dev, mode);
 }

+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the supported bus formats in display info structure.
+ * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
+ * a full list of available formats.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info,
+const u32 *fmts,
+unsigned int num_fmts)
+{
+   u32 *formats = NULL;
+
+   if (!fmts && num_fmts)
+   return -EINVAL;
+
+   if (fmts && num_fmts) {
+   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+   if (!formats)
+   return -ENOMEM;
+   }
+
+   kfree(info->bus_formats);
+   info->bus_formats = formats;
+   info->num_bus_formats = num_fmts;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
 /**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..65dd08a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;

+   const u32 *bus_formats;
+   unsigned int num_bus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;

@@ -982,6 +986,10 @@ extern int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);

+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+   const u32 *fmts,
+   unsigned int nfmts);
+
 static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
 {
-- 
1.9.1

[Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup bridge for VED

[Daniel Vetter]

On Mon, Dec 01, 2014 at 03:04:27AM +, Cheng, Yao wrote:
> > -Original Message-
> > From: Beckett, Robert
> > Sent: Saturday, November 29, 2014 0:59
> > To: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri-
> > devel at lists.freedesktop.org; daniel.vetter at ffwll.ch; Kelley, Sean V; 
> > Chehab,
> > John
> > Cc: emil.l.velikov at gmail.com; Jiang, Fei; dh.herrmann at gmail.com;
> > daniel at fooishbar.org
> > Subject: Re: [Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to 
> > setup
> > bridge for VED
> > > + * Threats:
> > > + * Due to the restriction in Linux platform device model, user need
> > > +manually
> > > + * uninstall ipvr driver before uninstalling i915 module, otherwise
> > > +he might
> > > + * run into use-after-free issues after i915 removes the platform device.
> > 
> > Can you go in to more detail on what you consider to be the restriction in 
> > the
> > platform device model?
> > 
> > When removing the device via platform_device_unregister, it will call the
> > remove callback of any drivers handling this device (via the bus remove
> > function). It is then up to the driver to ensure no further usage of the 
> > device
> > from which it is being removed. This usually involves removing all user 
> > input
> > vectors, disabling interrupts involved and flushing/canceling any delayed
> > work. This should prevent any further use of the device by the driver.
> > 
> > The driver's remove function is called in a direct call chain from
> > platform_device_unregister, so by the time it returns, there should be no
> > further chance of accesses.
> >
> 
> Bob, thx for your review comments.
> The symptom is, after "rmmod i915", though drm_drv_release() is also
> called on the child device "ipvr", I still see the module exist in the
> system (check it by "lsmod"). This causes issue when I modprobe i915 and
> ipvr again later. Actually I don't understand why this restriction
> exists, but accroding to Daniel, grabbing a module refcount for the
> platform device doesn't work (it would pin the module forever).

Btw this entire story with platform drivers make unload a mess was just a
best guess from my side why module unloading doesn't work well or could
blow up. I've thought platform drivers registered from modules are
inheritely racy, but I'll be very happy to learn that this is a
misunderstanding on my side ;-)

Wrt the testcase I'm fairly pragmatic though: Whatever makes it work
reliably is good enough for me, even if it's a gross hack (we already need
to manually kick fbcon anyway).
Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v4 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

[Boris Brezillon]

Foxlink's fl500wvr00-a0t supports RGB888 format.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 66838a5..695f406 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.width = 108,
.height = 65,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

 static const struct drm_display_mode innolux_n116bge_mode = {
-- 
1.9.1

[PATCH v4 2/3] drm: panel: simple-panel: add support for bus_format retrieval

[Boris Brezillon]

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 23de22f..66838a5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -61,6 +61,8 @@ struct panel_desc {
unsigned int disable;
unsigned int unprepare;
} delay;
+
+   u32 bus_format;
 };

 struct panel_simple {
@@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
connector->display_info.bpc = panel->desc->bpc;
connector->display_info.width_mm = panel->desc->size.width;
connector->display_info.height_mm = panel->desc->size.height;
+   if (panel->desc->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+>desc->bus_format, 1);

return num;
 }
-- 
1.9.1

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_crtc.c | 32 
 include/drm/drm_crtc.h |  7 +++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..d3b7ed0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector 
*connector,
drm_mode_destroy(connector->dev, mode);
 }

+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
+ * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
+ * a full list of available formats.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info, const u32 
*fmts,
+unsigned int num_fmts)
+{
+   u32 *formats = NULL;
+
+   if (!fmts && num_fmts)
+   return -EINVAL;
+
+   if (fmts && num_fmts) {
+   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+   if (!formats)
+   return -ENOMEM;
+   }
+
+   kfree(info->bus_formats);
+   info->bus_formats = formats;
+   info->num_bus_formats = num_fmts;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
 /**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..a35844f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;

+   const u32 *bus_formats;
+   unsigned int num_bus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;

@@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);

+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+   const u32 *fmts, unsigned int 
nfmts);
+
 static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
 {
-- 
1.9.1

[PATCH v4 0/3] drm: describe display bus format

[Boris Brezillon]

Hello,

This series makes use of the MEDIA_BUS_FMT definition to describe how
the data are transmitted to the display.

This will allow drivers to configure their output display bus according
to the display capabilities.
For example some display controllers support DPI (or raw RGB) connectors
and need to specify which format will be transmitted on the DPI bus
(RGB444, RGB565, RGB888, ...).

This series also adds a field to the panel_desc struct so that one
can specify which format is natevely supported by a panel.

Regards,

Boris

Changes since v3:
 - store num_bus_formats on an unsigned int
 - clearly state that fmts argument (in drm_display_info_set_bus_formats
   function) should be an array of MEDIA_BUS_FMT_* values.

Changes since v2:
 - use the MEDIA_BUS_FMT macros

Changes since v1:
 - rename nformats into num_formats
 - declare num_formats as an unsigned int

Boris Brezillon (3):
  drm: add bus_formats and num_bus_formats fields to drm_display_info
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: panel: simple-panel: add bus format information for foxlink panel

 drivers/gpu/drm/drm_crtc.c   | 32 
 drivers/gpu/drm/panel/panel-simple.c |  6 ++
 include/drm/drm_crtc.h   |  7 +++
 3 files changed, 45 insertions(+)

-- 
1.9.1

[PATCH v4 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

[Boris Brezillon]

Foxlink's fl500wvr00-a0t supports RGB888 format.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 66838a5..695f406 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -545,6 +545,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.width = 108,
.height = 65,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

 static const struct drm_display_mode innolux_n116bge_mode = {
-- 
1.9.1

[PATCH v4 2/3] drm: panel: simple-panel: add support for bus_format retrieval

[Boris Brezillon]

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 23de22f..66838a5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -61,6 +61,8 @@ struct panel_desc {
unsigned int disable;
unsigned int unprepare;
} delay;
+
+   u32 bus_format;
 };

 struct panel_simple {
@@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
connector->display_info.bpc = panel->desc->bpc;
connector->display_info.width_mm = panel->desc->size.width;
connector->display_info.height_mm = panel->desc->size.height;
+   if (panel->desc->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+>desc->bus_format, 1);

return num;
 }
-- 
1.9.1

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_crtc.c | 32 
 include/drm/drm_crtc.h |  7 +++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..d3b7ed0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -763,6 +763,38 @@ static void drm_mode_remove(struct drm_connector 
*connector,
drm_mode_destroy(connector->dev, mode);
 }

+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
+ * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
+ * a full list of available formats.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info, const u32 
*fmts,
+unsigned int num_fmts)
+{
+   u32 *formats = NULL;
+
+   if (!fmts && num_fmts)
+   return -EINVAL;
+
+   if (fmts && num_fmts) {
+   formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+   if (!formats)
+   return -ENOMEM;
+   }
+
+   kfree(info->bus_formats);
+   info->bus_formats = formats;
+   info->num_bus_formats = num_fmts;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
 /**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..a35844f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;

+   const u32 *bus_formats;
+   unsigned int num_bus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;

@@ -982,6 +986,9 @@ extern int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);

+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+   const u32 *fmts, unsigned int 
nfmts);
+
 static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
 {
-- 
1.9.1

[PATCH v4 0/3] drm: describe display bus format

[Boris Brezillon]

Hello,

This series makes use of the MEDIA_BUS_FMT definition to describe how
the data are transmitted to the display.

This will allow drivers to configure their output display bus according
to the display capabilities.
For example some display controllers support DPI (or raw RGB) connectors
and need to specify which format will be transmitted on the DPI bus
(RGB444, RGB565, RGB888, ...).

This series also adds a field to the panel_desc struct so that one
can specify which format is natevely supported by a panel.

Regards,

Boris

Changes since v3:
 - store num_bus_formats on an unsigned int
 - clearly state that fmts argument (in drm_display_info_set_bus_formats
   function) should be an array of MEDIA_BUS_FMT_* values.

Changes since v2:
 - use the MEDIA_BUS_FMT macros

Changes since v1:
 - rename nformats into num_formats
 - declare num_formats as an unsigned int

Boris Brezillon (3):
  drm: add bus_formats and num_bus_formats fields to drm_display_info
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: panel: simple-panel: add bus format information for foxlink panel

 drivers/gpu/drm/drm_crtc.c   | 32 
 drivers/gpu/drm/panel/panel-simple.c |  6 ++
 include/drm/drm_crtc.h   |  7 +++
 3 files changed, 45 insertions(+)

-- 
1.9.1

[Bug 88541] Resume of HDMI port fails

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

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

Aaron Lu  changed:

   What|Removed |Added

 CC||aaron.lu at intel.com
  Component|Hibernation/Suspend |Video(DRI - non Intel)
   Assignee|rjw at rjwysocki.net   |drivers_video-dri at 
kernel-bu
   ||gs.osdl.org
Product|Power Management|Drivers

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

RFC on upstreaming of a Mediatek DRM modesetting driver

[Alberto Martin]

+Puneet,+Zel

We will get back to you guys with answers soon.
On Dec 1, 2014 9:28 AM, "Daniel Vetter"  wrote:

> On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote:
> > Hi,
> >
> > We are currently in negotiations with one of our customers (Mediatek) on
> > a strategy that will allow them to push a DRM modesetting driver into
> > the upstream kernel. We are writing to get people's opinions and
> > feedback on our proposed approach.
> >
> > Currently, our driver is structured in such a way that the display
> > driver is more tightly integrated with the GPU driver than we would
> > like. Although our kernel driver has been shipped with a GPL license for
> > a long time, it is not in a form that would be considered acceptable
> > upstream. Unfortunately, it is going to be a long process to get this
> > part of the driver into a reasonable state. However, in the meantime, we
> > don't want to prevent customer portions of the driver from being
> > upstreamed. With the work done on recent kernels, and with a willing
> > partner in Mediatek, we now think that we can restructure our driver in
> > such a way as to allow this to happen.
> >
> > We see two basic approaches to achieving this:
> > 1) Two independent DRM drivers, i.e. modesetting and render node drivers
> > 2) A single componentised DRM driver
> >
> > Our (IMG's) preferred approach is to have a single componentised DRM
> > driver. This is due to the following reasons:
> >
> > - Existing user space is not fully prepared to handle render nodes.
> >
> > - There is concern that any IMG DRM render node driver will need
> > knowledge about multiple SoCs, each one being from a different vendor.
> > Would this be deemed acceptable?
> >
> > - There is a trend, at least for DRM SoC drivers, towards using the
> > component interface. Although there appears to be very few (one?)
> > examples of GPU component drivers.
> >
> > To give some high level details on how we expect the componentised DRM
> > driver model to work, each vendor (in this case Mediatek) will write
> > their own DRM driver (supporting modesetting, dumb buffers, GEM, prime,
> > etc) and IMG will provide an almost entirely independent component
> > driver that adds in GPU support. Until our GPU driver is in a suitable
> > state this will most likely necessitate a small kernel patch to wire up
> > support, e.g. GPU specific ioctls.
> >
> > Cross-device and cross-process memory allocations will be made using the
> > DRM driver. In order for this memory to be shared with the GPU component
> > driver it will be necessary, at least for the time being, to export it
> > via prime and import it via a GPU ioctl. Synchronisation between the
> > display and GPU will be performed via reservation objects.
> >
> > Does this sound like a sane approach? Questions and/or feedback is very
> > welcome.
>
> Rule of thumb is that if it's an externally licensed IP block it should be
> a separate driver. Which is the case here. The idea is that the mostly
> generic IMG driver could be reused on other platforms that ship the same
> IP-block, while linking up with the respective display controller driver.
> The end result is 2 drm drivers:
> - Display block drm driver which expose KMS objects for modesetting, but
>   only very basic gem (just enough to allocate dumb framebuffers and
>   import/export dma-bufs).
> - Full-blown gem driver for the img render IP block.
>
> For an example look at the tegra/nouveau combo which can run on TK1.
>
> Plugggin in an IMG driver into each display block like it's currently done
> with all the armsoc stuff on android is imo completely no-go.
>
> Note that the component interface is completely irrelevant wrt the
> interface you expose to userspace. It's just an driver-internal helper
> library useful in certain situation. Not even the drm core really cares
> whether you use component helpers or not.
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/57b1e1c6/attachment-0001.html>

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #58 from Chernovsky Oleg  ---
Another observation:
I've uncommented  ci_fan_ctrl_set_fan_speed_percent and tried to bind it to
hwmon interface.

So, if I try to set static value to the fan, then I see 0x50CB1435 in
CG_FDO_CTRL2 and the fan runs 100% percent always, regardless of values I'm
echoing

But if I push 0x50CB0C00 to the CG_FDO_CTRL2 instead of trusting 
ci_fan_ctrl_set_static_mode, it begins to react on values I echoed.

Can you elaborate on what each bit of this control register means? Maybe I just
can't into abbreviations :)

-- 
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/20141201/2aa5b68f/attachment.html>

[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games

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

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

--- Comment #10 from Shawn Starr  ---
Created attachment 110280
  --> https://bugs.freedesktop.org/attachment.cgi?id=110280=edit
Running threads listed

-- 
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/20141201/1c07ba83/attachment-0001.html>

[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen

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

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

--- Comment #3 from Michel Dänzer  ---
What version of Mesa are you using?

-- 
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/20141201/a2496892/attachment.html>

[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games

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

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

--- Comment #9 from Michel Dänzer  ---
Unfortunately, the r600g helper thread doesn't set a distinctive thread name.
Please attach (as opposed to paste) the output of 'thread apply all bt' in gdb
when setting RADEON_THREAD=0.

-- 
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/20141201/329c8ff1/attachment.html>

[Bug 86011] [drm] "Memory manager not clean during takedown" after vga-switcheroo turn off nvidia card

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

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

--- Comment #5 from Joaquín Aramendía  ---
Created attachment 159291
  --> https://bugzilla.kernel.org/attachment.cgi?id=159291=edit
fix for runtime power management in nouveau

I made this patch that fixed the issue for me. Applies on top of commit
a4c5f39. Should apply with offset to newer kernels but fine.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.

[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games

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

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

--- Comment #8 from Shawn Starr  ---
With the environment variable set prior to X (in .bashrc). Running game with
gdb still locks up GPU.

No crash in game reported (break within gdb):

here is threads:


(gdb) info threads
  Id   Target Id Frame
  14   Thread 0x7fffe0602700 (LWP 1625) "do-not-directly" 0x0037a5cc491d in
nanosleep () from /lib64/libc.so.6
  13   Thread 0x7000f700 (LWP 1624) "do-not-directly" 0x0037a640c578 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  12   Thread 0x7fffe0e03700 (LWP 1623) "threaded-ml" 0x0037a5cf51dd in
poll () from /lib64/libc.so.6
  11   Thread 0x7fffc23a4700 (LWP 1621) "gdbus" 0x0037a5cf51dd in poll ()
from /lib64/libc.so.6
  10   Thread 0x7fffc2ba5700 (LWP 1620) "do-not-directly" 0x0037a5d00d83 in
epoll_wait () from /lib64/libc.so.6
  9Thread 0x7fffe27fc700 (LWP 1615) "do-not-directly" 0x0037a640c590 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  8Thread 0x7fffe2ffd700 (LWP 1614) "do-not-directly" 0x0037a640c590 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  7Thread 0x7fffe37fe700 (LWP 1613) "do-not-directly" 0x0037a640c590 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  6Thread 0x7fffe3fff700 (LWP 1612) "do-not-directly" 0x0037a640c590 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  5Thread 0x70b46700 (LWP 1611) "do-not-directly" 0x0037a640c590 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  4Thread 0x71347700 (LWP 1610) "do-not-directly" 0x0037a640f8fd in
nanosleep () from /lib64/libpthread.so.0
  3Thread 0x71b48700 (LWP 1609) "do-not-directly" 0x0037a640c590 in
pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
  2Thread 0x72403700 (LWP 1583) "do-not-directly" 0x0037a640f8fd in
nanosleep () from /lib64/libpthread.so.0
* 1Thread 0x7270aa00 (LWP 1579) "do-not-directly" 0x0037a640f8fd in
nanosleep () from /lib64/libpthread.so.0

-- 
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/20141201/a92bc6e5/attachment-0001.html>

[RFC] drm: Start documenting userspace ABI

[Laurent Pinchart]

On Wednesday 19 November 2014 14:23:47 Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote:
> > On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> > > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding wrote:
> > > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> > > >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > > >> > From: Thierry Reding 
> > > >> > 
> > > >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented
> > > >> > with different semantics on different drivers it seems like a good
> > > >> > idea to start to more rigorously document userspace ABI to avoid
> > > >> > these things in the future.
> > > >> > 
> > > >> > This is a first draft of what such documentation could look like.
> > > >> > Not all IOCTLs are documented and some explanation about the other
> > > >> > system calls (mmap(), poll(), read(), ...) would be good too. But I
> > > >> > wanted to send this out for early review to see if the direction is
> > > >> > reasonable. If so my plan is to continue to chip away at this as I
> > > >> > find time.
> > > >> > 
> > > >> > Signed-off-by: Thierry Reding 
> > > >> 
> > > >> Imo for ioctls the right thing to do is having proper manpages, not
> > > >> kerneldoc or DocBook sections. manpages really lend themselves well
> > > >> to specify all the different facets of a single interface.
> > > > 
> > > > I don't think I've ever seen manpages document IOCTLs at this level of
> > > > detail. The intention of this is to add documentation about the IOCTLs
> > > > at the kernel/userspace transition. Keeping this in the kernel has the
> > > > advantage that it's a whole lot easier to keep updated, much like what
> > > > we do with the other kerneldoc.
> > > > 
> > > > That doesn't mean we shouldn't have manpages, but I think both are for
> > > > the most part orthogonal, even though they may describe various facets
> > > > of the same interfaces.
> > > 
> > > tty_ioctl(4)
> > > console_ioctl(4)
> > > 
> > > I think a similar man-page ala drm_ioctl(4) makes a lot of sense.

The DRM API is much more complex, I think it deserves one page per ioctl.

> > > >> Also, we already have some skeleton of that in libdrm, so I think
> > > >> extending that would be best.
> > > > 
> > > > One other reason why I don't think libdrm is the best fit for this is
> > > > that libdrm is just one userspace implementation abstracting away the
> > > > interfaces that this describes. Not everyone will use libdrm. So in my
> > > > opinion its great if libdrm documents the API that it exposes, but I
> > > > don't think it should document the kernel interfaces that it uses. The
> > > > kernel exposes them, so it should provide the documentation for it as
> > > > well.
> > > 
> > > I don't mind documenting this in the kernel-doc. But if we start
> > > something like drm_ioctl(4) (I pushed some more generic man-pages to
> > > libdrm a few years ago), we have this documented in 2 places, which is
> > > always annoying for updates.
> > 
> > I wonder if it would somehow be possible to generate manpages from the
> > DocBook to avoid this duplication.

I'm pretty sure that should be possible. DocBook has appropriate markup to 
document functions in a manpage-like manner, see 
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-reqbufs.html for instance.

> > One of the things that DRM_IOCTL_MODE_CREATE_DUMB showed is that both
> > drivers and userspace can interpret things wrongly, and I fear that if all
> > we have is a manpage to document the IOCTLs, people writing the drivers
> > may not be tempted enough to read that manpage. So I think we want
> > documentation for both driver and userspace developers.
> 
> Imo docs don't help with that kind of fumble, only nasty testcases will.
> People only read docs when they don't understand stuff (i.e. trying to
> write drivers). Imo manpages an ioctl docs are only really good for
> designing the interface (since it forces you to really think through the
> semantics to be able to describe them concisely and precisely). But even
> there I think having solid testcases is better invested time.
> 
> Documentation for developers is imo an entirely different matter, I think
> that gets used a lot more. Or at least I find them fairly useful.

I think both are useful. From my personal experience proper detailed ioctl 
documentation helps a lots when writing kernel drivers. Even in the case of 
the DRM subsystem where various helper functions push the driver away from the 
ioctl API, proper documentation of the structures passed by userspace is very 
helpful for driver developers.  Not to mention of course that the 
documentation helps getting the helpers right.

Test cases are also invaluable. I've seen both test cases being used to fix 
drivers and documentation, clarifying the API as they get developed. 
Implementing a test case is a very good way to test the maturity of an API.

> > Documenting 

[RFC PATCH v3 3/4] ipvr: user mode helper for ipvr drm driver

[Cheng, Yao]

Add Jon/Bob/Raf for detail review.
> -Original Message-
> From: Cheng, Yao
> Sent: Saturday, November 22, 2014 3:09
> To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> daniel.vetter at ffwll.ch; Kelley, Sean V; Chehab, John
> Cc: Jiang, Fei; dh.herrmann at gmail.com; jani.nikula at linux.intel.com;
> emil.l.velikov at gmail.com; ville.syrjala at linux.intel.com;
> jbarnes at virtuousgeek.org; daniel at fooishbar.org; Cheng, Yao
> Subject: [RFC PATCH v3 3/4] ipvr: user mode helper for ipvr drm driver
> 
> add usermode helper for the ipvr kernel driver.
> test_ioctl: test kernel driver by directly ioctl
> 
> v2:
> take Emil's comments
>   - correctly align ipvr_drm.h
> 
> v3:
> take Daniel Vetter and Daniel Stone's comments, and implement PRIME
>   - correctly align ipvr_drm.h
>   - use __u32 family in ipvr_drm.h
>   - rip out explicit fence from libdrm_ipvr
>   - implemented PRIME support
>   - add relocation fixup implementation
> 
> Signed-off-by: Yao Cheng 
> ---
>  Makefile.am|6 +-
>  Makefile.sources   |1 +
>  configure.ac   |   26 +-
>  include/drm/ipvr_drm.h |  278 +++
>  ipvr/Makefile.am   |   57 +++
>  ipvr/Makefile.sources  |5 +
>  ipvr/ipvr_bufmgr.h |  149 ++
>  ipvr/ipvr_bufmgr_gem.c | 1200
> 
>  ipvr/libdrm_ipvr.pc.in |   11 +
>  ipvr/test_ioctl.c  |  423 +
>  10 files changed, 2154 insertions(+), 2 deletions(-)
>  create mode 100644 include/drm/ipvr_drm.h
>  create mode 100644 ipvr/Makefile.am
>  create mode 100644 ipvr/Makefile.sources
>  create mode 100644 ipvr/ipvr_bufmgr.h
>  create mode 100644 ipvr/ipvr_bufmgr_gem.c
>  create mode 100644 ipvr/libdrm_ipvr.pc.in
>  create mode 100644 ipvr/test_ioctl.c
> 
> diff --git a/Makefile.am b/Makefile.am
> index 3952a88..2227add 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -33,6 +33,10 @@ if HAVE_INTEL
>  INTEL_SUBDIR = intel
>  endif
> 
> +if HAVE_IPVR
> +IPVR_SUBDIR = ipvr
> +endif
> +
>  if HAVE_NOUVEAU
>  NOUVEAU_SUBDIR = nouveau
>  endif
> @@ -53,7 +57,7 @@ if HAVE_FREEDRENO
>  FREEDRENO_SUBDIR = freedreno
>  endif
> 
> -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR)
> $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR)
> $(FREEDRENO_SUBDIR) tests man
> +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(IPVR_SUBDIR)
> $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR)
> $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests man
> 
>  libdrm_la_LTLIBRARIES = libdrm.la
>  libdrm_ladir = $(libdir)
> diff --git a/Makefile.sources b/Makefile.sources
> index d86fb2a..96f8c60 100644
> --- a/Makefile.sources
> +++ b/Makefile.sources
> @@ -18,6 +18,7 @@ LIBDRM_INCLUDE_H_FILES := \
>   include/drm/drm_mode.h \
>   include/drm/drm_sarea.h \
>   include/drm/i915_drm.h \
> + include/drm/ipvr_drm.h \
>   include/drm/mach64_drm.h \
>   include/drm/mga_drm.h \
>   include/drm/nouveau_drm.h \
> diff --git a/configure.ac b/configure.ac
> index ee59b03..6dcf1b2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -68,6 +68,11 @@ AC_ARG_ENABLE(intel,
> [Enable support for intel's KMS API (default: auto)]),
> [INTEL=$enableval], [INTEL=auto])
> 
> +AC_ARG_ENABLE(ipvr,
> +   AS_HELP_STRING([--disable-ipvr],
> +   [Enable support for baytrail's hardware VP8 decode (default:
> auto)]),
> +   [IPVR=$enableval], [IPVR=auto])
> +
>  AC_ARG_ENABLE(radeon,
> AS_HELP_STRING([--disable-radeon],
> [Enable support for radeon's KMS API (default: auto)]),
> @@ -204,7 +209,7 @@ if test "x$drm_cv_atomic_primitives" = "xlibatomic-
> ops"; then
>   AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have
> libatomic-ops-dev installed])
>  fi
> 
> -if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" !=
> "xno"; then
> +if test "x$INTEL" != "xno" -o "x$IPVR" != "xno" -o "x$RADEON" != "xno" -o
> "x$NOUVEAU" != "xno"; then
>   if test "x$drm_cv_atomic_primitives" = "xnone"; then
>   if test "x$INTEL" != "xauto"; then
>   if test "x$INTEL" != "xno"; then
> @@ -214,6 +219,14 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o
> "x$NOUVEAU" != "xno"; then
>   AC_MSG_WARN([Disabling libdrm_intel. It depends
> on atomic operations, which were not found for your compiler/cpu. Try
> compiling with -march=native, or install the libatomics-op-dev package.])
>   INTEL=no
>   fi
> + if test "x$IPVR" != "xauto"; then
> + if test "x$IPVR" != "xno"; then
> + AC_MSG_ERROR([libdrm_ipvr depends upon
> atomic operations, which were not found for your compiler/cpu. Try
> compiling with -march=native, or install the libatomics-op-dev package, or,
> failing both of those, disable support for Baytrail VP8 by passing 
> --disable-ipvr
> to ./configure])
> +