[Intel-gfx] [PATCH v2 6/6] drm/atomic: Clean up steal_encoder

[Ville Syrjälä]

On Wed, Mar 02, 2016 at 07:32:30PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 24, 2016 at 09:37:33AM +0100, Maarten Lankhorst wrote:
> > Now that only encoders can be stolen that are part of the state
> > steal_encoder no longer needs to inspect all connectors,
> > just those that are part of the atomic state.
> 
> steal_encoder() can no longer fail after this, so should clean up the
> caller a bit too I think.

Oh and maybe it should be called something different? We've sort of done
the stealing part already, so I think the only thing we have left to do
here is clean up the stale best_encoder pointers.

> 
> > 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
> >  1 file changed, 2 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 32bd5bebef0b..0fc56339001d 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -215,18 +215,11 @@ steal_encoder(struct drm_atomic_state *state,
> > struct drm_crtc_state *crtc_state;
> > struct drm_connector *connector;
> > struct drm_connector_state *connector_state;
> > +   int i;
> >  
> > -   drm_for_each_connector(connector, state->dev) {
> > +   for_each_connector_in_state(state, connector, connector_state, i) {
> > struct drm_crtc *encoder_crtc;
> >  
> > -   if (connector->state->best_encoder != encoder)
> > -   continue;
> > -
> > -   connector_state = drm_atomic_get_connector_state(state,
> > -connector);
> > -   if (IS_ERR(connector_state))
> > -   return PTR_ERR(connector_state);
> > -
> > if (connector_state->best_encoder != encoder ||
> > WARN_ON(!connector_state->crtc))
> > continue;
> > -- 
> > 2.1.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[PATCH v2 6/6] drm/atomic: Clean up steal_encoder

[Ville Syrjälä]

On Wed, Feb 24, 2016 at 09:37:33AM +0100, Maarten Lankhorst wrote:
> Now that only encoders can be stolen that are part of the state
> steal_encoder no longer needs to inspect all connectors,
> just those that are part of the atomic state.

steal_encoder() can no longer fail after this, so should clean up the
caller a bit too I think.

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 32bd5bebef0b..0fc56339001d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -215,18 +215,11 @@ steal_encoder(struct drm_atomic_state *state,
>   struct drm_crtc_state *crtc_state;
>   struct drm_connector *connector;
>   struct drm_connector_state *connector_state;
> + int i;
>  
> - drm_for_each_connector(connector, state->dev) {
> + for_each_connector_in_state(state, connector, connector_state, i) {
>   struct drm_crtc *encoder_crtc;
>  
> - if (connector->state->best_encoder != encoder)
> - continue;
> -
> - connector_state = drm_atomic_get_connector_state(state,
> -  connector);
> - if (IS_ERR(connector_state))
> - return PTR_ERR(connector_state);
> -
>   if (connector_state->best_encoder != encoder ||
>   WARN_ON(!connector_state->crtc))
>   continue;
> -- 
> 2.1.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[PATCH] staging/android: add flags member to sync ioctl structs

[Gustavo Padovan]

From: Gustavo Padovan 

Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.

v2: check if flags are valid (zero, in this case)

v3: return -EINVAL if flags are not zero'ed

v4: add padding for 64-bit alignment

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  |  8 
 drivers/staging/android/uapi/sync.h | 14 --
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3604e453..0196d3d 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}

+   if (data.flags || data.pad) {
+   err = -EINVAL;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (copy_from_user(, (void __user *)arg, sizeof(in)))
return -EFAULT;

+   if (in.flags || in.pad)
+   return -EINVAL;
+
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a122bb5..859977c 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,14 +16,18 @@

 /**
  * struct sync_merge_data - data passed to merge ioctl
- * @fd2:   file descriptor of second fence
  * @name:  name of new fence
+ * @fd2:   file descriptor of second fence
  * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad:   padding for 64-bit alignment, should always be zero
  */
 struct sync_merge_data {
-   __s32   fd2;
charname[32];
+   __s32   fd2;
__s32   fence;
+   __u32   flags;
+   __u32   pad;
 };

 /**
@@ -31,12 +35,14 @@ struct sync_merge_data {
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
  * @status:status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
 struct sync_fence_info {
charobj_name[32];
chardriver_name[32];
__s32   status;
+   __u32   flags;
__u64   timestamp_ns;
 };

@@ -44,14 +50,18 @@ struct sync_fence_info {
  * struct sync_file_info - data returned from fence info ioctl
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
  * @num_fences number of fences in the sync_file
+ * @pad:   padding for 64-bit alignment, should always be zero
  * @sync_fence_info: pointer to array of structs sync_fence_info with all
  *  fences in the sync_file
  */
 struct sync_file_info {
charname[32];
__s32   status;
+   __u32   flags;
__u32   num_fences;
+   __u32   pad;

__u64   sync_fence_info;
 };
-- 
2.5.0

[PATCH v6 4/6] staging/android: align struct sync_merge_data to a multiple of 64-bits

[Gustavo Padovan]

2016-03-02 Gustavo Padovan :

> From: Gustavo Padovan 
> 
> Change order of the field to avoid alignment issues with 64 bits
> platforms.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/staging/android/uapi/sync.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Please ignore this patch, it is not really needed.

Gustavo

[PATCH 1/2] drm: Add few more wrapper functions for drm panel

[Deepak M]

Currently there are few pair of functions which
are called during the panel enable/disable sequence.
To improve the granularity, adding few more wrapper
functions so that the functions are more specific
on what they are doing.

Cc: Thierry Reding 
Cc: David Airlie 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Deepak M 
Signed-off-by: Gaurav K Singh 
---
 include/drm/drm_panel.h | 92 +
 1 file changed, 77 insertions(+), 15 deletions(-)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 13ff44b..dadbcea 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -33,23 +33,33 @@ struct display_timing;

 /**
  * struct drm_panel_funcs - perform operations on a given panel
- * @disable: disable panel (turn off back light, etc.)
- * @unprepare: turn off panel
- * @prepare: turn on panel and perform set up
- * @enable: enable panel (turn on back light, etc.)
+ * @disable: disable panel
+ * @unprepare: uninitialize the panel
+ * @prepare: initialze the panel
+ * @enable: enable panel
  * @get_modes: add modes to the connector that the panel is attached to and
  * return the number of modes added
  * @get_timings: copy display timings into the provided array and return
  * the number of display timings available
+ * @power_on: powering on the panel
+ * @power_off: powering off the panel
+ * @backlight_on: turning on backlight
+ * @backlight_off: turning off backlight
+ *
+ * The .power_on function is called to turn on the panel and wait for it to
+ * become ready.
  *
  * The .prepare() function is typically called before the display controller
- * starts to transmit video data. Panel drivers can use this to turn the panel
- * on and wait for it to become ready. If additional configuration is required
- * (via a control bus such as I2C, SPI or DSI for example) this is a good time
- * to do that.
+ * starts to transmit video data. Panels will be iniatilzed during this call.
+ * If additional configuration is required (via a control bus such as I2C,
+ * SPI or DSI for example) this is a good time to do that. Some panels expects
+ * to wait and also to send some cmds before enabling the panel.
+ *
+ * The .enable() will typically enable the panel, some DSI panels need
+ * additional operations to opearte in differnt modes other than initalizing.
  *
- * After the display controller has started transmitting video data, it's safe
- * to call the .enable() function. This will typically enable the backlight to
+ * The .backlight_on() After the display controller has started transmitting
+ * video data, it's safe to turn on the panel backlight, which will
  * make the image on screen visible. Some panels require a certain amount of
  * time or frames before the image is displayed. This function is responsible
  * for taking this into account before enabling the backlight to avoid visual
@@ -57,13 +67,20 @@ struct display_timing;
  *
  * Before stopping video transmission from the display controller it can be
  * necessary to turn off the panel to avoid visual glitches. This is done in
- * the .disable() function. Analogously to .enable() this typically involves
- * turning off the backlight and waiting for some time to make sure no image
- * is visible on the panel. It is then safe for the display controller to
- * cease transmission of video data.
+ * the .backlight_off() function, this typically involves turning off the
+ * backlight and waiting for some time to make sure no image is visible
+ * on the panel.
+ *
+ * .disable() function will cease transmission of video data.
+ *
+ * .unprepare() function will typically uninitalize the panel.
  *
  * To save power when no video data is transmitted, a driver can power down
- * the panel. This is the job of the .unprepare() function.
+ * the panel. This is the job of the .power_off() function.
+ *
+ * The below sequence can be followed while calling these ops
+ * Enable : power_on(), prepare(), enable(), backlight_on()
+ * Disable : backlight_off(), disable(), unprepare(), power_off()
  */
 struct drm_panel_funcs {
int (*disable)(struct drm_panel *panel);
@@ -73,6 +90,10 @@ struct drm_panel_funcs {
int (*get_modes)(struct drm_panel *panel);
int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
   struct display_timing *timings);
+   int (*power_on)(struct drm_panel *panel);
+   int (*power_off)(struct drm_panel *panel);
+   int (*backlight_on)(struct drm_panel *panel);
+   int (*backlight_off)(struct drm_panel *panel);
 };

 struct drm_panel {
@@ -117,6 +138,47 @@ static inline int drm_panel_enable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
 }

+static inline int drm_panel_power_on(struct drm_panel *panel)
+{
+   if (panel && panel->funcs && panel->funcs->power_on)
+   return panel->funcs->power_on(panel);
+
+   return panel ? -ENOSYS : -EINVAL;
+}

[PATCH 0/8] drm/bochs: convert bochs to atomic mode-setting

[Emil Velikov]

On 2 March 2016 at 15:38, Gerd Hoffmann  wrote:
> On Mi, 2016-03-02 at 10:13 +, Emil Velikov wrote:
>> [+Dave, +Gerd]
>>
>> Hi all,
>>
>> Just noticed that this old(ish) series never hit master.
>>
>> On 16 July 2015 at 13:20, John Hunter  wrote:
>> > From: Zhao Junwang 
>> >
>> > This patch series aim to convert DRM_BOCHS to atomic mode-setting.
>> > I did this mostly reference Gustavo Padovan's patch series on
>> > drm/exynos conversion.
>> >
>> Dave, Gerd, being the authors/maintainers of this driver can you guys
>> take a look/test.
>> Ackes, review and testing will be greatly appreciated.
>
> Did testing a while back & reported back to John (not sure this was in
> public on the list as we had some ping-ping emails beforehand due to
> some problems of applying the patches).  No new version of the series
> since.
>
The only comment that I can see is this one [1] which was addressed a
couple of days later [2].
If you have any other comments please bring them up publicly.

Thanks
Emil

[1] https://lists.freedesktop.org/archives/dri-devel/2015-July/086651.html
[2] https://lists.freedesktop.org/archives/dri-devel/2015-July/086776.html

[PATCH v6 07/11] drm/hisilicon: Add designware dsi encoder driver

[Xinliang Liu]

On 1 March 2016 at 20:45, Archit Taneja  wrote:
>
>
> On 3/1/2016 4:03 PM, Xinliang Liu wrote:
>>
>> Hi,
>>
>> On 1 March 2016 at 02:49, Archit Taneja  wrote:
>>>
>>>
>>>
>>> On 2/26/2016 2:10 PM, Xinliang Liu wrote:


 Add DesignWare MIPI DSI Host Controller v1.02 encoder driver
 for hi6220 SoC.

 v6:
 - Change "pclk_dsi" to "pclk".
 v5: None.
 v4: None.
 v3:
 - Rename file name to dw_drm_dsi.c
 - Make encoder type as DRM_MODE_ENCODER_DSI.
 - A few cleanup.
 v2:
 - Remove abtraction layer.

 Signed-off-by: Xinliang Liu 
 Signed-off-by: Xinwei Kong 
 Signed-off-by: Andy Green 
 ---
drivers/gpu/drm/hisilicon/kirin/Kconfig  |   1 +
drivers/gpu/drm/hisilicon/kirin/Makefile |   3 +-
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 743
 +++
drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |  83 +++
4 files changed, 829 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h

 diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig
 b/drivers/gpu/drm/hisilicon/kirin/Kconfig
 index 3ac4b8edeac1..de0d454c5c13 100644
 --- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
 +++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
 @@ -4,6 +4,7 @@ config DRM_HISI_KIRIN
  select DRM_KMS_HELPER
  select DRM_GEM_CMA_HELPER
  select DRM_KMS_CMA_HELPER
 +   select DRM_MIPI_DSI
  help
Choose this option if you have a hisilicon Kirin
 chipsets(hi6220).
If M is selected the module will be called kirin-drm.
 diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile
 b/drivers/gpu/drm/hisilicon/kirin/Makefile
 index 2a61ab006ddb..5dcd0d4328b6 100644
 --- a/drivers/gpu/drm/hisilicon/kirin/Makefile
 +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
 @@ -1,4 +1,5 @@
kirin-drm-y := kirin_drm_drv.o \
 -  kirin_drm_ade.o
 +  kirin_drm_ade.o \
 +  dw_drm_dsi.o

obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
 diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 new file mode 100644
 index ..8329148cc89d
 --- /dev/null
 +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 @@ -0,0 +1,743 @@
 +/*
 + * DesignWare MIPI DSI Host Controller v1.02 driver
 + *
 + * Copyright (c) 2016 Linaro Limited.
 + * Copyright (c) 2014-2016 Hisilicon Limited.
 + *
 + * Author:
 + * Xinliang Liu 
 + * Xinliang Liu 
 + * Xinwei Kong 
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + */
 +
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include "dw_dsi_reg.h"
 +
 +#define MAX_TX_ESC_CLK(10)
 +#define ROUND(x, y) ((x) / (y) + ((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
 +#define PHY_REF_CLK_RATE   1920
 +#define PHY_REF_CLK_PERIOD_PS (10 / (PHY_REF_CLK_RATE / 1000))
 +
 +#define encoder_to_dsi(encoder) \
 +   container_of(encoder, struct dw_dsi, encoder)
 +#define host_to_dsi(host) \
 +   container_of(host, struct dw_dsi, host)
 +
 +struct mipi_phy_params {
 +   u32 clk_t_lpx;
 +   u32 clk_t_hs_prepare;
 +   u32 clk_t_hs_zero;
 +   u32 clk_t_hs_trial;
 +   u32 clk_t_wakeup;
 +   u32 data_t_lpx;
 +   u32 data_t_hs_prepare;
 +   u32 data_t_hs_zero;
 +   u32 data_t_hs_trial;
 +   u32 data_t_ta_go;
 +   u32 data_t_ta_get;
 +   u32 data_t_wakeup;
 +   u32 hstx_ckg_sel;
 +   u32 pll_fbd_div5f;
 +   u32 pll_fbd_div1f;
 +   u32 pll_fbd_2p;
 +   u32 pll_enbwt;
 +   u32 pll_fbd_p;
 +   u32 pll_fbd_s;
 +   u32 pll_pre_div1p;
 +   u32 pll_pre_p;
 +   u32 pll_vco_750M;
 +   u32 pll_lpf_rs;
 +   u32 pll_lpf_cs;
 +   u32 clklp2hs_time;
 +   u32 clkhs2lp_time;
 +   u32 lp2hs_time;
 +   u32 hs2lp_time;
 +   u32 clk_to_data_delay;
 +   u32 data_to_clk_delay;
 +   u32 lane_byte_clk_kHz;
 +   u32 clk_division;
 +};
 +
 +struct dsi_hw_ctx {
 +   void __iomem *base;
 +   struct clk *pclk;
 +};
 +
 +struct dw_dsi {
 +   struct drm_encoder encoder;
 +   struct drm_display_mode cur_mode;
 +   struct dsi_hw_ctx *ctx;
 +   struct 

[PATCH] drm/ast: Fix incorrect register check for DRAM width

[Dave Airlie]

On 2 March 2016 at 04:58, Timothy Pearson
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/26/2016 03:29 PM, Timothy Pearson wrote:
>> During DRAM initialization on certain ASpeed devices, an incorrect
>> bit (bit 10) was checked in the "SDRAM Bus Width Status" register
>> to determine DRAM width.
>>
>> Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.
>>
>> Signed-off-by: Timothy Pearson 
>> ---
>>  drivers/gpu/drm/ast/ast_main.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
>> index 9759009..b1480ac 100644
>> --- a/drivers/gpu/drm/ast/ast_main.c
>> +++ b/drivers/gpu/drm/ast/ast_main.c
>> @@ -227,7 +227,7 @@ static int ast_get_dram_info(struct drm_device *dev)
>>   } while (ast_read32(ast, 0x1) != 0x01);
>>   data = ast_read32(ast, 0x10004);
>>
>> - if (data & 0x400)
>> + if (data & 0x40)
>>   ast->dram_bus_width = 16;
>>   else
>>   ast->dram_bus_width = 32;
>
> Just wanted to give this a bump since I have not received any feedback
> on it.

Thanks,

I've confirmed with the userspace AST driver this is correct, I'll put
this in drm-fixes now.

Dave.

[PATCH 3/4] drm: bridge/dw-hdmi: detect initial connector state

[Thierry Reding]

On Fri, Jan 08, 2016 at 10:02:06AM +0100, Philipp Zabel wrote:
> Allow userspace to read the initial connector state via sysfs without
> having to issue a detect manually. There is no reason to keep the state
> unknown during initialization.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 2 ++
>  1 file changed, 2 insertions(+)

It would seem to me that this should be the default, rather than having
to duplicate this into every driver.

Daniel, can you think of a reason why we wouldn't want to do handle this
in the core so that all drivers can benefit?

Thierry

> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index e41ff4b..2388a55 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1660,6 +1660,8 @@ static int dw_hdmi_register(struct drm_device *drm, 
> struct dw_hdmi *hdmi)
>  DRM_MODE_CONNECTOR_HDMIA);
>  
>   hdmi->connector.encoder = encoder;
> + hdmi->connector.status = dw_hdmi_connector_detect(>connector,
> +   false);
>  
>   drm_mode_connector_attach_encoder(>connector, encoder);
>  
> -- 
> 2.6.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160302/d00fdee9/attachment.sig>

[PATCH] drm: bridge: Make (pre/post) enable/disable callbacks optional

[Thierry Reding]

On Fri, Feb 26, 2016 at 11:51:06AM +0200, Laurent Pinchart wrote:
> Instead of forcing bridges to implement empty callbacks make them all
> optional.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
> ---
>  drivers/gpu/drm/drm_bridge.c | 12 
>  include/drm/drm_crtc.h   |  8 
>  2 files changed, 16 insertions(+), 4 deletions(-)

Applied, thanks.

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

[PATCH 2/2] drm/panel: simple: Add URT UMSH-8596MD-xT panels support

[Thierry Reding]

On Sat, Feb 13, 2016 at 10:52:03PM +0100, Maciej S. Szmigiero wrote:
> Add support for United Radiant Technology UMSH-8596MD-xT
> 7.0" WVGA TFT LCD panels in DRM panel-simple driver.
> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
> This replaces "drm: panel-simple: implement URT UMSH-8596MD-xT panel support"
> submission.
> 
>  drivers/gpu/drm/panel/panel-simple.c | 54 
> 
>  1 file changed, 54 insertions(+)

Applied, thanks.

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

[PATCH 1/2] dt-bindings: Add URT UMSH-8596MD-xT panel bindings

[Thierry Reding]

On Sat, Feb 13, 2016 at 10:50:24PM +0100, Maciej S. Szmigiero wrote:
> Add DT bindings for United Radiant Technology
> UMSH-8596MD-xT 7.0" WVGA TFT LCD panels.
> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
> This replaces "of: add URT UMSH-8596MD-xT panel DT bindings"
> submission.
> 
>  .../bindings/display/panel/urt,umsh-8596md.txt   | 16 
> 
>  1 file changed, 16 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt

Applied, thanks.

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

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #118 from Edwin Smith  ---
In summary I think it was intimated that the issue might be caused by how XCOM
deals with indices.

===
The game is passing indices outside start..end range, which is illegal per
https://www.opengl.org/sdk/docs/man/html/glDrawRangeElementsBaseVertex.xhtml
"all values in the array indices must lie between start and end, inclusive,
prior to adding base vertex"
===

Mesa Intel and AMD/Nvidia closed source deal with this gracefully by ignoring
the range hint if they are invalid however RadeonSi does not and can in some
cases crash.

Due to XCOM originally being designed for DirectX on Windows where this
behaviour is not a fatal error combined with other OpenGL drivers on Linux &
Mac also not throwing an error/warning this issue was overlooked/missed on the
original port as Mesa RadeonSi was not a supported driver at the time so no-one
saw the issue.

This has already been fixed for our more recent games as the Mesa AMD drivers
now support most of the features needed for many games so they are actively
used/tested/bugs logged at Feral. 

We don't have any plans for a patch in the short term but we'll definitely back
port this fix so we match the spec correctly into XCOM when we next patch it.

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

[PATCH v2 2/2] drm/panel: Support for LG lp120up1 panel with eDP input

[Thierry Reding]

On Mon, Feb 22, 2016 at 07:01:44PM +0800, Jitao Shi wrote:
> The LG lp120up1 TFT LCD panel with eDP interface is a 12.0" 1920x1280
> panel, which can be supported by the simple panel driver
> 
> Signed-off-by: Jitao Shi 
> ---
> Changes since v1:
>  - Add eDP panel type in comment msg
>  - Fixed comment msg with 72 characters width
> ---
>  drivers/gpu/drm/panel/panel-simple.c |   26 ++
>  1 file changed, 26 insertions(+)

Applied, thanks.

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

[PATCH v2 1/2] dt-bindings: Add LG lp120up1 panel bindings

[Thierry Reding]

On Mon, Feb 22, 2016 at 07:01:43PM +0800, Jitao Shi wrote:
> Add documentation for lp120up1 panel
> 
> Signed-off-by: Jitao Shi 
> Acked-by: Rob Herring 
> ---
> Changes since v1:
>  - add Acked-by: Rob Herring 
> ---
>  .../bindings/display/panel/lg,lp120up1.txt |7 +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt

Applied, thanks.

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

[PATCH] drm/panel: simple: fix g121x1_l03 hsync/vsync polarity

[Thierry Reding]

On Tue, Mar 01, 2016 at 06:06:54PM -0500, Akshay Bhat wrote:
> Set hsync/vsync to active low for g121x1_l03 panel to match the
> recommended setting in datasheet.
> 
> Signed-off-by: Akshay Bhat 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

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

[PATCH v5 0/5] drm/dsi: DSI for devices with different control bus

[Thierry Reding]

On Fri, Feb 12, 2016 at 02:48:29PM +0530, Archit Taneja wrote:
> We are currently restricted when it comes to supporting DSI on devices
> that have a non-DSI control bus. For example, DSI encoder chips are
> available in the market that are configured via i2c. Configuring their
> registers via DSI bus is either optional or not available at all.
> 
> These devices still need to pass DSI parameters (data lanes, mode flags
> etc) to the DSI host they are connected to. We don't have a way to do
> that at the moment.
> 
> After some discussions on the previous RFC[1], we decided to support this
> by providing additional API in drm_mipi_dsi.c which lets us create new DSI
> devices without the need of them to have a DT node.
> 
> [1]: https://lkml.org/lkml/2015/6/30/42
> 
> Changes in v5:
> - Simplify refactoring as suggested by Thierry.
> - Use abbreviations correctly.
> - Drop "drm/dsi: Check for used channels"
> - Return the correct encoded error code for of_mipi_dsi_device_add
>   when CONFIG_OF is disabled.
> - Use mipi_dsi_device_unregister to implement mipi_dsi_remove_device_fn()
>   too.
> 
> Changes in v4:
> - Added a new patch that fixes build issues when CONFIG_OF is not set.
> 
> Changes in v3:
> 
> - Incorporated misc comments by Andrzej. Changed from RFC to a PATCH set.
> - Fixed htmldocs warnings.
> 
> 
> Archit Taneja (5):
>   drm/dsi: check for CONFIG_OF when defining of_mipi_dsi_device_add
>   drm/dsi: Use mipi_dsi_device_register_full for DSI device creation
>   drm/dsi: Try to match non-DT DSI devices
>   drm/dsi: Add routine to unregister a DSI device
>   drm/dsi: Get DSI host by DT device node
> 
>  drivers/gpu/drm/drm_mipi_dsi.c | 127 
> +
>  include/drm/drm_mipi_dsi.h |  26 +
>  2 files changed, 141 insertions(+), 12 deletions(-)

I've applied this with minor fixups and cleanups to the commit messages.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160302/396cb24e/attachment.sig>

[4.4-rc1][Regression] drm/i915: Check live status before reading edid

[Joseph Salisbury]

On 02/29/2016 04:33 AM, Jani Nikula wrote:
> On Wed, 24 Feb 2016, Joseph Salisbury  
> wrote:
>> Hi Sonika,
>>
>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>> bisect, it was found that reverting the following commit resolved this bug:
>>
>> commit 237ed86c693d8a8e4db476976aeb30df4deac74b
>> Author: Sonika Jindal 
>> Date:   Tue Sep 15 09:44:20 2015 +0530
>>
>> drm/i915: Check live status before reading edid
>>
>>
>>
>> The regression was introduced as of v4.4-rc1.
>>
>> I was hoping to get your feedback, since you are the patch author.  Do
>> think increasing the number of tries in intel_hdmi_detect() is worth
>> trying?  Do you think gathering any additional data will help diagnose
>> this issue, or would it be best to submit a revert request?
Thanks for the info.  I will have all of these commits tested.


> There are at least the following commits claiming to fix issues in the
> above commit. Please make sure you have them.
>
> BR,
> Jani.
>
>
> commit 8d409cb3e8a24196be7271defafd4638f3e0b514
> Author: Ville Syrjälä 
> Date:   Wed Feb 10 19:59:05 2016 +0200
>
> drm/i915: Fix hpd live status bits for g4x
>
> commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
> Author: Gary Wang 
> Date:   Wed Dec 23 16:11:35 2015 +0800
>
> drm/i915: increase the tries for HDMI hotplug live status checking
>
> commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715
> Author: Daniel Vetter 
> Date:   Fri Dec 11 19:44:15 2015 +0100
>
> drm/i915: mdelay(10) considered harmful
>
> commit 0f5a9be15797f78c9a34e432f26c796165b6e49a
> Author: Imre Deak 
> Date:   Fri Nov 27 18:55:29 2015 +0200
>
> drm/i915: take a power domain reference while checking the HDMI live 
> status
>
>
>
>

[PATCH v6 6/6] staging/android: add flags member to sync ioctl structs

[Gustavo Padovan]

From: Gustavo Padovan 

Play safe and add flags member to all structs. So we don't need to
break API or create new IOCTL in the future if new features that requires
flags arises.

v2: check if flags are valid (zero, in this case)

v3: return -EINVAL if flags are not zero'ed

v4: add padding for 64-bit alignment

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 8 
 drivers/staging/android/uapi/sync.h | 8 
 2 files changed, 16 insertions(+)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3604e453..e635e6e 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
*sync_file,
goto err_put_fd;
}

+   if (data.flags) {
+   err = -EINVAL;
+   goto err_put_fd;
+   }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (copy_from_user(, (void __user *)arg, sizeof(in)))
return -EFAULT;

+   if (in.flags || in.pad)
+   return -EINVAL;
+
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index f064923..4b4d079 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -19,11 +19,13 @@
  * @name:  name of new fence
  * @fd2:   file descriptor of second fence
  * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
  */
 struct sync_merge_data {
charname[32];
__s32   fd2;
__s32   fence;
+   __u32   flags;
 };

 /**
@@ -31,12 +33,14 @@ struct sync_merge_data {
  * @obj_name:  name of parent sync_timeline
  * @driver_name:   name of driver implementing the parent
  * @status:status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
  * @timestamp_ns:  timestamp of status change in nanoseconds
  */
 struct sync_fence_info {
charobj_name[32];
chardriver_name[32];
__s32   status;
+   __u32   flags;
__u64   timestamp_ns;
 };

@@ -44,14 +48,18 @@ struct sync_fence_info {
  * struct sync_file_info - data returned from fence info ioctl
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
  * @num_fences number of fences in the sync_file
+ * @padpadding for 64-bit alignment, should always be zero
  * @sync_fence_info: pointer to array of structs sync_fence_info with all
  *  fences in the sync_file
  */
 struct sync_file_info {
charname[32];
__s32   status;
+   __u32   flags;
__u32   num_fences;
+   __u32   pad;

__u64   sync_fence_info;
 };
-- 
2.5.0

[PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO

[Gustavo Padovan]

From: Gustavo Padovan 

Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
optimize buffer

Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.

However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.

Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.

Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.

Also, info->sync_fence_info was converted to __u64 pointer to prevent
32bit compatibility issues.

An example userspace code for the later would be:

struct sync_file_info *info;
int err, size, num_fences;

info = malloc(sizeof(*info));

info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;

if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
  sizeof(struct 
sync_fence_info));

err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}

v2: fix fence_info memory leak

v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()

Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size

Comments from Dan Carpenter
- fix info->sync_fence_info documentation

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/sync.c  | 64 -
 drivers/staging/android/uapi/sync.h |  9 ++
 2 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index dc5f382..3604e453 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -479,13 +479,9 @@ err_put_fd:
return err;
 }

-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+   struct sync_fence_info *info)
 {
-   struct sync_fence_info *info = data;
-
-   if (size < sizeof(*info))
-   return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,28 +491,20 @@ static int sync_fill_fence_info(struct fence *fence, void 
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
-   return sizeof(*info);
 }

 static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
 {
-   struct sync_file_info *info;
+   struct sync_file_info in, *info;
+   struct sync_fence_info *fence_info = NULL;
__u32 size;
-   __u32 len = 0;
int ret, i;

-   if (copy_from_user(, (void __user *)arg, sizeof(size)))
+   if (copy_from_user(, (void __user *)arg, sizeof(in)))
return -EFAULT;

-   if (size < sizeof(struct sync_file_info))
-   return -EINVAL;
-
-   if (size > 4096)
-   size = 4096;
-
-   info = kzalloc(size, GFP_KERNEL);
+   info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;

@@ -525,29 +513,47 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info->status >= 0)
info->status = !info->status;

-   info->num_fences = sync_file->num_fences;
-
-   len = sizeof(struct sync_file_info);
+   /*
+* Passing num_fences = 0 means that userspace doesn't want to
+* retrieve any sync_fence_info. If num_fences = 0 we skip filling
+* sync_fence_info and return the actual number of fences on
+* info->num_fences.
+*/
+   if (!in.num_fences)
+   goto no_fences;

-   for (i = 0; i < sync_file->num_fences; ++i) {
-   struct fence *fence = sync_file->cbs[i].fence;
+   if (in.num_fences < sync_file->num_fences) {
+   ret = -EINVAL;
+   goto out;
+   }

-   ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
+   size = 

[PATCH v6 4/6] staging/android: align struct sync_merge_data to a multiple of 64-bits

[Gustavo Padovan]

From: Gustavo Padovan 

Change order of the field to avoid alignment issues with 64 bits
platforms.

Signed-off-by: Gustavo Padovan 
---
 drivers/staging/android/uapi/sync.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index f0b41ce..a6c648c 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,13 +16,13 @@

 /**
  * struct sync_merge_data - data passed to merge ioctl
- * @fd2:   file descriptor of second fence
  * @name:  name of new fence
+ * @fd2:   file descriptor of second fence
  * @fence: returns the fd of the new fence to userspace
  */
 struct sync_merge_data {
-   __s32   fd2;
charname[32];
+   __s32   fd2;
__s32   fence;
 };

-- 
2.5.0

[PATCH v6 3/6] staging/android: remove redundant comments on sync_merge_data

[Gustavo Padovan]

From: Gustavo Padovan 

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
---
 drivers/staging/android/uapi/sync.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index dd0dd84..f0b41ce 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
  * @fence: returns the fd of the new fence to userspace
  */
 struct sync_merge_data {
-   __s32   fd2; /* fd of second fence */
-   charname[32]; /* name of new fence */
-   __s32   fence; /* fd on newly created fence */
+   __s32   fd2;
+   charname[32];
+   __s32   fence;
 };

 /**
-- 
2.5.0

[PATCH v6 2/6] staging/android: rename SYNC_IOC_FENCE_INFO

[Gustavo Padovan]

From: Gustavo Padovan 

We don't use the 'fence' name to refer to sync_file anymore. So rename it
to SYNC_IOC_FILE_INFO.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
---
 drivers/staging/android/sync.c  | 2 +-
 drivers/staging/android/uapi/sync.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 31aa462..dc5f382 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -562,7 +562,7 @@ static long sync_file_ioctl(struct file *file, unsigned int 
cmd,
case SYNC_IOC_MERGE:
return sync_file_ioctl_merge(sync_file, arg);

-   case SYNC_IOC_FENCE_INFO:
+   case SYNC_IOC_FILE_INFO:
return sync_file_ioctl_fence_info(sync_file, arg);

default:
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index 4ffb7cc..dd0dd84 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -81,6 +81,6 @@ struct sync_file_info {
  * pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
  * To iterate over the sync_pt_infos, use the sync_pt_info.len field.
  */
-#define SYNC_IOC_FENCE_INFO_IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)

 #endif /* _UAPI_LINUX_SYNC_H */
-- 
2.5.0

[PATCH v6 1/6] staging/android: add num_fences field to struct sync_file_info

[Gustavo Padovan]

From: Gustavo Padovan 

Inform userspace how many fences are in the sync_fence_info field.

Signed-off-by: Gustavo Padovan 
Reviewed-by: Maarten Lankhorst 
---
 drivers/staging/android/sync.c  | 2 ++
 drivers/staging/android/uapi/sync.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..31aa462 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -525,6 +525,8 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info->status >= 0)
info->status = !info->status;

+   info->num_fences = sync_file->num_fences;
+
len = sizeof(struct sync_file_info);

for (i = 0; i < sync_file->num_fences; ++i) {
diff --git a/drivers/staging/android/uapi/sync.h 
b/drivers/staging/android/uapi/sync.h
index a0cf357..4ffb7cc 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -47,12 +47,14 @@ struct sync_fence_info {
  * userspace including pt_info.
  * @name:  name of fence
  * @status:status of fence. 1: signaled 0:active <0:error
+ * @num_fences number of fences in the sync_file
  * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
  */
 struct sync_file_info {
__u32   len;
charname[32];
__s32   status;
+   __u32   num_fences;

__u8sync_fence_info[0];
 };
-- 
2.5.0

[PATCH v5 5/5] staging/android: add flags member to sync ioctl structs

[Gustavo Padovan]

Hi Emil,

2016-03-02 Emil Velikov :

> On 1 March 2016 at 13:13, Gustavo Padovan  wrote:
> > From: Gustavo Padovan 
> >
> > Play safe and add flags member to all structs. So we don't need to
> > break API or create new IOCTL in the future if new features that requires
> > flags arises.
> >
> > v2: check if flags are valid (zero, in this case)
> >
> > v3: return -EINVAL if flags are not zero'ed
> >
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/staging/android/sync.c  | 8 
> >  drivers/staging/android/uapi/sync.h | 6 ++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> > index 3604e453..3c265ed 100644
> > --- a/drivers/staging/android/sync.c
> > +++ b/drivers/staging/android/sync.c
> > @@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
> > *sync_file,
> > goto err_put_fd;
> > }
> >
> > +   if (data.flags) {
> > +   err = -EINVAL;
> > +   goto err_put_fd;
> > +   }
> > +
> > fence2 = sync_file_fdget(data.fd2);
> > if (!fence2) {
> > err = -ENOENT;
> > @@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file 
> > *sync_file,
> > if (copy_from_user(, (void __user *)arg, sizeof(in)))
> > return -EFAULT;
> >
> > +   if (in.flags)
> > +   return -EINVAL;
> > +
> > info = kzalloc(sizeof(*info), GFP_KERNEL);
> > if (!info)
> > return -ENOMEM;
> > diff --git a/drivers/staging/android/uapi/sync.h 
> > b/drivers/staging/android/uapi/sync.h
> > index a122bb5..11e2d28 100644
> > --- a/drivers/staging/android/uapi/sync.h
> > +++ b/drivers/staging/android/uapi/sync.h
> > @@ -19,11 +19,13 @@
> >   * @fd2:   file descriptor of second fence
> >   * @name:  name of new fence
> >   * @fence: returns the fd of the new fence to userspace
> > + * @flags: merge_data flags
> >   */
> >  struct sync_merge_data {
> > __s32   fd2;
> > charname[32];
> > __s32   fence;
> > +   __u32   flags;
> The comment from last round still stands, struct size must be multiple
> of 64bits. As is the struct will be broken whenever/if we decide to
> extend it. See [1] for an alternative wording.
> 
> >  };
> >
> >  /**
> > @@ -31,12 +33,14 @@ struct sync_merge_data {
> >   * @obj_name:  name of parent sync_timeline
> >   * @driver_name:   name of driver implementing the parent
> >   * @status:status of the fence 0:active 1:signaled <0:error
> > + * @flags: fence_info flags
> >   * @timestamp_ns:  timestamp of status change in nanoseconds
> >   */
> >  struct sync_fence_info {
> > charobj_name[32];
> > chardriver_name[32];
> > __s32   status;
> > +   __u32   flags;
> > __u64   timestamp_ns;
> >  };
> >
> > @@ -44,6 +48,7 @@ struct sync_fence_info {
> >   * struct sync_file_info - data returned from fence info ioctl
> >   * @name:  name of fence
> >   * @status:status of fence. 1: signaled 0:active <0:error
> > + * @flags: sync_file_info flags
> >   * @num_fences number of fences in the sync_file
> >   * @sync_fence_info: pointer to array of structs sync_fence_info with all
> >   *  fences in the sync_file
> > @@ -51,6 +56,7 @@ struct sync_fence_info {
> >  struct sync_file_info {
> > charname[32];
> > __s32   status;
> > +   __u32   flags;
> > __u32   num_fences;
> >
> > __u64   sync_fence_info;
> Thanks for taking my suggestion and dropping len. Although I fear that
> we introduced a hole which we should be explicitly padded [2].
> 
> In both cases the pad should be checked for 0 and -EINVAL should be
> returned if that's not the case. This will allow us to potentially
> reuse in the future.
> 
> Other than that I believe the series looks pretty much spot on.

I agree with both suggestions, a new version of the patches is on the
way.

Gustavo

[PATCH 0/8] drm/bochs: convert bochs to atomic mode-setting

[Gerd Hoffmann]

On Mi, 2016-03-02 at 10:13 +, Emil Velikov wrote:
> [+Dave, +Gerd]
> 
> Hi all,
> 
> Just noticed that this old(ish) series never hit master.
> 
> On 16 July 2015 at 13:20, John Hunter  wrote:
> > From: Zhao Junwang 
> >
> > This patch series aim to convert DRM_BOCHS to atomic mode-setting.
> > I did this mostly reference Gustavo Padovan's patch series on
> > drm/exynos conversion.
> >
> Dave, Gerd, being the authors/maintainers of this driver can you guys
> take a look/test.
> Ackes, review and testing will be greatly appreciated.

Did testing a while back & reported back to John (not sure this was in
public on the list as we had some ping-ping emails beforehand due to
some problems of applying the patches).  No new version of the series
since.

cheers,
  Gerd

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #117 from Kamil Páral  ---
(In reply to Marek Olšák from comment #116)
> This thread is too long. Could someone please summarize the issues here?
> Also, how does the apitrace crash relate to the GPU hang?

I hoped somebody clever would respond, but it seems it'll have to be me. OpenGL
layman alert.

There were multiple issues discovered in this report:
0. (the core issue) radeonsi hangs the system completely (or sometimes
recovers) when playing XCOM, randomly (can be minutes, can be hours)
1. Jose claims XCOM has a bug, issuing invalid OpenGL commands (see comment
115).
2. apitrace is crashing while replaying almost any XCOM trace. My trace from
comment 74 is affected by this, so you need a temporary fix from
https://github.com/apitrace/apitrace/issues/407#issuecomment-166619366 to stop
it from crashing. The fix is not mainlined, because Jose says the purpose of
apitrace is to help discover problems, not hide them.
3. Another discovered issue was that apitrace was trimming vertex data too
aggressively (comment 113,
https://github.com/apitrace/apitrace/issues/407#issuecomment-167866502). That
is now fixed in apitrace, but my trace is affected, I'd have to re-record it.
The problem is that I was really lucky that I recorded it in the first place,
my computer did not hang completely as in 99% of cases, but recovered, and
therefore the trace was not cut short. I don't think I'd get that lucky again.
Plus Nicolai said he does not need that. The trimmed vertex data does not seem
to affect the replay in a negative way, but I assume it might complicate the
debugging process.
4. When looping over my trace, I can reproduce the crash pretty quick (i.e. my
computer completely hangs), but not deterministically (does not happen on every
replay). But it seems there is no further info I could supply from my side to
help you debug this.
5. Nicolai said he can reproduce it (probably by running the game, not
replaying my trace), but it takes a long time, so he wasn't able to work on
this too much.

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

[PATCH 1/2] drm: Add few more wrapper functions for drm panel

[Thierry Reding]

On Wed, Mar 02, 2016 at 06:28:31PM +0530, Deepak M wrote:
> Currently there are few pair of functions which
> are called during the panel enable/disable sequence.
> To improve the granularity, adding few more wrapper
> functions so that the functions are more specific
> on what they are doing.
> 
> Cc: Thierry Reding 
> Cc: David Airlie 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Signed-off-by: Deepak M 
> Signed-off-by: Gaurav K Singh 
> ---
>  include/drm/drm_panel.h | 92 
> +
>  1 file changed, 77 insertions(+), 15 deletions(-)

Sorry, but no. You're not giving any rationale for why you think the
granularity needs to be increased. The documentation already states that
panel drivers can use ->enable() and ->disable() to turn on and off the
backlight, why do you need the extra callbacks? The same is true for the
->prepare() and ->unprepare() callbacks, which are described to perform
what your new ->power_on() and ->power_off() callbacks would do.

Increasing the granularity isn't always a good thing. It means that
drivers can now call the functions in many more variations.

If you think you really need finer granularity, you need to do a better
job of explaining why. Also, Cc'ing me on the second patch, which I do
not have in any of my inboxes, and which I assume contains a usage
example of these new callbacks, might help me understand the need for
this.

One more comment below...

> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
[...]
>  struct drm_panel_funcs {
>   int (*disable)(struct drm_panel *panel);
> @@ -73,6 +90,10 @@ struct drm_panel_funcs {
>   int (*get_modes)(struct drm_panel *panel);
>   int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
>  struct display_timing *timings);
> + int (*power_on)(struct drm_panel *panel);
> + int (*power_off)(struct drm_panel *panel);
> + int (*backlight_on)(struct drm_panel *panel);
> + int (*backlight_off)(struct drm_panel *panel);
>  };
[...]
> +static inline int drm_panel_get_info(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + if (connector && panel && panel->funcs && panel->funcs->get_info)
> + return panel->funcs->get_info(panel, connector);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}

This callback no longer exists, so this patch is going to break
compilation.

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

[PATCH 1/2] dt-bindings: Add URT UMSH-8596MD-xT panel bindings

[Maciej S. Szmigiero]

On 22.02.2016 03:54, Rob Herring wrote:
> On Sat, Feb 13, 2016 at 10:50:24PM +0100, Maciej S. Szmigiero wrote:
>> Add DT bindings for United Radiant Technology
>> UMSH-8596MD-xT 7.0" WVGA TFT LCD panels.
>>
>> Signed-off-by: Maciej S. Szmigiero 
>> ---
>> This replaces "of: add URT UMSH-8596MD-xT panel DT bindings"
>> submission.
>>
>>  .../bindings/display/panel/urt,umsh-8596md.txt   | 16 
>> 
>>  1 file changed, 16 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt
> 
> Acked-by: Rob Herring 


@Thierry:
now that both vendor prefix and DT bindings have been acked
can this panel support be merged?

Maciej

[Intel-gfx] [PATCH v7 7/7] drm: add parameter-order checking to drm memory allocators

[Tvrtko Ursulin]

On 01/03/16 16:33, Dave Gordon wrote:
> After the recent addition of drm_malloc_gfp(), it was noticed that
> some callers of these functions has swapped the parameters in the
> call - it's supposed to be 'number of members' and 'sizeof(element)',
> but a few callers had got the size first and the count second. This
> isn't otherwise detected because they're both type 'size_t', and
> the implementation at present just multiplies them anyway, so the
> result is still right. But some future implementation might treat
> them differently (e.g. allowing 0 elements but not zero size), so
> let's add some compile-time checks and complain if the second (size)
> parameter isn't a sizeof() expression, or at least a compile-time
> constant.
>
> This patch also fixes those callers where the order was wrong.
>
> v6: removed duplicate BUILD_BUG_ON_MSG(); avoided renaming functions
>  by shadowing them with #defines and then calling the function
>  (non-recursively!) from inside the #define [Chris Wilson]
>
> Signed-off-by: Dave Gordon 
> Cc: Chris Wilson 
> Cc: Ville Syrjälä Cc: dri-
> Cc: dri-devel at lists.freedesktop.org

Reviewed-by: Tvrtko Ursulin 

Daniel, there are two DRM core patches in this series and only thing 
missing is convincing Chris that 6/7 does bring some improvement, 
especially looking forward to following GuC refactoring it will enable.

Assuming that gets resolved, I assume because of the core DRM bits I 
will need to ping you to pickup the series?

Regards,

Tvrtko

> ---
>   drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  8 
>   include/drm/drm_mem_util.h   | 27 
> ---
>   3 files changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 1aba01a..9ae4a71 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -340,7 +340,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
>*/
>   bos = drm_malloc_ab(args->nr_bos, sizeof(*bos));
>   relocs = drm_malloc_ab(args->nr_relocs, sizeof(*relocs));
> - stream = drm_malloc_ab(1, args->stream_size);
> + stream = drm_malloc_ab(args->stream_size, sizeof(*stream));
>   cmdbuf = etnaviv_gpu_cmdbuf_new(gpu, ALIGN(args->stream_size, 8) + 8,
>   args->nr_bos);
>   if (!bos || !relocs || !stream || !cmdbuf) {
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index f734b3c..1a136d9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1686,8 +1686,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
>   }
>
>   /* Copy in the exec list from userland */
> - exec_list = drm_malloc_ab(sizeof(*exec_list), args->buffer_count);
> - exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count);
> + exec_list = drm_malloc_ab(args->buffer_count, sizeof(*exec_list));
> + exec2_list = drm_malloc_ab(args->buffer_count, sizeof(*exec2_list));
>   if (exec_list == NULL || exec2_list == NULL) {
>   DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
> args->buffer_count);
> @@ -1775,8 +1775,8 @@ static bool only_mappable_for_reloc(unsigned int flags)
>   return -EINVAL;
>   }
>
> - exec2_list = drm_malloc_gfp(sizeof(*exec2_list),
> - args->buffer_count,
> + exec2_list = drm_malloc_gfp(args->buffer_count,
> + sizeof(*exec2_list),
>   GFP_TEMPORARY);
>   if (exec2_list == NULL) {
>   DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
> diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
> index 741ce75..5b0111c 100644
> --- a/include/drm/drm_mem_util.h
> +++ b/include/drm/drm_mem_util.h
> @@ -29,7 +29,7 @@
>
>   #include 
>
> -static __inline__ void *drm_calloc_large(size_t nmemb, size_t size)
> +static __inline__ void *drm_calloc_large(size_t nmemb, const size_t size)
>   {
>   if (size != 0 && nmemb > SIZE_MAX / size)
>   return NULL;
> @@ -41,8 +41,15 @@ static __inline__ void *drm_calloc_large(size_t nmemb, 
> size_t size)
>GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO, PAGE_KERNEL);
>   }
>
> +#define  drm_calloc_large(nmemb, size)   
> \
> +({   \
> + BUILD_BUG_ON_MSG(!__builtin_constant_p(size),   \
> + "Non-constant 'size' - check argument ordering?");  \
> + (drm_calloc_large)(nmemb, size);\
> +})
> +
>   /* Modeled after cairo's malloc_ab, it's like 

Reminder: 2016 X.Org Board of Directors Elections Nomination period is NOW

[Peter Hutterer]

We are seeking nominations for candidates for election to the X.Org
Foundation Board of Directors.  All X.Org Foundation members are
eligible for election to the board.

Nominations for the 2016 election are now open and will remain open
until 23:59 UTC on 15 March 2016.

The Board consists of directors elected from the membership.  Each
year, an election is held to bring the total number of directors to
eight. The four members receiving the highest vote totals will serve
as directors for two year terms.

The directors who received two year terms starting in 2015 were
Peter Hutterer, Martin Peres, Rob Clark and Daniel Vetter, They
will continue to serve until their term ends in 2017.  Current
directors whose term expires in 2016 are Alex Deucher, Matt Dew,
Egbert Eich and Keith Packard.

A director is expected to participate in the fortnightly IRC meeting to
discuss current business and to attend the annual meeting of the X.Org
Foundation, which will be held at a location determined in advance by
the Board of Directors.

A member may nominate themselves or any other member they feel is
qualified. Nominations should be sent to the Election Committee at
elections at x.org.

Nominees shall be required to be current members of the X.Org
Foundation, and submit a  personal statement of up to 200 words that
will be provided to prospective voters.  The collected statements,
along with the statement of contribution to the X.Org Foundation in
the members account page on http://members.x.org, will be made
available to all voters to help them make their voting decisions.

Nominations, membership applications or renewals and completed
personal statements must be received no later than 23:59 UTC on 15 March
2016.

The slate of candidates will be published 17 March
2016 and candidate Q will begin then.  The deadline for Xorg
membership applications and renewals is 17 March 2016.

Cheers,
  Peter, on behalf of the X.Org BoD

[PATCH v12 08/14] arm64: dts: mt8173: Add display subsystem related nodes

[Philipp Zabel]

Hi Matthias,

Am Mittwoch, den 02.03.2016, 11:21 +0100 schrieb Matthias Brugger:
> > @@ -576,7 +621,183 @@
> > mmsys: clock-controller at 1400 {
> > compatible = "mediatek,mt8173-mmsys", "syscon";
> > reg = <0 0x1400 0 0x1000>;
> > +   power-domains = < MT8173_POWER_DOMAIN_MM>;
> > #clock-cells = <1>;
> > +
> > +   /* FIXME - remove iommus here */
> > +   iommus = < M4U_PORT_DISP_OVL0>,
> > +< M4U_PORT_DISP_OVL1>;
> > +   };
> 
> Do we need this iommus?
> Sorry I wasn't able to follow this series, but it looks suspicious here :)
> 
> Regards,
> Matthias

Thanks for the pointer, I completely forgot about that issue. Yes, I'd
like to get rid of the iommus property in the mmsys node. If I just drop
it though, currently all the DMA buffer allocations from the mmsys
device fail. It works if I use any of the OVL devices (which have the
iommus property) to do the DMA allocations instead:

-8<-
>From 8cfd59df22659a1fb5bb4355ceca18bfe5725361 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Wed, 2 Mar 2016 14:33:41 +0100
Subject: [PATCH] drm/mediatek: use OVL device for DMA allocations

Change-Id: Ic809a9d544e84c4f152a2a8dc280cb795523e180
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  1 +
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 17 ++---
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index e212052..80056d1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -132,6 +132,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
 {
struct mtk_drm_private *private = drm->dev_private;
struct platform_device *pdev;
+   struct device_node *np;
int ret;

if (!iommu_present(_bus_type))
@@ -177,6 +178,18 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (ret < 0)
goto err_component_unbind;

+   /* Use OVL device for all DMA memory allocations */
+   np = private->comp_node[mtk_ddp_main[0]] ?:
+private->comp_node[mtk_ddp_ext[0]];
+   pdev = of_find_device_by_node(np);
+   if (!pdev) {
+   ret = -ENODEV;
+   dev_err(drm->dev, "Need at least one OVL device\n");
+   goto err_component_unbind;
+   }
+
+   private->dma_dev = >dev;
+
/*
 * We don't use the drm_irq_install() helpers provided by the DRM
 * core, so we need to set this manually in order to allow the
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index b1340d3..e0fff2c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -30,6 +30,7 @@ struct regmap;

 struct mtk_drm_private {
struct drm_device *drm;
+   struct device *dma_dev;

struct drm_crtc *crtc[MAX_CRTC];
unsigned int num_pipes;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 6bc494e..a773bfa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -15,6 +15,7 @@
 #include 
 #include 

+#include "mtk_drm_drv.h"
 #include "mtk_drm_gem.h"

 static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
@@ -42,6 +43,7 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct 
drm_device *dev,
 struct mtk_drm_gem_obj *mtk_drm_gem_create(struct drm_device *dev,
   size_t size, bool alloc_kmap)
 {
+   struct mtk_drm_private *priv = dev->dev_private;
struct mtk_drm_gem_obj *mtk_gem;
struct drm_gem_object *obj;
int ret;
@@ -58,7 +60,7 @@ struct mtk_drm_gem_obj *mtk_drm_gem_create(struct drm_device 
*dev,
if (!alloc_kmap)
dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, _gem->dma_attrs);

-   mtk_gem->cookie = dma_alloc_attrs(dev->dev, obj->size,
+   mtk_gem->cookie = dma_alloc_attrs(priv->dma_dev, obj->size,
  _gem->dma_addr, GFP_KERNEL,
  _gem->dma_attrs);
if (!mtk_gem->cookie) {
@@ -85,11 +87,12 @@ err_gem_free:
 void mtk_drm_gem_free_object(struct drm_gem_object *obj)
 {
struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+   struct mtk_drm_private *priv = obj->dev->dev_private;

if (mtk_gem->sg)
drm_prime_gem_destroy(obj, mtk_gem->sg);
else
-   dma_free_attrs(obj->dev->dev, obj->size, mtk_gem->cookie,
+   dma_free_attrs(priv->dma_dev, obj->size, mtk_gem->cookie,
   mtk_gem->dma_addr, _gem->dma_attrs);

/* release 

[PATCH v2.1 5/6] drm/atomic: Handle encoder assignment conflicts in a separate check, v3.

[Maarten Lankhorst]

The current check doesn't handle the case where we don't steal an
encoder, but keep it on the current connector. If we repurpose
disable_conflicting_encoders to do the checking, we just have
to reject the ones that conflict.

Changes since v1:
- Return early with empty encoder_mask, drm_for_each_connector
  requires connection_mutex held.
Changes since v2:
- Add comments to the loops.

Signed-off-by: Maarten Lankhorst 
Testcase: kms_setmode.invalid-clone-single-crtc-stealing
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index db11c2f9b098..bb60148c5c8d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -86,7 +86,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
}
 }

-static int disable_conflicting_connectors(struct drm_atomic_state *state)
+static int handle_conflicting_encoders(struct drm_atomic_state *state,
+  bool disable_conflicting_encoders)
 {
struct drm_connector_state *conn_state;
struct drm_connector *connector;
@@ -94,6 +95,11 @@ static int disable_conflicting_connectors(struct 
drm_atomic_state *state)
unsigned encoder_mask = 0;
int i, ret;

+   /*
+* First loop, find all newly assigned encoders from the connectors
+* part of the state. If the same encoder is assigned to multiple
+* connectors bail out.
+*/
for_each_connector_in_state(state, connector, conn_state, i) {
const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
struct drm_encoder *new_encoder;
@@ -106,10 +112,33 @@ static int disable_conflicting_connectors(struct 
drm_atomic_state *state)
else
new_encoder = funcs->best_encoder(connector);

-   if (new_encoder)
+   if (new_encoder) {
+   if (encoder_mask & (1 << 
drm_encoder_index(new_encoder))) {
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] on 
[CONNECTOR:%d:%s] already assigned\n",
+   new_encoder->base.id, new_encoder->name,
+   connector->base.id, connector->name);
+
+   return -EINVAL;
+   }
+
encoder_mask |= 1 << drm_encoder_index(new_encoder);
+   }
}

+   if (!encoder_mask)
+   return 0;
+
+   /*
+* Second loop, iterate over all connectors not part of the state.
+*
+* If a conflicting encoder is found and disable_conflicting_encoders
+* is not set, an error is returned. Userspace can provide a solution
+* through the atomic ioctl.
+*
+* If the flag is set conflicting connectors are removed from the crtc
+* and the crtc is disabled if no encoder is left. This preserves
+* compatibility with the legacy set_config behavior.
+*/
drm_for_each_connector(connector, state->dev) {
struct drm_crtc_state *crtc_state;

@@ -120,6 +149,15 @@ static int disable_conflicting_connectors(struct 
drm_atomic_state *state)
if (!encoder || !(encoder_mask & (1 << 
drm_encoder_index(encoder
continue;

+   if (!disable_conflicting_encoders) {
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on 
[CRTC:%d:%s] by [CONNECTOR:%d:%s]\n",
+encoder->base.id, encoder->name,
+connector->state->crtc->base.id,
+connector->state->crtc->name,
+connector->base.id, connector->name);
+   return -EINVAL;
+   }
+
conn_state = drm_atomic_get_connector_state(state, connector);
if (IS_ERR(conn_state))
return PTR_ERR(conn_state);
@@ -148,26 +186,6 @@ static int disable_conflicting_connectors(struct 
drm_atomic_state *state)
return 0;
 }

-static bool
-check_pending_encoder_assignment(struct drm_atomic_state *state,
-struct drm_encoder *new_encoder)
-{
-   struct drm_connector *connector;
-   struct drm_connector_state *conn_state;
-   int i;
-
-   for_each_connector_in_state(state, connector, conn_state, i) {
-   if (conn_state->best_encoder != new_encoder)
-   continue;
-
-   /* encoder already assigned and we're trying to re-steal it! */
-   if (connector->state->best_encoder != conn_state->best_encoder)
-   return false;
-   }
-
-   return true;
-}
-
 static void
 set_best_encoder(struct drm_atomic_state *state,
 struct drm_connector_state *conn_state,
@@ -325,13 +343,6 @@ 

Alternative binding proposal for tda998x audio (Was: Re: [PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports)

[Mark Brown]

On Tue, Mar 01, 2016 at 05:16:30PM +0100, Jean-Francois Moine wrote:

> As told many times, the simple card is a pure Linux specific entity.
> It does not describe any hardware. It should not appear in a DT, or,

The physical integration of audio systems is meaningful hardware that
physically exists and matters to software.  I am completely fed up of 
having to go through this, I'm fairly sure I've been through it with you
before.

> if it does, its compatible should be "linux, simple-audio-card".

Documentation/SubmittingPatches.

> Then, how can the other OSs know the links between the audio
> devices and the audio encoders/connectors?

Documentation/devicetree/bindings/sound/simple-card.txt

> On the other way, the audio graph does not impose any particular
> software design. It just describes the links between the different
> hardware components and each OS is free to implement its own layout.

So long as there is no effort on actually upstreaming a graph based card
that shows realistic signs of getting merged in a useful form it doesn't
meaningfully exist.  Right now nobody is even trying to do that.

If you are concerned about simple-card being too Linux specific then by
all means add board specific bindings, preferably ones that can just be
added to simple-card as a compatible string.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160302/bf0065de/attachment.sig>

[PATCH v6 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

[Rob Herring]

On Fri, Feb 26, 2016 at 04:40:18PM +0800, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.
> 
> v6:
> - Cleanup values part of reg and clocks properties.
> - Change "pclk_dsi" clock name to "pclk".
> v5:
> - Remove endpoint unit address of dsi output port.
> - Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
> - Add "resets" property for ADE reset.
> v4:
> - Describe more specific of clocks and ports.
> - Fix indentation.
> v3:
> - Make ade as the drm master node.
> - Use assigned-clocks to set clock rate.
> - Use ports to connect display relavant nodes.
> v2:
> - Move dt binding docs to bindings/display/hisilicon directory.
> 
> Signed-off-by: Xinliang Liu 
> ---
>  .../bindings/display/hisilicon/dw-dsi.txt  | 72 
> ++
>  .../bindings/display/hisilicon/hisi-ade.txt| 64 +++
>  2 files changed, 136 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

Acked-by: Rob Herring 

[PATCH 2/2] drm/amdgpu: disable runtime pm on PX laptops without dGPU power control

[Alex Deucher]

Some PX laptops don't provide an ACPI method to control dGPU power.  On
those systems, the driver is responsible for handling the dGPU power
state.  Disable runtime PM on them until support for this is implemented.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 8 +++-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
index 3c89586..81dc6b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -63,6 +63,10 @@ bool amdgpu_has_atpx(void) {
return amdgpu_atpx_priv.atpx_detected;
 }

+bool amdgpu_has_atpx_dgpu_power_cntl(void) {
+   return amdgpu_atpx_priv.atpx.functions.power_cntl;
+}
+
 /**
  * amdgpu_atpx_call - call an ATPX method
  *
@@ -142,10 +146,6 @@ static void amdgpu_atpx_parse_functions(struct 
amdgpu_atpx_functions *f, u32 mas
  */
 static int amdgpu_atpx_validate(struct amdgpu_atpx *atpx)
 {
-   /* make sure required functions are enabled */
-   /* dGPU power control is required */
-   atpx->functions.power_cntl = true;
-
if (atpx->functions.px_params) {
union acpi_object *info;
struct atpx_px_params output;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 51bfc11..d6c68d0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -62,6 +62,12 @@ static const char *amdgpu_asic_name[] = {
"LAST",
 };

+#if defined(CONFIG_VGA_SWITCHEROO)
+bool amdgpu_has_atpx_dgpu_power_cntl(void);
+#else
+static inline bool amdgpu_has_atpx_dgpu_power_cntl(void) { return false; }
+#endif
+
 bool amdgpu_device_is_px(struct drm_device *dev)
 {
struct amdgpu_device *adev = dev->dev_private;
@@ -1511,7 +1517,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,

if (amdgpu_runtime_pm == 1)
runtime = true;
-   if (amdgpu_device_is_px(ddev))
+   if (amdgpu_device_is_px(ddev) && amdgpu_has_atpx_dgpu_power_cntl())
runtime = true;
vga_switcheroo_register_client(adev->pdev, _switcheroo_ops, 
runtime);
if (runtime)
-- 
2.5.0

[PATCH 1/2] drm/radeon: disable runtime pm on PX laptops without dGPU power control

[Alex Deucher]

Some PX laptops don't provide an ACPI method to control dGPU power.  On
those systems, the driver is responsible for handling the dGPU power
state.  Disable runtime PM on them until support for this is implemented.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_atpx_handler.c | 8 
 drivers/gpu/drm/radeon/radeon_device.c   | 8 +++-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index c4b4f29..9bc408c 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -62,6 +62,10 @@ bool radeon_has_atpx(void) {
return radeon_atpx_priv.atpx_detected;
 }

+bool radeon_has_atpx_dgpu_power_cntl(void) {
+   return radeon_atpx_priv.atpx.functions.power_cntl;
+}
+
 /**
  * radeon_atpx_call - call an ATPX method
  *
@@ -141,10 +145,6 @@ static void radeon_atpx_parse_functions(struct 
radeon_atpx_functions *f, u32 mas
  */
 static int radeon_atpx_validate(struct radeon_atpx *atpx)
 {
-   /* make sure required functions are enabled */
-   /* dGPU power control is required */
-   atpx->functions.power_cntl = true;
-
if (atpx->functions.px_params) {
union acpi_object *info;
struct atpx_px_params output;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 902b59c..4de23ae 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -103,6 +103,12 @@ static const char radeon_family_name[][16] = {
"LAST",
 };

+#if defined(CONFIG_VGA_SWITCHEROO)
+bool radeon_has_atpx_dgpu_power_cntl(void);
+#else
+static inline bool radeon_has_atpx_dgpu_power_cntl(void) { return false; }
+#endif
+
 #define RADEON_PX_QUIRK_DISABLE_PX  (1 << 0)
 #define RADEON_PX_QUIRK_LONG_WAKEUP (1 << 1)

@@ -1433,7 +1439,7 @@ int radeon_device_init(struct radeon_device *rdev,
 * ignore it */
vga_client_register(rdev->pdev, rdev, NULL, radeon_vga_set_decode);

-   if (rdev->flags & RADEON_IS_PX)
+   if ((rdev->flags & RADEON_IS_PX) && radeon_has_atpx_dgpu_power_cntl())
runtime = true;
vga_switcheroo_register_client(rdev->pdev, _switcheroo_ops, 
runtime);
if (runtime)
-- 
2.5.0

[PATCH v3 10/10] dt-bindings: msm/hdmi: Add HDMI PHY bindings

[Rob Herring]

On Thu, Feb 25, 2016 at 11:22:45AM +0530, Archit Taneja wrote:
> Add HDMI PHY bindings. Update the example to use HDMI PHY.
> 
> Added a missing power-domains property in the HDMI core bindings. Also,
> simplified HDMI TX's DT node name in the example.
> 
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring 
> 
> Signed-off-by: Archit Taneja 
> ---
>  .../devicetree/bindings/display/msm/hdmi.txt   | 46 
> +-
>  1 file changed, 44 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

[PATCH v2 7/7] drm/msm/dsi: Parse DSI lanes via DT

[Rob Herring]

On Thu, Feb 25, 2016 at 11:19:48AM +0530, Archit Taneja wrote:
> The DSI driver is currently unaware of how the DSI physical data lanes
> are mapped to the logical lanes provided by the DSI controller.
> 
> Create a DT binding "qcom,data-lane-map" that provides this information
> on a given platform.
> 
> The MSM DSI controller is restricted in terms of what all mappings
> it can support. The lane polarity is fixed for all the lanes, the clock
> lanes are fixed, and the data lanes can be swapped among each other only
> for a few combinations. Apply these restrictions when we parse the DT
> data.
> 
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring 
> Cc: Tomi Valkeinen 
> 
> Signed-off-by: Archit Taneja 
> ---
>  .../devicetree/bindings/display/msm/dsi.txt|  32 +-

Acked-by: Rob Herring 

>  drivers/gpu/drm/msm/dsi/dsi_host.c | 116 
> +
>  2 files changed, 125 insertions(+), 23 deletions(-)

[pull] radeon and amdgpu drm-fixes-4.5

[Alex Deucher]

Hi Dave,

Fixes for radeon and amdgpu:
- Fix GPUVM flushing on CI and VI
- Misc DPM and Powerplay fixes
- VCE DPM fixes for CZ/ST
- DP hotplug fix

The following changes since commit 6378076bcfdcd1d4f8d726d08d3fa044736873eb:

  drm/amdgpu: disable direct VM updates when vm_debug is set (2016-02-24 
12:46:06 -0500)

are available in the git repository at:

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

for you to fetch changes up to 0b39c531cfa12dad54eac238c2e303b994df1ef7:

  drm/amdgpu: return from atombios_dp_get_dpcd only when error (2016-03-02 
11:01:25 -0500)


Alex Deucher (5):
  drm/amdgpu/pm: update current crtc info after setting the powerstate
  drm/radeon/pm: update current crtc info after setting the powerstate
  drm/amdgpu/cz: enable/disable vce dpm even if vce pg is disabled
  drm/amdgpu/powerplay/cz: enable/disable vce dpm independent of vce pg
  drm/amdgpu/cz: remove commented out call to enable vce pg

Arindam Nath (1):
  drm/amdgpu: return from atombios_dp_get_dpcd only when error

Christian König (1):
  drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well

Chunming Zhou (1):
  drm/amdgpu/gfx8: specify which engine to wait before vm flush

Rex Zhu (2):
  drm/amd/powerplay: export AMD_PP_EVENT_COMPLETE_INIT task to amdgpu.
  drm/amd/powerplay: send event to notify powerplay all modules are 
initialized.

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |  6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |  4 +++-
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c|  7 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  | 13 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  3 ++-
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  |  5 -
 drivers/gpu/drm/amd/powerplay/eventmgr/eventactionchains.c |  1 +
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_pm.c |  8 
 10 files changed, 34 insertions(+), 17 deletions(-)

[PATCH v12 08/14] arm64: dts: mt8173: Add display subsystem related nodes

[Matthias Brugger]

On 01/03/16 16:20, Philipp Zabel wrote:
> From: CK Hu 
>
> This patch adds the device nodes for the DISP function blocks
> comprising the display subsystem.
>
> Signed-off-by: CK Hu 
> Signed-off-by: Cawa Cheng 
> Signed-off-by: Jie Qiu 
> Signed-off-by: Daniel Kurtz 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v10:
>   - reordered nodes by address
> ---
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 235 
> +++
>   1 file changed, 235 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 8048811..4ff666d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -26,6 +26,23 @@
>   #address-cells = <2>;
>   #size-cells = <2>;
>
> + aliases {
> + ovl0 = 
> + ovl1 = 
> + rdma0 = 
> + rdma1 = 
> + rdma2 = 
> + wdma0 = 
> + wdma1 = 
> + color0 = 
> + color1 = 
> + split0 = 
> + split1 = 
> + dpi0 = 
> + dsi0 = 
> + dsi1 = 
> + };
> +
>   cpus {
>   #address-cells = <1>;
>   #size-cells = <0>;
> @@ -295,6 +312,26 @@
>   #clock-cells = <1>;
>   };
>
> + mipi_tx0: mipi-dphy at 10215000 {
> + compatible = "mediatek,mt8173-mipi-tx";
> + reg = <0 0x10215000 0 0x1000>;
> + clocks = <>;
> + clock-output-names = "mipi_tx0_pll";
> + #clock-cells = <0>;
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
> + mipi_tx1: mipi-dphy at 10216000 {
> + compatible = "mediatek,mt8173-mipi-tx";
> + reg = <0 0x10216000 0 0x1000>;
> + clocks = <>;
> + clock-output-names = "mipi_tx1_pll";
> + #clock-cells = <0>;
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
>   gic: interrupt-controller at 1022 {
>   compatible = "arm,gic-400";
>   #interrupt-cells = <3>;
> @@ -441,6 +478,14 @@
>   status = "disabled";
>   };
>
> + hdmiddc0: i2c at 11012000 {
> + compatible = "mediatek,mt8173-hdmi-ddc";
> + interrupts = ;
> + reg = <0 0x11012000 0 0x1C>;
> + clocks = < CLK_PERI_I2C5>;
> + clock-names = "ddc-i2c";
> + };
> +
>   i2c6: i2c at 11013000 {
>   compatible = "mediatek,mt8173-i2c";
>   reg = <0 0x11013000 0 0x70>,
> @@ -576,7 +621,183 @@
>   mmsys: clock-controller at 1400 {
>   compatible = "mediatek,mt8173-mmsys", "syscon";
>   reg = <0 0x1400 0 0x1000>;
> + power-domains = < MT8173_POWER_DOMAIN_MM>;
>   #clock-cells = <1>;
> +
> + /* FIXME - remove iommus here */
> + iommus = < M4U_PORT_DISP_OVL0>,
> +  < M4U_PORT_DISP_OVL1>;
> + };

Do we need this iommus?
Sorry I wasn't able to follow this series, but it looks suspicious here :)

Regards,
Matthias

Alternative binding proposal for tda998x audio (Was: Re: [PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports)

[Jyri Sarha]

On 03/01/16 21:26, Jean-Francois Moine wrote:
> On Tue, 1 Mar 2016 20:29:17 +0200
> Jyri Sarha  wrote:
>
>> I understand the short comings of simple-card and it's binding. However,
>> the binding is documented and it is feasible to extract the audio
>> connections from a simple-card binding too. In fact it models the I2S
>> connections better than straight out of tehe box graph binding. Actually
>> a graph is not the best way describe an i2s-bus with multiple DAIs
>> (codec or CPU) connected to it.
>
> I still don't understand your problem. You want something like:
>

The problem is adding redundant unused details into binding without any 
plan of ever using them.

Fundamentally my problem is finding some consensus on the tda998x ASoC 
implementation. I've been reusing your binding for couple of review 
rounds and there has been some well justified critique towards it. I 
feel stupid in pushing forward something that I do not completely agree 
myself, so I decided to try something else.

>   audio-ports = < TDA998x_SPDIF   0x04
>   TDA998x_I2S 0x03>;
>
> and the graph definition would be:
>
>   port at 03 {
>   reg = <0x03>;
>   port-type = "audio-i2s";
>   ...
>   };
>
>   port at 04 {
>   reg = <0x04>;
>   port-type = "audio-spdif";
>   ...
>   };
>
> Apart the syntax, I don't really see the difference.
>

Yes, the necessary information is contained in both bindings. I can live 
with either one of them, but I would prefer my version. Essentially I 
would just like to move forward.

Best regards,
Jyri

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Daniel Vetter]

On Tue, Mar 01, 2016 at 06:17:33AM +0530, Thulasimani, Sivakumar wrote:
> 
> 
> On 3/1/2016 5:03 AM, Rob Clark wrote:
> >On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter  wrote:
> >>On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
> >>>
> >>>On 2/24/2016 3:41 AM, Lyude wrote:
> As it turns out, resuming DP MST is racey since we don't make sure MST
> is ready before we start modesetting, it just usually happens to be
> ready in time. This isn't the case on all systems, particularly a
> ThinkPad T560 with displays connected through the dock. On these
> systems, resuming the laptop while connected to the dock usually results
> in blank monitors. Making sure MST is ready before doing any kind of
> modesetting fixes this issue.
> >>>basic question since i haven't worked on MST much. MST should work like any
> >>>other digital panel on resume. i.e detect followed by modeset. in the
> >>>modified
> >>>commit mentioned below is it failing to detect the panel or failing at the
> >>>modeset ?
> >>>if we are depending on the intel_display_resume, how about moving the
> >>>intel_dp_mst_resume just above intel_display_resume?
> >>>
> >>>
> >>>Generic question to others in mail list on i915_drm_resume
> >>>we are doing a modeset and then doing the detect/hpd init.
> >>>shouldn't this be the other way round ? almost all displays
> >>>will pass a modeset even if display is not connected so we
> >>>are spending time on modeset even for displays that were
> >>>removed during the suspend state. if this is to simply
> >>>drm_state being saved and restored,
> >>We must restore anyway, we're not really allowed to shut down a display
> >>without userspace's consent. DP mst breaks this, and it's not fun really.
> >well, that isn't completely true.. I mean, if the user unplugs (for
> >example) an hdmi monitor, it isn't with userspace's consent..
> >
> >I wonder if we could just have flag per connector, ie.
> >connector->no_auto_resume and just automatically send unplug events
> >for those to userspace (followed shortly by a plug event if it is
> >still connected and the normal hpd mechanism kicks in?  I mean, for
> >all we know, the user unplugged the DP monitor/hub/etc and plugged in
> >a different one while we were suspended..
> >
> >BR,
> >-R
> i agree. performing a modeset on a display without even confirming
> if it is the same one when we had suspended the system will result in
> issues such as applying a mode that may not be supported on the
> new display or corruption or blankout or simply failing the modeset
> restore or worst case of doing modeset without a display connected.
> if we will not allow such a scenario during normal operation, i.e prevent
> incorrect modeset requests during normal functioning, why allow such
> a modeset during suspend-resume alone ?
> we can store the edid hash and if the display has the same hash
> post resume then we can allow mode to be restored.

We do allow such a situation for non-mst. Userspace can set whatever mode
it wants, on even disconnected outputs. Kernel simply executes. MST is
different here because we're not talking about the sink connected to the
MST branch that's unplugged, but the branch itself (with all it's
connectors).

One of those things is connector->status (enabling an unplugged screen).
The other is the existence of the connector itself (mst branch unplug).
-Daniel

> 
> regards,
> Sivakumar
> >>So for hotunplug the flow should always be:
> >>1. kernel notices something has changed in the output config.
> >>2. kernel sends out uevent
> >>3. userspace figures out what changed, and what needs to be done
> >>4. userspace asks the kernel to change display configuration through
> >>setCrtc and Atomic ioctl calls.
> >>
> >>Irrespective of hotunplug handling, the kernel also _must_ restore the
> >>entire display configuration before userspace resumes. We can do that
> >>asynchronously (and there's plans for that), but even then we must stall
> >>userspace on the first KMS ioclt to keep up the illusion that a system s/r
> >>is transparent.
> >>
> >>In short, even if we do hpd processing before resuming the display,
> >>nothing will be faster - we must wait for userspace to make up its mind,
> >>and that can only happen once we've restored the display config.
> >>
> >>And again, mst is kinda breaking this, since and mst unplug results in a
> >>force-disable. Which can upset userspace and in general results in the
> >>need for lots of fragile error handling all over.
> >>
> We originally changed the resume order in
> 
>  commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw 
>  state")
> 
> to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
> issue now anyhow.
> 
> CC: stable at vger.kernel.org
> Signed-off-by: Lyude 
> >>Wrt the patch itself: I think only in 4.6 we've actually fixed up all
> >>these mst WARN_ON. Cc: stable seems extremely risky on 

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Daniel Vetter]

On Mon, Feb 29, 2016 at 06:33:42PM -0500, Rob Clark wrote:
> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter  wrote:
> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
> >>
> >>
> >> On 2/24/2016 3:41 AM, Lyude wrote:
> >> >As it turns out, resuming DP MST is racey since we don't make sure MST
> >> >is ready before we start modesetting, it just usually happens to be
> >> >ready in time. This isn't the case on all systems, particularly a
> >> >ThinkPad T560 with displays connected through the dock. On these
> >> >systems, resuming the laptop while connected to the dock usually results
> >> >in blank monitors. Making sure MST is ready before doing any kind of
> >> >modesetting fixes this issue.
> >> basic question since i haven't worked on MST much. MST should work like any
> >> other digital panel on resume. i.e detect followed by modeset. in the
> >> modified
> >> commit mentioned below is it failing to detect the panel or failing at the
> >> modeset ?
> >> if we are depending on the intel_display_resume, how about moving the
> >> intel_dp_mst_resume just above intel_display_resume?
> >>
> >>
> >> Generic question to others in mail list on i915_drm_resume
> >> we are doing a modeset and then doing the detect/hpd init.
> >> shouldn't this be the other way round ? almost all displays
> >> will pass a modeset even if display is not connected so we
> >> are spending time on modeset even for displays that were
> >> removed during the suspend state. if this is to simply
> >> drm_state being saved and restored,
> >
> > We must restore anyway, we're not really allowed to shut down a display
> > without userspace's consent. DP mst breaks this, and it's not fun really.
> 
> well, that isn't completely true.. I mean, if the user unplugs (for
> example) an hdmi monitor, it isn't with userspace's consent..

But the pipe keeps running, which means the next pageflip or vblank wait
won't just fail and result in hilarity.

> I wonder if we could just have flag per connector, ie.
> connector->no_auto_resume and just automatically send unplug events
> for those to userspace (followed shortly by a plug event if it is
> still connected and the normal hpd mechanism kicks in?  I mean, for
> all we know, the user unplugged the DP monitor/hub/etc and plugged in
> a different one while we were suspended..

We need to be able to restore mst to avoid upsetting the desktop. I don't
think this would work.
-Daniel

> 
> BR,
> -R
> 
> > So for hotunplug the flow should always be:
> > 1. kernel notices something has changed in the output config.
> > 2. kernel sends out uevent
> > 3. userspace figures out what changed, and what needs to be done
> > 4. userspace asks the kernel to change display configuration through
> > setCrtc and Atomic ioctl calls.
> >
> > Irrespective of hotunplug handling, the kernel also _must_ restore the
> > entire display configuration before userspace resumes. We can do that
> > asynchronously (and there's plans for that), but even then we must stall
> > userspace on the first KMS ioclt to keep up the illusion that a system s/r
> > is transparent.
> >
> > In short, even if we do hpd processing before resuming the display,
> > nothing will be faster - we must wait for userspace to make up its mind,
> > and that can only happen once we've restored the display config.
> >
> > And again, mst is kinda breaking this, since and mst unplug results in a
> > force-disable. Which can upset userspace and in general results in the
> > need for lots of fragile error handling all over.
> >
> >> >We originally changed the resume order in
> >> >
> >> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw 
> >> > state")
> >> >
> >> >to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
> >> >issue now anyhow.
> >> >
> >> >CC: stable at vger.kernel.org
> >> >Signed-off-by: Lyude 
> >
> > Wrt the patch itself: I think only in 4.6 we've actually fixed up all
> > these mst WARN_ON. Cc: stable seems extremely risky on this one. Also, the
> > modeset state readout for mst is still not entirely correct (it still
> > relies on software state), so I'm not sure we've actually managed to shut
> > up all the WARNINGs. Iirc the way to repro them is to hot-unplug something
> > while suspended. In short the get_hw_state functions for mst should not
> > rely on any mst software state, but instead just look at hw registers and
> > dp aux registers to figure out what's going on. But not sure whether this
> > will result on WARNINGs on resume, since generally the bios doesn't enable
> > anything in that case.
> >
> > Furthermore MST still does a force-modeset when processing a hotunplug.
> > Doing that before we've resumed the display is likely a very bad idea.
> > What we need to fix that part is to separate the dp mst connector
> > hotplug/unplugging from actually updating the modeset change. This needs
> > reference-counting on drm_connector (so that we can lazily free
> > drm_connector 

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Rob Clark]

On Wed, Mar 2, 2016 at 4:29 AM, Daniel Vetter  wrote:
> On Mon, Feb 29, 2016 at 06:33:42PM -0500, Rob Clark wrote:
>> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter  wrote:
>> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>> >>
>> >>
>> >> On 2/24/2016 3:41 AM, Lyude wrote:
>> >> >As it turns out, resuming DP MST is racey since we don't make sure MST
>> >> >is ready before we start modesetting, it just usually happens to be
>> >> >ready in time. This isn't the case on all systems, particularly a
>> >> >ThinkPad T560 with displays connected through the dock. On these
>> >> >systems, resuming the laptop while connected to the dock usually results
>> >> >in blank monitors. Making sure MST is ready before doing any kind of
>> >> >modesetting fixes this issue.
>> >> basic question since i haven't worked on MST much. MST should work like 
>> >> any
>> >> other digital panel on resume. i.e detect followed by modeset. in the
>> >> modified
>> >> commit mentioned below is it failing to detect the panel or failing at the
>> >> modeset ?
>> >> if we are depending on the intel_display_resume, how about moving the
>> >> intel_dp_mst_resume just above intel_display_resume?
>> >>
>> >>
>> >> Generic question to others in mail list on i915_drm_resume
>> >> we are doing a modeset and then doing the detect/hpd init.
>> >> shouldn't this be the other way round ? almost all displays
>> >> will pass a modeset even if display is not connected so we
>> >> are spending time on modeset even for displays that were
>> >> removed during the suspend state. if this is to simply
>> >> drm_state being saved and restored,
>> >
>> > We must restore anyway, we're not really allowed to shut down a display
>> > without userspace's consent. DP mst breaks this, and it's not fun really.
>>
>> well, that isn't completely true.. I mean, if the user unplugs (for
>> example) an hdmi monitor, it isn't with userspace's consent..
>
> But the pipe keeps running, which means the next pageflip or vblank wait
> won't just fail and result in hilarity.

well, then shut it down?  But what do we do on hot unplug?  It seems
like we should be able to make it look like an unplug plus later
replug.

>> I wonder if we could just have flag per connector, ie.
>> connector->no_auto_resume and just automatically send unplug events
>> for those to userspace (followed shortly by a plug event if it is
>> still connected and the normal hpd mechanism kicks in?  I mean, for
>> all we know, the user unplugged the DP monitor/hub/etc and plugged in
>> a different one while we were suspended..
>
> We need to be able to restore mst to avoid upsetting the desktop. I don't
> think this would work.

I think the desktop already supports hotplug, or we'd have bigger issues.

What happens if the DP topology changes while suspended.  Ie. user
plugs in a different monitor with a hub in between, or things like
that?  Seems like you can end up in scenarios where previous mode is
no longer valid/possible.

BR,
-R

> -Daniel
>
>>
>> BR,
>> -R
>>
>> > So for hotunplug the flow should always be:
>> > 1. kernel notices something has changed in the output config.
>> > 2. kernel sends out uevent
>> > 3. userspace figures out what changed, and what needs to be done
>> > 4. userspace asks the kernel to change display configuration through
>> > setCrtc and Atomic ioctl calls.
>> >
>> > Irrespective of hotunplug handling, the kernel also _must_ restore the
>> > entire display configuration before userspace resumes. We can do that
>> > asynchronously (and there's plans for that), but even then we must stall
>> > userspace on the first KMS ioclt to keep up the illusion that a system s/r
>> > is transparent.
>> >
>> > In short, even if we do hpd processing before resuming the display,
>> > nothing will be faster - we must wait for userspace to make up its mind,
>> > and that can only happen once we've restored the display config.
>> >
>> > And again, mst is kinda breaking this, since and mst unplug results in a
>> > force-disable. Which can upset userspace and in general results in the
>> > need for lots of fragile error handling all over.
>> >
>> >> >We originally changed the resume order in
>> >> >
>> >> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw 
>> >> > state")
>> >> >
>> >> >to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
>> >> >issue now anyhow.
>> >> >
>> >> >CC: stable at vger.kernel.org
>> >> >Signed-off-by: Lyude 
>> >
>> > Wrt the patch itself: I think only in 4.6 we've actually fixed up all
>> > these mst WARN_ON. Cc: stable seems extremely risky on this one. Also, the
>> > modeset state readout for mst is still not entirely correct (it still
>> > relies on software state), so I'm not sure we've actually managed to shut
>> > up all the WARNINGs. Iirc the way to repro them is to hot-unplug something
>> > while suspended. In short the get_hw_state functions for mst should not
>> > rely on any mst software state, 

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Daniel Vetter]

On Tue, Mar 01, 2016 at 07:33:12AM +1000, Dave Airlie wrote:
> On 1 March 2016 at 02:12, Daniel Vetter  wrote:
> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
> >>
> >>
> >> On 2/24/2016 3:41 AM, Lyude wrote:
> >> >As it turns out, resuming DP MST is racey since we don't make sure MST
> >> >is ready before we start modesetting, it just usually happens to be
> >> >ready in time. This isn't the case on all systems, particularly a
> >> >ThinkPad T560 with displays connected through the dock. On these
> >> >systems, resuming the laptop while connected to the dock usually results
> >> >in blank monitors. Making sure MST is ready before doing any kind of
> >> >modesetting fixes this issue.
> >> basic question since i haven't worked on MST much. MST should work like any
> >> other digital panel on resume. i.e detect followed by modeset. in the
> >> modified
> >> commit mentioned below is it failing to detect the panel or failing at the
> >> modeset ?
> >> if we are depending on the intel_display_resume, how about moving the
> >> intel_dp_mst_resume just above intel_display_resume?
> >>
> >>
> >> Generic question to others in mail list on i915_drm_resume
> >> we are doing a modeset and then doing the detect/hpd init.
> >> shouldn't this be the other way round ? almost all displays
> >> will pass a modeset even if display is not connected so we
> >> are spending time on modeset even for displays that were
> >> removed during the suspend state. if this is to simply
> >> drm_state being saved and restored,
> >
> > We must restore anyway, we're not really allowed to shut down a display
> > without userspace's consent. DP mst breaks this, and it's not fun really.
> > So for hotunplug the flow should always be:
> > 1. kernel notices something has changed in the output config.
> > 2. kernel sends out uevent
> > 3. userspace figures out what changed, and what needs to be done
> > 4. userspace asks the kernel to change display configuration through
> > setCrtc and Atomic ioctl calls.
> >
> > Irrespective of hotunplug handling, the kernel also _must_ restore the
> > entire display configuration before userspace resumes. We can do that
> > asynchronously (and there's plans for that), but even then we must stall
> > userspace on the first KMS ioclt to keep up the illusion that a system s/r
> > is transparent.
> >
> > In short, even if we do hpd processing before resuming the display,
> > nothing will be faster - we must wait for userspace to make up its mind,
> > and that can only happen once we've restored the display config.
> >
> > And again, mst is kinda breaking this, since and mst unplug results in a
> > force-disable. Which can upset userspace and in general results in the
> > need for lots of fragile error handling all over.
> 
> >
> >> >We originally changed the resume order in
> >> >
> >> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw 
> >> > state")
> >> >
> >> >to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
> >> >issue now anyhow.
> >> >
> >> >CC: stable at vger.kernel.org
> >> >Signed-off-by: Lyude 
> >
> > Wrt the patch itself: I think only in 4.6 we've actually fixed up all
> > these mst WARN_ON. Cc: stable seems extremely risky on this one. Also, the
> > modeset state readout for mst is still not entirely correct (it still
> > relies on software state), so I'm not sure we've actually managed to shut
> > up all the WARNINGs. Iirc the way to repro them is to hot-unplug something
> > while suspended. In short the get_hw_state functions for mst should not
> > rely on any mst software state, but instead just look at hw registers and
> > dp aux registers to figure out what's going on. But not sure whether this
> > will result on WARNINGs on resume, since generally the bios doesn't enable
> > anything in that case.
> >
> > Furthermore MST still does a force-modeset when processing a hotunplug.
> > Doing that before we've resumed the display is likely a very bad idea.
> > What we need to fix that part is to separate the dp mst connector
> > hotplug/unplugging from actually updating the modeset change. This needs
> > reference-counting on drm_connector (so that we can lazily free
> > drm_connector structs after hot-unplug), and is a major change.
> 
> I agree on the dropping stable on this, just put it in 4.6 for now, actually 
> I'm
> happy to send in for 4.5 at this stage as it fixes some laptops I have as 
> well.
> 
> However I'm not sure how you think we can keep hw state programmed when
> the hw is gone away until userspace comes along to do something about it,
> the hw state is mostly on the other side of the MST link which has also gone
> away. My experience with leaving the crtcs programmed was and I might not
> be 100% sure was hw hangs, I even managed to get some MCEs over time.
> 
> Though I might be tempted to go investigate this a bit more.

Hm ... The issue is that stopping the pipe behind userspace back is kinda
really 

[PATCH 0/7] drm/cirrus: convert cirrus to atomic mode-setting

[Emil Velikov]

[+Dave]

Hi all,

Another necro bump - second part of John's work from GSOC 2015 that
did not land :-(

On 30 July 2015 at 11:08, John Hunter  wrote:
> From: Zhao Junwang 
>
> This patch series aim to convert DRM_CIRRUS to atomic mode-setting.
> This mostly reference my previous patch series on DRM_BOCHS and
> Gustavo Padovan;s patch series on drm/exynos.
>
Dave, I realise that you wrote the driver a long time ago, although
you're still one of the people best familiar with it.
Can you spare some time and check/ack it ?

Thanks
Emil

[PATCH 0/8] drm/bochs: convert bochs to atomic mode-setting

[Emil Velikov]

[+Dave, +Gerd]

Hi all,

Just noticed that this old(ish) series never hit master.

On 16 July 2015 at 13:20, John Hunter  wrote:
> From: Zhao Junwang 
>
> This patch series aim to convert DRM_BOCHS to atomic mode-setting.
> I did this mostly reference Gustavo Padovan's patch series on
> drm/exynos conversion.
>
Dave, Gerd, being the authors/maintainers of this driver can you guys
take a look/test.
Ackes, review and testing will be greatly appreciated.

Thanks
Emil

[PATCH] gpu: drm: rcar-du: rcar_du_drv: don't open code of_device_get_match_data()

[Geert Uytterhoeven]

On Tue, Mar 1, 2016 at 5:37 PM, Wolfram Sang  wrote:
> From: Wolfram Sang 
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the above helper function
> to tighten the code and make it more readable.
>
> Signed-off-by: Wolfram Sang 

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v5 5/5] staging/android: add flags member to sync ioctl structs

[Emil Velikov]

On 1 March 2016 at 13:13, Gustavo Padovan  wrote:
> From: Gustavo Padovan 
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
> v2: check if flags are valid (zero, in this case)
>
> v3: return -EINVAL if flags are not zero'ed
>
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/staging/android/sync.c  | 8 
>  drivers/staging/android/uapi/sync.h | 6 ++
>  2 files changed, 14 insertions(+)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index 3604e453..3c265ed 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file 
> *sync_file,
> goto err_put_fd;
> }
>
> +   if (data.flags) {
> +   err = -EINVAL;
> +   goto err_put_fd;
> +   }
> +
> fence2 = sync_file_fdget(data.fd2);
> if (!fence2) {
> err = -ENOENT;
> @@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file 
> *sync_file,
> if (copy_from_user(, (void __user *)arg, sizeof(in)))
> return -EFAULT;
>
> +   if (in.flags)
> +   return -EINVAL;
> +
> info = kzalloc(sizeof(*info), GFP_KERNEL);
> if (!info)
> return -ENOMEM;
> diff --git a/drivers/staging/android/uapi/sync.h 
> b/drivers/staging/android/uapi/sync.h
> index a122bb5..11e2d28 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -19,11 +19,13 @@
>   * @fd2:   file descriptor of second fence
>   * @name:  name of new fence
>   * @fence: returns the fd of the new fence to userspace
> + * @flags: merge_data flags
>   */
>  struct sync_merge_data {
> __s32   fd2;
> charname[32];
> __s32   fence;
> +   __u32   flags;
The comment from last round still stands, struct size must be multiple
of 64bits. As is the struct will be broken whenever/if we decide to
extend it. See [1] for an alternative wording.

>  };
>
>  /**
> @@ -31,12 +33,14 @@ struct sync_merge_data {
>   * @obj_name:  name of parent sync_timeline
>   * @driver_name:   name of driver implementing the parent
>   * @status:status of the fence 0:active 1:signaled <0:error
> + * @flags: fence_info flags
>   * @timestamp_ns:  timestamp of status change in nanoseconds
>   */
>  struct sync_fence_info {
> charobj_name[32];
> chardriver_name[32];
> __s32   status;
> +   __u32   flags;
> __u64   timestamp_ns;
>  };
>
> @@ -44,6 +48,7 @@ struct sync_fence_info {
>   * struct sync_file_info - data returned from fence info ioctl
>   * @name:  name of fence
>   * @status:status of fence. 1: signaled 0:active <0:error
> + * @flags: sync_file_info flags
>   * @num_fences number of fences in the sync_file
>   * @sync_fence_info: pointer to array of structs sync_fence_info with all
>   *  fences in the sync_file
> @@ -51,6 +56,7 @@ struct sync_fence_info {
>  struct sync_file_info {
> charname[32];
> __s32   status;
> +   __u32   flags;
> __u32   num_fences;
>
> __u64   sync_fence_info;
Thanks for taking my suggestion and dropping len. Although I fear that
we introduced a hole which we should be explicitly padded [2].

In both cases the pad should be checked for 0 and -EINVAL should be
returned if that's not the case. This will allow us to potentially
reuse in the future.

Other than that I believe the series looks pretty much spot on.

Cheers,
Emil

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt#n37
[2] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt#n32

[PATCH] dma-buf/fence: fix fence_is_later v2

[Sumit Semwal]

Hi Daniel,
On 29-Feb-2016 9:18 pm, "Daniel Vetter"  wrote:
>
> On Tue, Feb 23, 2016 at 11:04:57AM +0900, Michel Dänzer wrote:
> > On 23.02.2016 04:32, Alex Deucher wrote:
> > > From: Christian König 
> > >
> > > A fence is never later than itself. This caused a bunch of overhead
for AMDGPU.
> > >
> > > v2: simplify check as suggested by Michel.
> > >
> > > Signed-off-by: Christian König 
> > > Reviewed-by: Michel Dänzer 
> > > Reviewed-by: Alex Deucher 
> > > Signed-off-by: Alex Deucher 
> > > ---
> > >  include/linux/fence.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/fence.h b/include/linux/fence.h
> > > index bb52201..5aa95eb 100644
> > > --- a/include/linux/fence.h
> > > +++ b/include/linux/fence.h
> > > @@ -292,7 +292,7 @@ static inline bool fence_is_later(struct fence
*f1, struct fence *f2)
> > > if (WARN_ON(f1->context != f2->context))
> > > return false;
> > >
> > > -   return f1->seqno - f2->seqno < INT_MAX;
> > > +   return (int)(f1->seqno - f2->seqno) > 0;
> > >  }
> > >
> > >  /**
> > >
> >
> > According to
> >
> >  scripts/get_maintainer.pl include/linux/fence.h
> >
> > this patch should be sent to:
> >
> > Sumit Semwal  (maintainer:DMA BUFFER SHARING
FRAMEWORK)
> > linux-media at vger.kernel.org (open list:DMA BUFFER SHARING FRAMEWORK)
> > dri-devel at lists.freedesktop.org (open list:DMA BUFFER SHARING FRAMEWORK)
> > linaro-mm-sig at lists.linaro.org (moderated list:DMA BUFFER SHARING
FRAMEWORK)
> > linux-kernel at vger.kernel.org (open list)
> >
> > I'd add at least Sumit and the linaro-mm-sig list.
>
> Plus Maarten Lankhorst please, and Gustavo Padovan maybe. Not sure Sumit
> is still all that active on dma-buf/fence maintainership ...
Am here very much, though I do apologize I haven't actively provided review
comments on the fence related series. I'll improve on that for sure!

Yes, it is still a good idea to add Maarten for fence stuff in the least.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160302/b909f7b7/attachment.html>

[PATCH] drm/exynos/dsi: use core helper to create DSI packet

[Andrzej Hajda]

On 03/01/2016 04:20 PM, Inki Dae wrote:
> Fixed trivial one related to following warning,
> drivers/gpu/drm/exynos/exynos_drm_dsi.c:1188:2: warning: format '%ld'
> expects argument of type 'long int', but argument 5 has type 'size_t'
> [-Wformat]

Thanks.

Regards
Andrzej

[GIT PULL] exynos-drm-next for 4.6

[Inki Dae]

Hi Dave,

   This pull request includes Exynos5420/5422 SoC support, fixups and cleanups.

   Summary:
   - Add Exynos5420 SoC support to FIMD driver.
 . This patch makes MIC(Mobile Image Compressor) IP to be bypassed in 
default
   in case of Exynos5420 and later. The Display pipe line configuraion for
   Exynos DRM driver will be considered through of graph concept later.
   - Add Exynos5422 SoC support to MIPI-DSI driver.
 . Exynos5422 SoC is similar to Exynos5433 SoC but software reset is 
different
   each other so this patch consideres the difference.
   - Get more precise clock divider value of FIMD controller.
 . This patch changes DIV_ROUND_CLOSEST macro to be used instead of 
DIV_ROUND_UP.
   - Refactor Exynos DRM device and driver registeration.
 . This patch makes Exynos DRM driver to be easy-to-read and at the same 
time,
   cleans it up by removing #ifdef ~ #endif things.
   - Configure DMA-mapping address space common to Exynos DRM devices in more 
generic
 without any hacks.
   - some fixups and cleanups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit efcebcf983abf70a15958b9fb5237b1c38060d95:

  Merge tag 'drm-intel-next-2016-02-14' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-03-01 13:06:44 
+1000)

are available in the git repository at:


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

for you to fetch changes up to 6c81e96d4bd10617b856ce3cb5fa09337871bfdf:

  drm/exynos/dsi: use core helper to create DSI packet (2016-03-02 00:21:37 
+0900)


Andrzej Hajda (11):
  drm/exynos/decon: fix disable clocks order
  drm/exynos/dsi: replace registry access macros with functions
  drm/exynos/dsi: constify read only structures
  drm/exynos/hdmi: remove unused variable
  drm/exynos/decon: make irq handler static
  drm/exynos: remove incorrect ccflags from Makefile
  drm/exynos: remove struct exynos_drm_panel_info
  drm/exynos/fimc: remove unused camera interface polarization code
  drm/exynos: remove platform data structures and include/drm/exynos_drm.h
  drm/exynos: use arch independent types in uapi header
  drm/exynos/dsi: use core helper to create DSI packet

Chanho Park (3):
  drm/exynos: support exynos5422 mipi-dsi
  drm/exynos: use DIV_ROUND_CLOSEST to find the closest div
  drm/exynos: add exynos5420 support for fimd

Joonyoung Shim (1):
  drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS

Marek Szyprowski (11):
  drm/exynos: ipp: fix incorrect format specifiers in debug messages
  drm/exynos: fix types for compilation on 64bit architectures
  drm/exynos: mic: use devm_clk interface
  drm/exynos: mic: convert to component framework
  drm/exynos: mic: make all functions static
  drm/exynos: dsi: restore support for drm bridge
  drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable
  drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable
  drm/exynos: fix incorrect cpu address for dma_mmap_attrs()
  drm/exynos: refactor driver and device registration code
  drm/exynos: use real device for DMA-mapping operations

 .../bindings/display/exynos/exynos_dsim.txt|1 +
 .../bindings/display/exynos/samsung-fimd.txt   |3 +-
 drivers/gpu/drm/exynos/Kconfig |2 +-
 drivers/gpu/drm/exynos/Makefile|1 -
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |   10 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |1 -
 drivers/gpu/drm/exynos/exynos_dp_core.c|7 +-
 drivers/gpu/drm/exynos/exynos_dp_core.h|4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  265 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   10 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  235 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   |   30 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   34 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c|   12 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c|   16 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_iommu.c  |   39 +--
 drivers/gpu/drm/exynos/exynos_drm_iommu.h  |4 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c|   32 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c|   72 +++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c|3 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |8 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |2 -
 include/drm/exynos_drm.h   |  101 
 include/uapi/drm/exynos_drm.h  |   26 +-
 26 

[PATCH] drm/exynos/dsi: use core helper to create DSI packet

[Inki Dae]

Fixed trivial one related to following warning,
drivers/gpu/drm/exynos/exynos_drm_dsi.c:1188:2: warning: format '%ld'
expects argument of type 'long int', but argument 5 has type 'size_t'
[-Wformat]

2016-02-17 22:33 GMT+09:00 Andrzej Hajda :
> Core provides generic helper to create DSI packet, use it instead of
> custom code.
>
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 69 
> +++--
>  1 file changed, 23 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 77e17ae..f17be93 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -10,6 +10,8 @@
>   * published by the Free Software Foundation.
>  */
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -222,12 +224,8 @@ struct exynos_dsi_transfer {
> struct list_head list;
> struct completion completed;
> int result;
> -   u8 data_id;
> -   u8 data[2];
> +   struct mipi_dsi_packet packet;
> u16 flags;
> -
> -   const u8 *tx_payload;
> -   u16 tx_len;
> u16 tx_done;
>
> u8 *rx_payload;
> @@ -322,6 +320,7 @@ enum reg_idx {
>  static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
> u32 val)
>  {
> +
> writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
>  }
>
> @@ -983,13 +982,14 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
> struct exynos_dsi_transfer *xfer)
>  {
> struct device *dev = dsi->dev;
> -   const u8 *payload = xfer->tx_payload + xfer->tx_done;
> -   u16 length = xfer->tx_len - xfer->tx_done;
> +   struct mipi_dsi_packet *pkt = >packet;
> +   const u8 *payload = pkt->payload + xfer->tx_done;
> +   u16 length = pkt->payload_length - xfer->tx_done;
> bool first = !xfer->tx_done;
> u32 reg;
>
> dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> -   xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, 
> xfer->rx_done);
> +   xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>
> if (length > DSI_TX_FIFO_SIZE)
> length = DSI_TX_FIFO_SIZE;
> @@ -998,8 +998,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>
> /* Send payload */
> while (length >= 4) {
> -   reg = (payload[3] << 24) | (payload[2] << 16)
> -   | (payload[1] << 8) | payload[0];
> +   reg = get_unaligned_le32(payload);
> exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
> payload += 4;
> length -= 4;
> @@ -1017,16 +1016,13 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
> reg |= payload[0];
> exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
> break;
> -   case 0:
> -   /* Do nothing */
> -   break;
> }
>
> /* Send packet header */
> if (!first)
> return;
>
> -   reg = (xfer->data[1] << 16) | (xfer->data[0] << 8) | xfer->data_id;
> +   reg = get_unaligned_le32(pkt->header);
> if (exynos_dsi_wait_for_hdr_fifo(dsi)) {
> dev_err(dev, "waiting for header FIFO timed out\n");
> return;
> @@ -1147,13 +1143,14 @@ again:
>
> spin_unlock_irqrestore(>transfer_lock, flags);
>
> -   if (xfer->tx_len && xfer->tx_done == xfer->tx_len)
> +   if (xfer->packet.payload_length &&
> +   xfer->tx_done == xfer->packet.payload_length)
> /* waiting for RX */
> return;
>
> exynos_dsi_send_to_fifo(dsi, xfer);
>
> -   if (xfer->tx_len || xfer->rx_len)
> +   if (xfer->packet.payload_length || xfer->rx_len)
> return;
>
> xfer->result = 0;
> @@ -1189,10 +1186,11 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
> spin_unlock_irqrestore(>transfer_lock, flags);
>
> dev_dbg(dsi->dev,
> -   "> xfer %p, tx_len %u, tx_done %u, rx_len %u, rx_done %u\n",
> -   xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, 
> xfer->rx_done);
> +   "> xfer %p, tx_len %lu, tx_done %u, rx_len %u, rx_done %u\n",
> +   xfer, xfer->packet.payload_length, xfer->tx_done, 
> xfer->rx_len,

%zu would be required for xfer->packet.payload_length which has size_t type.

Thanks,
Inki Dae