[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface

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

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

--- Comment #3 from Andy Furniss  ---
(In reply to Boyuan Zhang from comment #2)
> Hi Andy,
> 
> The corruption/out of order issue has been reproduced locally. Root cause
> and fix can be found at
> https://lists.freedesktop.org/archives/mesa-dev/2016-October/132268.html
> 
> Please give a try.
> 
> Regards,
> Boyuan

Thanks, that does fix the out of order and corruption.

As you explained in the thread above, dual instance bitrate control is a
separate issue, but this patch does change behavior a bit.

cbr is unaffected by patch and could be seen as OK (unless I find a better test
to break it). md5sums may vary but the bitrate/file size is only different by a
tiny amount and visually things seem OK.

vbr is different, before patch it may be OK, but there was a chance of some
files being less that half size/rate than they should.

With the patch it seems that they are all now less than half rate. So at least
it's consistent (md5sums do still vary).

Will test more tomorrow as it's late here.

-- 
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/20161017/7838cd7f/attachment.html>

[PATCH] drm: rcar-du: Add R8A7796 device support

[Laurent Pinchart]

Document the R8A7796-specific DT bindings and support them in the
driver. The HDMI output is currently not supported.

Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/display/renesas,du.txt |  4 +++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 25 ++
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index 0d30e42e40be..abc986202fa2 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -9,6 +9,7 @@ Required Properties:
 - "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
 - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
+- "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU

   - reg: A list of base address and length of each memory resource, one for
 each entry in the reg-names property.
@@ -25,7 +26,7 @@ Required Properties:
   - clock-names: Name of the clocks. This property is model-dependent.
 - R8A7779 uses a single functional clock. The clock doesn't need to be
   named.
-- R8A779[01345] use one functional clock per channel and one clock per LVDS
+- R8A779[013456] use one functional clock per channel and one clock per 
LVDS
   encoder (if available). The functional clocks must be named "du.x" with
   "x" being the channel numerical index. The LVDS clocks must be named
   "lvds.x" with "x" being the LVDS encoder numerical index.
@@ -50,6 +51,7 @@ corresponding to each DU output.
  R8A7793 (M2-N)DPADLVDS 0  -   -
  R8A7794 (E2)  DPAD 0  DPAD 1  -   -
  R8A7795 (H3)  DPADHDMI 0  HDMI 1  LVDS
+ R8A7796 (M3-W)DPADHDMILVDS-


 Example: R8A7790 (R-Car H2) DU
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 73c971e39b1c..1a29e0b8b551 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -157,6 +157,30 @@ static const struct rcar_du_device_info 
rcar_du_r8a7795_info = {
.num_lvds = 1,
 };

+static const struct rcar_du_device_info rcar_du_r8a7796_info = {
+   .gen = 3,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
+   .num_crtcs = 3,
+   .routes = {
+   /* R8A7796 has one RGB output, one LVDS output and one
+* (currently unsupported) HDMI output.
+*/
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(2),
+   .encoder_type = DRM_MODE_ENCODER_NONE,
+   .port = 0,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .encoder_type = DRM_MODE_ENCODER_LVDS,
+   .port = 2,
+   },
+   },
+   .num_lvds = 1,
+};
+
 static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7779", .data = &rcar_du_r8a7779_info },
{ .compatible = "renesas,du-r8a7790", .data = &rcar_du_r8a7790_info },
@@ -164,6 +188,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7793", .data = &rcar_du_r8a7791_info },
{ .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info },
{ .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info },
+   { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info },
{ }
 };

-- 
Regards,

Laurent Pinchart

[Bug 96449] Dying Light reports OpenGL version 3.0 with mesa-git

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

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

--- Comment #14 from Adam Bolte  ---
Thanks for your thoughts. Much appreciated.

-- 
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/20161017/78ab04f0/attachment.html>

[Bug 96449] Dying Light reports OpenGL version 3.0 with mesa-git

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

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

--- Comment #13 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Adam Bolte from comment #11)
> Overrides do not work, so am I to understand that Dying Light will never be
> supported by Mesa due to the OpenGL feature set it uses? Or can this bug be
> reopened (or perhaps a new bug)?

In my opinion (which might differ from the opinion of a number of Mesa
developers), the case isn't that Dying Light will never be supported.
Currently, Mesa developers are investing their time into "OpenGL core profile"
features and performance (and into Vulkan support). After they are done with
this work, which will happen in year 2018 or later, the topic of supporting
compatibility profiles in Mesa can be brought up again.

(This isn't a place for discussing Mesa's future, so this is my last comment on
this topic here.)

-- 
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/20161017/0e531b27/attachment.html>

[Bug 178221] New: radeon performance drop from 4.8 to 4.9-rc1 in Shadow of Mordor

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

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

Bug ID: 178221
   Summary: radeon performance drop from 4.8 to 4.9-rc1 in Shadow
of Mordor
   Product: Drivers
   Version: 2.5
Kernel Version: 4.9-RC1
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: christiannissen at gmx.de
Regression: No

Created attachment 241881
  --> https://bugzilla.kernel.org/attachment.cgi?id=241881&action=edit
glxinfo output

Hello,

I have a Radeon HD7950 and use Kubuntu 16.04 with Kernel 4.8 and padoka ppa
(for mesa) to play Shadow of Mordor. I just tried out the 4.9-rc1 and noticed a
significant performance drop in the built in benchmark.

Kernel; Resolution; Details Setting; Min FPS; Avg FPS; Max FPS
4.8; FullHD; Very High; 21,37; 37,29; 64,47
4.8; FullHD; Lowest; 27,42; 48,70; 86,77
4.8; 384x216; Very High; 20,30; 39,66; 73,23
4.8; 384x216; Lowest; 27,14; 50,30; 87,34
4.9; FullHD; Very High; 15,15; 29,59; 59,51
4.9; FullHD; Lowest; 26,00; 39,20; 67,31
4.9; 384x216; Very High; 14,94; 30,33; 58,00
4.9; 384x216; Lowest; 22,07; 37,98; 70,93

4.8.1 seems fine as well, but I only tested FullHD / Very High getting the same
results as with 4.8.

All runs used:
- mesa (1:12.1~git161016172400.c61eb3c~y~padoka0)
- libdrm (2.4.71+git1610081859.a44c9c3~x~padoka0)


I build the 4.9-rc1 kernel as described on
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild 

If it helps I could try to bisect the kernel but that might take a few days
(maybe even a week or two) depending on how much free time I have.

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

[Bug 96449] Dying Light reports OpenGL version 3.0 with mesa-git

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

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

--- Comment #12 from Adam Bolte  ---
To be more accurate, I should instead write "confirming this game does not
work, which is presumably due to a lack of compatibility profile support".

-- 
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/20161017/96632d2b/attachment.html>

[Bug 96449] Dying Light reports OpenGL version 3.0 with mesa-git

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

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

--- Comment #11 from Adam Bolte  ---
Confirming this game does not work without compatibility profiles. Can we get a
link to the discussion on why compatibility profiles will not be supported?

Overrides do not work, so am I to understand that Dying Light will never be
supported by Mesa due to the OpenGL feature set it uses? Or can this bug be
reopened (or perhaps a new bug)?

-- 
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/20161017/e6a8065e/attachment.html>

[PATCH 00/28] Reenable maybe-uninitialized warnings

[Christoph Hellwig]

On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote:
> This is a set of patches that I hope to get into v4.9 in some form
> in order to turn on the -Wmaybe-uninitialized warnings again.

Hi Arnd,

I jsut complained to Geert that I was introducing way to many
bugs or pointless warnings for some compilers lately, but gcc didn't
warn me about them.  From a little research the lack of
-Wmaybe-uninitialized seems to be the reason for it, so I'm all
for re-enabling it.

[Bug 92806] 1 second freezes during new effects UT4

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

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

--- Comment #15 from Marek Olšák  ---
If you have OpenGL 4.3 (LLVM 3.9 needed), UE4 should no longer compile shaders
on demand or not do that so often.

-- 
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/20161017/dfb33df5/attachment-0001.html>

[Bug 96381] Texture artifacts with immutable texture storage and mipmaps

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

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

Marek Olšák  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #3 from Marek Olšák  ---
This seems to fixed. The output here looks the same on Tonga, Bonaire, and
llvmpipe.

-- 
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/20161017/c69cf52b/attachment.html>

[PATCH v6] drm: Helper for lspcon in drm_dp_dual_mode

[Shashank Sharma]

Readme: {
This patch-series got approved in drm-intel mailing list already.
Sending this one patch to dri-devel too, as this patch touches the
drm layer dp_dual_mode_helper implementation. Plese provide an ack
so that we can merge this in intel-gfx tree.
The full patch series and review history at:
https://patchwork.freedesktop.org/patch/115769/
}

This patch adds lspcon support in dp_dual_mode helper.
lspcon is essentially a dp->hdmi dongle with dual personality.

LS mode: It works as a passive dongle, by level shifting DP++
signals to HDMI signals, in LS mode.
PCON mode: It works as a protocol converter active dongle
in pcon mode, by converting DP++ outputs to HDMI 2.0 outputs.

This patch adds support for lspcon detection and mode set
switch operations, as a dp dual mode dongle.

v2: Addressed review comments from Ville
- add adaptor id for lspcon devices (0x08), use it to identify lspcon
- change function names
  old: drm_lspcon_get_current_mode/drm_lspcon_change_mode
  new: drm_lspcon_get_mode/drm_lspcon_set_mode
- change drm_lspcon_get_mode type to int, to match
  drm_dp_dual_mode_get_tmds_output
- change 'err' to 'ret' to match the rest of the functions
- remove pointless typecasting during call to dual_mode_read
- fix the but while setting value of data, while writing lspcon mode
- fix indentation
- change mdelay(10) -> msleep(10)
- return ETIMEDOUT instead of EFAULT, when lspcon mode change times out
- Add an empty line to separate std regs macros and lspcon regs macros
  Indent bit definition

v3: Addressed review comments from Rodrigo
- change macro name from DP_DUAL_MODE_TYPE_LSPCON to
  DP_DUAL_MODE_TYPE_HAS_DPCD for better readability
- change macro name from DP_DUAL_MODE_LSPCON_MODE_PCON to
  DP_DUAL_MODE_LSPCON_MODE_PCON for better readability
- add comment for MCA specific offsets like 0x40 and 0x41
- remove DP_DUAL_MODE_REV_TYPE2 check while checking lspcon adapter id

v4: Addressed review comments from Ville
- Fixed indentation at few places
- s/current_mode/mode
- s/reqd_mode/mode
- remove unnecessary void* cast
- remove drm_edid.h from includes
- Add a comment for _HAS_DPCD
- Fix enum description, for lspcon_mode.

v5: Rebase
v6: Rebase

Signed-off-by: Shashank Sharma 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 ++
 include/drm/drm_dp_dual_mode_helper.h |  26 
 2 files changed, 129 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a7b2a75..a7aeb1e 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -148,6 +148,14 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
  DP_DUAL_MODE_REV_TYPE2);
 }

+bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
+   const uint8_t adaptor_id)
+{
+   return is_hdmi_adaptor(hdmi_id) &&
+   (adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
+DP_DUAL_MODE_TYPE_HAS_DPCD));
+}
+
 /**
  * drm_dp_dual_mode_detect - Identify the DP dual mode adaptor
  * @adapter: I2C adapter for the DDC bus
@@ -203,6 +211,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
&adaptor_id, sizeof(adaptor_id));
if (ret == 0) {
+   if (is_lspcon_adaptor(hdmi_id, adaptor_id))
+   return DRM_DP_DUAL_MODE_LSPCON;
if (is_type2_adaptor(adaptor_id)) {
if (is_hdmi_adaptor(hdmi_id))
return DRM_DP_DUAL_MODE_TYPE2_HDMI;
@@ -364,3 +374,96 @@ const char *drm_dp_get_dual_mode_type_name(enum 
drm_dp_dual_mode_type type)
}
 }
 EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
+
+/**
+ * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
+ * by reading offset (0x80, 0x41)
+ * @i2c_adapter: I2C-over-aux adapter
+ * @current_mode: out vaiable, current lspcon mode of operation
+ *
+ * Returns:
+ * 0 on success, sets the current_mode value to appropriate mode
+ * -error on failure
+ */
+int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+   enum drm_lspcon_mode *mode)
+{
+   u8 data;
+   int ret = 0;
+
+   if (!mode) {
+   DRM_ERROR("NULL input\n");
+   return -EINVAL;
+   }
+
+   /* Read Status: i2c over aux */
+   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
+   &data, sizeof(data));
+   if (ret < 0) {
+   DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+   return -EFAULT;
+   }
+
+   if (data & DP_DUAL_MODE_LSPCON_MODE_PCON)
+   *mode = DRM_LSPCON_MODE_PCON;
+   else
+   *mode = DRM_LSPCON_MODE_LS;
+   return 0;
+}
+EXPORT_SYMBOL(

[Bug 95551] Firewatch: Missing elements in menu

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

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

--- Comment #4 from Marek Olšák  ---
Does it still occur with current Mesa git?

-- 
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/20161017/0fb8602a/attachment.html>

[Bug 95317] "the timeless" demo in wine: Red dot rendered that shouldn't be there

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

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

Marek Olšák  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #3 from Marek Olšák  ---
The trace doesn't work with the given overrides. It prints a lot of GL errors
if Mesa is built with --enable-debug, meaning there are failing GL calls. I
have to assume the trace simply doesn't work because Mesa doesn't support GL
4.3 Compatibility.

(the overrides aren't supposed to give you the Compatibility profile; instead,
they trick Mesa into thinking it's Compatibility, which sometimes works and
sometimes doesn't)

-- 
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/20161017/a327363c/attachment.html>

[PATCH] dma-buf/fence-array: fix deadlock in fence-array

[Chris Wilson]

On Mon, Oct 17, 2016 at 02:59:52PM -0400, Rob Clark wrote:
> On Mon, Oct 17, 2016 at 2:52 PM, Gustavo Padovan  
> wrote:
> > 2016-10-17 Rob Clark :
> >
> >> Currently with fence-array, we have a potential deadlock situation.  If we
> >> fence_add_callback() on an array-fence, the array-fence's lock is acquired
> >> first, and in it's ->enable_signaling() callback, it will install cb's on
> >> it's array-member fences, so the array-member's lock is acquired second.
> >>
> >> But in the signal path, the array-member's lock is acquired first, and the
> >> array-fence's lock acquired second.
> >>
> >> To solve that, always enabling signaling up-front (in the fence_array
> >> constructor) without the fence_array's lock held.
> >
> > Do we always want to enable signaling for arrays? One of the things we
> > removed from the Sync Framework was the need to enable signalling at
> > creation time.
> >
> > Just merging fencing doesn't mean you want signaling, that is supposed
> > to happen only when poll() is called on the sync file.
> 
> It was something Maarten suggested, as an alternative to introducing a
> wq into the mix or worse hacks..
> https://lists.freedesktop.org/archives/dri-devel/2016-October/120868.html
> 
> I think I agree with him that it is an optimization that is unlikely
> to be useful in the case of fence-arrays.  If you need to wait on
> multiple fences from different timelines, you probably aren't doing
> that in hw.

For 2 i915 fences, I definitely do not want signaling enabled at
creation time.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 8:30 PM, Ville Syrjälä wrote:
> On Mon, Oct 17, 2016 at 08:21:21PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 10/17/2016 7:36 PM, Ville Syrjälä wrote:
>>> On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:
 Regards

 Shashank


 On 10/17/2016 6:01 PM, Ville Syrjälä wrote:
> On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
>> Current DRM layer functions don't parse aspect ratio information
>> while converting a user mode->kernel mode or vice versa. This
>> causes modeset to pick mode with wrong aspect ratio, eventually
>> causing failures in HDMI compliance test cases, due to wrong VIC.
>>
>> This patch adds aspect ratio information in DRM's mode conversion
>> and mode comparision functions, to make sure kernel picks mode
>> with right aspect ratio (as per the VIC).
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Lin, Jia 
>> Signed-off-by: Akashdeep Sharma 
>> Reviewed-by: Jim Bride 
>> Reviewed-by: Jose Abreu 
>> Cc: Daniel Vetter 
>> Cc: Emil Velikov 
>>
>> V2: Addressed review comments from Sean:
>> - Fix spellings/typo
>> - No need to handle aspect ratio none
>> - Add a break, for default case too
>> V3: Rebase
>> V4: Added r-b from Jose
>> ---
>> drivers/gpu/drm/drm_modes.c | 31 +++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index 53f07ac..fde927a 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
>> drm_display_mode *mode1,
>>  mode1->vsync_end == mode2->vsync_end &&
>>  mode1->vtotal == mode2->vtotal &&
>>  mode1->vscan == mode2->vscan &&
>> +mode1->picture_aspect_ratio == mode2->picture_aspect_ratio 
>> &&
>>  (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>>   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>>  return true;
>> @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
>> drm_mode_modeinfo *out,
>>  out->vrefresh = in->vrefresh;
>>  out->flags = in->flags;
>>  out->type = in->type;
>> +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>> +
>> +switch (in->picture_aspect_ratio) {
>> +case HDMI_PICTURE_ASPECT_4_3:
>> +out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
>> +break;
>> +case HDMI_PICTURE_ASPECT_16_9:
>> +out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
>> +break;
>> +case HDMI_PICTURE_ASPECT_RESERVED:
>> +default:
>> +out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
>> +break;
>> +}
>> +
>>  strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>>  out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>> }
>> @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct 
>> drm_display_mode *out,
>>  strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>>  out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>> 
>> +/* Clearing picture aspect ratio bits from out flags */
>> +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>> +
>> +switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
>> +case DRM_MODE_FLAG_PIC_AR_4_3:
>> +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
>> +break;
>> +case DRM_MODE_FLAG_PIC_AR_16_9:
>> +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
>> +break;
>> +default:
>> +out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>> +break;
>> +}
> Hmm. So now we have the mode aspect ratio infromation duplicated
> in two different places. Not sure that won't lead to some confusion.
 In drm layer, this is the only place. Actually till now, DRM layer dint
 have the support for aspect ratio at all. This was causing
 HDMI compliance tests like 7-27 fail, which expect a particular unique
 VIC in AVI infoframe on modeset.

 I have given some details about this in cover-letter.
> Although we do want the user to be able to override via the property I
> suppose, so we'd have to change that (+ the inforframe code) to
> look at the mode flags instead if we would eliminate
> 'picture_aspect_ratio'.
 I had a small discussion on this with Daniel, and we discussed that it
 doesnt make sense to override just the aspect ratio if the monitor
 doesn't even support that aspect

[Bug 92428] Sword Coast Legends causing GPU lockup. radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000afd1 last fence id 0x000000000000b194 on ring 3)

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

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

--- Comment #11 from Marek Olšák  ---
Does it still happen with current Mesa git? If so, can you try to run it with
this environment variable?

R600_DEBUG=switch_on_eop

-- 
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/20161017/6a57270a/attachment.html>

[Bug 84156] Half of lighting gets broken in older apps

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

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

Marek Olšák  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marek Olšák  ---
This works fine on Tonga and Bonaire here.

