[PATCH v4 02/15] drm: bridge/dw_hdmi: wrap irq control in fucntions

[yakir]

Hi Philipp,

On 2015年03月12日 22:41, Philipp Zabel wrote:
> Hi Yakir,
>
> Am Donnerstag, den 12.03.2015, 22:31 +0800 schrieb yakir:
>> Hi Philipp,
>>
>> On 2015年03月12日 18:24, Philipp Zabel wrote:
>>> Hi Yakir,
>>>
>>> Am Samstag, den 28.02.2015, 21:28 -0500 schrieb Yakir Yang:
>>>> Wrap irq control in functions, and then we can call in
>>>> dw_hdmi_bind/dw_hdmi_unbind/dw_hdmi_resume/dw_hdmi_suspend
>>>> functions.
>>>>
>>>> Signed-off-by: Yakir Yang 
>>> [...]
>> Sorry, I can not understand this comment. could you please talk more
>> detail about this one.
>>
>> Thank you very much  :)
> I use "[...]" as a sign that I removed parts from the quoted email, like
> this:
>
> [...]

Okay, thanks for your explanation  :)

>>> Here you remove code added in the previous patch.
>>> It would be better to just apply patch 2 first and then rebase patch 1
>>> on top of it.
>> Thanks,  I will reorder patch 1 & patch 2, in next vesion   :)
> regards
> Philipp
>
regards :)
Yakir
>
>

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

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 4:02 AM, John Hunter  wrote:
> From: John Hunter 
>
> IMHO, some annotations were copypaste from somewhere else, it is
> obviously not rightly modified. Hope I am right with that.
> ---
>  drivers/gpu/drm/drm_crtc.c | 115 
> ++---
>  1 file changed, 56 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f2d667b..7f771e9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum 
> drm_connector_status status)
>  /**
>   * drm_mode_object_get - allocate a new identifier
>   * @dev: DRM device
> - * @ptr: object pointer, used to generate unique ID
> - * @type: object type
> + * @obj: object pointer, used to generate unique ID
> + * @obj_type: object type
>   *
>   * LOCKING:
>   *
> - * Create a unique identifier based on @ptr in @dev's identifier space.  Used
> + * Create a unique identifier based on @obj in @dev's identifier space.  Used
>   * for tracking modes, CRTCs and connectors.

so, I don't suppose you can rebase against a newer upstream kernel?

>From a quick look, it seems like the arg name errors where corrected
in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
bodies fixes from your patch are still applicable.  In the current
form, the patch does not apply against drm-next (or latest linux
master), but most of it is still applicable and would be a very
welcome improvement.

Thanks :-)

BR,
-R


>   *
>   * RETURNS:
> @@ -245,12 +245,12 @@ again:
>  /**
>   * drm_mode_object_put - free an identifer
>   * @dev: DRM device
> - * @id: ID to free
> + * @object: object to free
>   *
>   * LOCKING:
>   * Caller must hold DRM mode_config lock.
>   *
> - * Free @id from @dev's unique identifier pool.
> + * Free @object from @dev's unique identifier pool.
>   */
>  static void drm_mode_object_put(struct drm_device *dev,
> struct drm_mode_object *object)
> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
> struct drm_device *dev = fb->dev;
> +
> /*
>  * This could be moved to drm_framebuffer_remove(), but for
>  * debugging is nice to keep around the list of fb's that are
> -* no longer associated w/ a drm_file but are not unreferenced
> +* no longer associated with a drm_file but are not unreferenced
>  * yet.  (i915 and omapdrm have debugfs files which will show
>  * this.)
>  */
> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
>   * @dev: DRM device
>   * @connector: the connector to init
>   * @funcs: callbacks for this connector
> - * @name: user visible name of the connector
> + * @connector_type: type of the connector
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct 
> drm_plane *plane,
> plane->format_count = format_count;
> plane->possible_crtcs = possible_crtcs;
>
> -   /* private planes are not exposed to userspace, but depending on
> +   /*
> +* private planes are not exposed to userspace, but depending on
>  * display hardware, might be convenient to allow sharing programming
>  * for the scanout engine with the crtc implementation.
>  */
> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct 
> drm_display_mode *out,
>
>  /**
>   * drm_mode_getresources - get graphics configuration
> - * @inode: inode from the ioctl
> - * @filp: file * from the ioctl
> - * @cmd: cmd from ioctl
> - * @arg: arg from ioctl
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
> list_for_each(lh, >mode_config.encoder_list)
> encoder_count++;
> } else {
> -
> crtc_count = mode_group->num_crtcs;
> connector_count = mode_group->num_connectors;
> encoder_count = mode_group->num_encoders;
> @@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
> }
> copied++;
> }
> -
> }
> }
> card_res->count_encoders = encoder_count;
> @@ -1376,10 +1375,9 @@ out:
>
>  /**
>   * drm_mode_getcrtc - get CRTC configuration
> - * @inode: inode from the ioctl
> - * @filp: file * from the ioctl
> - * @cmd: cmd from ioctl
> - * @arg: arg from ioctl
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -1421,10 +1419,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
> crtc_resp->fb_id = 0;
>
>  

[PATCH v4 04/15] drm: bridge/dw_hdmi: add identification registers parse and record

[yakir]

Hi philipp,

On 2015年03月12日 18:29, Philipp Zabel wrote:
> Am Samstag, den 28.02.2015, 21:35 -0500 schrieb Yakir Yang:
>> By parsing the identification registers we can know what functions
>> are present on the hdmi ip.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v4:
>> -Correct phy_type assignment bug
>>
>> Changes in v3:
>> - Add ID registers parse and record
>>
>> Changes in v2: None
>>
>>   drivers/gpu/drm/bridge/dw_hdmi.c | 59 
>> 
>>   drivers/gpu/drm/bridge/dw_hdmi.h | 23 
>>   2 files changed, 82 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
>> b/drivers/gpu/drm/bridge/dw_hdmi.c
>> index 08f10da..937beed 100644
>> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
>> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
>> @@ -79,6 +79,23 @@ static const u16 csc_coeff_rgb_in_eitu709[3][4] = {
>>  { 0x6756, 0x78ab, 0x2000, 0x0200 }
>>   };
>>   
>> +struct hdmi_id {
>> +u8 design;
>> +u8 revision;
>> +
>> +bool prepen;
>> +bool audspdif;
>> +bool audi2s;
>> +bool hdmi14;
>> +bool csc;
>> +bool hdcp;
>> +bool hdmi20;
>> +bool confapb;
>> +bool ahbauddma;
>> +bool gpaud;
>> +u8 phy_type;
>> +};
>>
>>   struct hdmi_vmode {
>>  bool mdvi;
>>  bool mhsyncpolarity;
>> @@ -111,6 +128,8 @@ struct dw_hdmi {
>>  struct clk *isfr_clk;
>>  struct clk *iahb_clk;
>>   
>> +struct hdmi_id id;
>> +
>>  struct hdmi_data_info hdmi_data;
>>  const struct dw_hdmi_plat_data *plat_data;
>>   
>> @@ -1259,6 +1278,36 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
>> drm_display_mode *mode)
>>  return 0;
>>   }
>>   
>> +static void hdmi_parse_id(struct dw_hdmi *hdmi)
>> +{
>> +u8 config0_id, config1_id, config2_id, config3_id;
>> +
>> +config0_id = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
>> +config1_id = hdmi_readb(hdmi, HDMI_CONFIG1_ID);
>> +config2_id = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
>> +config3_id = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
>> +
>> +hdmi->id.prepen = config0_id & HDMI_CONFIG0_ID_PREPEN ? true : false;
>> +hdmi->id.audi2s = config0_id & HDMI_CONFIG0_ID_AUDI2S ? true : false;
>> +hdmi->id.hdmi14 = config0_id & HDMI_CONFIG0_ID_HDMI14 ? true : false;
>> +hdmi->id.hdcp = config0_id & HDMI_CONFIG0_ID_HDCP ? true : false;
>> +hdmi->id.csc = config0_id & HDMI_CONFIG0_ID_CSC ? true : false;
>> +hdmi->id.audspdif = config0_id & HDMI_CONFIG0_ID_AUDSPDIF ?
>> +true : false;
>> +
>> +hdmi->id.confapb = config1_id & HDMI_CONFIG1_ID_CONFAPB ? true : false;
>> +hdmi->id.hdmi20 = config1_id & HDMI_CONFIG1_ID_HDMI20 ? true : false;
>> +
>> +hdmi->id.phy_type = config2_id;
>> +
>> +hdmi->id.gpaud = config3_id & HDMI_CONFIG3_ID_GPAUD ? true : false;
>> +hdmi->id.ahbauddma = config3_id & HDMI_CONFIG3_ID_AHBAUDDMA ?
>> + true : false;
>> +
>> +hdmi->id.design = hdmi_readb(hdmi, HDMI_DESIGN_ID);
>> +hdmi->id.revision = hdmi_readb(hdmi, HDMI_REVISION_ID);
>> +}
> What is the purpose of creating a copy of all the feature bits? As far
> as I can tell you are only ever using hdmi_id.design afterwards.
Yeah, you are right. Seems hdmi audio have long long way to go.
As for now, we just need hdmi_id.design to separate registers.

Agree, I will simplify it in next verison.

>   
>
> regards
> Philipp
regards :)
Yakir
>
>
>

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

[PATCH v4 03/15] drm: rockchip/dw_hdmi_rockchip: add resume/suspend support

[yakir]

Hi Philipp,

On 2015年03月12日 18:24, Philipp Zabel wrote:
> Am Samstag, den 28.02.2015, 21:32 -0500 schrieb Yakir Yang:
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v4: None
>> Changes in v3:
>> - Setting the .pm member instead of suspend/resume
>>
>> Changes in v2:
>> - Add suspend/resume support for dw_hdmi_rockchip driver
>>
>>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
>> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> index d236faa..fc1d02e 100644
>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>> @@ -323,11 +323,27 @@ static int dw_hdmi_rockchip_remove(struct 
>> platform_device *pdev)
>>  return 0;
>>   }
>>   
>> +static int dw_hdmi_rockchip_suspend(struct device *dev)
>> +{
>> +return dw_hdmi_suspend(dev);
>> +}
>> +
>> +static int dw_hdmi_rockchip_resume(struct device *dev)
>> +{
>> +return dw_hdmi_resume(dev);
>> +}
> You could just skip dw_hdmi_rockchip_suspend/resume and
> set .suspend/.resume in dw_hdmi_rockchip_pm directly to
> dw_hdmi_suspend/resume.
>
Okay, sounds good, I will adjust it in next version.

Thanks  :)
>> +static const struct dev_pm_ops dw_hdmi_rockchip_pm = {
>> +.resume = dw_hdmi_rockchip_resume,
>> +.suspend = dw_hdmi_rockchip_suspend,
>> +};
>> +
>>   static struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
>>  .probe  = dw_hdmi_rockchip_probe,
>>  .remove = dw_hdmi_rockchip_remove,
>>  .driver = {
>>  .name = "dwhdmi-rockchip",
>> +.pm = _hdmi_rockchip_pm,
>>  .of_match_table = dw_hdmi_rockchip_dt_ids,
>>  },
>>   };
> regards
> Philipp
>
regards :)
Yakir
>
>

[PATCH v4 02/15] drm: bridge/dw_hdmi: wrap irq control in fucntions

[yakir]

Hi Philipp,

On 2015年03月12日 18:24, Philipp Zabel wrote:
> Hi Yakir,
>
> Am Samstag, den 28.02.2015, 21:28 -0500 schrieb Yakir Yang:
>> Wrap irq control in functions, and then we can call in
>> dw_hdmi_bind/dw_hdmi_unbind/dw_hdmi_resume/dw_hdmi_suspend
>> functions.
>>
>> Signed-off-by: Yakir Yang 
> [...]
Sorry, I can not understand this comment. could you please talk more 
detail about this one.

Thank you very much  :)
>> @@ -1702,17 +1722,8 @@ EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
>>   int dw_hdmi_suspend(struct device *dev)
>>   {
>>  struct dw_hdmi *hdmi = dev_get_drvdata(dev);
>> -u8 ih_mute;
>> -
>> -/* Disable all interrupts */
>> -hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
>> -
>> - /* Disable top level interrupt bits in HDMI block */
>> -ih_mute = hdmi_readb(hdmi, HDMI_IH_MUTE) |
>> -  HDMI_IH_MUTE_MUTE_WAKEUP_INTERRUPT |
>> -  HDMI_IH_MUTE_MUTE_ALL_INTERRUPT;
>>   
>> -hdmi_writeb(hdmi, ih_mute, HDMI_IH_MUTE);
>> +hdmi_mute_interrupts(hdmi);
>>   
>>  return 0;
>>   }
>> @@ -1722,19 +1733,7 @@ int dw_hdmi_resume(struct device *dev)
>>   {
>>  struct dw_hdmi *hdmi = dev_get_drvdata(dev);
>>   
>> -/*
>> - * Configure registers related to HDMI interrupt
>> - * generation before registering IRQ.
>> - */
>> -hdmi_writeb(hdmi, HDMI_PHY_HPD, HDMI_PHY_POL0);
>> -
>> -/* Clear Hotplug interrupts */
>> -hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD, HDMI_IH_PHY_STAT0);
>> -
>> -dw_hdmi_fb_registered(hdmi);
>> -
>> -/* Unmute interrupts */
>> -hdmi_writeb(hdmi, ~HDMI_IH_PHY_STAT0_HPD, HDMI_IH_MUTE_PHY_STAT0);
>> +hdmi_unmute_interrupts(hdmi);
>>   
>>  return 0;
>>   }
> Here you remove code added in the previous patch.
> It would be better to just apply patch 2 first and then rebase patch 1
> on top of it.

Thanks,  I will reorder patch 1 & patch 2, in next vesion   :)

> regards
> Philipp

regards :)
Yakir
>
>
>
>

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

 by the user via ioctl.
> @@ -2707,6 +2697,7 @@ int drm_mode_attachmode_ioctl(struct drm_device *dev,
> }
>
> drm_mode_attachmode(dev, connector, mode);
> +
>  out:
> mutex_unlock(>mode_config.mutex);
> return ret;
> @@ -2715,10 +2706,9 @@ out:
>
>  /**
>   * drm_fb_detachmode - Detach a user specified mode from an connector
> - * @inode: inode from the ioctl
> - * @filp: file * from the ioctl
> - * @cmd: cmd from ioctl
> - * @arg: arg from ioctl
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
>   *
>   * Called by the user via ioctl.
>   *
> @@ -2754,6 +2744,7 @@ int drm_mode_detachmode_ioctl(struct drm_device *dev,
> }
>
> ret = drm_mode_detachmode(dev, connector, );
> +
>  out:
> mutex_unlock(>mode_config.mutex);
> return ret;
> @@ -2790,6 +2781,7 @@ struct drm_property *drm_property_create(struct
> drm_device *dev, int flags,
>
> list_add_tail(>head, >mode_config.property_list);
> return property;
> +
>  fail:
> kfree(property->values);
> kfree(property);
> @@ -3078,6 +3070,7 @@ int drm_mode_getproperty_ioctl(struct drm_device
> *dev,
> }
> out_resp->count_enum_blobs = blob_count;
> }
> +
>  done:
> mutex_unlock(>mode_config.mutex);
> return ret;
> @@ -3187,6 +3180,7 @@ static bool drm_property_change_is_valid(struct
> drm_property *property,
>  {
> if (property->flags & DRM_MODE_PROP_IMMUTABLE)
> return false;
> +
> if (property->flags & DRM_MODE_PROP_RANGE) {
> if (value < property->values[0] || value >
> property->values[1])
> return false;
> @@ -3194,6 +3188,7 @@ static bool drm_property_change_is_valid(struct
> drm_property *property,
> } else if (property->flags & DRM_MODE_PROP_BITMASK) {
> int i;
> uint64_t valid_mask = 0;
> +
> for (i = 0; i < property->num_values; i++)
> valid_mask |= (1ULL << property->values[i]);
> return !(value & ~valid_mask);
> @@ -3326,6 +3321,7 @@ int drm_mode_obj_get_properties_ioctl(struct
> drm_device *dev, void *data,
> }
> }
> arg->count_props = props_count;
> +
>  out:
> mutex_unlock(>mode_config.mutex);
> return ret;
> @@ -3487,7 +3483,6 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
>  out:
> mutex_unlock(>mode_config.mutex);
> return ret;
> -
>  }
>
>  int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> @@ -3535,6 +3530,7 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> ret = -EFAULT;
> goto out;
> }
> +
>  out:
> mutex_unlock(>mode_config.mutex);
> return ret;
> @@ -3668,6 +3664,7 @@ int drm_mode_create_dumb_ioctl(struct drm_device
> *dev,
>
> if (!dev->driver->dumb_create)
> return -ENOSYS;
> +
> return dev->driver->dumb_create(file_priv, dev, args);
>  }
>
> --
> 1.9.1
>
>
>


-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150312/cd2f30f7/attachment-0001.html>

[PATCH v3 2/2] ARM: dts: rockchip: add hdmi analog power supplies to rk3288 boards

[Heiko Stuebner]

Add the recently added hdmi power supplies to evb and firefly boards.

Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
 arch/arm/boot/dts/rk3288-firefly.dtsi | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 5e895a5..edd45a0 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -118,6 +118,8 @@
 };

  {
+   vp-supply = <_lcd>;
+   vph-supply = <_lcd>;
ddc-i2c-bus = <>;
status = "okay";
 };
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi 
b/arch/arm/boot/dts/rk3288-firefly.dtsi
index e6f873a..09fcded 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -180,6 +180,8 @@
 };

  {
+   vp-supply = <_lcd>;
+   vph-supply = <_lcd>;
ddc-i2c-bus = <>;
status = "okay";
 };
-- 
2.1.4

[PATCH v3 1/2] drm/bridge: dw-hdmi: support optional supply regulators

[Heiko Stuebner]

At least the Rockchip variant of the dw_hdmi can have controllable power 
supplies
providing 1.0 and 1.8V. Therefore add the possibility for the generic bridge
driver to enable supplies provided by the hw-specific drivers.

Signed-off-by: Heiko Stuebner 
---
changes since v2:
- rename supplies to the names found in the hdmi IP databook
changes since v1:
- follow suggestion from Russell King to keep regulator handling local
  to the rockchip implementation for the time being and only generalize
  when a real second implementation needs regulator handling

 .../devicetree/bindings/drm/bridge/dw_hdmi.txt |  5 
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 32 +-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
index a905c14..bb74640 100644
--- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
@@ -22,6 +22,11 @@ Optional properties
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
 - clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"

+Optional supplies:
+rockchip,rk3288-dw-hdmi handles two optional power supplies:
+- vp-supply: 1.0V power supply
+- vph-supply: 1.8V power supply
+
 Example:
hdmi: hdmi at 012 {
compatible = "fsl,imx6q-hdmi";
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index d236faa..647a240 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +29,9 @@ struct rockchip_hdmi {
struct device *dev;
struct regmap *regmap;
struct drm_encoder encoder;
+   struct regulator_bulk_data supplies[2];
+   int nsupplies;
+   bool supplies_enabled;
 };

 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -179,6 +183,12 @@ static struct drm_encoder_funcs 
dw_hdmi_rockchip_encoder_funcs = {

 static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
 {
+   struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+
+   if (hdmi->nsupplies > 0 && hdmi->supplies_enabled) {
+   regulator_bulk_disable(hdmi->nsupplies, hdmi->supplies);
+   hdmi->supplies_enabled = false;
+   }
 }

 static bool
@@ -199,7 +209,16 @@ static void dw_hdmi_rockchip_encoder_commit(struct 
drm_encoder *encoder)
 {
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
u32 val;
-   int mux;
+   int mux, ret;
+
+   if (hdmi->nsupplies > 0 && !hdmi->supplies_enabled) {
+   ret = regulator_bulk_enable(hdmi->nsupplies, hdmi->supplies);
+   if (ret) {
+   dev_err(hdmi->dev, "could not enable hdmi analog 
supplies\n");
+   return;
+   }
+   hdmi->supplies_enabled = true;
+   }

mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
if (mux)
@@ -275,6 +294,17 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
if (!iores)
return -ENXIO;

+   hdmi->supplies[0].supply = "vp";
+   hdmi->supplies[1].supply = "vph";
+   hdmi->nsupplies = 2;
+
+   ret = devm_regulator_bulk_get(hdmi->dev,
+ hdmi->nsupplies, hdmi->supplies);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+   if (ret)
+   hdmi->nsupplies = 0;
+
platform_set_drvdata(pdev, hdmi);

encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
-- 
2.1.4

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 8:49 PM, John Hunter  wrote:
> Hi Rob,
>
> On Thu, Mar 12, 2015 at 10:34 PM, Rob Clark  wrote:
>>
>> On Thu, Mar 12, 2015 at 10:15 AM, John Hunter  wrote:
>> > Hi,
>> > I really don't  whether I am doing things on right workflow of
>> > dri-devel.
>> > I am new to this community and I want to help.
>> > Could anybody spare some time to tell me the right way .
>> > Thanks.
>>
>> Hi John,
>>
>> I don't actually see the original patch, just your reply to it..  if
>> you didn't already, could you git-send-email it to dri-devel?
>>
> I searched the archieve of the maillinglist, I think this may be the
> original patch
> http://lists.freedesktop.org/archives/dri-devel/2015-March/079198.html
>
>>
>> (If you did, but were not subscribed, perhaps it is still stuck in
>> list moderation queue?)
>>
> I subscribed with the email : zhjwpku at gmail.com, but when git-send-email to
> dri-devel,
> I used another not subscribed email: zhaojunwang at pku.edu.cn to git-send the
> patch ,
> because I got trouble when I use the gmail stmp server in git-send-mail
> I can only use the gmail under the help of chrome and goagent, cause I am in
> China :-(

I see your patch now, so I guess whoever has list admin privileges
stepped in and moderated it.. it is one my TODO list to review.. and
thanks for the patch, btw ;-)

hopefully someone else in China can suggest a good way of sending
patches (I have no clue there)

BR,
-R


>
> BR,
> John
>
>>
>> BR,
>> -R
>>
>>
>> > John
>> >
>> > On Thu, Mar 12, 2015 at 4:02 PM, John Hunter 
>> > wrote:
>> >>
>> >> From: John Hunter 
>> >>
>> >> IMHO, some annotations were copypaste from somewhere else, it is
>> >> obviously not rightly modified. Hope I am right with that.
>> >> ---
>> >>  drivers/gpu/drm/drm_crtc.c | 115
>> >> ++---
>> >>  1 file changed, 56 insertions(+), 59 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> index f2d667b..7f771e9 100644
>> >> --- a/drivers/gpu/drm/drm_crtc.c
>> >> +++ b/drivers/gpu/drm/drm_crtc.c
>> >> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> >> drm_connector_status status)
>> >>  /**
>> >>   * drm_mode_object_get - allocate a new identifier
>> >>   * @dev: DRM device
>> >> - * @ptr: object pointer, used to generate unique ID
>> >> - * @type: object type
>> >> + * @obj: object pointer, used to generate unique ID
>> >> + * @obj_type: object type
>> >>   *
>> >>   * LOCKING:
>> >>   *
>> >> - * Create a unique identifier based on @ptr in @dev's identifier
>> >> space.
>> >> Used
>> >> + * Create a unique identifier based on @obj in @dev's identifier
>> >> space.
>> >> Used
>> >>   * for tracking modes, CRTCs and connectors.
>> >>   *
>> >>   * RETURNS:
>> >> @@ -245,12 +245,12 @@ again:
>> >>  /**
>> >>   * drm_mode_object_put - free an identifer
>> >>   * @dev: DRM device
>> >> - * @id: ID to free
>> >> + * @object: object to free
>> >>   *
>> >>   * LOCKING:
>> >>   * Caller must hold DRM mode_config lock.
>> >>   *
>> >> - * Free @id from @dev's unique identifier pool.
>> >> + * Free @object from @dev's unique identifier pool.
>> >>   */
>> >>  static void drm_mode_object_put(struct drm_device *dev,
>> >> struct drm_mode_object *object)
>> >> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
>> >>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>> >>  {
>> >> struct drm_device *dev = fb->dev;
>> >> +
>> >> /*
>> >>  * This could be moved to drm_framebuffer_remove(), but for
>> >>  * debugging is nice to keep around the list of fb's that are
>> >> -* no longer associated w/ a drm_file but are not unreferenced
>> >> +* no longer associated with a drm_file but are not
>> >> unreferenced
>> >>  * yet.  (i915 and omapdrm have debugfs files which will show
>> >>  * this.)
>> >>  */
>> >> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
>> >>   * @dev: DRM device
>> >>   * @connector: the connector to init
>> >>   * @funcs: callbacks for this connector
>> >> - * @name: user visible name of the connector
>> >> + * @connector_type: type of the connector
>> >>   *
>> >>   * LOCKING:
>> >>   * Takes mode config lock.
>> >> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct
>> >> drm_plane *plane,
>> >> plane->format_count = format_count;
>> >> plane->possible_crtcs = possible_crtcs;
>> >>
>> >> -   /* private planes are not exposed to userspace, but depending
>> >> on
>> >> +   /*
>> >> +* private planes are not exposed to userspace, but depending
>> >> on
>> >>  * display hardware, might be convenient to allow sharing
>> >> programming
>> >>  * for the scanout engine with the crtc implementation.
>> >>  */
>> >> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct
>> >> drm_display_mode *out,
>> >>
>> >>  /**
>> >>   

[PATCH] drm: atmel-hlcdc: fixes wrong enabled flag used in PM suspend/resume support

[Sylvain Rochet]

Unfortunately we used the enabled flag in struct drm_crtc instead of the
enabled flag in struct atmel_hlcdc_crtc. This obviously leads to
discrepancies on crtc enable state.

This patch fixes the issue by using the struct atmel_hlcdc_crtc enabled
flag in PM support.

Signed-off-by: Sylvain Rochet 
---
We had to move CRTC suspend and resume support from DC to CRTC because
drm_crtc_to_atmel_hlcdc_crtc() is static, this is also cleaner this
way. 

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 21 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 19 ---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |  3 +++
 3 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d55c0c2..8ba98df 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -207,6 +207,27 @@ static void atmel_hlcdc_crtc_enable(struct drm_crtc *c)
crtc->enabled = true;
 }

+void atmel_hlcdc_crtc_suspend(struct drm_crtc *crtc)
+{
+   struct atmel_hlcdc_crtc *atmel_crtc = 
drm_crtc_to_atmel_hlcdc_crtc(crtc);
+
+   if (atmel_crtc->enabled) {
+   atmel_hlcdc_crtc_disable(crtc);
+   /* save enable state for resume */
+   atmel_crtc->enabled = true;
+   }
+}
+
+void atmel_hlcdc_crtc_resume(struct drm_crtc *crtc)
+{
+   struct atmel_hlcdc_crtc *atmel_crtc = 
drm_crtc_to_atmel_hlcdc_crtc(crtc);
+
+   if (atmel_crtc->enabled) {
+   atmel_crtc->enabled = false;
+   atmel_hlcdc_crtc_enable(crtc);
+   }
+}
+
 static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc *c,
 struct drm_crtc_state *s)
 {
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index c4bb1f9..60b0c13 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -569,14 +569,8 @@ static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
return 0;

drm_modeset_lock_all(drm_dev);
-   list_for_each_entry(crtc, _dev->mode_config.crtc_list, head) {
-   struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
-   if (crtc->enabled) {
-   crtc_funcs->disable(crtc);
-   /* save enable state for resume */
-   crtc->enabled = true;
-   }
-   }
+   list_for_each_entry(crtc, _dev->mode_config.crtc_list, head)
+   atmel_hlcdc_crtc_suspend(crtc);
drm_modeset_unlock_all(drm_dev);
return 0;
 }