-- 
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/20161017/ecf908b1/attachment.html>

[Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 7:36 PM, Ville Syrjälä wrote:
> On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 10/17/2016 6:01 PM, Ville Syrjälä wrote:
>>> On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
 Current DRM layer functions don't parse aspect ratio information
 while converting a user mode->kernel mode or vice versa. This
 causes modeset to pick mode with wrong aspect ratio, eventually
 causing failures in HDMI compliance test cases, due to wrong VIC.

 This patch adds aspect ratio information in DRM's mode conversion
 and mode comparision functions, to make sure kernel picks mode
 with right aspect ratio (as per the VIC).

 Signed-off-by: Shashank Sharma 
 Signed-off-by: Lin, Jia 
 Signed-off-by: Akashdeep Sharma 
 Reviewed-by: Jim Bride 
 Reviewed-by: Jose Abreu 
 Cc: Daniel Vetter 
 Cc: Emil Velikov 

 V2: Addressed review comments from Sean:
 - Fix spellings/typo
 - No need to handle aspect ratio none
 - Add a break, for default case too
 V3: Rebase
 V4: Added r-b from Jose
 ---
drivers/gpu/drm/drm_modes.c | 31 +++
1 file changed, 31 insertions(+)

 diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
 index 53f07ac..fde927a 100644
 --- a/drivers/gpu/drm/drm_modes.c
 +++ b/drivers/gpu/drm/drm_modes.c
 @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
 drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
 +  mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
 @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
 drm_mode_modeinfo *out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
 +  out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
 +
 +  switch (in->picture_aspect_ratio) {
 +  case HDMI_PICTURE_ASPECT_4_3:
 +  out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
 +  break;
 +  case HDMI_PICTURE_ASPECT_16_9:
 +  out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
 +  break;
 +  case HDMI_PICTURE_ASPECT_RESERVED:
 +  default:
 +  out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
 +  break;
 +  }
 +
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
}
 @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
 *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;

 +  /* Clearing picture aspect ratio bits from out flags */
 +  out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
 +
 +  switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
 +  case DRM_MODE_FLAG_PIC_AR_4_3:
 +  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
 +  break;
 +  case DRM_MODE_FLAG_PIC_AR_16_9:
 +  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
 +  break;
 +  default:
 +  out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 +  break;
 +  }
>>> Hmm. So now we have the mode aspect ratio infromation duplicated
>>> in two different places. Not sure that won't lead to some confusion.
>> In drm layer, this is the only place. Actually till now, DRM layer dint
>> have the support for aspect ratio at all. This was causing
>> HDMI compliance tests like 7-27 fail, which expect a particular unique
>> VIC in AVI infoframe on modeset.
>>
>> I have given some details about this in cover-letter.
>>> Although we do want the user to be able to override via the property I
>>> suppose, so we'd have to change that (+ the inforframe code) to
>>> look at the mode flags instead if we would eliminate
>>> 'picture_aspect_ratio'.
>> I had a small discussion on this with Daniel, and we discussed that it
>> doesnt make sense to override just the aspect ratio if the monitor
>> doesn't even support that aspect ratio.
>> And currently the was how this property is implemented is, we just
>> override the aspect ratio without any validity check.
>>
>> Now as we have all the supported aspect ratio added properly in the mode
>> info itself, we need not to have this property at all, So Daniel
>> suggested me to remove that property too.
>>> And that brings me to the other point. At least i915 will simply
>>> override the mode's aspect ration with the property. So this looks like
>>> a big no-op for now on i915.
>>

[Bug 98005] VCE dual instance encoding inconsistent since st/va: enable dual instances encode by sync surface

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

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

Boyuan Zhang  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Boyuan Zhang  ---
Hi Andy,

The corruption/out of order issue has been reproduced locally. Root cause and
fix can be found at
https://lists.freedesktop.org/archives/mesa-dev/2016-October/132268.html

Please give a try.

Regards,
Boyuan

-- 
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/20161017/2baaa04a/attachment-0001.html>

[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

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

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

--- Comment #7 from Johannes Hirte  ---
(In reply to Alex Deucher from comment #6)
> You can also unbind the console before unloading the module.
> 
> sudo bash -c "echo 0 > /sys/class/vtconsole/vtcon1/bind"

First time this resulted in a black screen with a panic, next time the system
hung, but reboot via SysReq Keys worked. Always happened on the unbind.

-- 
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/20161017/b0942862/attachment.html>

[Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 6:01 PM, Ville Syrjälä wrote:
> On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
>> Current DRM layer functions don't parse aspect ratio information
>> while converting a user mode->kernel mode or vice versa. This
>> causes modeset to pick mode with wrong aspect ratio, eventually
>> causing failures in HDMI compliance test cases, due to wrong VIC.
>>
>> This patch adds aspect ratio information in DRM's mode conversion
>> and mode comparision functions, to make sure kernel picks mode
>> with right aspect ratio (as per the VIC).
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Lin, Jia 
>> Signed-off-by: Akashdeep Sharma 
>> Reviewed-by: Jim Bride 
>> Reviewed-by: Jose Abreu 
>> Cc: Daniel Vetter 
>> Cc: Emil Velikov 
>>
>> V2: Addressed review comments from Sean:
>> - Fix spellings/typo
>> - No need to handle aspect ratio none
>> - Add a break, for default case too
>> V3: Rebase
>> V4: Added r-b from Jose
>> ---
>>   drivers/gpu/drm/drm_modes.c | 31 +++
>>   1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index 53f07ac..fde927a 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
>> drm_display_mode *mode1,
>>  mode1->vsync_end == mode2->vsync_end &&
>>  mode1->vtotal == mode2->vtotal &&
>>  mode1->vscan == mode2->vscan &&
>> +mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
>>  (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>>   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>>  return true;
>> @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
>> drm_mode_modeinfo *out,
>>  out->vrefresh = in->vrefresh;
>>  out->flags = in->flags;
>>  out->type = in->type;
>> +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>> +
>> +switch (in->picture_aspect_ratio) {
>> +case HDMI_PICTURE_ASPECT_4_3:
>> +out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
>> +break;
>> +case HDMI_PICTURE_ASPECT_16_9:
>> +out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
>> +break;
>> +case HDMI_PICTURE_ASPECT_RESERVED:
>> +default:
>> +out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
>> +break;
>> +}
>> +
>>  strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>>  out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>>   }
>> @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
>> *out,
>>  strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>>  out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>>   
>> +/* Clearing picture aspect ratio bits from out flags */
>> +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>> +
>> +switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
>> +case DRM_MODE_FLAG_PIC_AR_4_3:
>> +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
>> +break;
>> +case DRM_MODE_FLAG_PIC_AR_16_9:
>> +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
>> +break;
>> +default:
>> +out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>> +break;
>> +}
> Hmm. So now we have the mode aspect ratio infromation duplicated
> in two different places. Not sure that won't lead to some confusion.
In drm layer, this is the only place. Actually till now, DRM layer dint 
have the support for aspect ratio at all. This was causing
HDMI compliance tests like 7-27 fail, which expect a particular unique 
VIC in AVI infoframe on modeset.

I have given some details about this in cover-letter.
> Although we do want the user to be able to override via the property I
> suppose, so we'd have to change that (+ the inforframe code) to
> look at the mode flags instead if we would eliminate
> 'picture_aspect_ratio'.
I had a small discussion on this with Daniel, and we discussed that it 
doesnt make sense to override just the aspect ratio if the monitor 
doesn't even support that aspect ratio.
And currently the was how this property is implemented is, we just 
override the aspect ratio without any validity check.

Now as we have all the supported aspect ratio added properly in the mode 
info itself, we need not to have this property at all, So Daniel 
suggested me to remove that property too.
>
> And that brings me to the other point. At least i915 will simply
> override the mode's aspect ration with the property. So this looks like
> a big no-op for now on i915.
Yes, This is a bug in I915. When I published the first version of this 
series, I had one patch, which was overriding the value only when the 
property is set.
This should be the right case. And then Daniel suggested to remove the 
property all together (and it makes sense as we have proper aspect 
ratios in mode information
itself) So I kept that patch separate, to be merged separately.
>   It

[Bug 98298] System freezes 380X

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

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

Bug ID: 98298
   Summary: System freezes 380X
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: kuehner.moritz at gmail.com

Created attachment 127368
  --> https://bugs.freedesktop.org/attachment.cgi?id=127368&action=edit
dmesg output

I'm having random system freezes with my Amd R9 380X. The freezes happen under
3d load maybe once a hour.

This happens on both Arch (linux 4.7) and Ubuntu 16.04 (4.4 with backports).

The freeze itself produces no output (nether kernel nor any other log) but I
just found that after 2 min the kernel will produce a hung task info. (See
attachment)

The freeze affects all graphical output: No mouse movement or switching to
virtual terminal. The rest of the system still works.


Please let me know of any debugging steps I can try.

-- 
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/20161017/242b4c2f/attachment.html>

[PATCH v4 0/4] Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 5:55 PM, Daniel Vetter wrote:
> On Mon, Oct 17, 2016 at 05:34:36PM +0530, Shashank Sharma wrote:
>> This patch series adds 4 patches.
>> - The first two patches add aspect ratio support in DRM layes
>> - Next two patches add new aspect ratios defined in CEA-861-F
>>supported for HDMI 2.0 4k modes.
>>
>> Adding aspect ratio support in DRM layer:
>> - The CEA videmodes contain aspect ratio information, which we
>>parse when we read the modes from EDID. But while transforming
>>user_mode to kernel_mode or viceversa, DRM layer lose this
>>information.
>> - HDMI compliance testing for CEA modes, expects the AVI info frames
>>to contain exact VIC no for the 'video mode under test'. Now CEA
>>modes have different VIC for same modes but different aspect ratio
>>for example:
>>  VIC 2 = 720x480 at 60 4:3
>>  VIC 3 = 720x480 at 60 16:9
>>In this way, lack of aspect ratio information, can cause wrong VIC
>>no in AVI IF, causing HDMI complaince test to fail.
>> - This patch set adds code, which embeds the aspect ratio information
>>also in DRM video mode flags, and uses it while comparing two modes.
>>
>> Adding new aspect ratios for HDMI 2.0
>> - CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
>>modes.
>>  - 64:27
>>  - 256:135
>> Last two patches in the series, adds code to handle these new
>> aspect ratios.
>>
>> V2: Fixed review comments from Sean, Emil, Daniel
>> V3: Fixed review comments from Jim Bride, got r-b for all patches
>> V4: Added r-b from Jose for the series, and ack-by from Tomi on patch 3
>>
>> Shashank Sharma (4):
>>drm: add picture aspect ratio flags
>>drm: Add aspect ratio parsing in DRM layer
>>video: Add new aspect ratios for HDMI 2.0
>>drm: Add and handle new aspect ratios in DRM layer
> Applied to drm-misc, thanks. I guess you'll follow up with i915 patches to
> remove the picture aspect ratio for overrides eventually?
>
> Thanks, Daniel
Thanks Daniel, and yes, its in my to-do list to remove the pic aspect 
ratio property, to override, as suggested by you in our last communication.
I was waiting for this series to be merged, so that I can give reference 
of this.

Will add you for the review of the patch,

Regards
Shashank
>>   drivers/gpu/drm/drm_modes.c | 43 
>> +++
>>   drivers/video/hdmi.c|  4 
>>   include/linux/hdmi.h|  2 ++
>>   include/uapi/drm/drm_mode.h | 24 +++-
>>   4 files changed, 68 insertions(+), 5 deletions(-)
>>
>> -- 
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/bridge: Add ITE IT6251 bridge driver

[Marek Vasut]

Add driver for the ITE IT6251 LVDS-to-eDP bridge.

Signed-off-by: Marek Vasut 
Cc: Daniel Vetter 
Cc: Sean Cross 
---
 drivers/gpu/drm/bridge/Kconfig  |   9 +
 drivers/gpu/drm/bridge/Makefile |   1 +
 drivers/gpu/drm/bridge/ite-it6251.c | 606 
 3 files changed, 616 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6251.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 10e12e7..e9c96b9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -39,6 +39,15 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.

+config DRM_ITE_IT6251
+   tristate "ITE IT6251 LVDS/eDP bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   select REGMAP_I2C
+   ---help---
+ ITE IT6251 LVDS-eDP bridge chip driver.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cdf3a3c..736dba7 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_ITE_IT6251) += ite-it6251.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/bridge/ite-it6251.c 
b/drivers/gpu/drm/bridge/ite-it6251.c
new file mode 100644
index 000..a19bb4d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6251.c
@@ -0,0 +1,606 @@
+/*
+ * Copyright (C) 2014 Sean Cross 
+ *
+ * Rework for mainline: Marek Vasut 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drmP.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+#include "drm_atomic_helper.h"
+
+struct it6251_bridge {
+   struct i2c_client   *client;
+   struct i2c_client   *lvds_client;
+   struct regmap   *regmap;
+   struct regmap   *lvds_regmap;
+   struct regulator*regulator;
+
+   struct drm_connectorconnector;
+   struct drm_bridge   bridge;
+   struct drm_panel*panel;
+};
+
+/* Register definitions */
+#define IT6251_VENDOR_ID_LOW   0x00
+#define IT6251_VENDOR_ID_HIGH  0x01
+#define IT6251_DEVICE_ID_LOW   0x02
+#define IT6251_DEVICE_ID_HIGH  0x03
+#define IT6251_SYSTEM_STATUS   0x0d
+#define IT6251_SYSTEM_STATUS_RINTSTATUSBIT(0)
+#define IT6251_SYSTEM_STATUS_RHPDSTATUSBIT(1)
+#define IT6251_SYSTEM_STATUS_RVIDEOSTABLE  BIT(2)
+#define IT6251_SYSTEM_STATUS_RPLL_IOLOCK   BIT(3)
+#define IT6251_SYSTEM_STATUS_RPLL_XPLOCK   BIT(4)
+#define IT6251_SYSTEM_STATUS_RPLL_SPLOCK   BIT(5)
+#define IT6251_SYSTEM_STATUS_RAUXFREQ_LOCK BIT(6)
+#define IT6251_REF_STATE   0x0e
+#define IT6251_REF_STATE_MAIN_LINK_DISABLEDBIT(0)
+#define IT6251_REF_STATE_AUX_CHANNEL_READ  BIT(1)
+#define IT6251_REF_STATE_CR_PATTERNBIT(2)
+#define IT6251_REF_STATE_EQ_PATTERNBIT(3)
+#define IT6251_REF_STATE_NORMAL_OPERATION  BIT(4)
+#define IT6251_REF_STATE_MUTED BIT(5)
+#define IT6251_RPCLK_CNT_LOW   0x13
+#define IT6251_RPCLK_CNT_HIGH  0x14
+#define IT6251_RPC_REQ 0x2b
+#define IT6251_RPC_REQ_RPC_FIFOFULLBIT(6)
+#define IT6251_RPC_REQ_RPC_FIFOEMPTY   BIT(7)
+#define IT6251_PCLK_CNT_LOW0x57
+#define IT6251_PCLK_CNT_HIGH   0x58
+#define IT6251_DPHDEW_LOW  0xa5
+#define IT6251_DPHDEW_HIGH 0xa6
+#define IT6251_DPVDEW_LOW  0xaf
+#define IT6251_DPVDEW_HIGH 0xb0
+#define IT6251_LVDS_PORT_ADDR  0xfd
+#define IT6251_LVDS_PORT_CTRL  0xfe
+#define IT6251_LVDS_PORT_CTRL_EN   BIT(0)
+
+/*
+ * Register programming sequences.
+ * NOTE: There is a lot of registers here which are completely undocumented
+ *   and/or their meaning is not clear from the little documentation

[PATCH 2/3] dt-bindings: it6251: add bindings for IT6251 LVDS-to-eDP bridge

[Marek Vasut]

Add DT bindings for ITE IT6251 LVDS-to-eDP bridge.

Signed-off-by: Marek Vasut 
Cc: devicetree at vger.kernel.org
Cc: Daniel Vetter 
Cc: Rob Herring 
Cc: Sean Cross 
---
 .../bindings/display/bridge/ite,it6251.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ite,it6251.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6251.txt 
b/Documentation/devicetree/bindings/display/bridge/ite,it6251.txt
new file mode 100644
index 000..c5db82c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6251.txt
@@ -0,0 +1,35 @@
+ITE IT6251 LVDS-to-eDP bridge bindings
+
+Required properties:
+- compatible:  Should be "ite,it6251"
+- reg: i2c address of the bridge, i2c address of the LVDS part
+- reg-names:   Should be "bridge", "lvds"
+- power-supply:Regulator to provide the supply voltage
+- video interfaces:Device node can contain video interface port nodes
+   for panel according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   it6251 at 5c {
+   compatible = "ite,it6251";
+   reg = <0x5c>, <0x5e>;
+   reg-names = "bridge", "lvds";
+   power-supply = <®_display>;
+
+   ports {
+   port at 0 {
+   bridge_out_edp0: endpoint {
+   remote-endpoint = <&panel_in_edp0>;
+   };
+   };
+
+   port at 1 {
+   bridge_in_lvds0: endpoint {
+   remote-endpoint = <&lvds0_out>;
+   };
+   };
+   };
+   };
+
-- 
2.9.3

[PATCH 1/3] dt-bindings: Add ITE Tech prefix

[Marek Vasut]

Add vendor prefix for ITE Tech Inc, http://www.ite.com.tw/

Signed-off-by: Marek Vasut 
Cc: devicetree at vger.kernel.org
Cc: Daniel Vetter 
Cc: Rob Herring 
Cc: Sean Cross 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 536663c..3282dbe 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -144,6 +144,7 @@ iom Iomega Corporation
 isee   ISEE 2007 S.L.
 isil   Intersil
 issi   Integrated Silicon Solutions Inc.
+iteITE Tech, Inc.
 jdiJapan Display Inc.
 jedec  JEDEC Solid State Technology Association
 karo   Ka-Ro electronics GmbH
-- 
2.9.3

[PATCH 3/3] ARM: dts: da850: add the syscfg and ddrctl nodes

[Bartosz Golaszewski]

Add the nodes for the System Configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6440002..6d56ef2 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -407,6 +407,16 @@
interrupts = <52>;
status = "disabled";
};
+
+   ddrctl: da850-ddrctl {
+   compatible = "ti,da850-ddrctl";
+   status = "disabled";
+   };
+
+   syscfg: da850-syscfg {
+   compatible = "ti,da850-syscfg";
+   status = "disabled";
+   };
};
aemif: aemif at 6800 {
compatible = "ti,da850-aemif";
-- 
2.9.3

[PATCH 2/3] ARM: bus: da8xx-syscfg: new driver

[Bartosz Golaszewski]

Create the driver for the da8xx System Configuration and implement
support for writing to the three Master Priority registers.

Signed-off-by: Bartosz Golaszewski 
---
 .../devicetree/bindings/bus/ti,da850-syscfg.txt|  63 +++
 drivers/bus/Kconfig|   8 +
 drivers/bus/Makefile   |   2 +
 drivers/bus/da8xx-syscfg.c | 206 +
 4 files changed, 279 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt
 create mode 100644 drivers/bus/da8xx-syscfg.c

diff --git a/Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt 
b/Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt
new file mode 100644
index 000..07e5c38
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt
@@ -0,0 +1,63 @@
+* Device tree bindings for Texas Instruments da8xx system configuration driver
+
+The system configuration (SYSCFG) module is a system-level module containing
+status and top level control logic required by the device. The system
+configuration module consists of a set of memory-mapped status and control
+registers, accessible by the CPU, supporting all of the following system
+features, and miscellaneous functions and operations.
+
+Documentation:
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
+
+Required properties:
+
+- compatible:  "ti,da850-syscfg"
+
+Optional properties:
+
+The below properties are used to specify the priority of master peripherals.
+They must be between 0-7 where 0 is the highest priority and 7 is the lowest.
+
+- ti,pri-arm-i:ARM_I port priority.
+
+- ti,pri-arm-d:ARM_D port priority.
+
+- ti,pri-upp:  uPP port priority.
+
+- ti,pri-sata: SATA port priority.
+
+- ti,pri-pru0: PRU0 port priority.
+
+- ti,pri-pru1: PRU1 port priority.
+
+- ti,pri-edma30tc0:EDMA3_0_TC0 port priority.
+
+- ti,pri-edma30tc1:EDMA3_0_TC1 port priority.
+
+- ti,pri-edma31tc0:EDMA3_1_TC0 port priority.
+
+- ti,pri-vpif-dma-0:   VPIF DMA0 port priority.
+
+- ti,pri-vpif-dma-1:   VPIF DMA1 port priority.
+
+- ti,pri-emac: EMAC port priority.
+
+- ti,pri-usb0cfg:  USB0 CFG port priority.
+
+- ti,pri-usb0cdma: USB0 CDMA port priority.
+
+- ti,pri-uhpi: HPI port priority.
+
+- ti,pri-usb1: USB1 port priority.
+
+- ti,pri-lcdc: LCDC port priority.
+
+If any of the above properties is absent, the default value will be used as
+defined in the documentation.
+
+Example for da850-lcdk is shown below.
+
+mstpri {
+   compatible = "ti,da850-mstpri";
+   ti,pri-lcdc = 0;
+};
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 5a2d47c..6276132 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -165,4 +165,12 @@ config VEXPRESS_CONFIG
help
  Platform configuration infrastructure for the ARM Ltd.
  Versatile Express.
+
+config DA8XX_SYSCFG
+   bool "TI da8xx system configuration driver"
+   depends on ARCH_DAVINCI_DA8XX
+   help
+ Driver for Texas Instruments da8xx system configuration. Allows to
+ adjust various SoC configuration options.
+
 endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index c6cfa6b..3cba66a 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -21,3 +21,5 @@ obj-$(CONFIG_SIMPLE_PM_BUS)   += simple-pm-bus.o
 obj-$(CONFIG_TEGRA_ACONNECT)   += tegra-aconnect.o
 obj-$(CONFIG_UNIPHIER_SYSTEM_BUS)  += uniphier-system-bus.o
 obj-$(CONFIG_VEXPRESS_CONFIG)  += vexpress-config.o
+
+obj-$(CONFIG_DA8XX_SYSCFG) += da8xx-syscfg.o
diff --git a/drivers/bus/da8xx-syscfg.c b/drivers/bus/da8xx-syscfg.c
new file mode 100644
index 000..8a2cb4f
--- /dev/null
+++ b/drivers/bus/da8xx-syscfg.c
@@ -0,0 +1,206 @@
+/*
+ * TI da8xx System Configuration driver
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ *   Bartosz Golaszewski 
+ *
+ * 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 
+
+#define DA8XX_IO_PHYS  0x01c0ul
+#define DA8XX_SYSCFG0_BASE (DA8XX_IO_PHYS + 0x14000)
+
+#define DA8XX_MSTPRI0_REG  0x110
+#define DA8XX_MSTPRI1_REG  0x114
+#define DA8XX_MSTPRI2_REG  0x118
+
+#define DA8XX_MSTPRI_MAX   7
+
+struct da8xx_mstpri_descr {
+   const char *property;
+   int reg;
+   int shift;
+   int mask;
+};
+
+static const struct da8xx_mstpri_descr priorities[] = {
+   {
+   .property = "ti,pri-arm-i",
+   .reg = DA8XX_MSTPRI0_REG,
+   .shift = 0,
+   .mask = 0xfff0,
+   },
+   {
+   .property = "ti,pri-arm-d",
+   .reg = DA8XX_MSTPRI0_REG,
+  

[PATCH 1/3] ARM: memory: da8xx-ddrctl: new driver

[Bartosz Golaszewski]

Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.

Signed-off-by: Bartosz Golaszewski 
---
 .../memory-controllers/ti-da8xx-ddrctl.txt | 25 +++
 drivers/memory/Kconfig |  8 +++
 drivers/memory/Makefile|  1 +
 drivers/memory/da8xx-ddrctl.c  | 77 ++
 4 files changed, 111 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
 create mode 100644 drivers/memory/da8xx-ddrctl.c

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt 
b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
new file mode 100644
index 000..e340404
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
@@ -0,0 +1,25 @@
+* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
+
+The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs memory
+maps a set of registers which allow to tweak the controller's behavior.
+
+Documentation:
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
+
+Required properties:
+
+- compatible:  "ti,da850-ddrctl"
+
+Optional properties:
+
+- ti,pr-old-count: Priority raise old counter. Specifies the number of
+   memory transfers after which the DDR2/mDDR memory
+   controller will elevate the priority of the oldest
+   command in the command FIFO. Must be between 0-255.
+
+Example for da850 shown below.
+
+ddrctl {
+   compatible = "ti,da850-ddrctl";
+   ti,pr-old-count = <0x20>;
+};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 4b4c0c3..ec80e35 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -134,6 +134,14 @@ config MTK_SMI
  mainly help enable/disable iommu and control the power domain and
  clocks for each local arbiter.

+config DA8XX_DDRCTL
+   bool "Texas Instruments da8xx DDR2/mDDR driver"
+   depends on ARCH_DAVINCI_DA8XX
+   help
+ This driver is for the DDR2/mDDR Memory Controller present on
+ Texas Instruments da8xx SoCs. It's used to tweak various memory
+ controller configuration options.
+
 source "drivers/memory/samsung/Kconfig"
 source "drivers/memory/tegra/Kconfig"

diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index b20ae38..e88097fb 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MVEBU_DEVBUS)+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 obj-$(CONFIG_JZ4780_NEMC)  += jz4780-nemc.o
 obj-$(CONFIG_MTK_SMI)  += mtk-smi.o
+obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o

 obj-$(CONFIG_SAMSUNG_MC)   += samsung/
 obj-$(CONFIG_TEGRA_MC) += tegra/
diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
new file mode 100644
index 000..dcd0a61
--- /dev/null
+++ b/drivers/memory/da8xx-ddrctl.c
@@ -0,0 +1,77 @@
+/*
+ * TI da8xx DDR2/mDDR controller driver
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ *   Bartosz Golaszewski 
+ *
+ * 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 
+
+#define DA8XX_DDR_CTL_BASE 0xB000
+#define DA8XX_PBBPR_OFFSET 0x0020
+#define DA8XX_PBBPR_REG(p) ((p) + DA8XX_PBBPR_OFFSET)
+
+#define DA8XX_PBBPR_MAX0xff
+
+static void da8xx_ddrctl_set_pbbpr(void __iomem *ddrctl, struct device *dev)
+{
+   struct device_node *node = dev->of_node;
+   u32 pr_old_count;
+   int ret;
+
+   ret = of_property_read_u32(node, "ti,pr-old-count", &pr_old_count);
+   if (ret)
+   return;
+
+   if (pr_old_count > DA8XX_PBBPR_MAX) {
+   dev_warn(dev, "priority raise old counter value too high\n");
+   return;
+   }
+
+   __raw_writel(pr_old_count, DA8XX_PBBPR_REG(ddrctl));
+}
+
+static int da8xx_ddrctl_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   void __iomem *ddrctl;
+
+   ddrctl = ioremap(DA8XX_DDR_CTL_BASE, SZ_256);
+   if (!ddrctl) {
+   dev_err(dev, "unable to map memory controller registers\n");
+   return -EIO;
+   }
+
+   da8xx_ddrctl_set_pbbpr(ddrctl, dev);
+
+   iounmap(ddrctl);
+
+   return 0;
+}
+
+static const struct of_device_id da8xx_ddrctl_of_match[] = {
+   { .compatible = "ti,da850-ddrctl", },
+   { },
+};
+
+static struct platform_driver da8xx_ddrctl_driver = {
+   .probe = da8xx_ddrctl_probe,
+   .driver = {
+   .name = "da8xx-ddrctl",
+   .of_match_table =

[PATCH 0/3] ARM: da850: new drivers for better LCDC support

[Bartosz Golaszewski]

This series adds two new drivers in order to better support the LCDC
rev1 present on the da850 boards.

The first patch adds a new memory driver which allows to write to the
DDR2/mDDR memory controller present on the da8xx SoCs.

The second patch adds a new bus driver which allows to interact with
the SYSCFG module of da8xx SoCs.

Both drivers are incomplete - they currently only implement the
functionalities required to correctly support the LCDC on da850
boards. The first driver only allows to specify the value of the PBBP
register, while the second allows to modify all master peripheral
priorities, but doesn't know about other syscfg registers yet.

Potential extensions of these drivers should be straightforward in the
future.

The last patch adds disabled nodes for the above drivers to da850.dtsi.

Tested on a da850-lcdk with a display connected over VGA.

Bartosz Golaszewski (3):
  ARM: memory: da8xx-ddrctl: new driver
  ARM: bus: da8xx-syscfg: new driver
  ARM: dts: da850: add the syscfg and ddrctl nodes

 .../devicetree/bindings/bus/ti,da850-syscfg.txt|  63 +++
 .../memory-controllers/ti-da8xx-ddrctl.txt |  25 +++
 arch/arm/boot/dts/da850.dtsi   |  10 +
 drivers/bus/Kconfig|   8 +
 drivers/bus/Makefile   |   2 +
 drivers/bus/da8xx-syscfg.c | 206 +
 drivers/memory/Kconfig |   8 +
 drivers/memory/Makefile|   1 +
 drivers/memory/da8xx-ddrctl.c  |  77 
 9 files changed, 400 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
 create mode 100644 drivers/bus/da8xx-syscfg.c
 create mode 100644 drivers/memory/da8xx-ddrctl.c

-- 
2.9.3

[PATCH -next] gpu: ipu-v3: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

[Philipp Zabel]

Am Mittwoch, den 21.09.2016, 15:12 + schrieb Wei Yongjun:
> From: Wei Yongjun 
> 
> Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).
> 
> Generated by: scripts/coccinelle/api/err_cast.cocci
> 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/ipu-v3/ipu-image-convert.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c 
> b/drivers/gpu/ipu-v3/ipu-image-convert.c
> index 2ba7d43..805b6fa 100644
> --- a/drivers/gpu/ipu-v3/ipu-image-convert.c
> +++ b/drivers/gpu/ipu-v3/ipu-image-convert.c
> @@ -1617,7 +1617,7 @@ ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task 
> ic_task,
>   ctx = ipu_image_convert_prepare(ipu, ic_task, in, out, rot_mode,
>   complete, complete_context);
>   if (IS_ERR(ctx))
> - return ERR_PTR(PTR_ERR(ctx));
> + return ERR_CAST(ctx);
>  
>   run = kzalloc(sizeof(*run), GFP_KERNEL);
>   if (!run) {

Applied, thanks.

regards
Philipp

[patch] drm/imx: drm_dev_alloc() returns error pointers

[Philipp Zabel]

Am Donnerstag, den 13.10.2016, 11:53 +0300 schrieb Dan Carpenter:
> We are checking for NULL here, when we should be checking for error
> pointers.
> 
> Fixes: 54db5decce17 ("drm/imx: drop deprecated load/unload drm_driver ops")
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 98df09c..3acc976 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -357,8 +357,8 @@ static int imx_drm_bind(struct device *dev)
>   int ret;
>  
>   drm = drm_dev_alloc(&imx_drm_driver, dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>  
>   imxdrm = devm_kzalloc(dev, sizeof(*imxdrm), GFP_KERNEL);
>   if (!imxdrm) {

Applied, thanks.

regards
Philipp

[PATCH 3/3] drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12

[Philipp Zabel]

Hi Liu,

Am Montag, den 10.10.2016, 14:50 +0800 schrieb Liu Ying:
> Before accessing the u/v offset(aka, u/vbo for IPUv3) of the old plane state's
> relevant fb, we should make sure the fb is in YU12 or YV12 pixel format(which
> are the two YUV pixel formats we support only), otherwise, we are likely to
> trigger BUG_ON() in drm_plane_state_to_u/vbo() since the fb's pixel format is
> probably not YU12 or YV12.
> 
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98150
> Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
> Cc: stable at vger.kernel.org # 4.8
> Signed-off-by: Liu Ying 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index e33110e..a691892 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -359,7 +359,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
>   if ((ubo > 0xf8) || (vbo > 0xf8))
>   return -EINVAL;
>  
> - if (old_fb) {
> + if (old_fb && old_fb->pixel_format == fb->pixel_format) {
>   old_ubo = drm_plane_state_to_ubo(old_state);
>   old_vbo = drm_plane_state_to_vbo(old_state);
>   if (ubo != old_ubo || vbo != old_vbo)

thank you for the patches. I have applied patches 1 and 2, but with this
change UBO/VBO changes are ignored when switching from YU12 to YV12.

Shouldn't we rather set crtc_state->mode_changed = true if either
(fb->pixel_format != old_fb->pixel_format) for any pixel format or
(ubo != old_ubo || vbo != old_vbo) for YUV formats, instead of returning
-EINVAL?

regards
Philipp

[Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 08:21:21PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 10/17/2016 7:36 PM, Ville Syrjälä wrote:
> > On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 10/17/2016 6:01 PM, Ville Syrjälä wrote:
> >>> On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
>  Current DRM layer functions don't parse aspect ratio information
>  while converting a user mode->kernel mode or vice versa. This
>  causes modeset to pick mode with wrong aspect ratio, eventually
>  causing failures in HDMI compliance test cases, due to wrong VIC.
> 
>  This patch adds aspect ratio information in DRM's mode conversion
>  and mode comparision functions, to make sure kernel picks mode
>  with right aspect ratio (as per the VIC).
> 
>  Signed-off-by: Shashank Sharma 
>  Signed-off-by: Lin, Jia 
>  Signed-off-by: Akashdeep Sharma 
>  Reviewed-by: Jim Bride 
>  Reviewed-by: Jose Abreu 
>  Cc: Daniel Vetter 
>  Cc: Emil Velikov 
> 
>  V2: Addressed review comments from Sean:
>  - Fix spellings/typo
>  - No need to handle aspect ratio none
>  - Add a break, for default case too
>  V3: Rebase
>  V4: Added r-b from Jose
>  ---
> drivers/gpu/drm/drm_modes.c | 31 +++
> 1 file changed, 31 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>  index 53f07ac..fde927a 100644
>  --- a/drivers/gpu/drm/drm_modes.c
>  +++ b/drivers/gpu/drm/drm_modes.c
>  @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
>  drm_display_mode *mode1,
>   mode1->vsync_end == mode2->vsync_end &&
>   mode1->vtotal == mode2->vtotal &&
>   mode1->vscan == mode2->vscan &&
>  +mode1->picture_aspect_ratio == mode2->picture_aspect_ratio 
>  &&
>   (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>    (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>   return true;
>  @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
>  drm_mode_modeinfo *out,
>   out->vrefresh = in->vrefresh;
>   out->flags = in->flags;
>   out->type = in->type;
>  +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>  +
>  +switch (in->picture_aspect_ratio) {
>  +case HDMI_PICTURE_ASPECT_4_3:
>  +out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
>  +break;
>  +case HDMI_PICTURE_ASPECT_16_9:
>  +out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
>  +break;
>  +case HDMI_PICTURE_ASPECT_RESERVED:
>  +default:
>  +out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
>  +break;
>  +}
>  +
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> }
>  @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct 
>  drm_display_mode *out,
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> 
>  +/* Clearing picture aspect ratio bits from out flags */
>  +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>  +
>  +switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
>  +case DRM_MODE_FLAG_PIC_AR_4_3:
>  +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
>  +break;
>  +case DRM_MODE_FLAG_PIC_AR_16_9:
>  +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
>  +break;
>  +default:
>  +out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  +break;
>  +}
> >>> Hmm. So now we have the mode aspect ratio infromation duplicated
> >>> in two different places. Not sure that won't lead to some confusion.
> >> In drm layer, this is the only place. Actually till now, DRM layer dint
> >> have the support for aspect ratio at all. This was causing
> >> HDMI compliance tests like 7-27 fail, which expect a particular unique
> >> VIC in AVI infoframe on modeset.
> >>
> >> I have given some details about this in cover-letter.
> >>> Although we do want the user to be able to override via the property I
> >>> suppose, so we'd have to change that (+ the inforframe code) to
> >>> look at the mode flags instead if we would eliminate
> >>> 'picture_aspect_ratio'.
> >> I had a small discussion on this with Daniel, and we discussed that it
> >> doesnt make sense to override just the aspect ratio if the monitor
> >> doesn't even support that aspect ratio.
> >> And currently the was how this property is implemented is, we 

[PATCH] dma-buf/fence-array: fix deadlock in fence-array

[Gustavo Padovan]

2016-10-17 Chris Wilson :

> On Mon, Oct 17, 2016 at 02:59:52PM -0400, Rob Clark wrote:
> > On Mon, Oct 17, 2016 at 2:52 PM, Gustavo Padovan  
> > wrote:
> > > 2016-10-17 Rob Clark :
> > >
> > >> Currently with fence-array, we have a potential deadlock situation.  If 
> > >> we
> > >> fence_add_callback() on an array-fence, the array-fence's lock is 
> > >> acquired
> > >> first, and in it's ->enable_signaling() callback, it will install cb's on
> > >> it's array-member fences, so the array-member's lock is acquired second.
> > >>
> > >> But in the signal path, the array-member's lock is acquired first, and 
> > >> the
> > >> array-fence's lock acquired second.
> > >>
> > >> To solve that, always enabling signaling up-front (in the fence_array
> > >> constructor) without the fence_array's lock held.
> > >
> > > Do we always want to enable signaling for arrays? One of the things we
> > > removed from the Sync Framework was the need to enable signalling at
> > > creation time.
> > >
> > > Just merging fencing doesn't mean you want signaling, that is supposed
> > > to happen only when poll() is called on the sync file.
> > 
> > It was something Maarten suggested, as an alternative to introducing a
> > wq into the mix or worse hacks..
> > https://lists.freedesktop.org/archives/dri-devel/2016-October/120868.html
> > 
> > I think I agree with him that it is an optimization that is unlikely
> > to be useful in the case of fence-arrays.  If you need to wait on
> > multiple fences from different timelines, you probably aren't doing
> > that in hw.
> 
> For 2 i915 fences, I definitely do not want signaling enabled at
> creation time.