@@ -590,13 +584,8 @@ static int atmel_hlcdc_dc_drm_resume(struct device *dev)
return 0;

drm_modeset_lock_all(drm_dev);
-   list_for_each_entry(crtc, _dev->mode_config.crtc_list, head) {
-   struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
-   if (crtc->enabled) {
-   crtc->enabled = false;
-   crtc_funcs->enable(crtc);
-   }
-   }
+   list_for_each_entry(crtc, _dev->mode_config.crtc_list, head)
+   atmel_hlcdc_crtc_resume(crtc);
drm_modeset_unlock_all(drm_dev);
return 0;
 }
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 1ea9c2c..cf6b375 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -155,6 +155,9 @@ void atmel_hlcdc_crtc_irq(struct drm_crtc *c);
 void atmel_hlcdc_crtc_cancel_page_flip(struct drm_crtc *crtc,
   struct drm_file *file);

+void atmel_hlcdc_crtc_suspend(struct drm_crtc *crtc);
+void atmel_hlcdc_crtc_resume(struct drm_crtc *crtc);
+
 int atmel_hlcdc_crtc_create(struct drm_device *dev);

 int atmel_hlcdc_create_outputs(struct drm_device *dev);
-- 
2.1.4

[PATCH v3 00/10] Use media bus formats in imx-drm and add drm panel support

[Emil Renner Berthing]

Hi Philipp

On 12 March 2015 at 10:58, Philipp Zabel  wrote:
> Currently the imx-drm driver misuses the V4L2_PIX_FMT constants to describe 
> the
> pixel format on the parallel bus between display controllers and encoders. Now
> that MEDIA_BUS_FMT is available, use that instead.

I've tested this series on the Hercules eCAFE Slim HD, which uses the
RGB666_1X24_CPADHI format, and it still boots up with screen output.
You can add

Tested-by: Emil Renner Berthing 

--
/Emil

[PATCH] drm/radeon: Changing number of compute pipe lines

[Michel Dänzer]

On 12.03.2015 17:48, Oded Gabbay wrote:
> From: Ben Goz 
> 
> The current CP firmware can handle Usermode Queues only on MEC1.
> To reflect this firmware change, this commit reduces number of compute 
> pipelines
> to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd).
> 
> Signed-off-by: Ben Goz 
> Signed-off-by: Oded Gabbay 
> ---
>  drivers/gpu/drm/radeon/radeon_kfd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c 
> b/drivers/gpu/drm/radeon/radeon_kfd.c
> index 061eaa9..122eb56 100644
> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
> @@ -153,7 +153,7 @@ void radeon_kfd_device_init(struct radeon_device *rdev)
>   .compute_vmid_bitmap = 0xFF00,
>  
>   .first_compute_pipe = 1,
> - .compute_pipe_count = 8 - 1,
> + .compute_pipe_count = 4 - 1,
>   };
>  
>   radeon_doorbell_get_kfd_info(rdev,
> 

Does this need to be backported to 3.19? (Does the current CP microcode
work with 3.19?)


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

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Michel Dänzer]

On 12.03.2015 06:14, Alex Deucher wrote:
> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
> wrote:
>> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>>  wrote:
>>> On 11.03.2015 16:44, Alex Deucher wrote:

 radeon_bo_create() calls radeon_ttm_placement_from_domain()
 before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
 uses the ttm bo size to determine when to select top down
 allocation but since the ttm bo is not initialized yet the
 check is always false.

 Noticed-by: Oded Gabbay 
 Signed-off-by: Alex Deucher 
 Cc: stable at vger.kernel.org
>>>
>>>
>>> And I was already wondering why the heck the BOs always made this ping/pong
>>> in memory after creation.
>>>
>>> Patch is Reviewed-by: Christian König 
>>
>> And fixing that promptly broke VCE due to vram location requirements.
>> Updated patch attached.  Thoughts?
> 
> And one more take to make things a bit more explicit for static kernel
> driver allocations.

struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
problem is really that some BOs are expected to be within a certain
range from the beginning of VRAM, but lpfn isn't set accordingly. It
would be better to fix that by setting lpfn directly than indirectly via
RADEON_GEM_CPU_ACCESS.


Anyway, since this isn't the first bug which prevents
TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
wonder if its performance impact should be re-evaluated. Lauri?


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

[PATCH i-g-t v3] tests/core_getparams: Create new test core_getparams

[jeff.mc...@intel.com]

From: Jeff McGee 

New test core_getparams consists of 2 subtests, each one testing
the ability of userspace to query the correct value of a GT config
attribute: subslice total or EU total. drm/i915 implementation of
these queries is required for Cherryview and Gen9+ devices (non-
simulated).

v2: Duplicate small amount of new libdrm functionality to avoid
bumping libdrm version requirement (Daniel). Convert some
igt_asserts to the appropriate comparison variants. Add a
test description.
v3: Actually use the LOCAL GETPARAM defines. Otherwise can't build
against older libdrm as intended by v2.

For: VIZ-4636
Signed-off-by: Jeff McGee 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/core_getparams.c | 167 +
 3 files changed, 169 insertions(+)
 create mode 100644 tests/core_getparams.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 426cc67..c742308 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,6 +1,7 @@
 # Please keep sorted alphabetically
 core_get_client_auth
 core_getclient
+core_getparams
 core_getstats
 core_getversion
 drm_import_export
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 51e8376..999c8f8 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -15,6 +15,7 @@ NOUVEAU_TESTS_M = \

 TESTS_progs_M = \
core_get_client_auth \
+   core_getparams \
drv_suspend \
drv_hangman \
gem_bad_reloc \
diff --git a/tests/core_getparams.c b/tests/core_getparams.c
new file mode 100644
index 000..2855d06
--- /dev/null
+++ b/tests/core_getparams.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * 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 (including the next
+ * paragraph) 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 BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Jeff McGee 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "drmtest.h"
+#include "intel_chipset.h"
+#include "intel_bufmgr.h"
+
+IGT_TEST_DESCRIPTION("Tests the export of parameters via 
DRM_IOCTL_I915_GETPARAM\n");
+
+int drm_fd;
+int devid;
+
+static void
+init(void)
+{
+   drm_fd = drm_open_any();
+   devid = intel_get_drm_devid(drm_fd);
+}
+
+static void
+deinit(void)
+{
+   close(drm_fd);
+}
+
+#define LOCAL_I915_PARAM_SUBSLICE_TOTAL33
+#define LOCAL_I915_PARAM_EU_TOTAL  34
+
+static int
+getparam(int param, int *value)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memset(, 0, sizeof(gp));
+   gp.value = value;
+   gp.param = param;
+   ret = drmIoctl(drm_fd, DRM_IOCTL_I915_GETPARAM, );
+   if (ret)
+   return -errno;
+
+   return 0;
+}
+
+static void
+subslice_total(void)
+{
+   unsigned int subslice_total = 0;
+   int ret;
+
+   ret = getparam(LOCAL_I915_PARAM_SUBSLICE_TOTAL, (int*)_total);
+
+   if (ret) {
+   /*
+* These devices are not required to implement the
+* interface. If they do not, -ENODEV must be returned.
+   */
+   if ((intel_gen(devid) < 8) ||
+   IS_BROADWELL(devid) ||
+   igt_run_in_simulation()) {
+   igt_assert_eq(ret, -ENODEV);
+   igt_info("subslice total: unknown\n");
+   /*
+* All other devices must implement the interface, so
+* fail them if we are here.
+   */
+   } else {
+   igt_assert_neq(ret, EINVAL); /* request not recognized? 
*/
+   igt_assert_neq(ret, ENODEV); /* device not supported? */
+   igt_assert_eq(ret, 0); /* other error? */
+   }
+   } else {
+   /*
+* On success, just make sure the returned count value is
+* non-zero. The validity of the count value for the given
+* device is not 

[Bug 89536] GPU lockup and kernel OOPS when using PRIME

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

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

--- Comment #5 from Rafael Ristovski  ---
Created attachment 114265
  --> https://bugs.freedesktop.org/attachment.cgi?id=114265=edit
Another crash, this time with running 4.0.0 kernel, which also gave me a trace.

-- 
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/20150312/14397f55/attachment.html>

[PATCH] drm/msm: Refactor msm drm driver by introducing msm_drm_sub_dev

[Jilai Wang]

Introduce msm_drm_sub_dev for each mdp interface component such as
HDMI/eDP/DSI to contain common information shared with MDP.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/edp/edp.c   | 18 +--
 drivers/gpu/drm/msm/edp/edp.h   |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi.c | 22 ++---
 drivers/gpu/drm/msm/hdmi/hdmi.h |  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c |  3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 56 -
 drivers/gpu/drm/msm/msm_drv.h   | 23 +-
 7 files changed, 80 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
index 0940e84..8d8b7e9 100644
--- a/drivers/gpu/drm/msm/edp/edp.c
+++ b/drivers/gpu/drm/msm/edp/edp.c
@@ -14,6 +14,9 @@
 #include 
 #include "edp.h"

+static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev);
+
 static irqreturn_t edp_irq(int irq, void *dev_id)
 {
struct msm_edp *edp = dev_id;
@@ -63,6 +66,8 @@ static struct msm_edp *edp_init(struct platform_device *pdev)
if (ret)
goto fail;

+   edp->base.modeset_init = msm_edp_modeset_init;
+
return edp;

 fail:
@@ -82,7 +87,8 @@ static int edp_bind(struct device *dev, struct device 
*master, void *data)
edp = edp_init(to_platform_device(dev));
if (IS_ERR(edp))
return PTR_ERR(edp);
-   priv->edp = edp;
+
+   priv->edp = >base;

return 0;
 }
@@ -144,13 +150,19 @@ void __exit msm_edp_unregister(void)
 }

 /* Second part of initialization, the drm/kms level modeset_init */
-int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
-   struct drm_encoder *encoder)
+static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev)
 {
+   struct msm_edp *edp = container_of(base, struct msm_edp, base);
struct platform_device *pdev = edp->pdev;
struct msm_drm_private *priv = dev->dev_private;
+   struct drm_encoder *encoder;
int ret;

+   if (WARN_ON(base->num_encoders != 1))
+   return -EINVAL;
+
+   encoder = base->encoders[0];
edp->encoder = encoder;
edp->dev = dev;

diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h
index ba5bedd..00eff68 100644
--- a/drivers/gpu/drm/msm/edp/edp.h
+++ b/drivers/gpu/drm/msm/edp/edp.h
@@ -31,6 +31,7 @@ struct edp_aux;
 struct edp_phy;

 struct msm_edp {
+   struct msm_drm_sub_dev base;
struct drm_device *dev;
struct platform_device *pdev;

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 9a8a825..9e886ec 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -19,6 +19,9 @@
 #include 
 #include "hdmi.h"

+static int hdmi_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev);
+
 void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
 {
uint32_t ctrl = 0;
@@ -197,6 +200,8 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
goto fail;
}

+   hdmi->base.modeset_init = hdmi_modeset_init;
+
return hdmi;

 fail:
@@ -214,13 +219,19 @@ fail:
  * should be handled in hdmi_init() so that failure happens from
  * hdmi sub-device's probe.
  */
-int hdmi_modeset_init(struct hdmi *hdmi,
-   struct drm_device *dev, struct drm_encoder *encoder)
+static int hdmi_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev)
 {
+   struct hdmi *hdmi = container_of(base, struct hdmi, base);
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = hdmi->pdev;
+   struct drm_encoder *encoder;
int ret;

+   if (WARN_ON(base->num_encoders != 1))
+   return -EINVAL;
+
+   encoder = base->encoders[0];
hdmi->dev = dev;
hdmi->encoder = encoder;

@@ -439,7 +450,8 @@ static int hdmi_bind(struct device *dev, struct device 
*master, void *data)
hdmi = hdmi_init(to_platform_device(dev));
if (IS_ERR(hdmi))
return PTR_ERR(hdmi);
-   priv->hdmi = hdmi;
+
+   priv->hdmi = >base;

return 0;
 }