Should we add arg flags for fence_array_create()? We already have
signal_on_any flag there. We can convert that arg to a bitfield.

Gustavo

[PATCH] drm/msm/mdp5: expose "alpha" property

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 04:34:27PM +0200, Daniel Vetter wrote:
> On Mon, Oct 17, 2016 at 10:08:28AM -0400, Rob Clark wrote:
> > On Mon, Oct 17, 2016 at 2:24 AM, Daniel Vetter  wrote:
> > > On Fri, Oct 14, 2016 at 07:50:13PM -0400, Rob Clark wrote:
> > >> We had this wired up already internally but initially did not expose the
> > >> property pending bikeshed about alpha and color management properties.
> > >> I noted that drm-hwc2 was looking for this property, and a couple other
> > >> drivers already support it in the same way.  So time to expose it!
> > >>
> > >> Signed-off-by: Rob Clark 
> > >
> > > Can we please have a bit of shared property setup in drm_blend.c and some
> > > documentation how it is supposed to be used? Adding props is nice, but
> > > greating an undocumented and ill-defined mess of them, not so much ;-)
> > >
> > > I'd prefer the full specced blending equation in the docs, including how
> > > this interacts with fb formats which already have their own alpha value.
> > 
> > 
> > It is used same way as rcar-du and atmel-hlcdc (and already is in
> > kms-properties.csv
> > 
> > couldn't really tell you the blend equation.. but I guess it is
> > "whatever android wants"
> 
> This is the kind of answer that uapi disasters are made of. Can you pls
> figure this one out? Worst case just make it to fit msm ;-)

Someone could also try to pick up the full blend equation property stuff.
By now I've forgotten how we ended with that one the last time around.

> 
> Also would be great to put the alpha value into drm_plane_state, like with
> the other standardized properties.
> 
> Imo we really should be doing this right, and just because we didn't do it
> right in the past isn't a good excuse.
> -Daniel
> 
> > 
> > BR,
> > -R
> > 
> > > Thanks, Daniel
> > >
> > >> ---
> > >>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +++
> > >>  1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> > >> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > >> index 432c098..b6f1fc66 100644
> > >> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > >> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > >> @@ -120,6 +120,7 @@ static void mdp5_plane_install_properties(struct 
> > >> drm_plane *plane,
> > >>   ARRAY_SIZE(name##_prop_enum_list))
> > >>
> > >>   INSTALL_RANGE_PROPERTY(zpos, ZPOS, 1, 255, 1);
> > >> + INSTALL_RANGE_PROPERTY(alpha, ALPHA, 0, 255, 255);
> > >>
> > >>   mdp5_plane_install_rotation_property(dev, plane);
> > >>
> > >> @@ -148,6 +149,7 @@ static int mdp5_plane_atomic_set_property(struct 
> > >> drm_plane *plane,
> > >>   } while (0)
> > >>
> > >>   SET_PROPERTY(zpos, ZPOS, uint8_t);
> > >> + SET_PROPERTY(alpha, ALPHA, uint8_t);
> > >>
> > >>   dev_err(dev->dev, "Invalid property\n");
> > >>   ret = -EINVAL;
> > >> @@ -176,6 +178,7 @@ static int mdp5_plane_atomic_get_property(struct 
> > >> drm_plane *plane,
> > >>   } while (0)
> > >>
> > >>   GET_PROPERTY(zpos, ZPOS, uint8_t);
> > >> + GET_PROPERTY(alpha, ALPHA, uint8_t);
> > >>
> > >>   dev_err(dev->dev, "Invalid property\n");
> > >>   ret = -EINVAL;
> > >> --
> > >> 2.7.4
> > >>
> > >> ___
> > >> dri-devel mailing list
> > >> dri-devel at lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> 
> -- 
> 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

-- 
Ville Syrjälä
Intel OTC

[PATCH v4 4/4] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Rebase
V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride)
V4: Added r-b from Jose.
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fde927a..173b7d3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1509,6 +1509,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1570,6 +1576,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5c142b1..084b50a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,6 +81,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354

 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -90,6 +92,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

[PATCH v4 3/4] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Reviewed-by: Jose Abreu 
Acked-by: Tomi Valkeinen 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: rebase
V3: rebase
V4: Added r-b from Jose, Ack by Tomi
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };

-- 
1.9.1

[PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too
V3: Rebase
V4: Added r-b from Jose
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;

+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

[PATCH v4 1/4] drm: add picture aspect ratio flags

[Shashank Sharma]

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

Signed-off-by: Shashank Sharma 
Reviewed-by: Jim Bride 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean
- Changed PAR-> PIC_AR
V3: Rebase
V3: Added r-b by Jose
---
 include/uapi/drm/drm_mode.h | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index df0e350..5c142b1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,19 @@ extern "C" {
 #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
 #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)

+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
+/* Aspect ratio flag bitmask (4 bits 22:19) */
+#define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
+#define  DRM_MODE_FLAG_PIC_AR_NONE \
+   (DRM_MODE_PICTURE_ASPECT_NONE<<19)
+#define  DRM_MODE_FLAG_PIC_AR_4_3 \
+   (DRM_MODE_PICTURE_ASPECT_4_3<<19)
+#define  DRM_MODE_FLAG_PIC_AR_16_9 \
+   (DRM_MODE_PICTURE_ASPECT_16_9<<19)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
@@ -92,11 +105,6 @@ extern "C" {
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */

-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE   0
-#define DRM_MODE_PICTURE_ASPECT_4_31
-#define DRM_MODE_PICTURE_ASPECT_16_9   2
-
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
1.9.1

[PATCH v4 0/4] Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480 at 60 4:3
VIC 3 = 720x480 at 60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches
V4: Added r-b from Jose for the series, and ack-by from Tomi on patch 3

Shashank Sharma (4):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h | 24 +++-
 4 files changed, 68 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH] dma-buf/fence-array: fix deadlock in fence-array

[Gustavo Padovan]

2016-10-17 Rob Clark :

> On Mon, Oct 17, 2016 at 2:52 PM, Gustavo Padovan  
> wrote:
> > 2016-10-17 Rob Clark :
> >
> >> Currently with fence-array, we have a potential deadlock situation.  If we
> >> fence_add_callback() on an array-fence, the array-fence's lock is acquired
> >> first, and in it's ->enable_signaling() callback, it will install cb's on
> >> it's array-member fences, so the array-member's lock is acquired second.
> >>
> >> But in the signal path, the array-member's lock is acquired first, and the
> >> array-fence's lock acquired second.
> >>
> >> To solve that, always enabling signaling up-front (in the fence_array
> >> constructor) without the fence_array's lock held.
> >
> > Do we always want to enable signaling for arrays? One of the things we
> > removed from the Sync Framework was the need to enable signalling at
> > creation time.
> >
> > Just merging fencing doesn't mean you want signaling, that is supposed
> > to happen only when poll() is called on the sync file.
> 
> It was something Maarten suggested, as an alternative to introducing a
> wq into the mix or worse hacks..
> https://lists.freedesktop.org/archives/dri-devel/2016-October/120868.html
> 
> I think I agree with him that it is an optimization that is unlikely
> to be useful in the case of fence-arrays.  If you need to wait on
> multiple fences from different timelines, you probably aren't doing
> that in hw.

Fair enough, that makes sense to me. 

If no one else has concerns with this, I'd add my r-b to it:

Reviewed-by: Gustavo Padovan 

Gustavo

Etnaviv driver does bind with 4.9-rc1

[Lucas Stach]

Am Montag, den 17.10.2016, 12:49 -0200 schrieb Fabio Estevam:
> Hi,
> 
> With kernel 4.8.2 the following messages are seen on a mx6q:
> 
> root at imx6qsabresd:~# dmesg | grep etnaviv
> [2.378176] etnaviv gpu-subsystem: bound 134000.gpu (ops gpu_ops)
> [2.384352] etnaviv gpu-subsystem: bound 13.gpu (ops gpu_ops)
> [2.390542] etnaviv gpu-subsystem: bound 2204000.gpu (ops gpu_ops)
> [2.396745] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> [2.448947] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108
> [2.51] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
> [2.506119] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
> 
> However, with 4.9-rc1 none of these log messages appear:
> 
> root at imx6qsabresd:~# dmesg | grep etnaviv
> root at imx6qsabresd:~#
> 
> For some reason etnaviv_gpu_bind() is never getting called.
> 
> I haven't debugged this yet. If anyone has some ideas, please let me know.

This is the same issue you already fixed yourself in patch "ARM: imx:
gpc: Initialize all power domains" ;)

If the GPC driver fails to probe you get no power domains and the
etnaviv GPU drivers won't even be probed without them.

Regards,
Lucas

[Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 10/17/2016 6:01 PM, Ville Syrjälä wrote:
> > On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
> >> Current DRM layer functions don't parse aspect ratio information
> >> while converting a user mode->kernel mode or vice versa. This
> >> causes modeset to pick mode with wrong aspect ratio, eventually
> >> causing failures in HDMI compliance test cases, due to wrong VIC.
> >>
> >> This patch adds aspect ratio information in DRM's mode conversion
> >> and mode comparision functions, to make sure kernel picks mode
> >> with right aspect ratio (as per the VIC).
> >>
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Lin, Jia 
> >> Signed-off-by: Akashdeep Sharma 
> >> Reviewed-by: Jim Bride 
> >> Reviewed-by: Jose Abreu 
> >> Cc: Daniel Vetter 
> >> Cc: Emil Velikov 
> >>
> >> V2: Addressed review comments from Sean:
> >> - Fix spellings/typo
> >> - No need to handle aspect ratio none
> >> - Add a break, for default case too
> >> V3: Rebase
> >> V4: Added r-b from Jose
> >> ---
> >>   drivers/gpu/drm/drm_modes.c | 31 +++
> >>   1 file changed, 31 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> >> index 53f07ac..fde927a 100644
> >> --- a/drivers/gpu/drm/drm_modes.c
> >> +++ b/drivers/gpu/drm/drm_modes.c
> >> @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
> >> drm_display_mode *mode1,
> >>mode1->vsync_end == mode2->vsync_end &&
> >>mode1->vtotal == mode2->vtotal &&
> >>mode1->vscan == mode2->vscan &&
> >> +  mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
> >>(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
> >> (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
> >>return true;
> >> @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
> >> drm_mode_modeinfo *out,
> >>out->vrefresh = in->vrefresh;
> >>out->flags = in->flags;
> >>out->type = in->type;
> >> +  out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> >> +
> >> +  switch (in->picture_aspect_ratio) {
> >> +  case HDMI_PICTURE_ASPECT_4_3:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> >> +  break;
> >> +  case HDMI_PICTURE_ASPECT_16_9:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> >> +  break;
> >> +  case HDMI_PICTURE_ASPECT_RESERVED:
> >> +  default:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> >> +  break;
> >> +  }
> >> +
> >>strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> >>out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >>   }
> >> @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
> >> *out,
> >>strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> >>out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >>   
> >> +  /* Clearing picture aspect ratio bits from out flags */
> >> +  out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> >> +
> >> +  switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> >> +  case DRM_MODE_FLAG_PIC_AR_4_3:
> >> +  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
> >> +  break;
> >> +  case DRM_MODE_FLAG_PIC_AR_16_9:
> >> +  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> >> +  break;
> >> +  default:
> >> +  out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> >> +  break;
> >> +  }
> > Hmm. So now we have the mode aspect ratio infromation duplicated
> > in two different places. Not sure that won't lead to some confusion.
> In drm layer, this is the only place. Actually till now, DRM layer dint 
> have the support for aspect ratio at all. This was causing
> HDMI compliance tests like 7-27 fail, which expect a particular unique 
> VIC in AVI infoframe on modeset.
> 
> I have given some details about this in cover-letter.
> > Although we do want the user to be able to override via the property I
> > suppose, so we'd have to change that (+ the inforframe code) to
> > look at the mode flags instead if we would eliminate
> > 'picture_aspect_ratio'.
> I had a small discussion on this with Daniel, and we discussed that it 
> doesnt make sense to override just the aspect ratio if the monitor 
> doesn't even support that aspect ratio.
> And currently the was how this property is implemented is, we just 
> override the aspect ratio without any validity check.
> 
> Now as we have all the supported aspect ratio added properly in the mode 
> info itself, we need not to have this property at all, So Daniel 
> suggested me to remove that property too.
> >
> > And that brings me to the other point. At least i915 will simply
> > override the mode's aspect ration with the property. So this looks like
> > a big no-op for now on i915.
> Yes, This is a bug in I915. When I published the first version of this 
> series, I had one patch, which was overriding the value only when the 
> property is set.
> This should be 

[PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Regards

Shashank

On 10/17/2016 5:01 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 17-10-2016 12:32, Shashank Sharma wrote:
>> This patch series adds 4 patches.
>> - The first two patches add aspect ratio support in DRM layes
>> - Next two patches add new aspect ratios defined in CEA-861-F
>>supported for HDMI 2.0 4k modes.
>>
>> Adding aspect ratio support in DRM layer:
>> - The CEA videmodes contain aspect ratio information, which we
>>parse when we read the modes from EDID. But while transforming
>>user_mode to kernel_mode or viceversa, DRM layer lose this
>>information.
>> - HDMI compliance testing for CEA modes, expects the AVI info frames
>>to contain exact VIC no for the 'video mode under test'. Now CEA
>>modes have different VIC for same modes but different aspect ratio
>>for example:
>>  VIC 2 = 720x480 at 60 4:3
>>  VIC 3 = 720x480 at 60 16:9
>>In this way, lack of aspect ratio information, can cause wrong VIC
>>no in AVI IF, causing HDMI complaince test to fail.
>> - This patch set adds code, which embeds the aspect ratio information
>>also in DRM video mode flags, and uses it while comparing two modes.
>>
>> Adding new aspect ratios for HDMI 2.0
>> - CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
>>modes.
>>  - 64:27
>>  - 256:135
>> Last two patches in the series, adds code to handle these new
>> aspect ratios.
>>
>> V2: Fixed review comments from Sean, Emil, Daniel
>> V3: Fixed review comments from Jim Bride, got r-b for all patches
>>
>> Shashank Sharma (4):
>>drm: add picture aspect ratio flags
>>drm: Add aspect ratio parsing in DRM layer
>>video: Add new aspect ratios for HDMI 2.0
>>drm: Add and handle new aspect ratios in DRM layer
> I am using the previous version of these patches, the
> functionality remains the same so you can add my reviewed-by for
> the whole series if you want.
Thanks Joes. I will add a V4 with your r-b.
> Are you still planning in sending
> the patches for the new VIC's introduced in CEA-861-F?
Yes, the very next step is the patch with new VICs.

Regards
Shashank
>>   drivers/gpu/drm/drm_modes.c | 43 
>> +++
>>   drivers/video/hdmi.c|  4 
>>   include/linux/hdmi.h|  2 ++
>>   include/uapi/drm/drm_mode.h | 24 +++-
>>   4 files changed, 68 insertions(+), 5 deletions(-)
>>
> Best regards,
> Jose Miguel Abreu

[PATCH v3 4/4] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Rebase
V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride)
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fde927a..173b7d3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1509,6 +1509,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1570,6 +1576,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5c142b1..084b50a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,6 +81,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354

 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -90,6 +92,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

[PATCH v3 3/4] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: rebase
V3: rebase
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };

-- 
1.9.1

[PATCH v3 2/4] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too

V3: Rebase
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;

+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

[PATCH v3 1/4] drm: add picture aspect ratio flags

[Shashank Sharma]

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

Signed-off-by: Shashank Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean
- Changed PAR-> PIC_AR
V3: Rebase
---
 include/uapi/drm/drm_mode.h | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index df0e350..5c142b1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,19 @@ extern "C" {
 #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
 #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)

+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
+/* Aspect ratio flag bitmask (4 bits 22:19) */
+#define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
+#define  DRM_MODE_FLAG_PIC_AR_NONE \
+   (DRM_MODE_PICTURE_ASPECT_NONE<<19)
+#define  DRM_MODE_FLAG_PIC_AR_4_3 \
+   (DRM_MODE_PICTURE_ASPECT_4_3<<19)
+#define  DRM_MODE_FLAG_PIC_AR_16_9 \
+   (DRM_MODE_PICTURE_ASPECT_16_9<<19)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
@@ -92,11 +105,6 @@ extern "C" {
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */

-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE   0
-#define DRM_MODE_PICTURE_ASPECT_4_31
-#define DRM_MODE_PICTURE_ASPECT_16_9   2
-
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
1.9.1

[PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480 at 60 4:3
VIC 3 = 720x480 at 60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h | 24 +++-
 4 files changed, 68 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH v2][resend v2] drm: bridge: add DesignWare HDMI I2S audio support

[Kuninori Morimoto]

From: Kuninori Morimoto 

Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.

Tested-by: Jose Abreu 
Signed-off-by: Kuninori Morimoto 
---
v1 -> v2

 - tidyup return value of snd_dw_hdmi_probe()

 drivers/gpu/drm/bridge/Kconfig |   8 ++
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/dw-hdmi-audio.h |   7 ++
 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c | 130 +
 drivers/gpu/drm/bridge/dw-hdmi.c   |  22 -
 drivers/gpu/drm/bridge/dw-hdmi.h   |  21 +
 6 files changed, 187 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8f7423f..8e2a22d 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -32,6 +32,14 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.

+config DRM_DW_HDMI_I2S_AUDIO
+   tristate "Synopsis Designware I2S Audio interface"
+   depends on DRM_DW_HDMI
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the I2S Audio interface which is part of the Synopsis
+ Designware HDMI block.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 96b13b3..1af92ad 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-audio.h 
b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
index 91f631b..fd1f745 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi-audio.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi-audio.h
@@ -11,4 +11,11 @@ struct dw_hdmi_audio_data {
u8 *eld;
 };

+struct dw_hdmi_i2s_audio_data {
+   struct dw_hdmi *hdmi;
+
+   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
+   u8 (*read)(struct dw_hdmi *hdmi, int offset);
+};
+
 #endif
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
new file mode 100644
index 000..7dd2091
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
@@ -0,0 +1,130 @@
+/*
+ * dw-hdmi-i2s-audio.c
+ *
+ * Copyright (c) 2016 Kuninori Morimoto 
+ *
+ * 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 "dw-hdmi.h"
+#include "dw-hdmi-audio.h"
+
+#define DRIVER_NAME "dw-hdmi-i2s-audio"
+
+static inline void hdmi_write(struct dw_hdmi_i2s_audio_data *audio,
+ u8 val, int offset)
+{
+   struct dw_hdmi *hdmi = audio->hdmi;
+
+   audio->write(hdmi, val, offset);
+}
+
+static inline u8 hdmi_read(struct dw_hdmi_i2s_audio_data *audio, int offset)
+{
+   struct dw_hdmi *hdmi = audio->hdmi;
+
+   return audio->read(hdmi, offset);
+}
+
+static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms)
+{
+   struct dw_hdmi_i2s_audio_data *audio = data;
+   struct dw_hdmi *hdmi = audio->hdmi;
+   u8 conf0 = 0;
+   u8 conf1 = 0;
+   u8 inputclkfs = 0;
+
+   /* it cares I2S only */
+   if ((fmt->fmt != HDMI_I2S) ||
+   (fmt->bit_clk_master | fmt->frame_clk_master)) {
+   dev_err(dev, "unsupported format/settings\n");
+   return -EINVAL;
+   }
+
+   inputclkfs  = HDMI_AUD_INPUTCLKFS_64FS;
+   conf0   = HDMI_AUD_CONF0_I2S_ALL_ENABLE;
+
+   switch (hparms->sample_width) {
+   case 16:
+   conf1 = HDMI_AUD_CONF1_WIDTH_16;
+   break;
+   case 24:
+   case 32:
+   conf1 = HDMI_AUD_CONF1_WIDTH_24;
+   break;
+   }
+
+   dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
+
+   hdmi_write(audio, inputclkfs, HDMI_AUD_INPUTCLKFS);
+   hdmi_write(audio, conf0, HDMI_AUD_CONF0);
+   hdmi_write(audio, conf1, HDMI_AUD_CONF1);
+
+   dw_hdmi_audio_enable(hdmi);
+
+   return 0;
+}
+
+static void dw_hdmi_i2s_audio_shutdown(struct device *dev, void *data)
+{
+   struct dw_hdmi_i2s_audio_data *audio = data;
+   struct dw_hdmi *hdmi =

[PATCH] dma-buf/fence-array: fix deadlock in fence-array

[Gustavo Padovan]

2016-10-17 Rob Clark :

> Currently with fence-array, we have a potential deadlock situation.  If we
> fence_add_callback() on an array-fence, the array-fence's lock is acquired
> first, and in it's ->enable_signaling() callback, it will install cb's on
> it's array-member fences, so the array-member's lock is acquired second.
> 
> But in the signal path, the array-member's lock is acquired first, and the
> array-fence's lock acquired second.
> 
> To solve that, always enabling signaling up-front (in the fence_array
> constructor) without the fence_array's lock held.

Do we always want to enable signaling for arrays? One of the things we
removed from the Sync Framework was the need to enable signalling at
creation time. 

Just merging fencing doesn't mean you want signaling, that is supposed
to happen only when poll() is called on the sync file.

Gustavo

[PATCH v3 4/4] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Rebase
V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride)
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fde927a..173b7d3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1509,6 +1509,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1570,6 +1576,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5c142b1..084b50a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,6 +81,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354

 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -90,6 +92,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

[PATCH v3 3/4] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: rebase
V3: rebase
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };

-- 
1.9.1

[PATCH v3 2/4] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too

V3: Rebase
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;

+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

[PATCH v3 1/4] drm/i915: Add lspcon resume function

[Shashank Sharma]

As per the software design, we are driving lspcon in
PCON mode. But while resuming from suspend, lspcon can go
in LS mode (which is its default operating mode on power on)

This patch adds a resume function for lspcon, which makes sure
its operating in PCON mode, post resume.

V2: Address review comments from Imre
- move lspcon_resume call to encoder->reset()
- use early returns

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ++-
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_lspcon.c | 8 
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc03f61..25f4060 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4755,11 +4755,16 @@ static void intel_edp_panel_vdd_sanitize(struct 
intel_dp *intel_dp)
 void intel_dp_encoder_reset(struct drm_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+   struct intel_lspcon *lspcon = &intel_dig_port->lspcon;
+   struct intel_dp *intel_dp = &intel_dig_port->dp;

if (!HAS_DDI(dev_priv))
intel_dp->DP = I915_READ(intel_dp->output_reg);

+   if (IS_GEN9(dev_priv) && lspcon->active)
+   lspcon_resume(lspcon);
+
if (to_intel_encoder(encoder)->type != INTEL_OUTPUT_EDP)
return;

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cde05ff..ea43512 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1856,4 +1856,5 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state);

 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
+void lspcon_resume(struct intel_lspcon *lspcon);
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 628ae6fb..d606f1a 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -89,6 +89,14 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
return true;
 }

+void lspcon_resume(struct intel_lspcon *lspcon)
+{
+   if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
+   DRM_ERROR("LSPCON resume failed\n");
+   else
+   DRM_DEBUG_KMS("LSPCON resume success\n");
+}
+
 bool lspcon_init(struct intel_digital_port *intel_dig_port)
 {
struct intel_dp *dp = &intel_dig_port->dp;
-- 
1.9.1

[PATCH v3 0/4] Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480 at 60 4:3
VIC 3 = 720x480 at 60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel

V3: Fixed review comment from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm/i915: Add lspcon resume function
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +
 drivers/gpu/drm/i915/intel_dp.c |  7 +-
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_lspcon.c |  8 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h |  6 ++
 7 files changed, 70 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH v11 2/4] drm: Add API for capturing frame CRCs

[Daniel Vetter]

On Thu, Oct 06, 2016 at 05:21:06PM +0200, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
> 
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
> 
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
> 
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
>   generation gets enabled for the first time.
> v3:
> - Use the control file just to select the source, and start and stop
>   capture when the data file is opened and closed, respectively.
> - Make variable the number of CRC values per entry, per source.
> - Allocate entries queue each time we start capturing as now there
>   isn't a fixed number of CRC values per entry.
> - Store the frame counter in the data file as a 8-digit hex number.
> - For sources that cannot provide useful frame numbers, place
>    in the frame field.
> 
> v4:
> - Build only if CONFIG_DEBUG_FS is enabled.
> - Use memdup_user_nul.
> - Consolidate calculation of the size of an entry in a helper.
> - Add 0x prefix to hex numbers in the data file.
> - Remove unnecessary snprintf and strlen usage in read callback.
> 
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
> 
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
> 
> v8:
> - Call debugfs_remove_recursive when we fail to create the minor
>   device
> 
> v9:
> - Register the debugfs directory for a crtc from
>   drm_crtc_register_all()
> 
> v10:
> - Don't let debugfs failures interrupt CRTC registration (Emil
>   Velikov)
> 
> v11:
> - Remove extra brace that broke compilation. Sorry!
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
>  Documentation/gpu/drm-uapi.rst|   6 +
>  drivers/gpu/drm/Makefile  |   3 +-
>  drivers/gpu/drm/drm_crtc.c|  34 +++-
>  drivers/gpu/drm/drm_debugfs.c |  34 +++-
>  drivers/gpu/drm/drm_debugfs_crc.c | 351 
> ++
>  drivers/gpu/drm/drm_internal.h|  16 ++
>  include/drm/drm_crtc.h|  41 +
>  include/drm/drm_debugfs_crc.h |  73 
>  8 files changed, 555 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
>  create mode 100644 include/drm/drm_debugfs_crc.h
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 1ba301cebe16..de3ac9f90f8f 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
> interfaces to
>  userspace are driver specific for efficiency and other reasons these
>  interfaces can be rather substantial. Hence every driver has its own
>  chapter.
> +
> +Testing and validation
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> +   :doc: CRC ABI