@@ -449,8 +461,10 @@ static void hdmi_unbind(struct device *dev, struct device 
*master,
 {
struct drm_device *drm = dev_get_drvdata(master);
struct msm_drm_private *priv = drm->dev_private;
+
if (priv->hdmi) {
-   hdmi_destroy(priv->hdmi);
+   struct hdmi *hdmi = container_of(priv->hdmi, struct hdmi, base);
+   hdmi_destroy(hdmi);
priv->hdmi = NULL;
}
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 68fdfb3..a1d4595 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -38,6 +38,7 @@ struct hdmi_audio {
 };

 struct hdmi {
+

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

From: John Hunter 

IMHO, some annotations were copypaste from somewhere else, it is
obviously not rightly modified. Hope I am right with that.
---
 drivers/gpu/drm/drm_crtc.c | 115 ++---
 1 file changed, 56 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f2d667b..7f771e9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum 
drm_connector_status status)
 /**
  * drm_mode_object_get - allocate a new identifier
  * @dev: DRM device
- * @ptr: object pointer, used to generate unique ID
- * @type: object type
+ * @obj: object pointer, used to generate unique ID
+ * @obj_type: object type
  *
  * LOCKING:
  *
- * Create a unique identifier based on @ptr in @dev's identifier space.  Used
+ * Create a unique identifier based on @obj in @dev's identifier space.  Used
  * for tracking modes, CRTCs and connectors.
  *
  * RETURNS:
@@ -245,12 +245,12 @@ again:
 /**
  * drm_mode_object_put - free an identifer
  * @dev: DRM device
- * @id: ID to free
+ * @object: object to free
  *
  * LOCKING:
  * Caller must hold DRM mode_config lock.
  *
- * Free @id from @dev's unique identifier pool.
+ * Free @object from @dev's unique identifier pool.
  */
 static void drm_mode_object_put(struct drm_device *dev,
struct drm_mode_object *object)
@@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
 void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
+
/*
 * This could be moved to drm_framebuffer_remove(), but for
 * debugging is nice to keep around the list of fb's that are
-* no longer associated w/ a drm_file but are not unreferenced
+* no longer associated with a drm_file but are not unreferenced
 * yet.  (i915 and omapdrm have debugfs files which will show
 * this.)
 */
@@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
  * @dev: DRM device
  * @connector: the connector to init
  * @funcs: callbacks for this connector
- * @name: user visible name of the connector
+ * @connector_type: type of the connector
  *
  * LOCKING:
  * Takes mode config lock.
@@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;

-   /* private planes are not exposed to userspace, but depending on
+   /*
+* private planes are not exposed to userspace, but depending on
 * display hardware, might be convenient to allow sharing programming
 * for the scanout engine with the crtc implementation.
 */
@@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct 
drm_display_mode *out,

 /**
  * drm_mode_getresources - get graphics configuration
- * @inode: inode from the ioctl
- * @filp: file * from the ioctl
- * @cmd: cmd from ioctl
- * @arg: arg from ioctl
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
  *
  * LOCKING:
  * Takes mode config lock.
@@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
list_for_each(lh, >mode_config.encoder_list)
encoder_count++;
} else {
-
crtc_count = mode_group->num_crtcs;
connector_count = mode_group->num_connectors;
encoder_count = mode_group->num_encoders;
@@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
}
copied++;
}
-
}
}
card_res->count_encoders = encoder_count;
@@ -1376,10 +1375,9 @@ out:

 /**
  * drm_mode_getcrtc - get CRTC configuration
- * @inode: inode from the ioctl
- * @filp: file * from the ioctl
- * @cmd: cmd from ioctl
- * @arg: arg from ioctl
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
  *
  * LOCKING:
  * Takes mode config lock.
@@ -1421,10 +1419,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
crtc_resp->fb_id = 0;

if (crtc->enabled) {
-
drm_crtc_convert_to_umode(_resp->mode, >mode);
crtc_resp->mode_valid = 1;
-
} else {
crtc_resp->mode_valid = 0;
}
@@ -1436,10 +1432,9 @@ out:

 /**
  * drm_mode_getconnector - get connector configuration
- * @inode: inode from the ioctl
- * @filp: file * from the ioctl
- * @cmd: cmd from ioctl
- * @arg: arg from ioctl
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
  *
  * LOCKING:
  * Takes mode config lock.
@@ -1732,8 +1727,8 @@ out:
 /**
  * drm_mode_setplane - set up or tear down an plane
  * @dev: DRM device
- * @data: ioctl data*
- * @file_prive: DRM file info
+ * @data: ioctl data
+ * @file_priv: DRM 

[PATCH 0/7] drm/exynos: clean ups

[Gustavo Padovan]

2015-03-12 Inki Dae :

> On 2015년 02월 19일 22:22, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> >
> > Hi,
> >
> > Here goes some clean ups to the exynos drivers. The main clean ups is
> > the presetting and zpos making the property immutable and the removal
> > of *_win_data structures.
> 
> With your cleanup patch set, the plane test doesn't work. Have you ever
> tested plane feature with modetest application?
> 
> I typed like below and it looks like no problem but I cannot see
> anything on Panel except for cute four penguins.
> 
> # modetest -P 29:100x100+0+0
> trying to open device 'i915'...failed.
> trying to open device 'radeon'...failed.
> trying to open device 'nouveau'...failed.
> trying to open device 'vmwgfx'...failed.
> trying to open device 'omapdrm'...failed.
> trying to open device 'exynos'...success.
> testing 100x100 at XR24 overlay plane 25
> 
> And for two plane test,
> 
> # modetest -P 29:100x100+0+0 -P 29:100x100+0+100
> trying to open device 'i915'...failed.
> trying to open device 'radeon'...failed.
> trying to open device 'nouveau'...failed.
> trying to open device 'vmwgfx'...failed.
> trying to open device 'omapdrm'...failed.
> trying to open device 'exynos'...success.
> testing 100x100 at XR24 overlay plane 25
> testing 100x100 at XR24 overlay plane 26
> 
> Still no screen.

Well, I did some more testing and even without my patches I can't see a plane
on the screen. Running only on exynos-drm-next also doesn't work so it is not
something that my patches introduced, it is already a bug upstream.
I'm using a snow for testing.

Gustavo

[PATCH v4 02/15] drm: bridge/dw_hdmi: wrap irq control in fucntions

[Philipp Zabel]

Hi Yakir,

Am Donnerstag, den 12.03.2015, 22:31 +0800 schrieb yakir:
> Hi Philipp,
> 
> On 2015年03月12日 18:24, Philipp Zabel wrote:
> > Hi Yakir,
> >
> > Am Samstag, den 28.02.2015, 21:28 -0500 schrieb Yakir Yang:
> >> Wrap irq control in functions, and then we can call in
> >> dw_hdmi_bind/dw_hdmi_unbind/dw_hdmi_resume/dw_hdmi_suspend
> >> functions.
> >>
> >> Signed-off-by: Yakir Yang 
> > [...]
> Sorry, I can not understand this comment. could you please talk more 
> detail about this one.
>
> Thank you very much  :)

I use "[...]" as a sign that I removed parts from the quoted email, like
this:

[...]
> > Here you remove code added in the previous patch.
> > It would be better to just apply patch 2 first and then rebase patch 1
> > on top of it.
> 
> Thanks,  I will reorder patch 1 & patch 2, in next vesion   :)

regards
Philipp

[PATCH v2] drm/i915: Fix BUG in i915_gem.c when switch to console

[Xi Ruoyao]

In intel_crtc_page_flip, intel_display.c, the code changed the framebuffer
assigned to plane crtc->primary by

crtc->primary->fb = fb;

However, it forgot to change crtc->primary->state->fb. However, when we
switch to console, some kernel code will read crtc->primary->state->fb
to get the framebuffer assigned to crtc->primaty. Then a framebuffer
object can be unpinned twice and a kernel BUG will be produced in i915_gem.c.

So, update crtc->primary->state->fb in intel_display.c using
drm_atomic_set_fb_for_plane to fix the BUG.

Signed-off-by: Xi Ruoyao 
Fixed: Bug 93711 
---
 Sorry, the previous patch is mangled by email client, so I am re-sending it.

 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e730789..97083fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -37,6 +37,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_trace.h"
+#include 
 #include 
 #include 
 #include 
@@ -9816,6 +9817,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
drm_gem_object_reference(>base);

crtc->primary->fb = fb;
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);

work->pending_flip_obj = obj;

-- 
1.9.1

[PATCH v2 RESEND 4/4] ARM: dts: exynos5420: add async-bridge clocks to gsc power domain

[Andrzej Hajda]

Both GSCALER IPs in gsc power domain have async-bridges (to FIMD and MIXER),
therefore their clocks should be enabled during power domain switch.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/exynos5420.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 55e3887..4eaeabe 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -251,6 +251,8 @@
compatible = "samsung,exynos4210-pd";
reg = <0x10044000 0x20>;
#power-domain-cells = <0>;
+   clocks = < CLK_GSCL0>, < CLK_GSCL1>;
+   clock-names = "asb0", "asb1";
};

isp_pd: power-domain at 10044020 {
-- 
1.9.1

[PATCH v2 RESEND 3/4] ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain

[Andrzej Hajda]

FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
therefore their clocks should be enabled during power domain switch.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
Reviewed-by: Sylwester Nawrocki 
---
 arch/arm/boot/dts/exynos5420.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..55e3887 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -283,9 +283,11 @@
 < CLK_MOUT_SW_ACLK300>,
 < CLK_MOUT_USER_ACLK300_DISP1>,
 < CLK_MOUT_SW_ACLK400>,
-< CLK_MOUT_USER_ACLK400_DISP1>;
+< CLK_MOUT_USER_ACLK400_DISP1>,
+< CLK_FIMD1>, < CLK_MIXER>;
clock-names = "oscclk", "pclk0", "clk0",
- "pclk1", "clk1", "pclk2", "clk2";
+ "pclk1", "clk1", "pclk2", "clk2",
+ "asb0", "asb1";
};

pinctrl_0: pinctrl at 1340 {
-- 
1.9.1

[PATCH v2 RESEND 2/4] arm/exynos/pm_domains: add support for async-bridge clocks

[Andrzej Hajda]

Since Exynos5420 there are async-bridges (ASB) between different IPs. These
bridges must be operational during power domain on/off, ie. clocks used
by these bridges should be enabled.
This patch enabled these clocks during domain on/off.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
Reviewed-by: Sylwester Nawrocki 
---
 arch/arm/mach-exynos/pm_domains.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index 37266a8..507dad0 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -37,6 +37,7 @@ struct exynos_pm_domain {
struct clk *oscclk;
struct clk *clk[MAX_CLK_PER_DOMAIN];
struct clk *pclk[MAX_CLK_PER_DOMAIN];
+   struct clk *asb_clk[MAX_CLK_PER_DOMAIN];
 };

 static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
@@ -45,14 +46,19 @@ static int exynos_pd_power(struct generic_pm_domain 
*domain, bool power_on)
void __iomem *base;
u32 timeout, pwr;
char *op;
+   int i;

pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd->base;

+   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+   if (IS_ERR(pd->asb_clk[i]))
+   break;
+   clk_prepare_enable(pd->asb_clk[i]);
+   }
+
/* Set oscclk before powering off a domain*/
if (!power_on) {
-   int i;
-
for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd->clk[i]))
break;
@@ -81,8 +87,6 @@ static int exynos_pd_power(struct generic_pm_domain *domain, 
bool power_on)

/* Restore clocks after powering on a domain*/
if (power_on) {
-   int i;
-
for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd->clk[i]))
break;
@@ -92,6 +96,12 @@ static int exynos_pd_power(struct generic_pm_domain *domain, 
bool power_on)
}
}

+   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+   if (IS_ERR(pd->asb_clk[i]))
+   break;
+   clk_disable_unprepare(pd->asb_clk[i]);
+   }
+
return 0;
 }

@@ -131,6 +141,15 @@ static __init int exynos4_pm_init_power_domain(void)
pd->pd.power_off = exynos_pd_power_off;
pd->pd.power_on = exynos_pd_power_on;

+   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+   char clk_name[8];
+
+   snprintf(clk_name, sizeof(clk_name), "asb%d", i);
+   pd->asb_clk[i] = clk_get(dev, clk_name);
+   if (IS_ERR(pd->asb_clk[i]))
+   break;
+   }
+
pd->oscclk = clk_get(dev, "oscclk");
if (IS_ERR(pd->oscclk))
goto no_clk;
-- 
1.9.1

[PATCH v2 RESEND 1/4] arm/exynos: add asynchronous bridge clock bindings

[Andrzej Hajda]

The patch adds bindings for clocks required by async-bridges
present in the particular power domain.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 1e09703..5da38c5 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -22,6 +22,9 @@ Optional Properties:
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
+   - asbN: Clocks required by asynchronous bridges (ASB) present in
+   the power domain. These clock should be enabled during power
+   domain on/off operations.
 - power-domains: phandle pointing to the parent power domain, for more details
 see Documentation/devicetree/bindings/power/power_domain.txt

-- 
1.9.1

[PATCH v2 RESEND 0/4] Fix power domains handling on exynos542x

[Andrzej Hajda]

Hi Kukjin,

This is resend of my patchset with added (Reviewed|Tested)-by tags and removed 
RFC
prefix.

Exynos chipsets since 542x have asynchronous bridges connecting different IPs.
These bridges should be operational during power domain switching, ie associated
clocks cannot be gated.
This patchset adds binding to provide such clocks per power domain and adds code
which enables them during domain on/off operation.

This patchset fixes power domain issues with disp1 domain and HDMI (some of 
them)
on Odroid XU3:
- disp1 power domain can be turned off,
- no more "imprecise external abort" faults.

The patchset is based on samsung-fixes-dt tag from kgene/linux-samsung.

It was successfully tested on OdroidXU3.

Regards
Andrzej


Andrzej Hajda (4):
  arm/exynos: add asynchronous bridge clock bindings
  arm/exynos/pm_domains: add support for async-bridge clocks
  ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain
  ARM: dts: exynos5420: add async-bridge clocks to gsc power domain

 .../bindings/arm/exynos/power_domain.txt   |  3 +++
 arch/arm/boot/dts/exynos5420.dtsi  |  8 +--
 arch/arm/mach-exynos/pm_domains.c  | 27 ++
 3 files changed, 32 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH 5/5] drm/msm/mdp5: Add hardware configuration for msm8x16

[Archit Taneja]

Hi,

On 03/09/2015 06:41 PM, Stephane Viau wrote:
> This change adds the hw configuration for msm8x16 chipsets in
> mdp5_cfg module.
>
> Note that only one external display interface is present in this
> configuration (DSI) but has not been enabled yet. It will be enabled
> once drm/msm driver supports DSI connectors.
>
> Signed-off-by: Stephane Viau 
> ---
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 51 
> -
>   1 file changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> index 96ea6dd..9ff7ac1 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2014 The Linux Foundation. All rights reserved.
> + * Copyright (c) 2014-2015 The Linux Foundation. All rights reserved.
>*
>* This program is free software; you can redistribute it and/or modify
>* it under the terms of the GNU General Public License version 2 and
> @@ -150,10 +150,59 @@ const struct mdp5_cfg_hw apq8084_config = {
>   .max_clk = 32000,
>   };
>
> +const struct mdp5_cfg_hw msm8x16_config = {
> + .name = "msm8x16",
> + .mdp = {
> + .count = 1,
> + .base = { 0x01000 },
> + },
> + .smp = {
> + .mmb_count = 8,
> + .mmb_size = 8192,
> + .clients = {
> + [SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
> + [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
> + },
> + },
> + .ctl = {
> + .count = 5,
> + .base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
> + },
> + .pipe_vig = {
> + .count = 1,
> + .base = { 0x05000 },
> + },
> + .pipe_rgb = {
> + .count = 2,
> + .base = { 0x15000, 0x17000 },
> + },
> + .pipe_dma = {
> + .count = 1,
> + .base = { 0x25000 },
> + },
> + .lm = {
> + .count = 2, /* LM0 and LM3 */
> + .base = { 0x45000, 0x48000 },
> + .nb_stages = 5,
> + },
> + .dspp = {
> + .count = 1,
> + .base = { 0x55000 },
> +
> + },
> + .intf = {
> + .count = 1, /* INTF_1 */
> + .base = { 0x6B800 },

We would need to put the other non-existent INTF_0, INTF_2 and INTF_3 
base addresses here too, so that the writes to 
REG_MDP5_INTF_TIMING_ENGINE_EN in the patch "Make the intf connection in 
config module" access the correct registers.

Archit

> + },
> + /* TODO enable .intfs[] with [1] = INTF_DSI, once DSI is implemented */
> + .max_clk = 32000,
> +};
> +
>   static const struct mdp5_cfg_handler cfg_handlers[] = {
>   { .revision = 0, .config = { .hw = _config } },
>   { .revision = 2, .config = { .hw = _config } },
>   { .revision = 3, .config = { .hw = _config } },
> + { .revision = 6, .config = { .hw = _config } },
>   };
>
>
>

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

[RFC PATCH 2/3] arm/exynos/pm_domains: add support for async-bridge clocks

[Sylwester Nawrocki]

On 05/02/15 13:35, Andrzej Hajda wrote:
> Since Exynos5420 there are async-bridges (ASB) between different IPs. These
> bridges must be operational during power domain on/off, ie. clocks used
> by these bridges should be enabled.
> This patch enabled these clocks during domain on/off.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Sylwester Nawrocki 

> ---
>  arch/arm/mach-exynos/pm_domains.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/pm_domains.c 
> b/arch/arm/mach-exynos/pm_domains.c
> index 0e2bc36..ecff522 100644
> --- a/arch/arm/mach-exynos/pm_domains.c
> +++ b/arch/arm/mach-exynos/pm_domains.c
> @@ -37,6 +37,7 @@ struct exynos_pm_domain {
>   struct clk *oscclk;
>   struct clk *clk[MAX_CLK_PER_DOMAIN];
>   struct clk *pclk[MAX_CLK_PER_DOMAIN];
> + struct clk *asb_clk[MAX_CLK_PER_DOMAIN];
>  };
>  
>  static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
> @@ -45,14 +46,19 @@ static int exynos_pd_power(struct generic_pm_domain 
> *domain, bool power_on)
>   void __iomem *base;
>   u32 timeout, pwr;
>   char *op;
> + int i;
>  
>   pd = container_of(domain, struct exynos_pm_domain, pd);
>   base = pd->base;
>  
> + for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
> + if (IS_ERR(pd->asb_clk[i]))
> + break;
> + clk_prepare_enable(pd->asb_clk[i]);
> + }
> +
>   /* Set oscclk before powering off a domain*/
>   if (!power_on) {
> - int i;
> -
>   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
>   if (IS_ERR(pd->clk[i]))
>   break;
> @@ -81,8 +87,6 @@ static int exynos_pd_power(struct generic_pm_domain 
> *domain, bool power_on)
>  
>   /* Restore clocks after powering on a domain*/
>   if (power_on) {
> - int i;
> -
>   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
>   if (IS_ERR(pd->clk[i]))
>   break;
> @@ -92,6 +96,12 @@ static int exynos_pd_power(struct generic_pm_domain 
> *domain, bool power_on)
>   }
>   }
>  
> + for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
> + if (IS_ERR(pd->asb_clk[i]))
> + break;
> + clk_disable_unprepare(pd->asb_clk[i]);
> + }
> +
>   return 0;
>  }
>  
> @@ -137,6 +147,15 @@ static __init int exynos4_pm_init_power_domain(void)
>   pd->pd.power_off = exynos_pd_power_off;
>   pd->pd.power_on = exynos_pd_power_on;
>  
> + for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
> + char clk_name[8];
> +
> + snprintf(clk_name, sizeof(clk_name), "asb%d", i);
> + pd->asb_clk[i] = clk_get(dev, clk_name);
> + if (IS_ERR(pd->asb_clk[i]))
> + break;
> + }
> +
>   pd->oscclk = clk_get(dev, "oscclk");
>   if (IS_ERR(pd->oscclk))
>   goto no_clk;
> 


-- 
Sylwester Nawrocki
Samsung R Institute Poland

[RFC PATCH v2 3/3] ARM: dts: exynos5420: add async-bridge clocks to disp1 power domain

[Sylwester Nawrocki]

On 06/02/15 11:55, Andrzej Hajda wrote:
> FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
> therefore their clocks should be enabled during power domain switch.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index e1fa800..58579f5 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -293,9 +293,11 @@
>< CLK_MOUT_SW_ACLK300>,
>< CLK_MOUT_USER_ACLK300_DISP1>,
>< CLK_MOUT_SW_ACLK400>,
> -  < CLK_MOUT_USER_ACLK400_DISP1>;
> +  < CLK_MOUT_USER_ACLK400_DISP1>,
> +  < CLK_FIMD1>, < CLK_MIXER>;
>   clock-names = "oscclk", "pclk0", "clk0",
> -   "pclk1", "clk1", "pclk2", "clk2";
> +   "pclk1", "clk1", "pclk2", "clk2",
> +   "asb0", "asb1";
>   };

In general I don't like those clock/clock-names properties in the power
domain nodes, since the power domains are not really consumers of those
clocks. However these clocks are essential for the exynos power domains
operation. There are more dependencies between the clocks and the power
domains which adding of those properties does not cover. And we'll need
to address those dependencies somehow.
Anyway, the subject patch looks OK to me, given that support for clocks/
clock-names in the exynos power domain device nodes has been merged
for quite long already.
The entire feature has been merged without PM or clk subsystem
maintainer ACK, I don't see a reason not to merge this small addition
of more clocks, especially that it fixes a real bug.

Please feel free to add:
Reviewed-by: Sylwester Nawrocki 

-- 
Regards,
Sylwester

[Beignet] [PATCH 2/2 v2] Query the driver directly for compute units and subslice

[Jeff McGee]

On Thu, Mar 12, 2015 at 10:08:54AM +0800, Zhigang Gong wrote:
> LGTM,
> 
> Reviewed-by: Zhigang Gong 
> 
> Thanks.
> 

Thanks for the review, Zhigang.

With beignet portion reviewed, review should be able to proceed for
the i915, libdrm, and igt parts. These are all quite simple. Can someone(s)
please review?

-Jeff

[Beignet] [Intel-gfx] [PATCH i-g-t 2/2] configure: Bump required libdrm version to 2.4.60

[Jeff McGee]

On Wed, Mar 11, 2015 at 08:21:36AM +0100, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 01:06:44PM -0700, Jeff McGee wrote:
> > On Tue, Mar 10, 2015 at 07:47:03PM +0100, Daniel Vetter wrote:
> > > On Tue, Mar 10, 2015 at 01:58:52PM -0400, Rob Clark wrote:
> > > > On Tue, Mar 10, 2015 at 12:59 PM, Jeff McGee  
> > > > wrote:
> > > > > On Tue, Mar 10, 2015 at 08:37:30AM +0100, Daniel Vetter wrote:
> > > > >> On Mon, Mar 09, 2015 at 04:41:02PM -0700, jeff.mcgee at intel.com 
> > > > >> wrote:
> > > > >> > From: Jeff McGee 
> > > > >> >
> > > > >> > tests/core_getparams needs the new libdrm interfaces for
> > > > >> > querying subslice and EU counts.
> > > > >> >
> > > > >> > For: VIZ-4636
> > > > >> > Signed-off-by: Jeff McGee 
> > > > >> > ---
> > > > >> >  configure.ac | 2 +-
> > > > >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >> >
> > > > >> > diff --git a/configure.ac b/configure.ac
> > > > >> > index 16d6a2e..88a1c3d 100644
> > > > >> > --- a/configure.ac
> > > > >> > +++ b/configure.ac
> > > > >> > @@ -82,7 +82,7 @@ if test "x$GCC" = "xyes"; then
> > > > >> >  fi
> > > > >> >  AC_SUBST(ASSEMBLER_WARN_CFLAGS)
> > > > >> >
> > > > >> > -PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.52 libdrm])
> > > > >> > +PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.60 libdrm])
> > > > >>
> > > > >> Please don't and instead copypaste the new structs/defines with a 
> > > > >> local_
> > > > >> prefix like we do it for all the other new igt testcases. Forcing 
> > > > >> libdrm
> > > > >> to get updated for igt all the time can get annoying fast.
> > > > >> -Daniel
> > > > >>
> > > > > In this case I'm trying to exercise new API functions in libdrm which
> > > > > wrap the GETPARAM ioctl. Would you rather me bypass the wrapper to
> > > > > avoid requiring updated libdrm? I can do that, but it fails to test 
> > > > > the
> > > > > complete path that client would use.
> > > > 
> > > > 
> > > > Am I missing something, or does 2.4.60 not exist yet?
> > > > 
> > > > That said dependency bumps for igt seem like less of an issue than
> > > > dependency bumps for mesa..  I mean if you are using igt you are
> > > > probably on the latest anyways..  I'm not sure why Daniel is so
> > > > concerned about that..
> > > > 
> > > > (but dependency bumps to something that doesn't exist yet should
> > > > perhaps be avoided)
> > > 
> > > I'd like to avoid massive depency loops for igt tests so that I can merge
> > > the testcase right when the patches land in -nightly. Otherwise there's
> > > always a small delay involved where regression can creep in. Also if I
> > > have to update libdrm every time I update igt that's annoying since
> > > without that I don't have to install/update anything at all - I run igt
> > > in-place. And we've used the LOCAL_ prefixes for pretty much every abi
> > > addition in igt tests thus far.
> > > -Daniel
> > 
> > I understand that and it certainly makes sense when libdrm is only
> > providing defines or structs. But as I said, in this case there is
> > code in libdrm (the wrapper) that we could test as part of the
> > complete path. Are you recommending that I implement duplicate
> > wrapper functions in igt with the local prefix?
> 
> Sorry I totally didn't realize that. Generally we don't have a lot of igt
> testcase for libdrm really, imo it's usually simpler to just add the
> interface to each part. Since this is such a simple one there's no need to
> have a low-level test and the libdrm test on top, but that's what I'd do
> if there's something worth testing in libdrm. Because for complex
> functionality I really want to get the bare-metal tests in together with
> the kernel part. Stalling for libdrm release could take longer.
> 
> And yes, personally I'd just have open-coded the getparam call here in
> igt, but that's just a bikeshed.
> -Daniel
> -- 

Scratch this patch. I just sent v2 of the previous patch that removes
the dependency on libdrm update.
-Jeff

[PATCH i-g-t v2] tests/core_getparams: Create new test core_getparams

[jeff.mc...@intel.com]

From: Jeff McGee 

New test core_getparams consists of 2 subtests, each one testing
the ability of userspace to query the correct value of a GT config
attribute: subslice total or EU total. drm/i915 implementation of
these queries is required for Cherryview and Gen9+ devices (non-
simulated).

v2: Duplicate small amount of new libdrm functionality to avoid
bumping libdrm version requirement (Daniel). Convert some
igt_asserts to the appropriate comparison variants. Add a
test description.

For: VIZ-4636
Signed-off-by: Jeff McGee 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/core_getparams.c | 167 +
 3 files changed, 169 insertions(+)
 create mode 100644 tests/core_getparams.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 426cc67..c742308 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,6 +1,7 @@
 # Please keep sorted alphabetically
 core_get_client_auth
 core_getclient
+core_getparams
 core_getstats
 core_getversion
 drm_import_export
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 51e8376..999c8f8 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -15,6 +15,7 @@ NOUVEAU_TESTS_M = \

 TESTS_progs_M = \
core_get_client_auth \
+   core_getparams \
drv_suspend \
drv_hangman \
gem_bad_reloc \
diff --git a/tests/core_getparams.c b/tests/core_getparams.c
new file mode 100644
index 000..2855d06
--- /dev/null
+++ b/tests/core_getparams.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * 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 (including the next
+ * paragraph) 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 BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Jeff McGee 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "drmtest.h"
+#include "intel_chipset.h"
+#include "intel_bufmgr.h"
+
+IGT_TEST_DESCRIPTION("Tests the export of parameters via 
DRM_IOCTL_I915_GETPARAM\n");
+
+int drm_fd;
+int devid;
+
+static void
+init(void)
+{
+   drm_fd = drm_open_any();
+   devid = intel_get_drm_devid(drm_fd);
+}
+
+static void
+deinit(void)
+{
+   close(drm_fd);
+}
+
+#define LOCAL_I915_PARAM_SUBSLICE_TOTAL33
+#define LOCAL_I915_PARAM_EU_TOTAL  34
+
+static int
+getparam(int param, int *value)
+{
+   drm_i915_getparam_t gp;
+   int ret;
+
+   memset(, 0, sizeof(gp));
+   gp.value = value;
+   gp.param = param;
+   ret = drmIoctl(drm_fd, DRM_IOCTL_I915_GETPARAM, );
+   if (ret)
+   return -errno;
+
+   return 0;
+}
+
+static void
+subslice_total(void)
+{
+   unsigned int subslice_total = 0;
+   int ret;
+
+   ret = getparam(I915_PARAM_SUBSLICE_TOTAL, (int*)_total);
+
+   if (ret) {
+   /*
+* These devices are not required to implement the
+* interface. If they do not, -ENODEV must be returned.
+   */
+   if ((intel_gen(devid) < 8) ||
+   IS_BROADWELL(devid) ||
+   igt_run_in_simulation()) {
+   igt_assert_eq(ret, -ENODEV);
+   igt_info("subslice total: unknown\n");
+   /*
+* All other devices must implement the interface, so
+* fail them if we are here.
+   */
+   } else {
+   igt_assert_neq(ret, EINVAL); /* request not recognized? 
*/
+   igt_assert_neq(ret, ENODEV); /* device not supported? */
+   igt_assert_eq(ret, 0); /* other error? */
+   }
+   } else {
+   /*
+* On success, just make sure the returned count value is
+* non-zero. The validity of the count value for the given
+* device is not checked.
+   */
+   igt_assert_neq(subslice_total, 0);
+   igt_info("subslice total: 

[PATCH 2/2] drm/exynos: fix the initialization order in FIMD

[Hyungwon Hwang]

Since commit 0f04cf8df0b20a97369cb634663fef0578cbf273 ("drm/exynos:
fix wrong pipe calculation for crtc"), fimd_clear_channel() can be
called when is_drm_iommu_supported() returns true. In this case,
the kernel is going to be panicked because crtc is not set yet.

[1.211156] [drm] Initialized drm 1.1.0 20060810
[1.216785] Unable to handle kernel NULL pointer dereference at virtual 
address 0350
[1.223415] pgd = c0004000
[1.226086] [0350] *pgd=
[1.229649] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[1.234940] Modules linked in:
[1.237982] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 
4.0.0-rc1-00062-g7a7cc79-dirty #123
[1.246136] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.252214] task: ee8c8000 ti: ee8d task.ti: ee8d
[1.257606] PC is at fimd_wait_for_vblank+0x8/0xc8
[1.262370] LR is at fimd_bind+0x138/0x1a8
[1.266450] pc : []lr : []psr: 2113
[1.266450] sp : ee8d1d28  ip :   fp : 
[1.277906] r10: 0001  r9 : c09d693c  r8 : c0a2d6a8
[1.283114] r7 : 0034  r6 : 0001  r5 : ee0bb400  r4 : ee244c10
[1.289624] r3 :   r2 :   r1 : 0001  r0 : 
[1.296135] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[1.303426] Control: 10c5387d  Table: 4000404a  DAC: 0015
[1.309154] Process swapper/0 (pid: 1, stack limit = 0xee8d0210)
[1.315143] Stack: (0xee8d1d28 to 0xee8d2000)
[1.319486] 1d20:    c0113d18 ee0bb400 ee0bb400 
ee245c30 eebbe210
[1.327645] 1d40: ee008a40 ee244c10 ee0bb400 0001 0034 c02fb834 
 c030a858
[1.335804] 1d60: ee244a10 eeb60780 ee008a40 eeb60740 ee0bb400 c03030d0 
 
[1.343963] 1d80: ee244a10 ee0bb400  eeb60740 eeb60810  
 c02f6ba4
[1.352123] 1da0: ee0bb400   c02e0500 ee244a00 c0a04a14 
ee0bb400 c02e1de4
[1.360282] 1dc0:  c030a858 0002 eeb60820 eeb60820 0002 
eeb60780 c03033d4
[1.368441] 1de0: c06e9cec  ee244a10 eeb60780 c0a056f8 c03035fc 
c0a04b24 c0a04b24
[1.376600] 1e00: ee244a10 0001 c0a049d0 c02f6d34 c0ad462c eeba0790 
 ee244a10
[1.384759] 1e20: ffed c0a049d0  c03090b0 ee244a10 c0ad462c 
c0a2d840 c03077a0
[1.392919] 1e40: eeb5e880 c024b738 08db ee244a10 c0a049d0 ee244a44 
 c09e71d8
[1.401078] 1e60: 00c6 c0307a6c c0a049d0  c03079e0 c0305ea8 
ee826e5c ee1dc7b4
[1.409237] 1e80: c0a049d0 eeb5e880 c0a058a8 c0306e2c c0896204 c0a049d0 
c06e9d10 c0a049d0
[1.417396] 1ea0: c06e9d10 c0ad4600  c0308360  0003 
c06e9d10 c02f6e14
[1.42] 1ec0:  c0896204     
 
[1.433714] 1ee0:   c02f6d5c c02f6d5c  eeb5d740 
c09e71d8 c0008a30
[1.441874] 1f00: ef7fca5e   0066  ee8d1f28 
c003ff1c c02514e8
[1.450033] 1f20: 6113  c093906c ef7fca5e 00c6 c004018c 
 c093906c
[1.458192] 1f40: c08a9690 c093840c 0006 0006 c09eb2ac c09c0d74 
0006 c09c0d54
[1.466351] 1f60: c0a3d680 c09745a0 c09d693c 00c6  c0974db4 
0006 0006
[1.474510] 1f80: c09745a0   c0692e00   
 
[1.482669] 1fa0:  c0692e08  c000f040   
 
[1.490828] 1fc0:       
 
[1.498988] 1fe0:     0013  
 
[1.507159] [] (fimd_wait_for_vblank) from [] 
(fimd_bind+0x138/0x1a8)
[1.515313] [] (fimd_bind) from [] 
(component_bind_all+0xc4/0x20c)
[1.523209] [] (component_bind_all) from [] 
(exynos_drm_load+0xa0/0x140)
[1.531632] [] (exynos_drm_load) from [] 
(drm_dev_register+0xa0/0xf4)
[1.539788] [] (drm_dev_register) from [] 
(drm_platform_init+0x44/0xcc)
[1.548121] [] (drm_platform_init) from [] 
(try_to_bring_up_master.part.1+0xc8/0x104)
[1.557668] [] (try_to_bring_up_master.part.1) from [] 
(component_master_add_with_match+0xd0/0x118)
[1.568431] [] (component_master_add_with_match) from [] 
(exynos_drm_platform_probe+0xf0/0x118)
[1.578847] [] (exynos_drm_platform_probe) from [] 
(platform_drv_probe+0x48/0x98)
[1.588052] [] (platform_drv_probe) from [] 
(driver_probe_device+0x140/0x380)
[1.596902] [] (driver_probe_device) from [] 
(__driver_attach+0x8c/0x90)
[1.605321] [] (__driver_attach) from [] 
(bus_for_each_dev+0x54/0x88)
[1.613480] [] (bus_for_each_dev) from [] 
(bus_add_driver+0xec/0x200)
[1.621640] [] (bus_add_driver) from [] 
(driver_register+0x78/0xf4)
[1.629625] [] (driver_register) from [] 
(exynos_drm_init+0xb8/0x11c)
[1.637785] [] (exynos_drm_init) from [] 
(do_one_initcall+0xac/0x1ec)
[1.645950] [] (do_one_initcall) from [] 

[PATCH 1/2] drm/exynos: add more condition to check iommu support

[Hyungwon Hwang]

Checking whether the iommu mapping allocated is not enough to determine
whether iommu is supported properly or not. Even though there is mapping,
the kernel is going to be panicked without the iommu being allocated.
So this patch adds the additional condition to check whether iommu is
really supported or not.

[0.960859] [drm] Initialized drm 1.1.0 20060810
[1.016344] [ cut here ]
[1.016453] kernel BUG at drivers/iommu/exynos-iommu.c:481!
[1.020877] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[1.026693] Modules linked in:
[1.029736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
4.0.0-rc1-00089-gb7abcc2-dirty #13
[1.037802] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.043880] task: db0c ti: db0a6000 task.ti: db0a6000
[1.049268] PC is at __exynos_sysmmu_enable+0x188/0x214
[1.054470] LR is at exynos_iommu_attach_device+0x44/0x118
[1.059940] pc : []lr : []psr: 6193
[1.059940] sp : db0a7cd8  ip :   fp : 
[1.071394] r10: a113  r9 :   r8 : db355f90
[1.076603] r7 : db25b210  r6 : db355640  r5 :   r4 : 
[1.083113] r3 :   r2 : db355640  r1 : 5b244000  r0 : db25b210
[1.089624] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[1.097001] Control: 10c5387d  Table: 4000406a  DAC: 0015
[1.102729] Process swapper/0 (pid: 1, stack limit = 0xdb0a6210)
[1.108719] Stack: (0xdb0a7cd8 to 0xdb0a8000)
[1.113060] 7cc0:   
 db355f80
[1.121223] 7ce0:  db355640 db25b210 db355f90  a113 
 c02bf1a0
[1.129383] 7d00: a113 c0115974 00200200 5b244000 db25b210 db25b210 
da822c10 db157800
[1.137542] 7d20: c0846540  c07ea3f4 c02bc8e8 db25b210 db278b40 
da822c10 c001eb48
[1.145701] 7d40: da822e10 db25b210 da822c10 c02ef444 da822e10 0001 
0001 c02f0af4
[1.153860] 7d60: da822e10 db2b0640 db2b25c0 db2b0640  c02f3850 
db157800 
[1.162019] 7d80: db157800   db278900  c02eb7d8 
db157800 
[1.170179] 7da0:  c08267b8  c02d4a44 c08e69f4 da822c00 
db157800 c02d62c4
[1.178337] 7dc0:  c07ea3f4  c02faf6c db2b07e0 db2b07e0 
0002 db2b0640
[1.186497] 7de0: db2b07d0 c02f33f0 db2b0640  c0827130 c05a5230 
da822c10 c02f34dc
[1.194656] 7e00: c08268c8 da822c10 0001 c08268c8 c0826774 c02eb97c 
da822c10 da8c0cd0
[1.202815] 7e20:  c08e6ab0 da822c10 c0826774 fdfb c02f9acc 
c08e6ab0 da822c10
[1.210974] 7e40: c08466d8  c0826774 c02f7ea4 db2b8f80 c02491a0 
db2b7a80 da822c10
[1.219134] 7e60: c0826774 da822c44 c0827458 db2b7a80 007d c02f81cc 
 c0826774
[1.227293] 7e80: c02f8140 c02f61b0 db11205c db2b93b4 c0826774 db2b8f80 
 c02f7540
[1.235452] 7ea0: c070a3ac  c08e6a84 c0826774  c08e6a84 
 c02f8a48
[1.243611] 7ec0:   c08e6a84 c02eb6f0  c070a3ac 
 
[1.251770] 7ee0:       
c08095a0 c08095a0
[1.259930] 7f00: c02eb628 c0008a3c c0584ad4 c078395c 007d dfeff9b0 
 dfeff9af
[1.268089] 7f20:  db0a7f38 dfeffb46 dfeffb37 c0584ad4 c0040f40 
395c 
[1.276248] 7f40: c0716918 dfeffb57 0006 0006 c080d618 dfeff980 
c07fee24 0006
[1.284408] 7f60: c07ea3ec c0851c80 c0851c80 007d c07ea3f4 c07aee28 
0006 0006
[1.292566] 7f80: c07ae5ac c0047e88 1c80 c03c   
 
[1.300725] 7fa0:  c048  c000f390   
 
[1.308884] 7fc0:       
 
[1.317044] 7fe0:     0013  
 ffdf
[1.325220] [] (__exynos_sysmmu_enable) from [] 
(exynos_iommu_attach_device+0x44/0x118)
[1.334928] [] (exynos_iommu_attach_device) from [] 
(iommu_attach_device+0x1c/0xc8)
[1.344305] [] (iommu_attach_device) from [] 
(arm_iommu_attach_device+0x18/0x50)
[1.353420] [] (arm_iommu_attach_device) from [] 
(drm_iommu_attach_device+0x4c/0xcc)
[1.362880] [] (drm_iommu_attach_device) from [] 
(fimd_bind+0x124/0x198)
[1.371298] [] (fimd_bind) from [] 
(component_bind_all+0xc4/0x228)
[1.379195] [] (component_bind_all) from [] 
(exynos_drm_load+0xa0/0x148)
[1.387618] [] (exynos_drm_load) from [] 
(drm_dev_register+0xa8/0x104)
[1.395864] [] (drm_dev_register) from [] 
(drm_platform_init+0x44/0xdc)
[1.404195] [] (drm_platform_init) from [] 
(try_to_bring_up_master.part.2+0xc8/0x108)
[1.413741] [] (try_to_bring_up_master.part.2) from [] 
(component_master_add_with_match+0xac/0x124)
[1.424505] [] (component_master_add_with_match) from [] 
(exynos_drm_platform_probe+0xfc/0x128)
[1.434925] [] 

[Bug 89534] GPU lockup with wine

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

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

--- Comment #4 from John  ---
I tested it and it works fine with the Intel driver (well fine... if you call
2fps or so fine... but at least no crash)

-- 
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/20150312/a72903b1/attachment.html>

[PATCH] drm/msm: Refactor msm drm driver to be able to support module

[Jilai Wang]

Each HW component's driver such as HDMI/eDP/DSI should be able to
compiled as a module which allows user to prevent this part of code
to be compiled if not needed.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 13 +--
 drivers/gpu/drm/msm/edp/edp.c  | 31 +
 drivers/gpu/drm/msm/edp/edp.h  |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi.c| 35 +++
 drivers/gpu/drm/msm/hdmi/hdmi.h|  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c|  3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 56 +++---
 drivers/gpu/drm/msm/msm_drv.c  |  6 
 drivers/gpu/drm/msm/msm_drv.h  | 29 
 drivers/gpu/drm/msm/msm_gpu.h  |  2 --
 10 files changed, 110 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index be83dee..ff7d743 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -287,12 +287,19 @@ static struct platform_driver adreno_driver = {
},
 };

-void __init adreno_register(void)
+static int __init adreno_register(void)
 {
-   platform_driver_register(_driver);
+   return platform_driver_register(_driver);
 }

-void __exit adreno_unregister(void)
+static void __exit adreno_unregister(void)
 {
platform_driver_unregister(_driver);
 }
+
+module_init(adreno_register);
+module_exit(adreno_unregister);
+
+MODULE_AUTHOR("Rob Clark 
 #include "edp.h"

+static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev);
+
 static irqreturn_t edp_irq(int irq, void *dev_id)
 {
struct msm_edp *edp = dev_id;
@@ -63,6 +66,8 @@ static struct msm_edp *edp_init(struct platform_device *pdev)
if (ret)
goto fail;

+   edp->base.modeset_init = msm_edp_modeset_init;
+
return edp;

 fail:
@@ -82,7 +87,8 @@ static int edp_bind(struct device *dev, struct device 
*master, void *data)
edp = edp_init(to_platform_device(dev));
if (IS_ERR(edp))
return PTR_ERR(edp);
-   priv->edp = edp;
+
+   priv->edp = >base;

return 0;
 }
@@ -131,26 +137,32 @@ static struct platform_driver edp_driver = {
},
 };

-void __init msm_edp_register(void)
+static int __init msm_edp_register(void)
 {
DBG("");
-   platform_driver_register(_driver);
+   return platform_driver_register(_driver);
 }

-void __exit msm_edp_unregister(void)
+static void __exit msm_edp_unregister(void)
 {
DBG("");
platform_driver_unregister(_driver);
 }

 /* Second part of initialization, the drm/kms level modeset_init */
-int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
-   struct drm_encoder *encoder)
+static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev)
 {
+   struct msm_edp *edp = container_of(base, struct msm_edp, base);
struct platform_device *pdev = edp->pdev;
struct msm_drm_private *priv = dev->dev_private;
+   struct drm_encoder *encoder;
int ret;

+   if (WARN_ON(base->num_encoders != 1))
+   return -EINVAL;
+
+   encoder = base->encoders[0];
edp->encoder = encoder;
edp->dev = dev;

@@ -206,3 +218,10 @@ fail:

return ret;
 }
+
+module_init(msm_edp_register);
+module_exit(msm_edp_unregister);
+
+MODULE_AUTHOR("Hai Li 
 #include "hdmi.h"

+static int hdmi_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev);
+
 void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
 {
uint32_t ctrl = 0;
@@ -197,6 +200,8 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
goto fail;
}

+   hdmi->base.modeset_init = hdmi_modeset_init;
+
return hdmi;

 fail:
@@ -214,13 +219,19 @@ fail:
  * should be handled in hdmi_init() so that failure happens from
  * hdmi sub-device's probe.
  */
-int hdmi_modeset_init(struct hdmi *hdmi,
-   struct drm_device *dev, struct drm_encoder *encoder)
+static int hdmi_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev)
 {
+   struct hdmi *hdmi = container_of(base, struct hdmi, base);
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = hdmi->pdev;
+   struct drm_encoder *encoder;
int ret;

+   if (WARN_ON(base->num_encoders != 1))
+   return -EINVAL;
+
+   encoder = base->encoders[0];
hdmi->dev = dev;
hdmi->encoder = encoder;

@@ -439,7 +450,8 @@ static int hdmi_bind(struct device *dev, struct device 
*master, void *data)
hdmi = hdmi_init(to_platform_device(dev));
if (IS_ERR(hdmi))
return PTR_ERR(hdmi);
-   priv->hdmi = hdmi;
+
+   priv->hdmi = >base;

return 0;
 }

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Lauri Kasanen]