Just realized that you don't pull in the abi docs itself drom
drm_debugfs_crc.[hc]. Can you pls address that in a follow-up patch?

Merged this one here meanwhile to drm-misc. I couldn't apply the i915
patches to drm-misc, stuff is diverging too much :( I think it's better to
get the i915 patches in once I've done a backmerge from drm-misc to
drm-intel.

Thanks, Daniel

> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 25c720454017..74579d2e796e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -9,7 +9,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
>   drm_scatter.o drm_pci.o \
>   drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
>   drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
> - drm_info.o drm_debugfs.o drm_encoder_slave.o \
> + drm_info.o drm_encoder_slave.o \
>   drm_trace_points.o drm_global.o drm_prime.o \
>   drm_rect.o drm_vma_manager.o drm_flip_work.o \
>   drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> @@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
> +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>  
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 2d7bedf28647..60403bf7a4ff 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -40,7 +40,7 @@
>  #include 
>  #include 
>  #include 
> -#include 

[RFC] drm/fb-helper: reject any changes to the fbdev

[Daniel Vetter]

On Wed, Oct 12, 2016 at 12:37:07PM +0300, Tomi Valkeinen wrote:
> On 12/10/16 02:15, Stefan Agner wrote:
> > The current fbdev emulation does not allow to push back changes in
> > width, height or depth to KMS, hence reject any changes with an
> > error. This makes sure that fbdev ioctl's fail properly and user
> > space does not assume that changes succeeded.
> 
> The description is a bit confusing. Don't you mean that currently the
> fbdev emulation does allow changes, but doesn't actually push those
> changes to KMS? And this patch makes the driver reject those changes.
> 
> The change itself sounds good to me.
> 
> Reviewed-by: Tomi Valkeinen 

Applied to drm-misc, thanks.
-Daniel

> 
> > Signed-off-by: Stefan Agner 
> > ---
> > This rejects reconfiguration of framebuffer like
> > fbset -rgba 5,6,5 -depth 16 (when in 24 bit mode by default)
> > fbset -xres 123
> > 
> > I think all users of drm_fb_helper_check_var use also the generic
> > drm_fb_helper_set_par (or do otherwise not support changing size/
> > depth). Hence, afaict, the change should be the right thing to do
> > for all driver...
> > 
> >  drivers/gpu/drm/drm_fb_helper.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 03414bd..596c056 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1211,11 +1211,14 @@ int drm_fb_helper_check_var(struct 
> > fb_var_screeninfo *var,
> > if (var->pixclock != 0 || in_dbg_master())
> > return -EINVAL;
> >  
> > -   /* Need to resize the fb object !!! */
> > -   if (var->bits_per_pixel > fb->bits_per_pixel ||
> > -   var->xres > fb->width || var->yres > fb->height ||
> > -   var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> > -   DRM_DEBUG("fb userspace requested width/height/bpp is greater 
> > than current fb "
> > +   /*
> > +* Changes struct fb_var_screeninfo are currently not pushed back
> > +* to KMS, hence fail if different settings are requested.
> > +*/
> > +   if (var->bits_per_pixel != fb->bits_per_pixel ||
> > +   var->xres != fb->width || var->yres != fb->height ||
> > +   var->xres_virtual != fb->width || var->yres_virtual != fb->height) {
> > +   DRM_DEBUG("fb userspace requested width/height/bpp different 
> > than current fb "
> >   "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> >   var->xres, var->yres, var->bits_per_pixel,
> >   var->xres_virtual, var->yres_virtual,
> > 
> 




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


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] crygpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap

[Arvind Yadav]

Free memory mapping, if hdmi_probe is not successful.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..9b7857b 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
 err_hdmiphy:
if (hdata->hdmiphy_port)
put_device(&hdata->hdmiphy_port->dev);
+   if (hdata->regs_hdmiphy)
+   iounmap(hdata->regs_hdmiphy);
 err_ddc:
put_device(&hdata->ddc_adpt->dev);

-- 
1.7.9.5

kernel panic caused by raedon driver during reboot

[Michel Dänzer]

On 17/10/16 04:17 PM, Baoquan He wrote:
> In fact this could happen in radeon_pci_shutdown. I tried reboot and
> poweroff, kernel panic happened in both cases. Attachments are console
> log and kernel config of 4.9-rc1 on linus's tree.

This is fixed with these commits, which should land in Linus' tree soon:

https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9305ee6fe52035f63d70d023235b792ba22107f0


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

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/b3063fd9/attachment.sig>

[PATCH] drm/msm/mdp5: expose "alpha" property

[Daniel Vetter]

On Mon, Oct 17, 2016 at 10:08:28AM -0400, Rob Clark wrote:
> On Mon, Oct 17, 2016 at 2:24 AM, Daniel Vetter  wrote:
> > On Fri, Oct 14, 2016 at 07:50:13PM -0400, Rob Clark wrote:
> >> We had this wired up already internally but initially did not expose the
> >> property pending bikeshed about alpha and color management properties.
> >> I noted that drm-hwc2 was looking for this property, and a couple other
> >> drivers already support it in the same way.  So time to expose it!
> >>
> >> Signed-off-by: Rob Clark 
> >
> > Can we please have a bit of shared property setup in drm_blend.c and some
> > documentation how it is supposed to be used? Adding props is nice, but
> > greating an undocumented and ill-defined mess of them, not so much ;-)
> >
> > I'd prefer the full specced blending equation in the docs, including how
> > this interacts with fb formats which already have their own alpha value.
> 
> 
> It is used same way as rcar-du and atmel-hlcdc (and already is in
> kms-properties.csv
> 
> couldn't really tell you the blend equation.. but I guess it is
> "whatever android wants"

This is the kind of answer that uapi disasters are made of. Can you pls
figure this one out? Worst case just make it to fit msm ;-)

Also would be great to put the alpha value into drm_plane_state, like with
the other standardized properties.

Imo we really should be doing this right, and just because we didn't do it
right in the past isn't a good excuse.
-Daniel

> 
> BR,
> -R
> 
> > Thanks, Daniel
> >
> >> ---
> >>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> >> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> >> index 432c098..b6f1fc66 100644
> >> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> >> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> >> @@ -120,6 +120,7 @@ static void mdp5_plane_install_properties(struct 
> >> drm_plane *plane,
> >>   ARRAY_SIZE(name##_prop_enum_list))
> >>
> >>   INSTALL_RANGE_PROPERTY(zpos, ZPOS, 1, 255, 1);
> >> + INSTALL_RANGE_PROPERTY(alpha, ALPHA, 0, 255, 255);
> >>
> >>   mdp5_plane_install_rotation_property(dev, plane);
> >>
> >> @@ -148,6 +149,7 @@ static int mdp5_plane_atomic_set_property(struct 
> >> drm_plane *plane,
> >>   } while (0)
> >>
> >>   SET_PROPERTY(zpos, ZPOS, uint8_t);
> >> + SET_PROPERTY(alpha, ALPHA, uint8_t);
> >>
> >>   dev_err(dev->dev, "Invalid property\n");
> >>   ret = -EINVAL;
> >> @@ -176,6 +178,7 @@ static int mdp5_plane_atomic_get_property(struct 
> >> drm_plane *plane,
> >>   } while (0)
> >>
> >>   GET_PROPERTY(zpos, ZPOS, uint8_t);
> >> + GET_PROPERTY(alpha, ALPHA, uint8_t);
> >>
> >>   dev_err(dev->dev, "Invalid property\n");
> >>   ret = -EINVAL;
> >> --
> >> 2.7.4
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

About the Xserver for rockchip

[Randy Li]

On 10/17/2016 04:02 PM, Mark yao wrote:
> On 2016年10月17日 15:12, Heiko Stuebner wrote:
>> Am Montag, 17. Oktober 2016, 14:45:30 CEST schrieb Randy Li:
>>> Hello Tomasz:
>>>Heiko told me you are in charge of the graphics part of chromium, I
>>> think I had better told you the developing status of the xorg xserver in
>>> rockchip.
>> What I actually said was that Tomasz did the original VPU driver used on
>> veyron chromebooks, so may be interested in your current work on that
>> :-) .
Yes, I am rewriting the VPU driver. The last topic is
something different ideas from chromium's decoder settings API
in linux-media
>>
>> Also ChromeOS moved from X11 to use Freon instead, so I'm not sure if
>> ChromeOS
>> cares about that anymore.
And Mark is thinking about moving forward to wayland.
>>
>>> Currently the graphics department released a modification
>>> version of xserver which would support the libMali, but the way to
>>> support it is some kind of hacker which disabled the original mesa gl
>>> support.
>>> https://github.com/rockchip-linux/xserver/commit/bae12718e76d50d7388a93a251e
>>>
>>> f6777f6ca4850#diff-92a9ba7d51895d2d69c5c893fa0f658dL792
>>>
>>> Since the code base of that is really a mess, I rebase the branch
>>> rockchip with the xserver branch 1.18 from upstream, it is there
>>> https://github.com/rockchip-linux/xserver/tree/rockchip-1.18
>>> But the version I made would omit some pixels when it is drawing, I have
>>> not found out why.
>> Didn't Mark do a lot of changes on your xserver, so maybe he knows
>> what might
>> be going wrong?
>
> I don't what the problem it's, I haven't a chance to try Randy's issue yet.
>
> Hi Randy
>
> Did you re-test it with this patch:
> https://github.com/rockchip-linux/xserver/commit/bfee8067608b9dcbf6dae0ed897ae1295fdef7f2
No, I have merged that patch in my branch, just forget to push it 
recently it.
Your branch works fine now, it may be caused some mistakes when I was 
rebasing. It is not serious problem for now.
>
>
> Thanks.
>
>>
>>
>> Heiko
>>
>>
>>
>
>

-- 
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

[git pull] drm fixes for 4.9-rc2

[Dave Airlie]

Hi Linus,

Just had a couple of amdgpu fixes and one core fix I wanted to get out
early to fix some regressions.

I'm sure I'll have more stuff this week for -rc2.

Signed tags should be working again.

Dave.

The following changes since commit 69405d3da98b48633b78a49403e4f9cdb7c6a0f5:

  Merge tag 'topic/drm-misc-2016-10-11' of
git://anongit.freedesktop.org/drm-intel into drm-next (2016-10-12
06:07:38 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.9-rc2

for you to fetch changes up to fa860a1751e388385a7f249dd3f24a6c76db0ba9:

  drm: Print device information again in debugfs (2016-10-17 16:20:53 +1000)


drm: amdgpu/radeon and one core regression fix


Alex Deucher (9):
  drm/radeon: fix up dp aux tear down (v2)
  drm/radeon: fix modeset tear down code
  drm/amdgpu/gfx8: fix CGCG_CGLS handling
  drm/amdgpu: clarify UVD/VCE special handling for CG
  drm/radeon: change vblank_time's calculation method to reduce
computational error.
  drm/amdgpu: fix amdgpu_need_full_reset (v2)
  drm/amdgpu: disable smu hw first on tear down
  drm/amdgpu/powerplay: implement thermal sensor for CZ/ST
  drm/amdgpu/dpm: implement thermal sensor for CZ/ST

Arindam Nath (1):
  drm/amd/amdgpu: enable clockgating only after late init

Dan Carpenter (1):
  drm/amdgpu: potential NULL dereference in debugfs code

Daniel Vetter (1):
  drm: Print device information again in debugfs

Dave Airlie (1):
  Merge branch 'drm-next-4.9' of
git://people.freedesktop.org/~agd5f/linux into drm-next

Grazvydas Ignotas (1):
  drm/amdgpu: use .early_unregister hook to remove DP AUX i2c

Marek Olšák (1):
  drm/radeon: allow TA_CS_BC_BASE_ADDR on SI

Nicolai Hähnle (1):
  drm/amdgpu: initialize the context reset_counter in amdgpu_ctx_init

Rex Zhu (6):
  drm/amdgpu: change vblank_time's calculation method to reduce
computational error.
  drm/amd/powerplay: fix static checker warnings in iceland_smc.c
  drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
  drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
  drm/amd/powerplay: notify smu no display by default.
  drm/amd/powerplay: fix bug stop dpm can't work on Vi.

Tom St Denis (1):
  drm/amdgpu/si_dpm: Limit clocks on HD86xx part

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 13 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c|  3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 69 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 14 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c|  8 ++-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 12 +---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 30 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  | 13 ++--
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 14 ++---
 drivers/gpu/drm/amd/amdgpu/si_dpm.c|  6 ++
 drivers/gpu/drm/amd/amdgpu/tonga_ih.c  | 14 ++---
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  | 14 ++---
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  | 15 +++--
 drivers/gpu/drm/amd/include/amd_shared.h   |  2 +-
 .../drm/amd/powerplay/eventmgr/eventactionchains.c |  1 +
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 18 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 53 ++---
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c |  2 +-
 drivers/gpu/drm/drm_info.c |  4 --
 drivers/gpu/drm/radeon/r600_dpm.c  | 15 ++---
 drivers/gpu/drm/radeon/radeon_connectors.c | 17 ++
 drivers/gpu/drm/radeon/radeon_display.c| 14 ++---
 drivers/gpu/drm/radeon/radeon_drv.c|  3 +-
 drivers/gpu/drm/radeon/radeon_i2c.c|  3 +-
 drivers/gpu/drm/radeon/si.c|  1 +
 drivers/gpu/drm/radeon/sid.h   |  1 +
 27 files changed, 232 insertions(+), 131 deletions(-)

[Bug 91965] RS482M [Mobility Radeon Xpress 200] screen corruption

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

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

Vedran Miletić  changed:

   What|Removed |Added

Summary|pictures artefacts  |RS482M [Mobility Radeon
   ||Xpress 200] screen
   ||corruption

-- 
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/20161017/e8b4f6ed/attachment.html>

[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

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

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

--- Comment #6 from Alex Deucher  ---
You can also unbind the console before unloading the module.

sudo bash -c "echo 0 > /sys/class/vtconsole/vtcon1/bind"
sudo modprobe -r amdgpu

-- 
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/20161017/9b96a9c4/attachment.html>

[bug report] drm/amd/powerplay: add vce state tables initialize for ppt v1.

[Christian König]

Reviewed-by: Christian König .

Am 17.10.2016 um 12:37 schrieb Zhu, Rex:
> Thanks, please help to review the attached patch.
>
> Best Regards
> Rex
>
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpenter at oracle.com]
> Sent: Thursday, October 13, 2016 9:26 PM
> To: Zhu, Rex
> Cc: dri-devel at lists.freedesktop.org
> Subject: [bug report] drm/amd/powerplay: add vce state tables initialize for 
> ppt v1.
>
> Hello Rex Zhu,
>
> The patch 48d7b759a8bc: "drm/amd/powerplay: add vce state tables initialize 
> for ppt v1." from Aug 31, 2016, leads to the following static checker warning:
>
>   
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/process_pptables_v1_0.c:1211 
> ppt_get_num_of_vce_state_table_entries_v1_0()
>   warn: 'vce_state_table' can't be NULL.
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/process_pptables_v1_0.c
>1200
>1201  static int ppt_get_num_of_vce_state_table_entries_v1_0(struct 
> pp_hwmgr *hwmgr)
>1202  {
>1203  const ATOM_Tonga_POWERPLAYTABLE *pp_table = 
> get_powerplay_table(hwmgr);
>1204  const ATOM_Tonga_VCE_State_Table *vce_state_table =
>1205  (ATOM_Tonga_VCE_State_Table 
> *)(((unsigned long)pp_table) + le16_to_cpu(pp_table->usVCEStateTableOffset));
>   
>    pp_table can't be NULL because 
> we're dereferencing it here.  That means vce_state_table can't be NULL either.
>
>1206
>1207  if (vce_state_table == NULL)
>1208  return 0;
>1209
>1210  return vce_state_table->ucNumEntries;
>1211  }
>1212
>
> A cleaner way to write this is maybe:
>
> static int ppt_get_num_of_vce_state_table_entries_v1_0(struct pp_hwmgr 
> *hwmgr) {
>   const ATOM_Tonga_POWERPLAYTABLE *pp_table = get_powerplay_table(hwmgr);
>   const ATOM_Tonga_VCE_State_Table *vce_state_table;
>
>   if (!pp_table)
>   return 0;
>
>   vce_state_table = (void *)pp_table + 
> le16_to_cpu(pp_table->usVCEStateTableOffset);
>   return vce_state_table->ucNumEntries;
> }
>
> regards,
> dan carpenter
>
>
> ___
> 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/20161017/5ed91f0f/attachment.html>

kernel panic caused by raedon driver during reboot

[Baoquan He]

On 10/17/16 at 04:37pm, Michel Dänzer wrote:
> On 17/10/16 04:17 PM, Baoquan He wrote:
> > In fact this could happen in radeon_pci_shutdown. I tried reboot and
> > poweroff, kernel panic happened in both cases. Attachments are console
> > log and kernel config of 4.9-rc1 on linus's tree.
> 
> This is fixed with these commits, which should land in Linus' tree soon:
> 
> https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
> https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=9305ee6fe52035f63d70d023235b792ba22107f0

Great, thanks for telling!

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

About the Xserver for rockchip

[Mark yao]

On 2016年10月17日 15:12, Heiko Stuebner wrote:
> Am Montag, 17. Oktober 2016, 14:45:30 CEST schrieb Randy Li:
>> Hello Tomasz:
>>Heiko told me you are in charge of the graphics part of chromium, I
>> think I had better told you the developing status of the xorg xserver in
>> rockchip.
> What I actually said was that Tomasz did the original VPU driver used on
> veyron chromebooks, so may be interested in your current work on that :-) .
>
> Also ChromeOS moved from X11 to use Freon instead, so I'm not sure if ChromeOS
> cares about that anymore.
>
>> Currently the graphics department released a modification
>> version of xserver which would support the libMali, but the way to
>> support it is some kind of hacker which disabled the original mesa gl
>> support.
>> https://github.com/rockchip-linux/xserver/commit/bae12718e76d50d7388a93a251e
>> f6777f6ca4850#diff-92a9ba7d51895d2d69c5c893fa0f658dL792
>>
>> Since the code base of that is really a mess, I rebase the branch
>> rockchip with the xserver branch 1.18 from upstream, it is there
>> https://github.com/rockchip-linux/xserver/tree/rockchip-1.18
>> But the version I made would omit some pixels when it is drawing, I have
>> not found out why.
> Didn't Mark do a lot of changes on your xserver, so maybe he knows what might
> be going wrong?

I don't what the problem it's, I haven't a chance to try Randy's issue yet.

Hi Randy

Did you re-test it with this patch: 
https://github.com/rockchip-linux/xserver/commit/bfee8067608b9dcbf6dae0ed897ae1295fdef7f2

Thanks.

>
>
> Heiko
>
>
>


-- 
ï¼­ark Yao

[PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Bartosz Golaszewski]

2016-10-17 14:29 GMT+02:00 Tomi Valkeinen :
> On 17/10/16 14:40, Laurent Pinchart wrote:
>> Hello,
>>
>> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>>> On 17/10/16 10:12, Sekhar Nori wrote:
 On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
> On 15/10/16 20:42, Sekhar Nori wrote:
>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>> b/arch/arm/boot/dts/da850.dtsi
>>> index f79e1b9..32908ae 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -399,6 +420,14 @@
>>>  <&edma0 0 1>;
>>>  dma-names = "tx", "rx";
>>>  };
>>> +
>>> +display: display at 213000 {
>>> +compatible = "ti,am33xx-tilcdc", 
>>> "ti,da850-tilcdc";
>>
>> This should instead be:
>>
>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>
>> as the closest match should appear first in the list.
>
> Actually I don't think that's correct. The LCDC on da850 is not
> compatible with the LCDC on AM335x. I think it should be just
> "ti,da850-tilcdc".

 So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
 the case, I wonder how the patch passed testing. Bartosz?
>>>
>>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>>> similar, but different.
>>>
>>> The driver gets the version number from LCDC's register, and acts based
>>> on that, so afaik the compatible string doesn't really affect the
>>> functionality (as long as it matches).
>>>
>>> But even if it works with the current driver, I don't think
>>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
>>
>> If the hardware provides IP revision information, how about just "ti,lcdc" ?
>
> Maybe, and I agree that's the "correct" way, but looking at the history,
> it's not just once or twice when we've suddenly found out some
> difference or bug or such in an IP revision, or the integration to a
> SoC, that can't be found based on the IP revision.
>
> That's why I feel it's usually safer to have the SoC revision there in
> the compatible string.
>
> That said, we have only a few different old SoCs with LCDC (compared to,
> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.
>
>  Tomi
>

I Sekhar is ok with this, I'll send a follow-up patch for that.

Thanks,
Bartosz

[Bug 91965] pictures artefacts

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

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

--- Comment #3 from JohnDoe_71Rus  ---
latest data

server glx vendor string: SGI
server glx version string: 1.4
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RS480
OpenGL version string: 2.1 Mesa 11.2.0
Linux 4.6.0-040600-generic

-- 
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/20161017/dd0c0676/attachment.html>

[GIT PULL] etnaviv-fixes for 4.9-rc2

[Lucas Stach]

Hi Dave,

2 more patches to stabilize the new MMUv2 support.

Regards,
Lucas

The following changes since commit b89857852656f016328d2d7ccec5fff57445fa85:

  Merge branch 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2016-10-10 16:40:16 +1000)

are available in the git repository at:

  git://git.pengutronix.de/lst/linux drm-etnaviv-fixes

for you to fetch changes up to 8814d2dce00f77c5eeb7278981ac6fd08835629e:

  drm/etnaviv: block 64K of address space behind each cmdstream (2016-10-10 
15:26:39 +0200)


Lucas Stach (2):
  drm/etnaviv: ensure write caches are flushed at end of user cmdstream
  drm/etnaviv: block 64K of address space behind each cmdstream

 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 24 +++-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c|  3 ++-
 2 files changed, 21 insertions(+), 6 deletions(-)

[PATCH 3/3] reservation: revert "wait only with non-zero timeout specified (v3)"

[Christian König]

From: Christian König 

This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.

Otherwise signaling might never be activated on the fences. This can
result in infinite waiting with hardware which has unreliable interrupts.

Signed-off-by: Christian König 
---
 drivers/dma-buf/reservation.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 9566a62..bb97b04 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -381,9 +381,6 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
unsigned seq, shared_count, i = 0;
long ret = timeout;

-   if (!timeout)
-   return reservation_object_test_signaled_rcu(obj, wait_all);
-
 retry:
fence = NULL;
shared_count = 0;
-- 
2.5.0

[PATCH 2/3] dma-buf/fence: revert "don't wait when specified timeout is zero"

[Christian König]

From: Christian König 

This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.

When we don't call the wait function software signaling might never be
activated. This can cause infinite polling loops with unreliable interrupt
driven hardware.

Signed-off-by: Christian König 
---
 drivers/dma-buf/fence.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index fb915ab..64478f9 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -159,9 +159,6 @@ fence_wait_timeout(struct fence *fence, bool intr, signed 
long timeout)
if (WARN_ON(timeout < 0))
return -EINVAL;

-   if (timeout == 0)
-   return fence_is_signaled(fence);
-
trace_fence_wait_start(fence);
ret = fence->ops->wait(fence, intr, timeout);
trace_fence_wait_end(fence);
-- 
2.5.0

[PATCH 1/3] dma-buf/fence: make timeout handling in fence_default_wait consistent

[Christian König]

From: Christian König 

Kernel functions taking a timeout usually return 1 on success even
when they get a zero timeout.

Signen-off-by: Christian König 
---
 drivers/dma-buf/fence.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 4d51f9e..fb915ab 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -335,18 +335,20 @@ fence_default_wait_cb(struct fence *fence, struct 
fence_cb *cb)
  * @timeout:   [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
  *
  * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the
- * remaining timeout in jiffies on success.
+ * remaining timeout in jiffies on success. If timeout is zero the value one is
+ * returned if the fence is already signaled for consistency with other
+ * functions taking a jiffies timeout.
  */
 signed long
 fence_default_wait(struct fence *fence, bool intr, signed long timeout)
 {
struct default_wait_cb cb;
unsigned long flags;
-   signed long ret = timeout;
+   signed long ret = timeout ? timeout : 1;
bool was_set;

if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags))
-   return timeout;
+   return ret;

spin_lock_irqsave(fence->lock, flags);

-- 
2.5.0

[Bug 91965] pictures artefacts

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

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

--- Comment #2 from JohnDoe_71Rus  ---
Created attachment 127361
  --> https://bugs.freedesktop.org/attachment.cgi?id=127361&action=edit
dmesg

sorry. Just see

-- 
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/20161017/c0d368ba/attachment.html>

[PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Laurent Pinchart]

Hi Tomi,

On Monday 17 Oct 2016 15:29:23 Tomi Valkeinen wrote:
> On 17/10/16 14:40, Laurent Pinchart wrote:
> > On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
> >> On 17/10/16 10:12, Sekhar Nori wrote:
> >>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>  On 15/10/16 20:42, Sekhar Nori wrote:
> >> diff --git a/arch/arm/boot/dts/da850.dtsi
> >> b/arch/arm/boot/dts/da850.dtsi
> >> index f79e1b9..32908ae 100644
> >> --- a/arch/arm/boot/dts/da850.dtsi
> >> +++ b/arch/arm/boot/dts/da850.dtsi
> >> @@ -399,6 +420,14 @@
> >><&edma0 0 1>;
> >>dma-names = "tx", "rx";
> >>};
> >> +
> >> +  display: display at 213000 {
> >> +  compatible = "ti,am33xx-tilcdc", "ti,da850-
tilcdc";
> > 
> > This should instead be:
> > 
> > compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
> > 
> > as the closest match should appear first in the list.
>  
>  Actually I don't think that's correct. The LCDC on da850 is not
>  compatible with the LCDC on AM335x. I think it should be just
>  "ti,da850-tilcdc".
> >>> 
> >>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
> >>> the case, I wonder how the patch passed testing. Bartosz?
> >> 
> >> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
> >> similar, but different.
> >> 
> >> The driver gets the version number from LCDC's register, and acts based
> >> on that, so afaik the compatible string doesn't really affect the
> >> functionality (as long as it matches).
> >> 
> >> But even if it works with the current driver, I don't think
> >> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
> > 
> > If the hardware provides IP revision information, how about just "ti,lcdc"
> > ?
>
> Maybe, and I agree that's the "correct" way, but looking at the history,
> it's not just once or twice when we've suddenly found out some
> difference or bug or such in an IP revision, or the integration to a
> SoC, that can't be found based on the IP revision.
> 
> That's why I feel it's usually safer to have the SoC revision there in
> the compatible string.
> 
> That said, we have only a few different old SoCs with LCDC (compared to,
> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.

You obviously know more than I do on this topic so I'll trust your opinion. If 
the version register isn't enough I'm fine with multiple compatible strings.

-- 
Regards,

Laurent Pinchart

[PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Laurent Pinchart]

Hi Rob,

On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
> >>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>> Multiple incompatible data link layers have been used over time to
> >>> transmit image data to LVDS panels. This binding supports display
> >>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
> >>> specifications.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> ---
> >>> 
> >>>  .../bindings/display/panel/panel-lvds.txt  | 119 ++
> >>>  1 file changed, 119 insertions(+)
> >>>  create mode 100644
> >>>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
> >>> 
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> new file mode 100644
> >>> index ..250861f2673e
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> >>> @@ -0,0 +1,119 @@
> >>> +Generic LVDS Panel
> >>> +==
> >>> +
> >>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> >>> Multiple
> >>> +incompatible data link layers have been used over time to transmit
> >>> image data
> >>> +to LVDS panels. This bindings supports display panels compatible with
> >>> the
> >>> +following specifications.
> >>> +
> >>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
> >>> February
> >>> +1999 (Version 1.0), Japan Electronic Industry Development Association
> >>> (JEIDA)
> >>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
> >>> +Semiconductor
> >>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
> >>> Video
> >>> +Electronics Standards Association (VESA)
> >>> +
> >>> +Device compatible with those specifications have been marketed under
> >>> the
> >>> +FPD-Link and FlatLink brands.
> >>> +
> >>> +
> >>> +Required properties:
> >>> +- compatible: shall contain "panel-lvds"
> >> 
> >> Maybe as a fallback, but on its own, no way.
> > 
> > Which brings an interesting question: when designing generic DT bindings,
> > what's the rule regarding

Looks like I forgot part of the question. I meant to ask what is the rule 
regarding usage of more precise compatible strings ?

For instance (but perhaps not the best example), the input/rotary-encoder.txt 
bindings define a "rotary-encoder" compatible string, with no other bindings 
defining more precise compatible strings for the exact rotary encoder model. 
When it comes to panels I believe it makes sense to define model-specific 
compatible strings even if they're unused by drivers. I'm however wondering 
what the rule is there, and where those device-specific compatible strings 
should be defined. I'd like to avoid using one file per panel model as done 
today for the simple-panel bindings.

> Call it "simple" so I can easily NAK it. :)
> 
> Define a generic structure, not a single binding trying to serve all.
> 
> >> > +- width-mm: panel display width in millimeters
> >> > +- height-mm: panel display height in millimeters
> >> 
> >> This is already documented for all panels IIRC.
> > 
> > Note that this DT binding has nothing to do with the simple-panel binding.
> > It is instead similar to the panel-dpi and panel-dsi-cm bindings (which
> > currently don't but should specify the panel size in DT). The LVDS panel
> > driver will *not* include any panel-specific information such as size or
> > timings, these are specified in DT.
> 
> The panel bindings aren't really different. The biggest difference was
> location in the tree, but we now generally allow panels to be either a
> child of the LCD controller or connected with OF graph. We probably
> need to work on restructuring the panel bindings a bit. We should have
> an inheritance with a base panel binding of things like size, label,
> graph, backlight, etc, then perhaps an interface specific bindings for
> LVDS, DSI, and parallel, then a panel specific binding. With this the
> panel specific binding is typically just a compatible string and which
> inherited properties apply to it.

That sounds good to me, but we have multiple models for panel bindings.

As you mentioned panels can be referenced through an LCD controller node 
property containing a phandle to the panel node, or through OF graph. That's a 
situation we have today, and we need to keep supporting both (at least for 
existing panels, perhaps not for the new ones).

Another difference is how to express panel data such as size and timings. The 
simple-panel DT bindings don't contain such data and expects the drivers to 
contain a table of panel data for all models supported, while the DPI, DSI and 
now the proposed LVDS panel bindings contain properties for panel

[PATCH v4 3/4] video: Add new aspect ratios for HDMI 2.0

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 05:34:39PM +0530, Shashank Sharma wrote:
> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> - 64:27
> - 256:135
> 
> This patch adds enumeration for the new aspect ratios
> in the existing aspect ratio list.
> 
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Sean Paul 
> Reviewed-by: Jose Abreu 
> Acked-by: Tomi Valkeinen 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> 
> V2: rebase
> V3: rebase
> V4: Added r-b from Jose, Ack by Tomi
> ---
>  drivers/video/hdmi.c | 4 
>  include/linux/hdmi.h | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 1626892..1cf907e 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
> picture_aspect)
>   return "4:3";
>   case HDMI_PICTURE_ASPECT_16_9:
>   return "16:9";
> + case HDMI_PICTURE_ASPECT_64_27:
> + return "64:27";
> + case HDMI_PICTURE_ASPECT_256_135:
> + return "256:135";
>   case HDMI_PICTURE_ASPECT_RESERVED:
>   return "Reserved";
>   }
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index e974420..edbb4fc 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
>   HDMI_PICTURE_ASPECT_NONE,
>   HDMI_PICTURE_ASPECT_4_3,
>   HDMI_PICTURE_ASPECT_16_9,
> + HDMI_PICTURE_ASPECT_64_27,
> + HDMI_PICTURE_ASPECT_256_135,

Hmm. How's this gonna work? The AVI infoframe doesn't have these.

>   HDMI_PICTURE_ASPECT_RESERVED,
>  };
>  
> -- 
> 1.9.1
> 
> ___
> 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] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
> Current DRM layer functions don't parse aspect ratio information
> while converting a user mode->kernel mode or vice versa. This
> causes modeset to pick mode with wrong aspect ratio, eventually
> causing failures in HDMI compliance test cases, due to wrong VIC.
> 
> This patch adds aspect ratio information in DRM's mode conversion
> and mode comparision functions, to make sure kernel picks mode
> with right aspect ratio (as per the VIC).
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lin, Jia 
> Signed-off-by: Akashdeep Sharma 
> Reviewed-by: Jim Bride 
> Reviewed-by: Jose Abreu 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> 
> V2: Addressed review comments from Sean:
> - Fix spellings/typo
> - No need to handle aspect ratio none
> - Add a break, for default case too
> V3: Rebase
> V4: Added r-b from Jose
> ---
>  drivers/gpu/drm/drm_modes.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 53f07ac..fde927a 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
> drm_display_mode *mode1,
>   mode1->vsync_end == mode2->vsync_end &&
>   mode1->vtotal == mode2->vtotal &&
>   mode1->vscan == mode2->vscan &&
> + mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
>   (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>   return true;
> @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
>   out->vrefresh = in->vrefresh;
>   out->flags = in->flags;
>   out->type = in->type;
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->picture_aspect_ratio) {
> + case HDMI_PICTURE_ASPECT_4_3:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> + break;
> + case HDMI_PICTURE_ASPECT_16_9:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> + break;
> + case HDMI_PICTURE_ASPECT_RESERVED:
> + default:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> + break;
> + }
> +
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  }
> @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
> *out,
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  
> + /* Clearing picture aspect ratio bits from out flags */
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> + case DRM_MODE_FLAG_PIC_AR_4_3:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
> + break;
> + case DRM_MODE_FLAG_PIC_AR_16_9:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> + break;
> + default:
> + out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + break;
> + }