On Thu, 12 Mar 2015 18:02:56 +0900
Michel Dänzer  wrote:

> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
> problem is really that some BOs are expected to be within a certain
> range from the beginning of VRAM, but lpfn isn't set accordingly. It
> would be better to fix that by setting lpfn directly than indirectly via
> RADEON_GEM_CPU_ACCESS.
> 
> 
> Anyway, since this isn't the first bug which prevents
> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
> wonder if its performance impact should be re-evaluated. Lauri?

I'm sorry, I'm not in a place where I could spend the time to redo the
benchmarks.

If it causes too many issues it is of course easy to disable, but so
far the issues shown have not been caused by it - it merely exposed
wrong settings/bugs elsewhere. From this POV I would say it's good to
have it enabled, to stress the various parts.

This doesn't warm the heart of the guy with flicker after suspend, so
perhaps a kernel module parameter to disable it (defaulting to enabled)?

- Lauri

[PATCH 0/7] drm/exynos: clean ups

[Gustavo Padovan]

2015-03-12 Inki Dae :

> On 2015년 02월 19일 22:22, Gustavo Padovan wrote:
> > From: Gustavo Padovan 
> >
> > Hi,
> >
> > Here goes some clean ups to the exynos drivers. The main clean ups is
> > the presetting and zpos making the property immutable and the removal
> > of *_win_data structures.
> 
> With your cleanup patch set, the plane test doesn't work. Have you ever
> tested plane feature with modetest application?
> 
> I typed like below and it looks like no problem but I cannot see
> anything on Panel except for cute four penguins.
> 
> # modetest -P 29:100x100+0+0
> trying to open device 'i915'...failed.
> trying to open device 'radeon'...failed.
> trying to open device 'nouveau'...failed.
> trying to open device 'vmwgfx'...failed.
> trying to open device 'omapdrm'...failed.
> trying to open device 'exynos'...success.
> testing 100x100 at XR24 overlay plane 25
> 
> And for two plane test,
> 
> # modetest -P 29:100x100+0+0 -P 29:100x100+0+100
> trying to open device 'i915'...failed.
> trying to open device 'radeon'...failed.
> trying to open device 'nouveau'...failed.
> trying to open device 'vmwgfx'...failed.
> trying to open device 'omapdrm'...failed.
> trying to open device 'exynos'...success.
> testing 100x100 at XR24 overlay plane 25
> testing 100x100 at XR24 overlay plane 26
> 
> Still no screen.

Okay, I'll check on that. I was using a test app we wrote here.
I'll test this again with modetest too.

Gustavo

[PATCH 1/2] dt-bindings: drm/bridge: Add IT6151 bridge chip driver bindings.

[Matthias Brugger]

2015-03-11 7:18 GMT+01:00 CK Hu :
> Add devicetree bindings for IT6151 MIPI to eDP bridge chip driver.
>
> Signed-off-by: CK Hu 
> Signed-off-by: Jitao Shi 

Please use scripts/get_maintainer.pl for all people to which send the
next version of the patch set.

Thanks,
Matthias

> ---
>  Documentation/devicetree/bindings/drm/bridge/it6151.txt | 15 +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/it6151.txt
>
> diff --git a/Documentation/devicetree/bindings/drm/bridge/it6151.txt 
> b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
> new file mode 100644
> index 000..ad0ad60
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/bridge/it6151.txt
> @@ -0,0 +1,15 @@
> +it6151 bridge bindings
> +
> +Required properties:
> +   - compatible: "ite,it6151"
> +   - reg: i2c address of the bridge's dp tx.
> +   - rxreg: i2c address of the bridge's mipi rx.
> +   - reset-gpio: OF device-tree gpio specification
> +
> +Example:
> +   ite6151: edp-bridge at 5c {
> +   compatible = "ite,it6151";
> +   reg = <0x5c>;
> +   rxreg = <0x6c>;
> +   reset-gpio = < 94 GPIO_ACTIVE_HIGH>;
> +   };
> --
> 1.8.1.1.dirty
>
>
> ___
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek



-- 
motzblog.wordpress.com

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Oded Gabbay]

On 03/12/2015 11:23 AM, Christian König wrote:
> On 12.03.2015 10:02, Michel Dänzer wrote:
>> On 12.03.2015 06:14, Alex Deucher wrote:
>>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
>>> wrote:
 On Wed, Mar 11, 2015 at 2:21 PM, Christian König
  wrote:
> On 11.03.2015 16:44, Alex Deucher wrote:
>> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>> uses the ttm bo size to determine when to select top down
>> allocation but since the ttm bo is not initialized yet the
>> check is always false.
>>
>> Noticed-by: Oded Gabbay 
>> Signed-off-by: Alex Deucher 
>> Cc: stable at vger.kernel.org
>
> And I was already wondering why the heck the BOs always made this
> ping/pong
> in memory after creation.
>
> Patch is Reviewed-by: Christian König 
 And fixing that promptly broke VCE due to vram location requirements.
 Updated patch attached.  Thoughts?
>>> And one more take to make things a bit more explicit for static kernel
>>> driver allocations.
>> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
>> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
>> problem is really that some BOs are expected to be within a certain
>> range from the beginning of VRAM, but lpfn isn't set accordingly. It
>> would be better to fix that by setting lpfn directly than indirectly via
>> RADEON_GEM_CPU_ACCESS.
> 
> Yeah, agree. We should probably try to find the root cause of this instead.
> 
> As far as I know VCE has no documented limitation on where buffers are
> placed (unlike UVD). So this is a bit strange. Are you sure that it isn't
> UVD which breaks here?
> 
> Regards,
> Christian.
I noticed this bug when trying to allocate very large BOs (385MB) from the
other side of VRAM.
However, even with this fix, the following scenario still fails:
1. Allocate BO of 385MB on VRAM with no CPU access.
2. Map it to VRAM
3. Allocate second BO of 385MB on VRAM with no CPU access

The last step fails as the ttm can't find a place to put this second BO. I
suspect the Top-Down thing isn't being respected at all by the
creation/pinning of BO.

I think that what happens is that the first BO is pinned right after the
first 256 MB, instead of pinning it at the end of the VRAM.
Then, when trying to create the second BO, there is no room for it, as there
is only 256MB before the first BO, and 383MB after the first BO.

I need to debug it further, but will probably only do that on Sunday.

Oded

> 
>>
>>
>> Anyway, since this isn't the first bug which prevents
>> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
>> wonder if its performance impact should be re-evaluated. Lauri?
>>
>>
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 04/15] drm: bridge/dw_hdmi: add identification registers parse and record

[Philipp Zabel]

Am Samstag, den 28.02.2015, 21:35 -0500 schrieb Yakir Yang:
> By parsing the identification registers we can know what functions
> are present on the hdmi ip.
> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4:
> -Correct phy_type assignment bug
> 
> Changes in v3:
> - Add ID registers parse and record
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/dw_hdmi.c | 59 
> 
>  drivers/gpu/drm/bridge/dw_hdmi.h | 23 
>  2 files changed, 82 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c 
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 08f10da..937beed 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -79,6 +79,23 @@ static const u16 csc_coeff_rgb_in_eitu709[3][4] = {
>   { 0x6756, 0x78ab, 0x2000, 0x0200 }
>  };
>  
> +struct hdmi_id {
> + u8 design;
> + u8 revision;
> +
> + bool prepen;
> + bool audspdif;
> + bool audi2s;
> + bool hdmi14;
> + bool csc;
> + bool hdcp;
> + bool hdmi20;
> + bool confapb;
> + bool ahbauddma;
> + bool gpaud;
> + u8 phy_type;
> +};
>
>  struct hdmi_vmode {
>   bool mdvi;
>   bool mhsyncpolarity;
> @@ -111,6 +128,8 @@ struct dw_hdmi {
>   struct clk *isfr_clk;
>   struct clk *iahb_clk;
>  
> + struct hdmi_id id;
> +
>   struct hdmi_data_info hdmi_data;
>   const struct dw_hdmi_plat_data *plat_data;
>  
> @@ -1259,6 +1278,36 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
> drm_display_mode *mode)
>   return 0;
>  }
>  
> +static void hdmi_parse_id(struct dw_hdmi *hdmi)
> +{
> + u8 config0_id, config1_id, config2_id, config3_id;
> +
> + config0_id = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
> + config1_id = hdmi_readb(hdmi, HDMI_CONFIG1_ID);
> + config2_id = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> + config3_id = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
> +
> + hdmi->id.prepen = config0_id & HDMI_CONFIG0_ID_PREPEN ? true : false;
> + hdmi->id.audi2s = config0_id & HDMI_CONFIG0_ID_AUDI2S ? true : false;
> + hdmi->id.hdmi14 = config0_id & HDMI_CONFIG0_ID_HDMI14 ? true : false;
> + hdmi->id.hdcp = config0_id & HDMI_CONFIG0_ID_HDCP ? true : false;
> + hdmi->id.csc = config0_id & HDMI_CONFIG0_ID_CSC ? true : false;
> + hdmi->id.audspdif = config0_id & HDMI_CONFIG0_ID_AUDSPDIF ?
> + true : false;
> +
> + hdmi->id.confapb = config1_id & HDMI_CONFIG1_ID_CONFAPB ? true : false;
> + hdmi->id.hdmi20 = config1_id & HDMI_CONFIG1_ID_HDMI20 ? true : false;
> +
> + hdmi->id.phy_type = config2_id;
> +
> + hdmi->id.gpaud = config3_id & HDMI_CONFIG3_ID_GPAUD ? true : false;
> + hdmi->id.ahbauddma = config3_id & HDMI_CONFIG3_ID_AHBAUDDMA ?
> +  true : false;
> +
> + hdmi->id.design = hdmi_readb(hdmi, HDMI_DESIGN_ID);
> + hdmi->id.revision = hdmi_readb(hdmi, HDMI_REVISION_ID);
> +}

What is the purpose of creating a copy of all the feature bits? As far
as I can tell you are only ever using hdmi_id.design afterwards.

regards
Philipp

[PATCH v4 03/15] drm: rockchip/dw_hdmi_rockchip: add resume/suspend support

[Philipp Zabel]

Am Samstag, den 28.02.2015, 21:32 -0500 schrieb Yakir Yang:
> Signed-off-by: Yakir Yang 
> ---
> Changes in v4: None
> Changes in v3:
> - Setting the .pm member instead of suspend/resume
> 
> Changes in v2:
> - Add suspend/resume support for dw_hdmi_rockchip driver
> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index d236faa..fc1d02e 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -323,11 +323,27 @@ static int dw_hdmi_rockchip_remove(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> +static int dw_hdmi_rockchip_suspend(struct device *dev)
> +{
> + return dw_hdmi_suspend(dev);
> +}
> +
> +static int dw_hdmi_rockchip_resume(struct device *dev)
> +{
> + return dw_hdmi_resume(dev);
> +}

You could just skip dw_hdmi_rockchip_suspend/resume and
set .suspend/.resume in dw_hdmi_rockchip_pm directly to
dw_hdmi_suspend/resume.

> +static const struct dev_pm_ops dw_hdmi_rockchip_pm = {
> + .resume = dw_hdmi_rockchip_resume,
> + .suspend = dw_hdmi_rockchip_suspend,
> +};
> +
>  static struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
>   .probe  = dw_hdmi_rockchip_probe,
>   .remove = dw_hdmi_rockchip_remove,
>   .driver = {
>   .name = "dwhdmi-rockchip",
> + .pm = _hdmi_rockchip_pm,
>   .of_match_table = dw_hdmi_rockchip_dt_ids,
>   },
>  };

regards
Philipp

[PATCH v4 02/15] drm: bridge/dw_hdmi: wrap irq control in fucntions

[Philipp Zabel]

Hi Yakir,

Am Samstag, den 28.02.2015, 21:28 -0500 schrieb Yakir Yang:
> Wrap irq control in functions, and then we can call in
> dw_hdmi_bind/dw_hdmi_unbind/dw_hdmi_resume/dw_hdmi_suspend
> functions.
> 
> Signed-off-by: Yakir Yang 
[...]
> @@ -1702,17 +1722,8 @@ EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
>  int dw_hdmi_suspend(struct device *dev)
>  {
>   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
> - u8 ih_mute;
> -
> - /* Disable all interrupts */
> - hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
> -
> -  /* Disable top level interrupt bits in HDMI block */
> - ih_mute = hdmi_readb(hdmi, HDMI_IH_MUTE) |
> -   HDMI_IH_MUTE_MUTE_WAKEUP_INTERRUPT |
> -   HDMI_IH_MUTE_MUTE_ALL_INTERRUPT;
>  
> - hdmi_writeb(hdmi, ih_mute, HDMI_IH_MUTE);
> + hdmi_mute_interrupts(hdmi);
>  
>   return 0;
>  }
> @@ -1722,19 +1733,7 @@ int dw_hdmi_resume(struct device *dev)
>  {
>   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
>  
> - /*
> -  * Configure registers related to HDMI interrupt
> -  * generation before registering IRQ.
> -  */
> - hdmi_writeb(hdmi, HDMI_PHY_HPD, HDMI_PHY_POL0);
> -
> - /* Clear Hotplug interrupts */
> - hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD, HDMI_IH_PHY_STAT0);
> -
> - dw_hdmi_fb_registered(hdmi);
> -
> - /* Unmute interrupts */
> - hdmi_writeb(hdmi, ~HDMI_IH_PHY_STAT0_HPD, HDMI_IH_MUTE_PHY_STAT0);
> + hdmi_unmute_interrupts(hdmi);
>  
>   return 0;
>  }

Here you remove code added in the previous patch.
It would be better to just apply patch 2 first and then rebase patch 1
on top of it.

regards
Philipp

[PATCH 2/2] drm/bridge: Add IT6151 bridge driver

[Heiko Stuebner]

Am Donnerstag, 12. März 2015, 10:00:47 schrieb Paul Bolle:
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/it6151.c
> > 
> > +#include 
> 
> This file can only be built-in. So I couldn't help but notice this
> include. And if I remove it
> make drivers/gpu/drm/bridge/it6151.o
> 
> still runs without warning or errors. Unless I've missed something
> non-obvious I'd say it is not needed.

I think the more interesting question would be, why can it only be built in 
:-) .

The drm/bridge series from Ajay Kumar [0] made it into 4.0-rc that enables 
drm-bridges to be regular platform/i2c devices, see [1] for example.

So I think any new bridge driver should use this approach and can thus also be 
build as module.


Heiko


[0] http://www.spinics.net/lists/linux-samsung-soc/msg41403.html
[1] http://www.spinics.net/lists/linux-samsung-soc/msg41406.html

[PATCH] drm/radeon: Changing number of compute pipe lines

[Oded Gabbay]

On 03/12/2015 11:04 AM, Michel Dänzer wrote:
> On 12.03.2015 17:48, Oded Gabbay wrote:
>> From: Ben Goz 
>>
>> The current CP firmware can handle Usermode Queues only on MEC1.
>> To reflect this firmware change, this commit reduces number of compute 
>> pipelines
>> to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd).
>>
>> Signed-off-by: Ben Goz 
>> Signed-off-by: Oded Gabbay 
>> ---
>>  drivers/gpu/drm/radeon/radeon_kfd.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c 
>> b/drivers/gpu/drm/radeon/radeon_kfd.c
>> index 061eaa9..122eb56 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
>> @@ -153,7 +153,7 @@ void radeon_kfd_device_init(struct radeon_device *rdev)
>>  .compute_vmid_bitmap = 0xFF00,
>>  
>>  .first_compute_pipe = 1,
>> -.compute_pipe_count = 8 - 1,
>> +.compute_pipe_count = 4 - 1,
>>  };
>>  
>>  radeon_doorbell_get_kfd_info(rdev,
>>
> 
> Does this need to be backported to 3.19? (Does the current CP microcode
> work with 3.19?)
> 
> 
Yes, I remembered that the moment after I sent the email :)
So I added the Cc stable to the patch in my repo.
Thanks for the reminder.

Oded

[PATCH v3 00/10] Use media bus formats in imx-drm and add drm panel support

[Hans Verkuil]

Hi Philipp,

On 03/12/15 10:58, Philipp Zabel wrote:
> Currently the imx-drm driver misuses the V4L2_PIX_FMT constants to describe 
> the
> pixel format on the parallel bus between display controllers and encoders. Now
> that MEDIA_BUS_FMT is available, use that instead.
> 
> I'd like to get the V4L2 maintainers' acks for the four necessary media
> bus format patches to be merged through the drm tree, if that still is the
> preferred way for the media format patches to go in together with the driver
> changes using them.

Yes, that's the preferred way.

For patches 1-5:

Acked-by: Hans Verkuil 

Regards,

Hans

> 
> The two drm/imx core patches replace V4L2_PIX_FMT with MEDIA_BUS_FMT where
> appropriate and consolidate the variable names for clarification.
> 
> The three LDB patches depend on the of-graph helper series:
> http://permalink.gmane.org/gmane.linux.kernel/1898485
> They allow to optionally use LVDS panels with drm_panel drivers, connected to
> the LDB encoder in the device tree via of-graph endpoint links.
> 
> Changes since v2:
>  - Added explanation for component-wise padded format names (CPADHI/LO)
>  - Improved documentation (wording, spelling and syntax fixes)
>  - Also rename pixel_fmt parameter to ipu_dc_init_sync to bus_format
> (- Added linux-media to Cc for the media format patches)
> 
> regards
> Philipp
> 
> Boris Brezillion (1):
>   Add RGB444_1X12 and RGB565_1X16 media bus formats
> 
> Philipp Zabel (9):
>   Add LVDS RGB media bus formats
>   Add BGR888_1X24 and GBR888_1X24 media bus formats
>   Add YUV8_1X24 media bus format
>   Add RGB666_1X24_CPADHI media bus format
>   drm/imx: switch to use media bus formats
>   drm/imx: consolidate bus format variable names
>   drm/imx: imx-ldb: add drm_panel support
>   drm/imx: imx-ldb: reset display clock input when disabling LVDS
>   drm/imx: imx-ldb: allow to determine bus format from the connected
> panel
> 
>  Documentation/DocBook/media/v4l/subdev-formats.xml | 426 
> -
>  Documentation/devicetree/bindings/drm/imx/ldb.txt  |  62 ++-
>  drivers/gpu/drm/imx/Kconfig|   1 +
>  drivers/gpu/drm/imx/dw_hdmi-imx.c  |   2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c |  14 +-
>  drivers/gpu/drm/imx/imx-drm.h  |  10 +-
>  drivers/gpu/drm/imx/imx-ldb.c  | 196 +++---
>  drivers/gpu/drm/imx/imx-tve.c  |   6 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c   |  13 +-
>  drivers/gpu/drm/imx/parallel-display.c |  13 +-
>  drivers/gpu/ipu-v3/ipu-dc.c|  18 +-
>  include/uapi/linux/media-bus-format.h  |  13 +-
>  include/video/imx-ipu-v3.h |   2 +-
>  13 files changed, 655 insertions(+), 121 deletions(-)
> 

[PATCH v3 10/10] drm/imx: imx-ldb: allow to determine bus format from the connected panel

[Philipp Zabel]

This patch makes the fsl,data-width and fsl,data-mapping device tree
properties optional if a panel is connected to the ldb output port
via the of_graph bindings. The data mapping is determined from the
display_info.bus_format field provided by the panel.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-ldb.c | 116 +++---
 1 file changed, 63 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 544282b..abacc8f 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -63,6 +63,7 @@ struct imx_ldb_channel {
int edid_len;
struct drm_display_mode mode;
int mode_valid;
+   int bus_format;
 };

 struct bus_mux {
@@ -96,7 +97,11 @@ static int imx_ldb_connector_get_modes(struct drm_connector 
*connector)

if (imx_ldb_ch->panel && imx_ldb_ch->panel->funcs &&
imx_ldb_ch->panel->funcs->get_modes) {
+   struct drm_display_info *di = >display_info;
+
num_modes = 
imx_ldb_ch->panel->funcs->get_modes(imx_ldb_ch->panel);
+   if (!imx_ldb_ch->bus_format && di->num_bus_formats)
+   imx_ldb_ch->bus_format = di->bus_formats[0];
if (num_modes > 0)
return num_modes;
}
@@ -173,21 +178,33 @@ static void imx_ldb_encoder_prepare(struct drm_encoder 
*encoder)
 {
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
+   int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
u32 bus_format;

-   switch (imx_ldb_ch->chno) {
-   case 0:
-   bus_format = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH0_24) ?
-   MEDIA_BUS_FMT_RGB888_1X24 : MEDIA_BUS_FMT_RGB666_1X18;
+   switch (imx_ldb_ch->bus_format) {
+   default:
+   dev_warn(ldb->dev,
+"could not determine data mapping, default to 18-bit 
\"spwg\"\n");
+   /* fallthrough */
+   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+   bus_format = MEDIA_BUS_FMT_RGB666_1X18;
break;
-   case 1:
-   bus_format = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH1_24) ?
-   MEDIA_BUS_FMT_RGB888_1X24 : MEDIA_BUS_FMT_RGB666_1X18;
+   case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
+   bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+   if (imx_ldb_ch->chno == 0 || dual)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
+   if (imx_ldb_ch->chno == 1 || dual)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
break;
-   default:
-   dev_err(ldb->dev, "unable to config di%d panel format\n",
-   imx_ldb_ch->chno);
+   case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+   if (imx_ldb_ch->chno == 0 || dual)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
+LDB_BIT_MAP_CH0_JEIDA;
+   if (imx_ldb_ch->chno == 1 || dual)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
+LDB_BIT_MAP_CH1_JEIDA;
+   break;
}

imx_drm_set_bus_format(encoder, bus_format);
@@ -426,25 +443,39 @@ enum {
LVDS_BIT_MAP_JEIDA
 };

-static const char * const imx_ldb_bit_mappings[] = {
-   [LVDS_BIT_MAP_SPWG]  = "spwg",
-   [LVDS_BIT_MAP_JEIDA] = "jeida",
+struct imx_ldb_bit_mapping {
+   u32 bus_format;
+   u32 datawidth;
+   const char * const mapping;
 };

-static const int of_get_data_mapping(struct device_node *np)
+static const struct imx_ldb_bit_mapping imx_ldb_bit_mappings[] = {
+   { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,  18, "spwg" },
+   { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,  24, "spwg" },
+   { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, 24, "jeida" },
+};
+
+static u32 of_get_bus_format(struct device *dev, struct device_node *np)
 {
const char *bm;
+   u32 datawidth = 0;
int ret, i;

ret = of_property_read_string(np, "fsl,data-mapping", );
if (ret < 0)
return ret;

-   for (i = 0; i < ARRAY_SIZE(imx_ldb_bit_mappings); i++)
-   if (!strcasecmp(bm, imx_ldb_bit_mappings[i]))
-   return i;
+   of_property_read_u32(np, "fsl,data-width", );
+
+   for (i = 0; i < ARRAY_SIZE(imx_ldb_bit_mappings); i++) {
+   if (!strcasecmp(bm, imx_ldb_bit_mappings[i].mapping) &&
+   datawidth == imx_ldb_bit_mappings[i].datawidth)
+   return imx_ldb_bit_mappings[i].bus_format;
+   }
+
+   dev_err(dev, "invalid data mapping: %d-bit \"%s\"\n", datawidth, bm);

-   return -EINVAL;
+   return -ENOENT;
 }

 static struct bus_mux imx6q_lvds_mux[2] = {
@@ -481,8 +512,6 @@ static int 

[PATCH v3 09/10] drm/imx: imx-ldb: reset display clock input when disabling LVDS

[Philipp Zabel]

The LDB driver changes the attached display interface's input clock mux
to the LDB_DI clock reference. Change it back again when disabling the
LVDS display. Changing back to the PLL5 for example allows to configure
the same DI for HDMI output later.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-ldb.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 4286399..544282b 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -77,6 +77,7 @@ struct imx_ldb {
struct imx_ldb_channel channel[2];
struct clk *clk[2]; /* our own clock */
struct clk *clk_sel[4]; /* parent of display clock */
+   struct clk *clk_parent[4]; /* original parent of clk_sel */
struct clk *clk_pll[2]; /* upstream clock we can adjust */
u32 ldb_ctrl;
const struct bus_mux *lvds_mux;
@@ -287,6 +288,7 @@ static void imx_ldb_encoder_disable(struct drm_encoder 
*encoder)
 {
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
+   int mux, ret;

/*
 * imx_ldb_encoder_disable is called by
@@ -314,6 +316,28 @@ static void imx_ldb_encoder_disable(struct drm_encoder 
*encoder)
clk_disable_unprepare(ldb->clk[1]);
}

+   if (ldb->lvds_mux) {
+   const struct bus_mux *lvds_mux = NULL;
+
+   if (imx_ldb_ch == >channel[0])
+   lvds_mux = >lvds_mux[0];
+   else if (imx_ldb_ch == >channel[1])
+   lvds_mux = >lvds_mux[1];
+
+   regmap_read(ldb->regmap, lvds_mux->reg, );
+   mux &= lvds_mux->mask;
+   mux >>= lvds_mux->shift;
+   } else {
+   mux = (imx_ldb_ch == >channel[0]) ? 0 : 1;
+   }
+
+   /* set display clock mux back to original input clock */
+   ret = clk_set_parent(ldb->clk_sel[mux], ldb->clk_parent[mux]);
+   if (ret)
+   dev_err(ldb->dev,
+   "unable to set di%d parent clock to original parent\n",
+   mux);
+
drm_panel_unprepare(imx_ldb_ch->panel);
 }

@@ -499,6 +523,8 @@ static int imx_ldb_bind(struct device *dev, struct device 
*master, void *data)
imx_ldb->clk_sel[i] = NULL;
break;
}
+
+   imx_ldb->clk_parent[i] = clk_get_parent(imx_ldb->clk_sel[i]);
}
if (i == 0)
return ret;
-- 
2.1.4

[PATCH v3 08/10] drm/imx: imx-ldb: add drm_panel support

[Philipp Zabel]

This patch allows to optionally attach the lvds-channel to a panel
supported by a drm_panel driver using of-graph bindings, instead of
supplying the modes via display-timings in the device tree.

This depends on of_graph_get_port_by_id and uses the OF graph to
link the optional DRM panel to the LDB lvds-channel. The output
port number is 1 on devices without the 4-port input multiplexer
(i.MX5) and 4 on devices with the mux (i.MX6).

Before:

ldb {
...

lvds-channel at 0 {
...

display-timings {
native-timing = <>;
timing1: etm0700g0dh6 {
hactive = <800>;
vactive = <480>;
clock-frequency = <3326>;
hsync-len = <128>;
hback-porch = <88>;
hfront-porch = <40>;
vsync-len = <2>;
vback-porch = <33>;
vfront-porch = <10>;
hsync-active = <0>;
vsync-active = <0>;
...
};
};
...
};
};

After:
ldb {
...

lvds-channel at 0 {
...

port at 4 {
reg = <4>;

lvds_out: endpoint {
remote_endpoint = <_in>;
};
};
};
};

panel {
compatible = "edt,etm0700g0dh6", "simple-panel";
...

port {
panel_in: endpoint {
remote-endpoint = <_out>;
};
};
};

[Fixed build error due to missing select on DRM_PANEL --rmk]
Signed-off-by: Russell King 
Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Improved documentation (wording, spelling and syntax fixes)
---
 Documentation/devicetree/bindings/drm/imx/ldb.txt | 62 ---
 drivers/gpu/drm/imx/Kconfig   |  1 +
 drivers/gpu/drm/imx/imx-ldb.c | 48 +-
 3 files changed, 90 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/imx/ldb.txt 
b/Documentation/devicetree/bindings/drm/imx/ldb.txt
index 443bcb6..9a21366 100644
--- a/Documentation/devicetree/bindings/drm/imx/ldb.txt
+++ b/Documentation/devicetree/bindings/drm/imx/ldb.txt
@@ -44,23 +44,30 @@ Optional properties:
 LVDS Channel
 

-Each LVDS Channel has to contain a display-timings node that describes the
-video timings for the connected LVDS display. For detailed information, also
-have a look at Documentation/devicetree/bindings/video/display-timing.txt.
+Each LVDS Channel has to contain either an of graph link to a panel device node
+or a display-timings node that describes the video timings for the connected
+LVDS display as well as the fsl,data-mapping and fsl,data-width properties.

 Required properties:
  - reg : should be <0> or <1>
+ - port: Input and output port nodes with endpoint definitions as defined in
+   Documentation/devicetree/bindings/graph.txt.
+   On i.MX5, the internal two-input-multiplexer is used. Due to hardware
+   limitations, only one input port (port@[0,1]) can be used for each channel
+   (lvds-channel@[0,1], respectively).
+   On i.MX6, there should be four input ports (port@[0-3]) that correspond
+   to the four LVDS multiplexer inputs.
+   A single output port (port at 2 on i.MX5, port at 4 on i.MX6) must be 
connected
+   to a panel input port. Optionally, the output port can be left out if
+   display-timings are used instead.
+
+Optional properties (required if display-timings are used):
+ - display-timings : A node that describes the display timings as defined in
+   Documentation/devicetree/bindings/video/display-timing.txt.
  - fsl,data-mapping : should be "spwg" or "jeida"
   This describes how the color bits are laid out in the
   serialized LVDS signal.
  - fsl,data-width : should be <18> or <24>
- - port: A port node with endpoint definitions as defined in
-   Documentation/devicetree/bindings/media/video-interfaces.txt.
-   On i.MX5, the internal two-input-multiplexer is used.
-   Due to hardware limitations, only one port (port@[0,1])
-   can be used for each channel (lvds-channel@[0,1], respectively)
-   On i.MX6, there should be four ports (port@[0-3]) that 

[PATCH v3 07/10] drm/imx: consolidate bus format variable names

[Philipp Zabel]

This patch consolidates the different interface_pix_fmt, pixel_fmt, pix_fmt,
and pixfmt variables to a common name "bus_format" wherever they describe the
pixel format on the bus between display controller and encoder hardware.
At the same time, it renames imx_drm_panel_format to imx_drm_set_bus_format.

Signed-off-by: Philipp Zabel 
---
 - Also rename pixel_fmt parameter to ipu_dc_init_sync to bus_format
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c | 14 +++---
 drivers/gpu/drm/imx/imx-drm.h  | 10 +-
 drivers/gpu/drm/imx/imx-ldb.c  | 10 +-
 drivers/gpu/drm/imx/imx-tve.c  |  6 +++---
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 13 +
 drivers/gpu/drm/imx/parallel-display.c | 13 ++---
 drivers/gpu/ipu-v3/ipu-dc.c|  4 ++--
 include/video/imx-ipu-v3.h |  2 +-
 9 files changed, 35 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 61ef987..1834ac8 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -123,7 +123,7 @@ static void dw_hdmi_imx_encoder_commit(struct drm_encoder 
*encoder)

 static void dw_hdmi_imx_encoder_prepare(struct drm_encoder *encoder)
 {
-   imx_drm_panel_format(encoder, MEDIA_BUS_FMT_RGB888_1X24);
+   imx_drm_set_bus_format(encoder, MEDIA_BUS_FMT_RGB888_1X24);
 }

 static struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs = {
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index a002f53..c6f2c472 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -103,8 +103,8 @@ static struct imx_drm_crtc *imx_drm_find_crtc(struct 
drm_crtc *crtc)
return NULL;
 }

-int imx_drm_panel_format_pins(struct drm_encoder *encoder,
-   u32 interface_pix_fmt, int hsync_pin, int vsync_pin)
+int imx_drm_set_bus_format_pins(struct drm_encoder *encoder, u32 bus_format,
+   int hsync_pin, int vsync_pin)
 {
struct imx_drm_crtc_helper_funcs *helper;
struct imx_drm_crtc *imx_crtc;
@@ -116,16 +116,16 @@ int imx_drm_panel_format_pins(struct drm_encoder *encoder,
helper = _crtc->imx_drm_helper_funcs;
if (helper->set_interface_pix_fmt)
return helper->set_interface_pix_fmt(encoder->crtc,
-   interface_pix_fmt, hsync_pin, vsync_pin);
+   bus_format, hsync_pin, vsync_pin);
return 0;
 }
-EXPORT_SYMBOL_GPL(imx_drm_panel_format_pins);
+EXPORT_SYMBOL_GPL(imx_drm_set_bus_format_pins);

-int imx_drm_panel_format(struct drm_encoder *encoder, u32 interface_pix_fmt)
+int imx_drm_set_bus_format(struct drm_encoder *encoder, u32 bus_format)
 {
-   return imx_drm_panel_format_pins(encoder, interface_pix_fmt, 2, 3);
+   return imx_drm_set_bus_format_pins(encoder, bus_format, 2, 3);
 }
-EXPORT_SYMBOL_GPL(imx_drm_panel_format);
+EXPORT_SYMBOL_GPL(imx_drm_set_bus_format);

 int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc)
 {
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 3c559cc..28e776d 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -18,7 +18,7 @@ struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
int (*set_interface_pix_fmt)(struct drm_crtc *crtc,
-   u32 pix_fmt, int hsync_pin, int vsync_pin);
+   u32 bus_format, int hsync_pin, int vsync_pin);
const struct drm_crtc_helper_funcs *crtc_helper_funcs;
const struct drm_crtc_funcs *crtc_funcs;
 };
@@ -40,10 +40,10 @@ void imx_drm_mode_config_init(struct drm_device *drm);

 struct drm_gem_cma_object *imx_drm_fb_get_obj(struct drm_framebuffer *fb);