Hmm. So now we have the mode aspect ratio infromation duplicated
in two different places. Not sure that won't lead to some confusion.
Although we do want the user to be able to override via the property I
suppose, so we'd have to change that (+ the inforframe code) to
look at the mode flags instead if we would eliminate
'picture_aspect_ratio'.

And that brings me to the other point. At least i915 will simply
override the mode's aspect ration with the property. So this looks like
a big no-op for now on i915. It's looking like we might need a new
propetty value to differentiate between "auto" and "none" for real.

> +
>   out->status = drm_mode_validate_basic(out);
>   if (out->status != MODE_OK)
>   goto out;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Tomi Valkeinen]

On 17/10/16 14:40, Laurent Pinchart wrote:
> Hello,
> 
> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>> On 17/10/16 10:12, Sekhar Nori wrote:
>>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>>> On 15/10/16 20:42, Sekhar Nori wrote:
>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>> index f79e1b9..32908ae 100644
>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>> @@ -399,6 +420,14 @@
>>>>>>  <&edma0 0 1>;
>>>>>>  dma-names = "tx", "rx";
>>>>>>  };
>>>>>> +
>>>>>> +display: display at 213000 {
>>>>>> +compatible = "ti,am33xx-tilcdc", 
>>>>>> "ti,da850-tilcdc";
>>>>>
>>>>> This should instead be:
>>>>>
>>>>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>>>>
>>>>> as the closest match should appear first in the list.
>>>>
>>>> Actually I don't think that's correct. The LCDC on da850 is not
>>>> compatible with the LCDC on AM335x. I think it should be just
>>>> "ti,da850-tilcdc".
>>>
>>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>>> the case, I wonder how the patch passed testing. Bartosz?
>>
>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>> similar, but different.
>>
>> The driver gets the version number from LCDC's register, and acts based
>> on that, so afaik the compatible string doesn't really affect the
>> functionality (as long as it matches).
>>
>> But even if it works with the current driver, I don't think
>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
> 
> If the hardware provides IP revision information, how about just "ti,lcdc" ?

Maybe, and I agree that's the "correct" way, but looking at the history,
it's not just once or twice when we've suddenly found out some
difference or bug or such in an IP revision, or the integration to a
SoC, that can't be found based on the IP revision.

That's why I feel it's usually safer to have the SoC revision there in
the compatible string.

That said, we have only a few different old SoCs with LCDC (compared to,
say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161017/6c32126e/attachment.sig>

[RESEND][PATCH 2/2 v4] drm/bridge: adv7511: Enable the audio data and clock pads on adv7533

[John Stultz]

From: Srinivas Kandagatla 

This patch enables the Audio Data and Clock pads to the adv7533 bridge.
Without this patch audio can not be played.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Archit Taneja 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7533.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c 
b/drivers/gpu/drm/bridge/adv7511/adv7533.c
index d7f7b7c..8b21037 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
@@ -29,6 +29,7 @@ static const struct reg_sequence 
adv7533_cec_fixed_registers[] = {
{ 0x17, 0xd0 },
{ 0x24, 0x20 },
{ 0x57, 0x11 },
+   { 0x05, 0xc8 },
 };

 static const struct regmap_config adv7533_cec_regmap_config = {
-- 
2.7.4

[RESEND][PATCH 1/2 v4] drm/bridge: adv7511: Add Audio support.

[John Stultz]

This patch adds support to Audio for both adv7511 and adv7533
bridge chips.

This patch was originally from [1] by Lars-Peter Clausen 
and was adapted by Archit Taneja  and
Srinivas Kandagatla .

Then I heavily reworked it to use the hdmi-codec driver. And also
folded in some audio packet initialization done by Andy Green
. So credit to them, but blame to me.

[1] 
https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i2c/adv7511_audio.c

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
Cc: Wolfram Sang 
Cc: Srinivas Kandagatla 
Cc: "Ville Syrjälä" 
Cc: Boris Brezillon 
Cc: Andy Green 
Cc: Dave Long 
Cc: Guodong Xu 
Cc: Zhangfei Gao 
Cc: Mark Brown 
Cc: Lars-Peter Clausen 
Cc: Jose Abreu 
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Archit Taneja 
Acked-by: Lars-Peter Clausen 
Signed-off-by: John Stultz 
---
v4:
* Kconfig tweaks suggested by Lars-Peter Clausen
v3:
* Allowed audio support to be configured in or out, as suggested by Laurent
* Minor cleanups suggested by Laurent
* Folded in Andy's audio packet initialization patch, as suggested by Archit
---
 drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
 drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511.h   |  16 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 213 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |   4 +
 5 files changed, 242 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_audio.c

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index d2b0499..2fed567 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -6,6 +6,14 @@ config DRM_I2C_ADV7511
help
  Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.

+config DRM_I2C_ADV7511_AUDIO
+   bool "ADV7511 HDMI Audio driver"
+   depends on DRM_I2C_ADV7511 && SND_SOC
+   select SND_SOC_HDMI_CODEC
+   help
+ Support the ADV7511 HDMI Audio interface. This is used in
+ conjunction with the AV7511  HDMI driver.
+
 config DRM_I2C_ADV7533
bool "ADV7533 encoder"
depends on DRM_I2C_ADV7511
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index 9019327..5ba6755 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,3 +1,4 @@
 adv7511-y := adv7511_drv.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
 adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 161c923..992d76c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -309,6 +309,8 @@ struct adv7511 {
struct drm_display_mode curr_mode;

unsigned int f_tmds;
+   unsigned int f_audio;
+   unsigned int audio_source;

unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -334,6 +336,7 @@ struct adv7511 {
bool use_timing_gen;

enum adv7511_type type;
+   struct platform_device *audio_pdev;
 };

 #ifdef CONFIG_DRM_I2C_ADV7533
@@ -389,4 +392,17 @@ static inline int adv7533_parse_dt(struct device_node *np, 
struct adv7511 *adv)
 }
 #endif

+#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
+int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
+void adv7511_audio_exit(struct adv7511 *adv7511);
+#else /*CONFIG_DRM_I2C_ADV7511_AUDIO */
+static inline int adv7511_audio_init(struct device *dev, struct adv7511 
*adv7511)
+{
+   return 0;
+}
+static inline void adv7511_audio_exit(struct adv7511 *adv7511)
+{
+}
+#endif /* CONFIG_DRM_I2C_ADV7511_AUDIO */
+
 #endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
new file mode 100644
index 000..5ce29a5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -0,0 +1,213 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ * Copyright (c) 2016, Linaro Limited
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "adv7511.h"
+
+static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs,
+  unsigned int *cts, unsigned int *n)
+{
+   switch (fs) {
+   case 32000:
+   *n = 4096;
+   break;
+   case 44100:
+   *n = 6272;
+   break;
+   case 48000:
+   *n = 6144;
+   break;
+   }
+
+   *cts = ((f_tmds * *n) / (128 * fs)) * 1000;
+}
+
+static int adv7511_update_cts_n(struct adv7511 *adv7511)
+{
+   unsigned int cts = 0;
+   unsigned int n = 0;
+
+   adv7511_calc_cts_n(adv7511->f_tmds, adv7511->f_audio, &cts, &n)

kernel panic caused by raedon driver during reboot

[Baoquan He]

In fact this could happen in radeon_pci_shutdown. I tried reboot and
poweroff, kernel panic happened in both cases. Attachments are console
log and kernel config of 4.9-rc1 on linus's tree.
-- next part --
[   14.275003] Rebooting in 10 seconds..[   24.329266] ACPI MEMORY or I/O 
RESET_REG.
[0.00] Linux version 4.9.0-rc1+ (bhe at dhcp-129-10.nay.redhat.com) 
(gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) ) #89 SMP Sun Oct 16
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.9.0-rc1+ 
root=/dev/mapper/fedora_dhcp--129--10-root ro rd.lvm.lv=fedora_dhcp-129-10/root 
rd.ll
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x7cc99fff] usable
[0.00] BIOS-e820: [mem 0x7cc9a000-0x7ccc9fff] reserved
[0.00] BIOS-e820: [mem 0x7ccca000-0x7cf9] usable
[0.00] BIOS-e820: [mem 0x7cfa-0x7d06dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7d06e000-0x7e1c7fff] reserved
[0.00] BIOS-e820: [mem 0x7e1c8000-0x7e1c8fff] usable
[0.00] BIOS-e820: [mem 0x7e1c9000-0x7e3cefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7e3cf000-0x7e850fff] usable
[0.00] BIOS-e820: [mem 0x7e851000-0x7efe1fff] reserved
[0.00] BIOS-e820: [mem 0x7efe2000-0x7eff] usable
[0.00] BIOS-e820: [mem 0xfec0-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] e820: last_pfn = 0x23f000 max_arch_pfn = 0x4
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0x7f000 max_arch_pfn = 0x4
[0.00] Scan for SMP in [mem 0x-0x03ff]
[0.00] Scan for SMP in [mem 0x0009fc00-0x0009]
[0.00] Scan for SMP in [mem 0x000f-0x000f]
[0.00] found SMP MP-table at [mem 0x000fd6f0-0x000fd6ff] mapped at 
[880fd6f0]
[0.00]   mpc: fd430-fd66c
[0.00] Using GB pages for direct mapping
[0.00] RAMDISK: [mem 0x31894000-0x34c41fff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F0490 24 (v02 ALASKA)
[0.00] ACPI: XSDT 0x7D024080 84 (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: FACP 0x7D02A598 00010C (v05 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has 
valid Length but zero Address: 0x/0x1 (20160831/)
[0.00] ACPI: DSDT 0x7D0241A0 0063F2 (v02 ALASKA A M I
0088 INTL 20051117)
[0.00] ACPI: FACS 0x7D063080 40
[0.00] ACPI: APIC 0x7D02A6A8 7E (v03 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: FPDT 0x7D02A728 44 (v01 ALASKA A M I
01072009 AMI  00010013)
[0.00] ACPI: MCFG 0x7D02A770 3C (v01 ALASKA A M I
01072009 MSFT 00010013)
[0.00] ACPI: HPET 0x7D02A7B0 38 (v01 ALASKA A M I
01072009 AMI  0005)
[0.00] ACPI: WDRT 0x7D02A7E8 47 (v01 ALASKA A M I
01072009 AMI  0005)
[0.00] ACPI: IVRS 0x7D02A830 78 (v02 AMDBANTRY   
0001 AMD  )
[0.00] ACPI: SSDT 0x7D02A8A8 000B9C (v01 AMDBANTRY   
0001 AMD  0001)
[0.00] ACPI: SSDT 0x7D02B448 00033B (v02 AMDBANTRY   
0002 MSFT 0400)
[0.00] ACPI: CRAT 0x7D02B788 000550 (v01 AMDBANTRY   
0001 AMD  0001)
[0.00] ACPI: SSDT 0x7D02BCD8 001457 (v01 AMDCPMDFIGP 
0001 I

[PATCH] dma-buf/fence-array: fix deadlock in fence-array

[Rob Clark]

On Mon, Oct 17, 2016 at 2:52 PM, Gustavo Padovan  wrote:
> 2016-10-17 Rob Clark :
>
>> Currently with fence-array, we have a potential deadlock situation.  If we
>> fence_add_callback() on an array-fence, the array-fence's lock is acquired
>> first, and in it's ->enable_signaling() callback, it will install cb's on
>> it's array-member fences, so the array-member's lock is acquired second.
>>
>> But in the signal path, the array-member's lock is acquired first, and the
>> array-fence's lock acquired second.
>>
>> To solve that, always enabling signaling up-front (in the fence_array
>> constructor) without the fence_array's lock held.
>
> Do we always want to enable signaling for arrays? One of the things we
> removed from the Sync Framework was the need to enable signalling at
> creation time.
>
> Just merging fencing doesn't mean you want signaling, that is supposed
> to happen only when poll() is called on the sync file.

It was something Maarten suggested, as an alternative to introducing a
wq into the mix or worse hacks..
https://lists.freedesktop.org/archives/dri-devel/2016-October/120868.html

I think I agree with him that it is an optimization that is unlikely
to be useful in the case of fence-arrays.  If you need to wait on
multiple fences from different timelines, you probably aren't doing
that in hw.

BR,
-R

> Gustavo
>

About the Xserver for rockchip

[Randy Li]

Hello Tomasz:
  Heiko told me you are in charge of the graphics part of chromium, I 
think I had better told you the developing status of the xorg xserver in 
rockchip. Currently the graphics department released a modification
version of xserver which would support the libMali, but the way to 
support it is some kind of hacker which disabled the original mesa gl 
support.
https://github.com/rockchip-linux/xserver/commit/bae12718e76d50d7388a93a251ef6777f6ca4850#diff-92a9ba7d51895d2d69c5c893fa0f658dL792

   Since the code base of that is really a mess, I rebase the branch 
rockchip with the xserver branch 1.18 from upstream, it is there
https://github.com/rockchip-linux/xserver/tree/rockchip-1.18
But the version I made would omit some pixels when it is drawing, I have 
not found out why.

-- 
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

[PATCH] dma-buf/fence-array: fix deadlock in fence-array

[Rob Clark]

Currently with fence-array, we have a potential deadlock situation.  If we
fence_add_callback() on an array-fence, the array-fence's lock is acquired
first, and in it's ->enable_signaling() callback, it will install cb's on
it's array-member fences, so the array-member's lock is acquired second.

But in the signal path, the array-member's lock is acquired first, and the
array-fence's lock acquired second.

To solve that, always enabling signaling up-front (in the fence_array
constructor) without the fence_array's lock held.

lockdep splat:

 ==
[ INFO: possible circular locking dependency detected ]
4.7.0-rc7+ #489 Not tainted
---
surfaceflinger/2034 is trying to acquire lock:
 (&(&array->lock)->rlock){..}, at: [] 
fence_signal+0x5c/0xf8

but task is already holding lock:
 (&(&obj->child_list_lock)->rlock){..}, at: [] 
sw_sync_ioctl+0x228/0x3b0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&(&obj->child_list_lock)->rlock){..}:
   [] __lock_acquire+0x173c/0x18d8
   [] lock_acquire+0x4c/0x68
   [] _raw_spin_lock_irqsave+0x54/0x70
   [] fence_add_callback+0x3c/0x100
   [] fence_array_enable_signaling+0x80/0x170
   [] fence_add_callback+0xb8/0x100
   [] sync_file_poll+0xd4/0xf0
   [] do_sys_poll+0x220/0x438
   [] SyS_ppoll+0x1b0/0x1d8
   [] el0_svc_naked+0x24/0x28

-> #0 (&(&array->lock)->rlock){..}:
   [] print_circular_bug+0x80/0x2e0
   [] __lock_acquire+0x17c4/0x18d8
   [] lock_acquire+0x4c/0x68
   [] _raw_spin_lock_irqsave+0x54/0x70
   [] fence_signal+0x5c/0xf8
   [] fence_array_cb_func+0x78/0x88
   [] fence_signal_locked+0x80/0xe0
   [] sw_sync_ioctl+0x2f8/0x3b0
   [] do_vfs_ioctl+0xa4/0x790
   [] SyS_ioctl+0x8c/0xa0
   [] el0_svc_naked+0x24/0x28

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(&(&obj->child_list_lock)->rlock);
   lock(&(&array->lock)->rlock);
   lock(&(&obj->child_list_lock)->rlock);
  lock(&(&array->lock)->rlock);

 *** DEADLOCK ***

1 lock held by surfaceflinger/2034:
 #0:  (&(&obj->child_list_lock)->rlock){..}, at: [] 
sw_sync_ioctl+0x228/0x3b0

Suggested-by: Maarten Lankhorst 
Signed-off-by: Rob Clark 
---
 drivers/dma-buf/fence-array.c |  8 
 drivers/dma-buf/fence.c   | 21 +
 include/linux/fence.h |  1 +
 3 files changed, 30 insertions(+)

diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
index f1989fc..b5821e9 100644
--- a/drivers/dma-buf/fence-array.c
+++ b/drivers/dma-buf/fence-array.c
@@ -140,6 +140,14 @@ struct fence_array *fence_array_create(int num_fences, 
struct fence **fences,
atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;

+   /* enable signaling without our lock being held while callbacks
+* are installed on the array-member fences.  Otherwise there is
+* a potential deadlock between enabling signaling (our lock
+* acquired first) and the array-members getting signalled (their
+* lock aquired first).
+*/
+   fence_enable_sw_signaling_nolock(&array->base);
+
return array;
 }
 EXPORT_SYMBOL(fence_array_create);
diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index cc05ddd..ff6b410 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -219,6 +219,27 @@ void fence_enable_sw_signaling(struct fence *fence)
 EXPORT_SYMBOL(fence_enable_sw_signaling);

 /**
+ * fence_enable_sw_signaling_nolock - enable signaling on fence without taking 
lock
+ * @fence: [in]the fence to enable
+ *
+ * WARNING this is only safe to use when you know you have the only reference
+ * to the fence there is no possibility for race conditions as a result of
+ * calling ops->enable_signaling() without lock.  Ie. it is probably only safe
+ * to use from the fence's construction function.
+ */
+void fence_enable_sw_signaling_nolock(struct fence *fence)
+{
+   if (!test_and_set_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, &fence->flags) &&
+   !test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
+   trace_fence_enable_signal(fence);
+
+   if (!fence->ops->enable_signaling(fence))
+   fence_signal(fence);
+   }
+}
+EXPORT_SYMBOL(fence_enable_sw_signaling_nolock);
+
+/**
  * fence_add_callback - add a callback to be called when the fence
  * is signaled
  * @fence: [in]the fence to wait on
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 0d76305..076ac29 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -226,6 +226,7 @@ int fence_add_callback(struct fence *fence, struct fence_cb 
*c

[PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Laurent Pinchart]

Hello,

On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
> On 17/10/16 10:12, Sekhar Nori wrote:
>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>>> On 15/10/16 20:42, Sekhar Nori wrote:
> diff --git a/arch/arm/boot/dts/da850.dtsi
> b/arch/arm/boot/dts/da850.dtsi
> index f79e1b9..32908ae 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -399,6 +420,14 @@
>   <&edma0 0 1>;
>   dma-names = "tx", "rx";
>   };
> +
> + display: display at 213000 {
> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
 
 This should instead be:
 
 compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
 
 as the closest match should appear first in the list.
>>> 
>>> Actually I don't think that's correct. The LCDC on da850 is not
>>> compatible with the LCDC on AM335x. I think it should be just
>>> "ti,da850-tilcdc".
>> 
>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>> the case, I wonder how the patch passed testing. Bartosz?
> 
> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
> similar, but different.
> 
> The driver gets the version number from LCDC's register, and acts based
> on that, so afaik the compatible string doesn't really affect the
> functionality (as long as it matches).
> 
> But even if it works with the current driver, I don't think
> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.

If the hardware provides IP revision information, how about just "ti,lcdc" ?

-- 
Regards,

Laurent Pinchart

[PATCH 19/19] drm/atomic: Rename atomic oldnew iterator

[Maarten Lankhorst]

With the old users of for_each_obj_in_state gone, we can rename
for_each_oldnew_obj_in_state back to that name. It's slightly less
ugly.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 34 ++---
 drivers/gpu/drm/drm_blend.c |  4 ++--
 drivers/gpu/drm/i915/intel_display.c| 16 +++---
 drivers/gpu/drm/imx/imx-drm-core.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  2 +-
 drivers/gpu/drm/msm/msm_atomic.c|  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c   |  2 +-
 include/drm/drm_atomic.h| 30 +++--
 9 files changed, 35 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c8aba493fc17..8fb955181641 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -241,7 +241,7 @@ steal_encoder(struct drm_atomic_state *state,
struct drm_connector_state *old_connector_state, *new_connector_state;
int i;

-   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
+   for_each_connector_in_state(state, connector, old_connector_state, 
new_connector_state, i) {
struct drm_crtc *encoder_crtc;

if (new_connector_state->best_encoder != encoder)
@@ -482,7 +482,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
struct drm_connector_state *old_connector_state, *new_connector_state;
int i, ret;

-   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
if (!drm_mode_equal(&old_crtc_state->mode, 
&new_crtc_state->mode)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode changed\n",
 crtc->base.id, crtc->name);
@@ -510,7 +510,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (ret)
return ret;

-   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
+   for_each_connector_in_state(state, connector, old_connector_state, 
new_connector_state, i) {
/*
 * This only sets crtc->connectors_changed for routing changes,
 * drivers must set crtc->connectors_changed themselves when
@@ -529,7 +529,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 * configuration. This must be done before calling mode_fixup in case a
 * crtc only changed its mode but has the same set of connectors.
 */
-   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
bool has_connectors =
!!new_crtc_state->connector_mask;

@@ -685,7 +685,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
int i;

-   for_each_oldnew_connector_in_state(old_state, connector, 
old_conn_state, new_conn_state, i) {
+   for_each_connector_in_state(old_state, connector, old_conn_state, 
new_conn_state, i) {
const struct drm_encoder_helper_funcs *funcs;
struct drm_encoder *encoder;

@@ -733,7 +733,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
drm_bridge_post_disable(encoder->bridge);
}

-   for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, 
i) {
const struct drm_crtc_helper_funcs *funcs;

/* Shut down everything that needs a full modeset. */
@@ -785,7 +785,7 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
drm_device *dev,
int i;

/* clear out existing links and update dpms */
-   for_each_oldnew_connector_in_state(old_state, connector, 
old_conn_state, new_conn_state, i) {
+   for_each_connector_in_state(old_state, connector, old_conn_state, 
new_conn_state, i) {
if (connector->encoder) {
WARN_ON(!connector->encoder->crtc);

@@ -1074,7 +1074,7 @@ bool drm_atomic_helper_framebuffer_changed(struct 
drm_device *dev,
struct drm_plane_state *old_plane_state, *new_plane_state;
int i;

-   for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
+   for_each_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
if (new_plane_state->crtc != crtc &&
old_plane_state->crtc != crtc)
continue;
@@ -,7 +,7 

[PATCH 18/19] drm/i915: Use new atomic iterator macros in display code

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 156 ++-
 1 file changed, 80 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3bd3f6a93c12..d310abace86a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3510,7 +3510,12 @@ __intel_display_resume(struct drm_device *dev,
if (!state)
return 0;

-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   /*
+* We've duplicated the state, pointers to the old state are invalid.
+*
+* Don't attempt to use the old state until we commit the duplicated 
state.
+*/
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
/*
 * Force recalculation even if we restore
 * current state. With fast modeset this may not result
@@ -5078,13 +5083,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
}
 }

-static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
+static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
+  struct intel_crtc_state *pipe_config)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->base.state);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
@@ -5186,12 +5190,11 @@ static void intel_encoders_pre_pll_enable(struct 
drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;

-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);

@@ -5207,12 +5210,11 @@ static void intel_encoders_pre_enable(struct drm_crtc 
*crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;

-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);

@@ -5228,12 +5230,11 @@ static void intel_encoders_enable(struct drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;

-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);

@@ -5253,7 +5254,7 @@ static void intel_encoders_disable(struct drm_crtc *crtc,
struct drm_connector *conn;
int i;

-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);

@@ -5273,7 +5274,7 @@ static void intel_encoders_post_disable(struct drm_crtc 
*crtc,
struct drm_connector *conn;
int i;

-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);

@@ -5293,7 +5294,7 @@ static void intel_encoders_post_pll_disable(struct 
drm_crtc *crtc,
struct drm_connector *conn;
int i;

-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   fo

[PATCH 17/19] drm/i915: Use new atomic iterator macros in wm code

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2df06b703e3d..163b73b493bf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3227,7 +3227,7 @@ skl_get_total_relative_data_rate(struct intel_crtc_state 
*intel_cstate)
return 0;

/* Calculate and cache data rate for each plane */
-   for_each_plane_in_state(state, plane, pstate, i) {
+   for_each_new_plane_in_state(state, plane, pstate, i) {
id = skl_wm_plane_id(to_intel_plane(plane));
intel_plane = to_intel_plane(plane);

@@ -3364,14 +3364,14 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
alloc_size -= cursor_blocks;

/* 1. Allocate the mininum required blocks for each active plane */
-   for_each_plane_in_state(state, plane, pstate, i) {
+   for_each_new_plane_in_state(state, plane, pstate, i) {
intel_plane = to_intel_plane(plane);
id = skl_wm_plane_id(intel_plane);

if (intel_plane->pipe != pipe)
continue;

-   if (!to_intel_plane_state(pstate)->base.visible) {
+   if (!pstate->visible) {
minimum[id] = 0;
y_minimum[id] = 0;
continue;
@@ -3933,7 +3933,7 @@ pipes_modified(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
uint32_t i, ret = 0;

-   for_each_crtc_in_state(state, crtc, cstate, i)
+   for_each_new_crtc_in_state(state, crtc, cstate, i)
ret |= drm_crtc_mask(crtc);

return ret;
@@ -4048,7 +4048,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 * since any racing commits that want to update them would need to
 * hold _all_ CRTC state mutexes.
 */
-   for_each_crtc_in_state(state, crtc, cstate, i)
+   for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
if (!changed)
return 0;
@@ -4070,7 +4070,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 * should allow skl_update_pipe_wm() to return failure in cases where
 * no suitable watermark values can be found.
 */
-   for_each_crtc_in_state(state, crtc, cstate, i) {
+   for_each_new_crtc_in_state(state, crtc, cstate, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *intel_cstate =
to_intel_crtc_state(cstate);
-- 
2.7.4

[PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index faa67624e1ed..0028335fc1bb 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,

mutex_lock(&fbc->lock);

-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (fbc->crtc == to_intel_crtc(crtc)) {
fbc_crtc_present = true;
break;
@@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
 * plane. We could go for fancier schemes such as checking the plane
 * size, but this would just affect the few platforms that don't tie FBC
 * to pipe or plane A. */
-   for_each_plane_in_state(state, plane, plane_state, i) {
+   for_each_new_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);

if (!intel_plane_state->base.visible)
continue;

-   for_each_crtc_in_state(state, crtc, crtc_state, j) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, j) {
struct intel_crtc_state *intel_crtc_state =
to_intel_crtc_state(crtc_state);

-- 
2.7.4

[PATCH 15/19] drm/i915: Use new atomic iterator macros in ddi

[Maarten Lankhorst]

Also make the function static, it's only used inside intel_ddi.c

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
 drivers/gpu/drm/i915/intel_drv.h | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 15d47c87def6..0e79c84e14e0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -740,7 +740,7 @@ intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
return ret;
 }

-struct intel_encoder *
+static struct intel_encoder *
 intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -753,7 +753,7 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
*crtc_state)

state = crtc_state->base.state;

-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_new_connector_in_state(state, connector, connector_state, i) {
if (connector_state->crtc != crtc_state->base.crtc)
continue;

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fd16adf069b..588d8af68043 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1156,8 +1156,6 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
*intel_dp);
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config);
-struct intel_encoder *
-intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state);

 void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
 void intel_ddi_clock_get(struct intel_encoder *encoder,
-- 
2.7.4

[PATCH 14/19] drm/mediatek: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index db61aa5f32ef..414e848d8cbf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -50,8 +50,8 @@ static void mtk_atomic_wait_for_fences(struct 
drm_atomic_state *state)
struct drm_plane_state *plane_state;
int i;

-   for_each_plane_in_state(state, plane, plane_state, i)
-   mtk_fb_wait(plane->state->fb);
+   for_each_new_plane_in_state(state, plane, plane_state, i)
+   mtk_fb_wait(plane_state->fb);
 }

 static void mtk_atomic_complete(struct mtk_drm_private *private,
-- 
2.7.4

[PATCH 13/19] drm/imx: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 98df09c2b388..d484af773460 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -155,7 +155,7 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
 struct drm_atomic_state *state,
 bool nonblock)
 {
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_plane *plane;
struct dma_buf *dma_buf;
int i;
@@ -164,13 +164,13 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
 * If the plane fb has an dma-buf attached, fish out the exclusive
 * fence for the atomic helper to wait on.
 */
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   if ((plane->state->fb != plane_state->fb) && plane_state->fb) {
-   dma_buf = drm_fb_cma_get_gem_obj(plane_state->fb,
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   if ((old_plane_state->fb != new_plane_state->fb) && 
new_plane_state->fb) {
+   dma_buf = drm_fb_cma_get_gem_obj(new_plane_state->fb,
 0)->base.dma_buf;
if (!dma_buf)
continue;
-   plane_state->fence =
+   new_plane_state->fence =
reservation_object_get_excl_rcu(dma_buf->resv);
}
}
-- 
2.7.4

[PATCH 12/19] drm/msm: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  4 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  6 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  4 ++--
 drivers/gpu/drm/msm/msm_atomic.c  | 16 
 5 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 571a91ee9607..d18d0a0e0a35 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -113,7 +113,7 @@ static void mdp4_prepare_commit(struct msm_kms *kms, struct 
drm_atomic_state *st
mdp4_enable(mdp4_kms);

/* see 119ecb7fd */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_get(crtc);
 }

@@ -125,7 +125,7 @@ static void mdp4_complete_commit(struct msm_kms *kms, 
struct drm_atomic_state *s
struct drm_crtc_state *crtc_state;

/* see 119ecb7fd */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_put(crtc);

mdp4_disable(mdp4_kms);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index ed7143d35b25..7cfeb0455039 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -82,10 +82,10 @@ static void mdp5_complete_commit(struct msm_kms *kms, 
struct drm_atomic_state *s
int i;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_state, *new_state;

-   for_each_plane_in_state(state, plane, plane_state, i)
-   mdp5_plane_complete_commit(plane, plane_state);
+   for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i)
+   mdp5_plane_complete_commit(plane, old_state, new_state);

mdp5_disable(mdp5_kms);
 }
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 03738927be10..90e80619fc54 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -198,7 +198,8 @@ void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
 uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
 void mdp5_plane_complete_flip(struct drm_plane *plane);
 void mdp5_plane_complete_commit(struct drm_plane *plane,
-   struct drm_plane_state *state);
+   struct drm_plane_state *old_state,
+   struct drm_plane_state *new_state);
 enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
 struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 951c002b05df..19c44b968f4e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -859,13 +859,13 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)

 /* called after vsync in thread context */
 void mdp5_plane_complete_commit(struct drm_plane *plane,
-   struct drm_plane_state *state)
+   struct drm_plane_state *old_state, struct drm_plane_state *new_state)
 {
struct mdp5_kms *mdp5_kms = get_kms(plane);
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
enum mdp5_pipe pipe = mdp5_plane->pipe;

-   if (!plane_enabled(plane->state) && mdp5_kms->smp) {
+   if (!plane_enabled(new_state) && mdp5_kms->smp) {
DBG("%s: free SMP", mdp5_plane->name);
mdp5_smp_release(mdp5_kms->smp, pipe);
}
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index db193f835298..333c379e6561 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -89,8 +89,8 @@ static void msm_atomic_wait_for_commit_done(struct drm_device 
*dev,
struct msm_kms *kms = priv->kms;
int i;

-   for_each_crtc_in_state(old_state, crtc, crtc_state, i) {
-   if (!crtc->state->enable)
+   for_each_new_crtc_in_state(old_state, crtc, crtc_state, i) {
+   if (!crtc_state->enable)
continue;

/* Legacy cursor ioctls are completely unsynced, and userspace
@@ -191,7 +191,7 @@ int msm_atomic_commit(struct drm_device *dev,
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *new_plane_state, *old_plane_state;
int i, ret;

ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -207,18 +207,18 @@ int msm_atomic_commit(struct drm_device *dev,
/*
 

[PATCH 11/19] drm/omap: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 1735c7accf72..74f9519878a2 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -69,13 +69,13 @@ struct omap_atomic_state_commit {
 static void omap_atomic_wait_for_completion(struct drm_device *dev,
struct drm_atomic_state *old_state)
 {
-   struct drm_crtc_state *old_crtc_state;
+   struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
unsigned int i;
int ret;

-   for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
-   if (!crtc->state->enable)
+   for_each_new_crtc_in_state(old_state, crtc, crtc_state, i) {
+   if (!crtc_state->enable)
continue;

ret = omap_crtc_wait_pending(crtc);
@@ -164,7 +164,7 @@ static int omap_atomic_commit(struct drm_device *dev,
/* Wait until all affected CRTCs have completed previous commits and
 * mark them as pending.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
commit->crtcs |= drm_crtc_mask(crtc);

wait_event(priv->commit.wait, !omap_atomic_is_pending(priv, commit));
-- 
2.7.4

[PATCH 10/19] drm/rcar-du: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index c76ed9ee6a01..153dafac753c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -312,7 +312,7 @@ static int rcar_du_atomic_commit(struct drm_device *dev,
/* Wait until all affected CRTCs have completed previous commits and
 * mark them as pending.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
commit->crtcs |= drm_crtc_mask(crtc);

spin_lock(&rcdu->commit.wait.lock);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index a74f8ed8ca2e..b8c35ad9db34 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -144,7 +144,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
struct drm_plane_state *drm_plane_state;

/* Check if hardware planes need to be reallocated. */
-   for_each_plane_in_state(state, drm_plane, drm_plane_state, i) {
+   for_each_new_plane_in_state(state, drm_plane, drm_plane_state, i) {
struct rcar_du_plane_state *plane_state;
struct rcar_du_plane *plane;
unsigned int index;
@@ -246,7 +246,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
}

/* Reallocate hardware planes for each plane that needs it. */
-   for_each_plane_in_state(state, drm_plane, drm_plane_state, i) {
+   for_each_new_plane_in_state(state, drm_plane, drm_plane_state, i) {
struct rcar_du_plane_state *plane_state;
struct rcar_du_plane *plane;
unsigned int crtc_planes;
-- 
2.7.4

[PATCH 09/19] drm/rockchip: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba305c488..5c0625e5dca1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1009,7 +1009,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
struct drm_atomic_state *old_state = old_crtc_state->state;
-   struct drm_plane_state *old_plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
struct vop *vop = to_vop(crtc);
struct drm_plane *plane;
int i;
@@ -1040,11 +1040,11 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
}
spin_unlock_irq(&crtc->dev->event_lock);

-   for_each_plane_in_state(old_state, plane, old_plane_state, i) {
+   for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
if (!old_plane_state->fb)
continue;

-   if (old_plane_state->fb == plane->state->fb)
+   if (old_plane_state->fb == new_plane_state->fb)
continue;

drm_framebuffer_reference(old_plane_state->fb);
-- 
2.7.4

[PATCH 08/19] drm/vc4: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index f31f72af8551..76cc9b374215 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -111,7 +111,7 @@ static int vc4_atomic_commit(struct drm_device *dev,
uint64_t wait_seqno = 0;
struct vc4_commit *c;
struct drm_plane *plane;
-   struct drm_plane_state *new_state;
+   struct drm_plane_state *old_state, *new_state;

c = commit_init(state);
if (!c)
@@ -139,8 +139,8 @@ static int vc4_atomic_commit(struct drm_device *dev,
return ret;
}

-   for_each_plane_in_state(state, plane, new_state, i) {
-   if ((plane->state->fb != new_state->fb) && new_state->fb) {
+   for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i) {
+   if (old_state->fb != new_state->fb && new_state->fb) {
struct drm_gem_cma_object *cma_bo =
drm_fb_cma_get_gem_obj(new_state->fb, 0);
struct vc4_bo *bo = to_vc4_bo(&cma_bo->base);
-- 
2.7.4