-int imx_drm_panel_format_pins(struct drm_encoder *encoder,
-   u32 interface_pix_fmt, int hsync_pin, int vsync_pin);
-int imx_drm_panel_format(struct drm_encoder *encoder,
-   u32 interface_pix_fmt);
+int imx_drm_set_bus_format_pins(struct drm_encoder *encoder,
+   u32 bus_format, int hsync_pin, int vsync_pin);
+int imx_drm_set_bus_format(struct drm_encoder *encoder,
+   u32 bus_format);

 int imx_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index f9ec17a..cd062b1 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -163,24 +163,24 @@ static void imx_ldb_encoder_prepare(struct drm_encoder 
*encoder)
 {
struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
struct imx_ldb *ldb = imx_ldb_ch->ldb;
-   u32 pixel_fmt;
+   u32 bus_format;

switch (imx_ldb_ch->chno) {
case 0:
-   

[PATCH v3 06/10] drm/imx: switch to use media bus formats

[Philipp Zabel]

imx-drm internally misused the V4L2_PIX_FMT constants, which are supposed to
describe the pixel format of frame buffers in memory, to describe the pixel
format on the bus between the display controller and the encoder hardware.
Now that MEDIA_BUS_FMT constants are available to drm drivers, use those
instead.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  2 +-
 drivers/gpu/drm/imx/imx-ldb.c  |  6 +++---
 drivers/gpu/drm/imx/imx-tve.c  |  4 ++--
 drivers/gpu/drm/imx/parallel-display.c |  8 
 drivers/gpu/ipu-v3/ipu-dc.c| 16 
 5 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 87fe8ed..61ef987 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -123,7 +123,7 @@ static void dw_hdmi_imx_encoder_commit(struct drm_encoder 
*encoder)

 static void dw_hdmi_imx_encoder_prepare(struct drm_encoder *encoder)
 {
-   imx_drm_panel_format(encoder, V4L2_PIX_FMT_RGB24);
+   imx_drm_panel_format(encoder, MEDIA_BUS_FMT_RGB888_1X24);
 }

 static struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs = {
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 2d6dc94..f9ec17a 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -168,16 +168,16 @@ static void imx_ldb_encoder_prepare(struct drm_encoder 
*encoder)
switch (imx_ldb_ch->chno) {
case 0:
pixel_fmt = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH0_24) ?
-   V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+   MEDIA_BUS_FMT_RGB888_1X24 : MEDIA_BUS_FMT_RGB666_1X18;
break;
case 1:
pixel_fmt = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH1_24) ?
-   V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+   MEDIA_BUS_FMT_RGB888_1X24 : MEDIA_BUS_FMT_RGB666_1X18;
break;
default:
dev_err(ldb->dev, "unable to config di%d panel format\n",
imx_ldb_ch->chno);
-   pixel_fmt = V4L2_PIX_FMT_RGB24;
+   pixel_fmt = MEDIA_BUS_FMT_RGB888_1X24;
}

imx_drm_panel_format(encoder, pixel_fmt);
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 4216e47..bcdcb1b 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -301,11 +301,11 @@ static void imx_tve_encoder_prepare(struct drm_encoder 
*encoder)

switch (tve->mode) {
case TVE_MODE_VGA:
-   imx_drm_panel_format_pins(encoder, IPU_PIX_FMT_GBR24,
+   imx_drm_panel_format_pins(encoder, MEDIA_BUS_FMT_YUV8_1X24,
tve->hsync_pin, tve->vsync_pin);
break;
case TVE_MODE_TVOUT:
-   imx_drm_panel_format(encoder, V4L2_PIX_FMT_YUV444);
+   imx_drm_panel_format(encoder, MEDIA_BUS_FMT_YUV8_1X24);
break;
}
 }
diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index 900dda6..e645fe1 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -225,14 +225,14 @@ static int imx_pd_bind(struct device *dev, struct device 
*master, void *data)
ret = of_property_read_string(np, "interface-pix-fmt", );
if (!ret) {
if (!strcmp(fmt, "rgb24"))
-   imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB24;
+   imxpd->interface_pix_fmt = MEDIA_BUS_FMT_RGB888_1X24;
else if (!strcmp(fmt, "rgb565"))
-   imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
+   imxpd->interface_pix_fmt = MEDIA_BUS_FMT_RGB565_1X16;
else if (!strcmp(fmt, "bgr666"))
-   imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+   imxpd->interface_pix_fmt = MEDIA_BUS_FMT_RGB666_1X18;
else if (!strcmp(fmt, "lvds666"))
imxpd->interface_pix_fmt =
-   v4l2_fourcc('L', 'V', 'D', '6');
+   MEDIA_BUS_FMT_RGB666_1X24_CPADHI;
}

panel_node = of_parse_phandle(np, "fsl,panel", 0);
diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 4864f83..651c20c 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -147,20 +147,20 @@ static void dc_write_tmpl(struct ipu_dc *dc, int word, 
u32 opcode, u32 operand,
writel(reg2, priv->dc_tmpl_reg + word * 8 + 4);
 }

-static int ipu_pixfmt_to_map(u32 fmt)
+static int ipu_bus_format_to_map(u32 fmt)
 {
switch (fmt) {
-   case V4L2_PIX_FMT_RGB24:
+   case MEDIA_BUS_FMT_RGB888_1X24:
return IPU_DC_MAP_RGB24;
-   case V4L2_PIX_FMT_RGB565:
+  

[PATCH v3 05/10] Add RGB666_1X24_CPADHI media bus format

[Philipp Zabel]

Commit 9e74d2926a28 ("staging: imx-drm: add LVDS666 support for parallel
display") describes a 24-bit bus format where three 6-bit components each
take the lower part of 8 bits with the two high bits zero padded. Add a
component-wise padded media bus format RGB666_1X24_CPADHI to support this
connection.

Cc: Emil Renner Berthing 
Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Added explanation for component-wise padded format names (CPADHI/LO)
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 34 +-
 include/uapi/linux/media-bus-format.h  |  3 +-
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 8d1f624..18b71af 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -91,7 +91,9 @@ see .
For formats where the total number of bits per pixel is 
smaller
than the number of bus samples per pixel times the bus width, a padding
value stating if the bytes are padded in their most high order bits
-   (PADHI) or low order bits (PADLO).
+   (PADHI) or low order bits (PADLO). A "C" prefix is used for 
component-wise
+   padding in the most high order bits (CPADHI) or low order bits (CPADLO)
+   of each separate component.
For formats where the number of bus samples per pixel 
is larger
than 1, an endianness value stating if the pixel is transferred MSB 
first
(BE) or LSB first (LE).
@@ -480,6 +482,36 @@ see .
  b1
  b0

+   
+ MEDIA_BUS_FMT_RGB666_1X24_CPADHI
+ 0x1015
+ 
+ 
+ 0
+ 0
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+ 0
+ 0
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+ 0
+ 0
+ b5
+ b4
+ b3
+ b2
+ b1
+ b0
+   

  MEDIA_BUS_FMT_BGR888_1X24
  0x1013
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 8dbf16c..83ea46f 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,7 +33,7 @@

 #define MEDIA_BUS_FMT_FIXED0x0001

-/* RGB - next is   0x1015 */
+/* RGB - next is   0x1016 */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x100e
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -45,6 +45,7 @@
 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
 #define MEDIA_BUS_FMT_RGB565_2X8_LE0x1008
 #define MEDIA_BUS_FMT_RGB666_1X18  0x1009
+#define MEDIA_BUS_FMT_RGB666_1X24_CPADHI   0x1015
 #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG0x1010
 #define MEDIA_BUS_FMT_BGR888_1X24  0x1013
 #define MEDIA_BUS_FMT_GBR888_1X24  0x1014
-- 
2.1.4

[PATCH v3 04/10] Add YUV8_1X24 media bus format

[Philipp Zabel]

This patch adds the media bus format for a 24-bit bus format with three
8-bit YUV components.

Signed-off-by: Philipp Zabel 
Acked-by: Laurent Pinchart 
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 37 ++
 include/uapi/linux/media-bus-format.h  |  3 +-
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 805cbe1..8d1f624 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -3015,6 +3015,43 @@ see .
  u1
  u0

+   
+ MEDIA_BUS_FMT_YUV8_1X24
+ 0x2024
+ 
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ -
+ y7
+ y6
+ y5
+ y4
+ y3
+ y2
+ y1
+ y0
+ u7
+ u6
+ u5
+ u4
+ u3
+ u2
+ u1
+ u0
+ v7
+ v6
+ v5
+ v4
+ v3
+ v2
+ v1
+ v0
+   

  MEDIA_BUS_FMT_YUV10_1X30
  0x2016
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 6f6942e..8dbf16c 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -55,7 +55,7 @@
 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA   0x1012
 #define MEDIA_BUS_FMT_ARGB_1X320x100d

-/* YUV (including grey) - next is  0x2024 */
+/* YUV (including grey) - next is  0x2025 */
 #define MEDIA_BUS_FMT_Y8_1X8   0x2001
 #define MEDIA_BUS_FMT_UV8_1X8  0x2015
 #define MEDIA_BUS_FMT_UYVY8_1_5X8  0x2002
@@ -81,6 +81,7 @@
 #define MEDIA_BUS_FMT_VYUY10_1X20  0x201b
 #define MEDIA_BUS_FMT_YUYV10_1X20  0x200d
 #define MEDIA_BUS_FMT_YVYU10_1X20  0x200e
+#define MEDIA_BUS_FMT_YUV8_1X240x2024
 #define MEDIA_BUS_FMT_YUV10_1X30   0x2016
 #define MEDIA_BUS_FMT_AYUV8_1X32   0x2017
 #define MEDIA_BUS_FMT_UYVY12_2X12  0x201c
-- 
2.1.4

[PATCH v3 03/10] Add BGR888_1X24 and GBR888_1X24 media bus formats

[Philipp Zabel]

This patch adds two more 24-bit RGB formats. BGR888 is more or less common,
GBR888 is used on the internal connection between the IPU display interface
and the TVE (VGA DAC) on i.MX53 SoCs.

Signed-off-by: Philipp Zabel 
Acked-by: Laurent Pinchart 
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 60 ++
 include/uapi/linux/media-bus-format.h  |  4 +-
 2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 18449b3..805cbe1 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -480,6 +480,66 @@ see .
  b1
  b0

+   
+ MEDIA_BUS_FMT_BGR888_1X24
+ 0x1013
+ 
+ 
+ b7
+ b6
+ b5
+ b4
+ b3
+ b2
+ b1
+ b0
+ g7
+ g6
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+ r7
+ r6
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+   
+   
+ MEDIA_BUS_FMT_GBR888_1X24
+ 0x1014
+ 
+ 
+ g7
+ g6
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+ b7
+ b6
+ b5
+ b4
+ b3
+ b2
+ b1
+ b0
+ r7
+ r6
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+   

  MEDIA_BUS_FMT_RGB888_1X24
  0x100a
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 3fb9cbb..6f6942e 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,7 +33,7 @@

 #define MEDIA_BUS_FMT_FIXED0x0001

-/* RGB - next is   0x1013 */
+/* RGB - next is   0x1015 */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x100e
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -46,6 +46,8 @@
 #define MEDIA_BUS_FMT_RGB565_2X8_LE0x1008
 #define MEDIA_BUS_FMT_RGB666_1X18  0x1009
 #define MEDIA_BUS_FMT_RGB666_1X7X3_SPWG0x1010
+#define MEDIA_BUS_FMT_BGR888_1X24  0x1013
+#define MEDIA_BUS_FMT_GBR888_1X24  0x1014
 #define MEDIA_BUS_FMT_RGB888_1X24  0x100a
 #define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
 #define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
-- 
2.1.4

[PATCH v3 02/10] Add LVDS RGB media bus formats

[Philipp Zabel]

This patch adds three new RGB media bus formats that describe
18-bit or 24-bit samples transferred over an LVDS bus with three
or four differential data pairs, serialized into 7 time slots,
using standard SPWG/PSWG/VESA or JEIDA data ordering.

Signed-off-by: Philipp Zabel 
Acked-by: Sakari Ailus 
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 255 +
 include/uapi/linux/media-bus-format.h  |   5 +-
 2 files changed, 259 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 29fe601..18449b3 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -622,6 +622,261 @@ see .
  

   
+
+  On LVDS buses, usually each sample is transferred serialized in
+  seven time slots per pixel clock, on three (18-bit) or four (24-bit)
+  differential data pairs at the same time. The remaining bits are used for
+  control signals as defined by SPWG/PSWG/VESA or JEIDA standards.
+  The 24-bit RGB format serialized in seven time slots on four lanes using
+  JEIDA defined bit mapping will be named
+  MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, for example.
+  
+
+  
+   LVDS RGB formats
+   
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+   
+ Identifier
+ Code
+ 
+ 
+ Data organization
+   
+   
+ 
+ 
+ Timeslot
+ Lane
+ 3
+ 2
+ 1
+ 0
+   
+ 
+ 
+   
+ MEDIA_BUS_FMT_RGB666_1X7X3_SPWG
+ 0x1010
+ 0
+ 
+ -
+ d
+ b1
+ g0
+   
+   
+ 
+ 
+ 1
+ 
+ -
+ d
+ b0
+ r5
+   
+   
+ 
+ 
+ 2
+ 
+ -
+ d
+ g5
+ r4
+   
+   
+ 
+ 
+ 3
+ 
+ -
+ b5
+ g4
+ r3
+   
+   
+ 
+ 
+ 4
+ 
+ -
+ b4
+ g3
+ r2
+   
+   
+ 
+ 
+ 5
+ 
+ -
+ b3
+ g2
+ r1
+   
+   
+ 
+ 
+ 6
+ 
+ -
+ b2
+ g1
+ r0
+   
+   
+ MEDIA_BUS_FMT_RGB888_1X7X4_SPWG
+ 0x1011
+ 0
+ 
+ d
+ d
+ b1
+ g0
+   
+   
+ 
+ 
+ 1
+ 
+ b7
+ d
+ b0
+ r5
+   
+   
+ 
+ 
+ 2
+ 
+ b6
+ d
+ g5
+ r4
+   
+   
+ 
+ 
+ 3
+ 
+ g7
+ b5
+ g4
+ r3
+   
+   
+ 
+ 
+ 4
+ 
+ g6
+ b4
+ g3
+ r2
+   
+   
+ 
+ 
+ 5
+ 
+ r7
+ b3
+ g2
+ r1
+   
+   
+ 
+ 
+ 6
+ 
+ r6
+ b2
+ g1
+ r0
+   
+   
+ MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
+ 0x1012
+ 0
+ 
+ d
+ d
+ b3
+ g2
+   
+   
+ 
+ 
+ 1
+ 
+ b1
+ d
+ b2
+ r7
+   
+   
+ 
+ 
+ 2
+ 
+ b0
+ d
+ g7
+ r6
+   
+   
+ 
+ 
+ 3
+ 
+ g1
+ b7
+ g6
+ r5
+   
+   
+ 
+ 
+ 4
+ 
+ g0
+ b6
+ g5
+ r4
+   
+   
+ 
+ 
+ 5
+ 
+ r1
+ b5
+ g4
+ r3
+   
+   
+ 
+ 

[PATCH v3 01/10] Add RGB444_1X12 and RGB565_1X16 media bus formats

[Philipp Zabel]

From: Boris Brezillion 

Add RGB444_1X12 and RGB565_1X16 format definitions and update the
documentation.

Signed-off-by: Boris Brezillon 
Acked-by: Mauro Carvalho Chehab 
Acked-by: Sakari Ailus 
Acked-by: Laurent Pinchart 
Signed-off-by: Philipp Zabel 
---
 Documentation/DocBook/media/v4l/subdev-formats.xml | 40 ++
 include/uapi/linux/media-bus-format.h  |  4 ++-
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml 
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index c5ea868..29fe601 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -192,6 +192,24 @@ see .

  
  
+   
+ MEDIA_BUS_FMT_RGB444_1X12
+ 0x100e
+ 
+ 
+ r3
+ r2
+ r1
+ r0
+ g3
+ g2
+ g1
+ g0
+ b3
+ b2
+ b1
+ b0
+   

  MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE
  0x1001
@@ -304,6 +322,28 @@ see .
  g4
  g3

+   
+ MEDIA_BUS_FMT_RGB565_1X16
+ 0x100f
+ 
+ 
+ r4
+ r3
+ r2
+ r1
+ r0
+ g5
+ g4
+ g3
+ g2
+ g1
+ g0
+ b4
+ b3
+ b2
+ b1
+ b0
+   

  MEDIA_BUS_FMT_BGR565_2X8_BE
  0x1005
diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 23b4090..37091c6 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -33,11 +33,13 @@

 #define MEDIA_BUS_FMT_FIXED0x0001

-/* RGB - next is   0x100e */
+/* RGB - next is   0x1010 */
+#define MEDIA_BUS_FMT_RGB444_1X12  0x100e
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE  0x1004
+#define MEDIA_BUS_FMT_RGB565_1X16  0x100f
 #define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005
 #define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006
 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
-- 
2.1.4

[PATCH v3 00/10] Use media bus formats in imx-drm and add drm panel support

[Philipp Zabel]

Currently the imx-drm driver misuses the V4L2_PIX_FMT constants to describe the
pixel format on the parallel bus between display controllers and encoders. Now
that MEDIA_BUS_FMT is available, use that instead.

I'd like to get the V4L2 maintainers' acks for the four necessary media
bus format patches to be merged through the drm tree, if that still is the
preferred way for the media format patches to go in together with the driver
changes using them.

The two drm/imx core patches replace V4L2_PIX_FMT with MEDIA_BUS_FMT where
appropriate and consolidate the variable names for clarification.

The three LDB patches depend on the of-graph helper series:
http://permalink.gmane.org/gmane.linux.kernel/1898485
They allow to optionally use LVDS panels with drm_panel drivers, connected to
the LDB encoder in the device tree via of-graph endpoint links.

Changes since v2:
 - Added explanation for component-wise padded format names (CPADHI/LO)
 - Improved documentation (wording, spelling and syntax fixes)
 - Also rename pixel_fmt parameter to ipu_dc_init_sync to bus_format
(- Added linux-media to Cc for the media format patches)

regards
Philipp

Boris Brezillion (1):
  Add RGB444_1X12 and RGB565_1X16 media bus formats

Philipp Zabel (9):
  Add LVDS RGB media bus formats
  Add BGR888_1X24 and GBR888_1X24 media bus formats
  Add YUV8_1X24 media bus format
  Add RGB666_1X24_CPADHI media bus format
  drm/imx: switch to use media bus formats
  drm/imx: consolidate bus format variable names
  drm/imx: imx-ldb: add drm_panel support
  drm/imx: imx-ldb: reset display clock input when disabling LVDS
  drm/imx: imx-ldb: allow to determine bus format from the connected
panel

 Documentation/DocBook/media/v4l/subdev-formats.xml | 426 -
 Documentation/devicetree/bindings/drm/imx/ldb.txt  |  62 ++-
 drivers/gpu/drm/imx/Kconfig|   1 +
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |   2 +-
 drivers/gpu/drm/imx/imx-drm-core.c |  14 +-
 drivers/gpu/drm/imx/imx-drm.h  |  10 +-
 drivers/gpu/drm/imx/imx-ldb.c  | 196 +++---
 drivers/gpu/drm/imx/imx-tve.c  |   6 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  13 +-
 drivers/gpu/drm/imx/parallel-display.c |  13 +-
 drivers/gpu/ipu-v3/ipu-dc.c|  18 +-
 include/uapi/linux/media-bus-format.h  |  13 +-
 include/video/imx-ipu-v3.h |   2 +-
 13 files changed, 655 insertions(+), 121 deletions(-)

-- 
2.1.4

[PATCH] drm/radeon: Changing number of compute pipe lines

[Oded Gabbay]

From: Ben Goz 

The current CP firmware can handle Usermode Queues only on MEC1.
To reflect this firmware change, this commit reduces number of compute pipelines
to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd).

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/radeon_kfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c 
b/drivers/gpu/drm/radeon/radeon_kfd.c
index 061eaa9..122eb56 100644
--- a/drivers/gpu/drm/radeon/radeon_kfd.c
+++ b/drivers/gpu/drm/radeon/radeon_kfd.c
@@ -153,7 +153,7 @@ void radeon_kfd_device_init(struct radeon_device *rdev)
.compute_vmid_bitmap = 0xFF00,

.first_compute_pipe = 1,
-   .compute_pipe_count = 8 - 1,
+   .compute_pipe_count = 4 - 1,
};

radeon_doorbell_get_kfd_info(rdev,
-- 
2.1.0

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

More i915 fixes, three out of four are fixes to old bugs, cc: stable.

BR,
Jani.

The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:

  Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-03-12

for you to fetch changes up to 5e4f518959bdf8a4f9c8f80879e4a0f7a95d2cb3:

  drm/i915: Prevent TLB error on first execution on SNB (2015-03-10 15:30:23 
+0200)


Chris Wilson (2):
  drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again
  drm/i915: Prevent TLB error on first execution on SNB

Dave Gordon (1):
  drm/i915: use in_interrupt() not in_irq() to check context

Mika Kuoppala (1):
  drm/i915: Do both mt and gen6 style forcewake reset on ivb probe

 drivers/gpu/drm/i915/i915_gem.c  | 25 -
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c  |  8 +++-
 3 files changed, 28 insertions(+), 7 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Christian König]

On 12.03.2015 10:30, Oded Gabbay wrote:
>
> On 03/12/2015 11:23 AM, Christian König wrote:
>> On 12.03.2015 10:02, Michel Dänzer wrote:
>>> On 12.03.2015 06:14, Alex Deucher wrote:
 On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
 wrote:
> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>  wrote:
>> On 11.03.2015 16:44, Alex Deucher wrote:
>>> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>>> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>>> uses the ttm bo size to determine when to select top down
>>> allocation but since the ttm bo is not initialized yet the
>>> check is always false.
>>>
>>> Noticed-by: Oded Gabbay 
>>> Signed-off-by: Alex Deucher 
>>> Cc: stable at vger.kernel.org
>> And I was already wondering why the heck the BOs always made this
>> ping/pong
>> in memory after creation.
>>
>> Patch is Reviewed-by: Christian König 
> And fixing that promptly broke VCE due to vram location requirements.
> Updated patch attached.  Thoughts?
 And one more take to make things a bit more explicit for static kernel
 driver allocations.
>>> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
>>> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
>>> problem is really that some BOs are expected to be within a certain
>>> range from the beginning of VRAM, but lpfn isn't set accordingly. It
>>> would be better to fix that by setting lpfn directly than indirectly via
>>> RADEON_GEM_CPU_ACCESS.
>> Yeah, agree. We should probably try to find the root cause of this instead.
>>
>> As far as I know VCE has no documented limitation on where buffers are
>> placed (unlike UVD). So this is a bit strange. Are you sure that it isn't
>> UVD which breaks here?
>>
>> Regards,
>> Christian.
> I noticed this bug when trying to allocate very large BOs (385MB) from the
> other side of VRAM.
> However, even with this fix, the following scenario still fails:
> 1. Allocate BO of 385MB on VRAM with no CPU access.
> 2. Map it to VRAM
> 3. Allocate second BO of 385MB on VRAM with no CPU access
>
> The last step fails as the ttm can't find a place to put this second BO. I
> suspect the Top-Down thing isn't being respected at all by the
> creation/pinning of BO.
>
> I think that what happens is that the first BO is pinned right after the
> first 256 MB, instead of pinning it at the end of the VRAM.
> Then, when trying to create the second BO, there is no room for it, as there
> is only 256MB before the first BO, and 383MB after the first BO.
>
> I need to debug it further, but will probably only do that on Sunday.

What is the content of radeon_vram_mm (in debugfs) after you allocated 
the first BO?

The placement should be visible there pretty fine.

Regards,
Christian.

>
>   Oded
>
>>>
>>> Anyway, since this isn't the first bug which prevents
>>> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
>>> wonder if its performance impact should be re-evaluated. Lauri?
>>>
>>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 10:15 AM, John Hunter  wrote:
> Hi,
> I really don't  whether I am doing things on right workflow of dri-devel.
> I am new to this community and I want to help.
> Could anybody spare some time to tell me the right way .
> Thanks.

Hi John,

I don't actually see the original patch, just your reply to it..  if
you didn't already, could you git-send-email it to dri-devel?

(If you did, but were not subscribed, perhaps it is still stuck in
list moderation queue?)

BR,
-R


> John
>
> On Thu, Mar 12, 2015 at 4:02 PM, John Hunter  
> wrote:
>>
>> From: John Hunter 
>>
>> IMHO, some annotations were copypaste from somewhere else, it is
>> obviously not rightly modified. Hope I am right with that.
>> ---
>>  drivers/gpu/drm/drm_crtc.c | 115
>> ++---
>>  1 file changed, 56 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index f2d667b..7f771e9 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> drm_connector_status status)
>>  /**
>>   * drm_mode_object_get - allocate a new identifier
>>   * @dev: DRM device
>> - * @ptr: object pointer, used to generate unique ID
>> - * @type: object type
>> + * @obj: object pointer, used to generate unique ID
>> + * @obj_type: object type
>>   *
>>   * LOCKING:
>>   *
>> - * Create a unique identifier based on @ptr in @dev's identifier space.
>> Used
>> + * Create a unique identifier based on @obj in @dev's identifier space.
>> Used
>>   * for tracking modes, CRTCs and connectors.
>>   *
>>   * RETURNS:
>> @@ -245,12 +245,12 @@ again:
>>  /**
>>   * drm_mode_object_put - free an identifer
>>   * @dev: DRM device
>> - * @id: ID to free
>> + * @object: object to free
>>   *
>>   * LOCKING:
>>   * Caller must hold DRM mode_config lock.
>>   *
>> - * Free @id from @dev's unique identifier pool.
>> + * Free @object from @dev's unique identifier pool.
>>   */
>>  static void drm_mode_object_put(struct drm_device *dev,
>> struct drm_mode_object *object)
>> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
>>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>>  {
>> struct drm_device *dev = fb->dev;
>> +
>> /*
>>  * This could be moved to drm_framebuffer_remove(), but for
>>  * debugging is nice to keep around the list of fb's that are
>> -* no longer associated w/ a drm_file but are not unreferenced
>> +* no longer associated with a drm_file but are not unreferenced
>>  * yet.  (i915 and omapdrm have debugfs files which will show
>>  * this.)
>>  */
>> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
>>   * @dev: DRM device
>>   * @connector: the connector to init
>>   * @funcs: callbacks for this connector
>> - * @name: user visible name of the connector
>> + * @connector_type: type of the connector
>>   *
>>   * LOCKING:
>>   * Takes mode config lock.
>> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct
>> drm_plane *plane,
>> plane->format_count = format_count;
>> plane->possible_crtcs = possible_crtcs;
>>
>> -   /* private planes are not exposed to userspace, but depending on
>> +   /*
>> +* private planes are not exposed to userspace, but depending on
>>  * display hardware, might be convenient to allow sharing
>> programming
>>  * for the scanout engine with the crtc implementation.
>>  */
>> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct
>> drm_display_mode *out,
>>
>>  /**
>>   * drm_mode_getresources - get graphics configuration
>> - * @inode: inode from the ioctl
>> - * @filp: file * from the ioctl
>> - * @cmd: cmd from ioctl
>> - * @arg: arg from ioctl
>> + * @dev: DRM device
>> + * @data: ioctl data
>> + * @file_priv: DRM file info
>>   *
>>   * LOCKING:
>>   * Takes mode config lock.
>> @@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev,
>> void *data,
>> list_for_each(lh, >mode_config.encoder_list)
>> encoder_count++;
>> } else {
>> -
>> crtc_count = mode_group->num_crtcs;
>> connector_count = mode_group->num_connectors;
>> encoder_count = mode_group->num_encoders;
>> @@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev,
>> void *data,
>> }
>> copied++;
>> }
>> -
>> }
>> }
>> card_res->count_encoders = encoder_count;
>> @@ -1376,10 +1375,9 @@ out:
>>
>>  /**
>>   * drm_mode_getcrtc - get CRTC configuration
>> - * @inode: inode from the ioctl
>> - * @filp: file * from the ioctl
>> - * @cmd: cmd from ioctl
>> - * @arg: arg from ioctl
>> + * @dev: DRM device
>> + * @data: ioctl data
>> + * 

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Christian König]

On 12.03.2015 10:02, Michel Dänzer wrote:
> On 12.03.2015 06:14, Alex Deucher wrote:
>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
>> wrote:
>>> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>>>  wrote:
 On 11.03.2015 16:44, Alex Deucher wrote:
> radeon_bo_create() calls radeon_ttm_placement_from_domain()
> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
> uses the ttm bo size to determine when to select top down
> allocation but since the ttm bo is not initialized yet the
> check is always false.
>
> Noticed-by: Oded Gabbay 
> Signed-off-by: Alex Deucher 
> Cc: stable at vger.kernel.org

 And I was already wondering why the heck the BOs always made this ping/pong
 in memory after creation.

 Patch is Reviewed-by: Christian König 
>>> And fixing that promptly broke VCE due to vram location requirements.
>>> Updated patch attached.  Thoughts?
>> And one more take to make things a bit more explicit for static kernel
>> driver allocations.
> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
> problem is really that some BOs are expected to be within a certain
> range from the beginning of VRAM, but lpfn isn't set accordingly. It
> would be better to fix that by setting lpfn directly than indirectly via
> RADEON_GEM_CPU_ACCESS.

Yeah, agree. We should probably try to find the root cause of this instead.

As far as I know VCE has no documented limitation on where buffers are 
placed (unlike UVD). So this is a bit strange. Are you sure that it 
isn't UVD which breaks here?

Regards,
Christian.

>
>
> Anyway, since this isn't the first bug which prevents
> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
> wonder if its performance impact should be re-evaluated. Lauri?
>
>

[RFC][PATCH] amdkfd: Convert timestamping to use 64bit time accessors

[John Stultz]

Convert the timestamping in the amdkfd driver to use
a timespec64 and 64bit time accessors.

Cc: Arnd Bergmann 
Cc: Oded Gabbay 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 5c50aa8..50fc8ba 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -435,7 +435,7 @@ static int kfd_ioctl_get_clock_counters(struct file *filep,
 {
struct kfd_ioctl_get_clock_counters_args *args = data;
struct kfd_dev *dev;
-   struct timespec time;
+   struct timespec64 time;

dev = kfd_device_by_id(args->gpu_id);
if (dev == NULL)
@@ -445,11 +445,11 @@ static int kfd_ioctl_get_clock_counters(struct file 
*filep,
args->gpu_clock_counter = kfd2kgd->get_gpu_clock_counter(dev->kgd);

/* No access to rdtsc. Using raw monotonic time */
-   getrawmonotonic();
-   args->cpu_clock_counter = (uint64_t)timespec_to_ns();
+   getrawmonotonic64();
+   args->cpu_clock_counter = (uint64_t)timespec64_to_ns();

-   get_monotonic_boottime();
-   args->system_clock_counter = (uint64_t)timespec_to_ns();
+   get_monotonic_boottime64();
+   args->system_clock_counter = (uint64_t)timespec64_to_ns();

/* Since the counter is in nano-seconds we use 1GHz frequency */
args->system_clock_freq = 10;
-- 
1.9.1

[Beignet] [PATCH 2/2 v2] Query the driver directly for compute units and subslice

[Zhigang Gong]

LGTM,

Reviewed-by: Zhigang Gong 

Thanks.

> -Original Message-
> From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On Behalf Of
> jeff.mcgee at intel.com
> Sent: Tuesday, March 10, 2015 7:36 AM
> To: beignet at lists.freedesktop.org
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Subject: [Beignet] [PATCH 2/2 v2] Query the driver directly for compute units
> and subslice
> 
> From: Jeff McGee 
> 
> Values of device max compute units and max subslice obtained directly from
> the driver should be more accurate than our own ID-based lookup values. This
> is particularly important when a single device ID may encompass more than
> one configuration. If the driver cannot provide a valid value for the given 
> device,
> we fallback on the ID-based lookup value.
> 
> This query requires libdrm 2.4.60. For now we will consider the use of this 
> query
> to be optional and exclude it from compilation when building against older
> libdrm. Later we may want to consider requiring the query or at least warning
> more strongly when it is not supported.
> 
> v2: Make feature use conditional on libdrm version (Zhigang).
> 
> Signed-off-by: Jeff McGee 
> ---
>  CMakeLists.txt   |  9 +
>  src/CMakeLists.txt   | 10 ++
>  src/intel/intel_driver.c | 25 +
>  3 files changed, 40 insertions(+), 4 deletions(-)
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt index 65f2c70..bb03566 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -131,6 +131,15 @@ IF(DRM_INTEL_FOUND)
>ELSE(DRM_INTEL_VERSION VERSION_GREATER 2.4.57)
>  MESSAGE(STATUS "Disable userptr support")
>ENDIF(DRM_INTEL_VERSION VERSION_GREATER 2.4.57)
> +  IF(DRM_INTEL_VERSION VERSION_GREATER 2.4.59)
> +MESSAGE(STATUS "Enable EU total query support")
> +SET(DRM_INTEL_EU_TOTAL "enable")
> +MESSAGE(STATUS "Enable subslice total query support")
> +SET(DRM_INTEL_SUBSLICE_TOTAL "enable")
> ELSE(DRM_INTEL_VERSION
> + VERSION_GREATER 2.4.59)
> +MESSAGE(STATUS "Disable EU total query support")
> +MESSAGE(STATUS "Disable subslice total query support")
> + ENDIF(DRM_INTEL_VERSION VERSION_GREATER 2.4.59)
>  ELSE(DRM_INTEL_FOUND)
>MESSAGE(FATAL_ERROR "Looking for DRM Intel (>= 2.4.52) - not found")
>  ENDIF(DRM_INTEL_FOUND)
> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index d4181d8..464765f
> 100644
> --- a/src/CMakeLists.txt
> +++ b/src/CMakeLists.txt
> @@ -118,6 +118,16 @@ SET(CMAKE_CXX_FLAGS "-DHAS_USERPTR
> ${CMAKE_CXX_FLAGS}")  SET(CMAKE_C_FLAGS "-DHAS_USERPTR
> ${CMAKE_C_FLAGS}")  endif (DRM_INTEL_USERPTR)
> 
> +if (DRM_INTEL_EU_TOTAL)
> +SET(CMAKE_CXX_FLAGS "-DHAS_EU_TOTAL ${CMAKE_CXX_FLAGS}")
> +SET(CMAKE_C_FLAGS "-DHAS_EU_TOTAL ${CMAKE_C_FLAGS}") endif
> +(DRM_INTEL_EU_TOTAL)
> +
> +if (DRM_INTEL_SUBSLICE_TOTAL)
> +SET(CMAKE_CXX_FLAGS "-DHAS_SUBSLICE_TOTAL ${CMAKE_CXX_FLAGS}")
> +SET(CMAKE_C_FLAGS "-DHAS_SUBSLICE_TOTAL ${CMAKE_C_FLAGS}") endif
> +(DRM_INTEL_SUBSLICE_TOTAL)
> +
>  set(GIT_SHA1 "git_sha1.h")
>  add_custom_target(${GIT_SHA1} ALL
>COMMAND chmod +x ${CMAKE_CURRENT_SOURCE_DIR}/git_sha1.sh
> diff --git a/src/intel/intel_driver.c b/src/intel/intel_driver.c index
> d61988c..755ab6b 100644
> --- a/src/intel/intel_driver.c
> +++ b/src/intel/intel_driver.c
> @@ -757,10 +757,7 @@ static int intel_buffer_set_tiling(cl_buffer bo,  static
> void  intel_update_device_info(cl_device_id device)  { -#ifdef HAS_USERPTR
>intel_driver_t *driver;
> -  const size_t sz = 4096;
> -  void *host_ptr;
> 
>driver = intel_driver_new();
>assert(driver != NULL);
> @@ -769,6 +766,10 @@ intel_update_device_info(cl_device_id device)
>  return;
>}
> 
> +#ifdef HAS_USERPTR
> +  const size_t sz = 4096;
> +  void *host_ptr;
> +
>host_ptr = cl_aligned_malloc(sz, 4096);
>if (host_ptr != NULL) {
>  cl_buffer bo = intel_buffer_alloc_userptr((cl_buffer_mgr)driver->bufmgr,
> @@ -781,12 +782,28 @@ intel_update_device_info(cl_device_id device)
>}
>else
>  device->host_unified_memory = CL_FALSE;
> +#endif
> +
> +#ifdef HAS_EU_TOTAL
> +  unsigned int eu_total;
> +
> +  /* Prefer driver-queried max compute units if supported */
> +  if (!drm_intel_get_eu_total(driver->fd, _total))
> +device->max_compute_unit = eu_total; #endif
> +
> +#ifdef HAS_SUBSLICE_TOTAL
> +  unsigned int subslice_total;
> +
> +  /* Prefer driver-queried subslice count if supported */
> +  if (!drm_intel_get_subslice_total(driver->fd, _total))
> +device->sub_slice_count = subslice_total; #endif
> 
>intel_driver_context_destroy(driver);
>intel_driver_close(driver);
>intel_driver_terminate(driver);
>intel_driver_delete(driver);
> -#endif
>  }
> 
>  LOCAL void
> --
> 2.3.0
> 
> ___
> Beignet mailing list
> Beignet at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/beignet

[PATCH 2/2] drm/bridge: Add IT6151 bridge driver

[Paul Bolle]

Just a few nits, I'm afraid.

On Wed, 2015-03-11 at 14:18 +0800, CK Hu wrote:
>  drivers/gpu/drm/bridge/Kconfig  |  10 +
>  drivers/gpu/drm/bridge/Makefile |   1 +

I applied 1/2 and 2/2 on top of next-20150312 to check a trivial issue.
The chunks for these two files needed context changes to git this patch
applied.

>  drivers/gpu/drm/bridge/it6151.c | 601 
> 
>  include/drm/bridge/it6151.h |  34 +++
>  4 files changed, 646 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/it6151.c
>  create mode 100644 include/drm/bridge/it6151.h

> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index f38bbcd..2b3a78e 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -11,3 +11,13 @@ config DRM_PTN3460
>   select DRM_PANEL
>   ---help---
> ptn3460 eDP-LVDS bridge chip driver.
> +
> +config DRM_IT6151
> + bool "Enable IT6151FN : MIPI to eDP Converter"
> + depends on DRM
> + select DRM_KMS_HELPER
> + help
> +   Choose this option if you have IT6151 for display
> +   The IT6151 is a high-performance and low-power
> +   MIPI to eDP converter
> +

(This empty line makes git am whine: "new blank line at EOF.".)

> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/it6151.c

> +#include 

This file can only be built-in. So I couldn't help but notice this
include. And if I remove it
make drivers/gpu/drm/bridge/it6151.o

still runs without warning or errors. Unless I've missed something
non-obvious I'd say it is not needed.

> +

(Empty line at end of file.)

> --- /dev/null
> +++ b/include/drm/bridge/it6151.h

> +

(Another empty line at end of file.)


Paul Bolle

[pull] radeon drm-fixes-4.0

[Alex Deucher]

Hi Dave,

Some additional radeon fixes for 4.0

The following changes since commit cd961bb9eebb630452f49dcbf3e5f0059428614a:

  drm/mst: fix recursive sleep warning on qlock (2015-03-10 13:44:31 +1000)

are available in the git repository at:

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

for you to fetch changes up to a17d4996e051e78d164989b894608cf37cd5110b:

  drm/radeon: drop setting UPLL to sleep mode (2015-03-11 08:31:56 -0400)


Christian König (1):
  drm/radeon: drop setting UPLL to sleep mode

Maarten Lankhorst (1):
  drm/radeon: fix wait to actually occur after the signaling callback

 drivers/gpu/drm/radeon/radeon_fence.c | 68 +++
 drivers/gpu/drm/radeon/si.c   |  6 ++--
 2 files changed, 47 insertions(+), 27 deletions(-)

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Alex Deucher]

On Thu, Mar 12, 2015 at 5:23 AM, Christian König
 wrote:
> On 12.03.2015 10:02, Michel Dänzer wrote:
>>
>> On 12.03.2015 06:14, Alex Deucher wrote:
>>>
>>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher 
>>> wrote:

 On Wed, Mar 11, 2015 at 2:21 PM, Christian König
  wrote:
>
> On 11.03.2015 16:44, Alex Deucher wrote:
>>
>> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>> uses the ttm bo size to determine when to select top down
>> allocation but since the ttm bo is not initialized yet the
>> check is always false.
>>
>> Noticed-by: Oded Gabbay 
>> Signed-off-by: Alex Deucher 
>> Cc: stable at vger.kernel.org
>
>
> And I was already wondering why the heck the BOs always made this
> ping/pong
> in memory after creation.
>
> Patch is Reviewed-by: Christian König 

 And fixing that promptly broke VCE due to vram location requirements.
 Updated patch attached.  Thoughts?
>>>
>>> And one more take to make things a bit more explicit for static kernel
>>> driver allocations.
>>
>> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
>> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
>> problem is really that some BOs are expected to be within a certain
>> range from the beginning of VRAM, but lpfn isn't set accordingly. It
>> would be better to fix that by setting lpfn directly than indirectly via
>> RADEON_GEM_CPU_ACCESS.
>
>
> Yeah, agree. We should probably try to find the root cause of this instead.
>
> As far as I know VCE has no documented limitation on where buffers are
> placed (unlike UVD). So this is a bit strange. Are you sure that it isn't
> UVD which breaks here?

It's definitely VCE, I don't know why UVD didn't have a problem.  I
considered using pin_restricted to make sure it got pinned in the CPU
visible region, but that had two problems: 1. it would end up getting
migrated when pinned, 2. it would end up at the top of the restricted
region since the top down flag is set which would end up fragmenting
vram.

Alex

>
> Regards,
> Christian.
>
>
>>
>>
>> Anyway, since this isn't the first bug which prevents
>> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
>> wonder if its performance impact should be re-evaluated. Lauri?
>>
>>
>

[PATCH thomash] drm/vmwgfx: vmw_kms_generic_present() can be static

[Sinclair Yeh]

Reviewed-by:  Sinclair Yeh 

On Thu, Mar 12, 2015 at 03:42:34AM +0800, kbuild test robot wrote:
> 
> Signed-off-by: Fengguang Wu 
> ---
>  vmwgfx_kms.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 8344504..5a3be8d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -867,7 +867,7 @@ static const struct drm_mode_config_funcs vmw_kms_funcs = 
> {
>   .fb_create = vmw_kms_fb_create,
>  };
>  
> -int vmw_kms_generic_present(struct vmw_private *dev_priv,
> +static int vmw_kms_generic_present(struct vmw_private *dev_priv,
>   struct drm_file *file_priv,
>   struct vmw_framebuffer *vfb,
>   struct vmw_surface *surface,
> --
> 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  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=w9Iu3o4zAy-3-s8MFvrNSQ=NTs5Ah9MtxTv6TotuhTxX6gC7jYd2id7blsEMerQ16c=ETcWXj-AMaFIFRBQavkaYwf09sY6FEMNE4fp1Rac4Lc=
>  
> Please read the FAQ at  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tux.org_lkml_=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=w9Iu3o4zAy-3-s8MFvrNSQ=NTs5Ah9MtxTv6TotuhTxX6gC7jYd2id7blsEMerQ16c=uRhtLhE22YZyVA-Ideds1uZCtB8ghx4hxCjvq25uz3M=
>  

[Bug 89534] GPU lockup with wine

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

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

--- Comment #3 from John  ---
I have tried various combinations of Linux and Mesa with no better result, so
I'm *guessing* it is not a regression but something that never worked.

I've tried Linux 3.14.5, 3.19, 3.19.1 and 4.0rc1 to 4.0rc3.
I've tried Mesa 10.1, 10.2, 10.3, 10.4 and git (with the corresponding llvm
builds).

I have more dmesg saved, but I am not sure if they would be helpful, especially
using older versions...

I'm out of ideas of what to try now...

-- 
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/20150312/5a4960ee/attachment.html>

[PATCH thomash] drm/vmwgfx: vmw_kms_generic_present() can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu 
---
 vmwgfx_kms.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 8344504..5a3be8d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -867,7 +867,7 @@ static const struct drm_mode_config_funcs vmw_kms_funcs = {
.fb_create = vmw_kms_fb_create,
 };

-int vmw_kms_generic_present(struct vmw_private *dev_priv,
+static int vmw_kms_generic_present(struct vmw_private *dev_priv,
struct drm_file *file_priv,
struct vmw_framebuffer *vfb,
struct vmw_surface *surface,

[thomash:vmwgfx-next 4/7] drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:870:5: sparse: symbol 'vmw_kms_generic_present' was not declared. Should it be static?

[kbuild test robot]

tree:   git://people.freedesktop.org/~thomash/linux vmwgfx-next
head:   51850be6365084dc3ff6516bb9d89c6d7e3a98f1
commit: fd465bad8cb18eb6e99aa81bc1349c221250391f [4/7] drm/vmwgfx: Major KMS 
refactoring / cleanup in preparation of screen targets
reproduce:
  # apt-get install sparse
  git checkout fd465bad8cb18eb6e99aa81bc1349c221250391f
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:109:18: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:109:18:expected unsigned int 
[unsigned] [usertype] cmd
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:109:18:got restricted __le32 
[usertype] 
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:110:24: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:110:24:expected unsigned int 
[unsigned] [usertype] id
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:110:24:got restricted __le32 
[usertype] 
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:111:27: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:111:27:expected unsigned int 
[unsigned] [usertype] width
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:111:27:got restricted __le32 
[usertype] 
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:112:28: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:112:28:expected unsigned int 
[unsigned] [usertype] height
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:112:28:got restricted __le32 
[usertype] 
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:113:30: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:113:30:expected unsigned int 
[unsigned] [usertype] hotspotX
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:113:30:got restricted __le32 
[usertype] 
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:114:30: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:114:30:expected unsigned int 
[unsigned] [usertype] hotspotY
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:114:30:got restricted __le32 
[usertype] 
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:931:24: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:931:24:expected unsigned int 
[unsigned] [usertype] id
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:931:24:got restricted __le32 
[usertype] 
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:991:34: sparse: incorrect type in 
assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:991:34:expected unsigned int 
[unsigned] [usertype] size
   drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:991:34:got restricted __le32 
[usertype] 
   objdump: 'drivers/gpu/drm/vmwgfx/.tmp_vmwgfx_kms.o': No such file
   mv: cannot stat 'drivers/gpu/drm/vmwgfx/.tmp_vmwgfx_kms.o': No such file or 
directory
--
>> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:479:31: sparse: incorrect type in 
>> assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:479:31:expected unsigned int 
[unsigned] [usertype] header
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:479:31:got restricted __le32 
[usertype] 
>> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:480:31: sparse: incorrect type in 
>> assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:480:31:expected unsigned int 
[unsigned] [usertype] x
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:480:31:got restricted __le32 
[usertype] 
>> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:481:31: sparse: incorrect type in 
>> assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:481:31:expected unsigned int 
[unsigned] [usertype] y
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:481:31:got restricted __le32 
[usertype] 
>> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:482:35: sparse: incorrect type in 
>> assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:482:35:expected unsigned int 
[unsigned] [usertype] width
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:482:35:got restricted __le32 
[usertype] 
>> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:483:36: sparse: incorrect type in 
>> assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:483:36:expected unsigned int 
[unsigned] [usertype] height
   drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c:483:36:got restricted __le32 
[usertype] 
   objdump: 'drivers/gpu/drm/vmwgfx/.tmp_vmwgfx_ldu.o': No such file
   mv: cannot stat 'drivers/gpu/drm/vmwgfx/.tmp_vmwgfx_ldu.o': No such file or 
directory
--
>> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:762:24: sparse: incorrect type in 
>> assignment (different base types)
   drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:762:24:expected unsigned int 
[unsigned] [usertype] id
   drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:762:24:got restricted __le32 
[usertype] 
>> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c:763:26: sparse: incorrect type in 
>> assignment 

[Bug 89549] DisplayLink (udl) Linux kernel memory fault on USB hot unplug, proposed patch

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

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

Bug ID: 89549
   Summary: DisplayLink (udl)  Linux kernel memory fault on USB
hot unplug, proposed patch
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adam_richter2004 at yahoo.com

Created attachment 114235
  --> https://bugs.freedesktop.org/attachment.cgi?id=114235=edit
Add ".get_vblank_counter = drm_vblank_count," to DisplayLink drm_driver
functions

[This is an edit of an email that I sent yesterday to linux-fbdev at
vger.kernel.org and the Linux kernel udlfb maintainer.]

In Linux-4.0-rc3, the DisplayLink driver gets a kernel memory fault when its
USB device is unplugged, specifically when vblank_disable_and_save in
linux-4.0-rc3/drivers/gpu/drm/drm_irq.c attempts to call the NULL function
pointer dev->driver_get_vblank_counter.

linux-4.0-rc3/Documentation/DocBook/drm.tmpl says of that field, "Otherwise
drivers can use the drm_vblank_count helper function to handle this operation."
 Trying that seems to have eliminated the oops when I unplug the device,
although I do see these lines in the console log at device driver
initialization time that I think are probably fine, but which I should mention
in case the indicate that I did the wrong the thing:

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.

If that doesn't look like a problem, then please apply the attached patch and
push it upstream.  The patch just adds one line that appears in six other
framebuffer drivers to initialize the driver_get_vblank_counter drm_driver
function.

Thanks in advance for your attention to this problem.

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

[PATCH 4/7] drm/exynos: make zpos property immutable

[Inki Dae]

On 2015년 02월 19일 22:22, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> We already set each plane zpos at init, after that changes to zpos are
> not expected. This patch turns zpos into a read-only property so now it is
> impossible to set zpos.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++---
>  1 file changed, 2 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 504bd6e..2fbac9b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -184,27 +184,10 @@ static void exynos_plane_destroy(struct drm_plane 
> *plane)
>   drm_plane_cleanup(plane);
>  }
>  
> -static int exynos_plane_set_property(struct drm_plane *plane,
> -  struct drm_property *property,
> -  uint64_t val)
> -{
> - struct drm_device *dev = plane->dev;
> - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> - struct exynos_drm_private *dev_priv = dev->dev_private;
> -
> - if (property == dev_priv->plane_zpos_property) {
> - exynos_plane->zpos = val;
> - return 0;
> - }
> -
> - return -EINVAL;
> -}
> -
>  static struct drm_plane_funcs exynos_plane_funcs = {
>   .update_plane   = exynos_update_plane,
>   .disable_plane  = exynos_disable_plane,
>   .destroy= exynos_plane_destroy,
> - .set_property   = exynos_plane_set_property,

It's a good idea for a hardware overlay to a plane object isn't changed
by user-space. However, this patch would make the compatibility of the
existing application - using set_property ioctl to change hardware
overlay to particular plane - to be broken because the set_property
ioctl request will always be failed without the set_property callback.

So how about leaving warning message 'the hardware overlay cannot be
changed to another anymore' when the set_property ioctl is requested by
user-space, and returning just 0?

Thanks,
Inki Dae

>  };
>  
>  static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
> @@ -216,8 +199,8 @@ static void exynos_plane_attach_zpos_property(struct 
> drm_plane *plane,
>  
>   prop = dev_priv->plane_zpos_property;
>   if (!prop) {
> - prop = drm_property_create_range(dev, 0, "zpos", 0,
> -  MAX_PLANE - 1);
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
> +  "zpos", 0, MAX_PLANE - 1);
>   if (!prop)
>   return;
>  
>