[Bug 98977] Regression on X-Plane on mesa-git

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

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

Bug ID: 98977
   Summary: Regression on X-Plane on mesa-git
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: amarildo-geral at autistici.org
QA Contact: dri-devel at lists.freedesktop.org

Just updated today and noticed a huge regression on X-Plane.
Mesa-git-87102.c45d84a works fine, but 87106.a7b510f causes the Sim frames to
drop to 10 at certain areas.

I don't know how to bisect a git product, unfortunately, and the weather here
in Brazil is hot and my processor would fry if I compiled for too long.
However, X-Plane offers a Free demo which you can try.

Downgraded to 87102.c45d84a for the time being.

Arch Linux
mesa-git
llvm-svn
Sapphire R9 270X
amdgpu Kernel driver (amd-staging-4.7)

-- 
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/20161202/be9596c3/attachment.html>

[Bug 98333] 4K @ 60Hz over HDMI 2.0 not working with AMDGPU-DAL

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

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

--- Comment #7 from John Bridgman  ---
The NVidia ticket suggests this might be an EDID issue, with the display saying
that it supports 4:2:2 at 4K/60 Hz when in fact it only supports 4:2:0.

Or could have been an NVidia driver bug that caused problems when modes for
both 4:2:2 and 4:2:0 were available, hard to say. Anyways, seems like if we can
get the driver to try 4:2:0 (possibly ignoring the monitor to do so) then it
should work at 60 Hz.

-- 
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/20161202/6d2e4fa7/attachment.html>

[Bug 98333] 4K @ 60Hz over HDMI 2.0 not working with AMDGPU-DAL

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

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

--- Comment #6 from Dillon Dixon  ---
I was reminded today that this TV is a bit strange in that 4K @ 60 Hz only
works with 4:2:0 chroma, while the common expectation would perhaps be 4:4:4.
Perhaps that can help lead to a solution?

-- 
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/20161202/4dca2ae8/attachment.html>

[PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Thierry Reding]

From: Thierry Reding 

Sinks that support SCDC can optionally have the capability to initiate
read requests, which are a mechanism by which a sink can notify its
source that it should read the Update Flags. If either the sink or the
source are not Read Request capable, polling of the Update Flags shall
be employed.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- new patch

 drivers/gpu/drm/drm_edid.c | 36 
 include/drm/drm_edid.h |  1 +
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 369961597ee5..8211cce3e09e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3736,6 +3736,42 @@ bool drm_detect_hdmi_scdc(struct edid *edid)
 EXPORT_SYMBOL(drm_detect_hdmi_scdc);

 /**
+ * drm_detect_hdmi_scdc_rr_capable - detect whether an HDMI sink is capable of
+ *initiating an SCDC Read Request
+ * @edid: sink EDID information
+ *
+ * Parse the CEA extension according to CEA-861-B to find an HF-VSDB as
+ * defined in HDMI 2.0, section 10.3.2 "HDMI Forum Vendor Specific Data
+ * Block" and checks if the RR_Capable bit (bit 6 of byte 6) is set.
+ *
+ * Returns:
+ * True if the sink is capable of initiating an SCDC Read Request, false
+ * otherwise.
+ */
+bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid)
+{
+   unsigned int start, end, i;
+   const u8 *cea;
+
+   cea = drm_find_cea_extension(edid);
+   if (!cea)
+   return false;
+
+   if (cea_db_offsets(cea, , ))
+   return false;
+
+   for_each_cea_db(cea, i, start, end) {
+   if (cea_db_is_hdmi_forum_vsdb([i])) {
+   if (cea[i + 6] & 0x40)
+   return true;
+   }
+   }
+
+   return false;
+}
+EXPORT_SYMBOL(drm_detect_hdmi_scdc_rr_capable);
+
+/**
  * drm_detect_monitor_audio - check monitor audio capability
  * @edid: EDID block to scan
  *
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 7ea7e90846d8..d1c29586035e 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -441,6 +441,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match);
 enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
 bool drm_detect_hdmi_monitor(struct edid *edid);
 bool drm_detect_hdmi_scdc(struct edid *edid);
+bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid);
 bool drm_detect_monitor_audio(struct edid *edid);
 bool drm_rgb_quant_range_selectable(struct edid *edid);
 int drm_add_modes_noedid(struct drm_connector *connector,
-- 
2.10.2

[PATCH v2 2/3] drm/edid: Implement SCDC support detection

[Thierry Reding]

From: Thierry Reding 

Sinks compliant with the HDMI 2.0 specification may support SCDC, a
mechanism for the source and the sink to communicate. Sinks advertise
support for this feature in the HDMI Forum Vendor Specific Data Block
as defined in the HDMI 2.0 specification, section 10.4 "Status and
Control Data Channel". Implement a small helper that find the HF-VSDB
and parses it to check if the sink supports SCDC.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- rename internal function to cea_db_is_hdmi_forum_vsdb() for more
  clarity (Ville Syrjälä)

 drivers/gpu/drm/drm_edid.c | 49 ++
 include/drm/drm_edid.h |  1 +
 include/linux/hdmi.h   |  1 +
 3 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 336be31ff3de..369961597ee5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3238,6 +3238,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
return hdmi_id == HDMI_IEEE_OUI;
 }

+static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
+{
+   unsigned int oui;
+
+   if (cea_db_tag(db) != VENDOR_BLOCK)
+   return false;
+
+   if (cea_db_payload_len(db) < 7)
+   return false;
+
+   oui = db[3] << 16 | db[2] << 8 | db[1];
+
+   return oui == HDMI_FORUM_IEEE_OUI;
+}
+
 #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)

@@ -3687,6 +3702,40 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
 EXPORT_SYMBOL(drm_detect_hdmi_monitor);

 /**
+ * drm_detect_hdmi_scdc - detect whether an HDMI sink supports SCDC
+ * @edid: sink EDID information
+ *
+ * Parse the CEA extension according to CEA-861-B to find an HF-VSDB as
+ * defined in HDMI 2.0, section 10.3.2 "HDMI Forum Vendor Specific Data
+ * Block" and checks if the SCDC_Present bit (bit 7 of byte 6) is set.
+ *
+ * Returns:
+ * True if the sink supports SCDC, false otherwise.
+ */
+bool drm_detect_hdmi_scdc(struct edid *edid)
+{
+   unsigned int start, end, i;
+   const u8 *cea;
+
+   cea = drm_find_cea_extension(edid);
+   if (!cea)
+   return false;
+
+   if (cea_db_offsets(cea, , ))
+   return false;
+
+   for_each_cea_db(cea, i, start, end) {
+   if (cea_db_is_hdmi_forum_vsdb([i])) {
+   if (cea[i + 6] & 0x80)
+   return true;
+   }
+   }
+
+   return false;
+}
+EXPORT_SYMBOL(drm_detect_hdmi_scdc);
+
+/**
  * drm_detect_monitor_audio - check monitor audio capability
  * @edid: EDID block to scan
  *
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 38eabf65f19d..7ea7e90846d8 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -440,6 +440,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid);
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
 enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
 bool drm_detect_hdmi_monitor(struct edid *edid);
+bool drm_detect_hdmi_scdc(struct edid *edid);
 bool drm_detect_monitor_audio(struct edid *edid);
 bool drm_rgb_quant_range_selectable(struct edid *edid);
 int drm_add_modes_noedid(struct drm_connector *connector,
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index edbb4fc674ed..d271ff23984f 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -35,6 +35,7 @@ enum hdmi_infoframe_type {
 };

 #define HDMI_IEEE_OUI 0x000c03
+#define HDMI_FORUM_IEEE_OUI 0xc45dd8
 #define HDMI_INFOFRAME_HEADER_SIZE  4
 #define HDMI_AVI_INFOFRAME_SIZE13
 #define HDMI_SPD_INFOFRAME_SIZE25
-- 
2.10.2

[PATCH v2 1/3] drm: Add SCDC helpers

[Thierry Reding]

From: Thierry Reding 

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- indent register field definitions for readability (Ville Syrjälä)
- use GFP_TEMPORARY for temporary buffer allocation (Jani Nikula)

 Documentation/gpu/drm-kms-helpers.rst |  12 
 drivers/gpu/drm/Kconfig   |   4 ++
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/drm_scdc_helper.c | 111 
 include/drm/drm_scdc_helper.h | 132 ++
 5 files changed, 260 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
 create mode 100644 include/drm/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa14fe8..759275629fcf 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:

+SCDC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :export:
+
 Rectangle Utilities Reference
 =

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95fc0410e129..d0031fe45bab 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -84,6 +84,10 @@ config DRM_FBDEV_EMULATION

  If in doubt, say "Y".

+config DRM_SCDC
+   bool
+   depends on DRM_KMS_HELPER
+
 config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
depends on DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 883f3e75cfbc..71c38b6dd546 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o

+drm_kms_helper-$(CONFIG_DRM_SCDC) += drm_scdc_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index ..fe0e1211e873
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+#include 
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * The number of bytes read from SCDC or a negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t 

[GIT PULL] etnaviv-next for 4.10

[Lucas Stach]

Hi Dave,

Not much news in etnaviv land this time around.

- fix dma-buf export path to return correct SG table
- trivially implement direct dma-buf mapping
- allow DRAW_INSTANCED commands in validator
- make the driver work on i.MX6SX, yielding a working 2D/3D stack
together with Mareks MXS DRM driver

Regards,
Lucas

The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -0700)

are available in the git repository at:

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

for you to fetch changes up to c4ae94a36c76a901149b24d297f7b9c7aad3eb89:

  MAINTAINERS: add etnaviv mailinglist (2016-12-02 19:30:25 +0100)


Lucas Stach (5):
      drm/etnaviv: implement dma-buf mmap
      drm/etnaviv: fix gem_prime_get_sg_table to return new SG table
      drm/etnaviv: don't invoke OOM killer from dump code
      drm/etnaviv: move linear window on MC1.0 parts if necessary
      MAINTAINERS: add etnaviv mailinglist

Wladimir J. van der Laan (1):
      drm/etnaviv: Allow DRAW_INSTANCED commands

 MAINTAINERS                                 
 |  1 +
 drivers/gpu/drm/etnaviv/cmdstream.xml.h      | 60 

 drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c        |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.h        |  2 ++
 drivers/gpu/drm/etnaviv/etnaviv_dump.c       |  3 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  | 19 +--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c        |  4 
 8 files changed, 84 insertions(+), 7 deletions(-)

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

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

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

Matt Turner  changed:

   What|Removed |Added

  Component|Drivers/DRI/i965|Drivers/DRI/i915
 QA Contact|intel-3d-bugs at lists.freedes |dri-devel at 
lists.freedesktop
   |ktop.org|.org
   Assignee|intel-3d-bugs at lists.freedes |dri-devel at 
lists.freedesktop
   |ktop.org|.org

--- Comment #5 from Matt Turner  ---
i915 is basically unmaintained.

If this is a regression and you can bisect it to find the commit that caused
it, someone might be able to fix it.

> Otherwise Chromium becomes a snail for rendering as it tries to use OpenGL 
> 2.1.

That is good feedback. I'll send a patch to revert the 2.1 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/20161202/374292f6/attachment.html>

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

[Laurent Pinchart]

Hi Russell,

On Friday 02 Dec 2016 16:08:17 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote:
> > DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that.
> > 
> > Do you know why this function needs to write to the HDMI_FC_INVIDCONF
> > register  four times in the normal case, and once only for IMX6DL ?
> 
> (I don't have much time at present, I'm buried in ARM64 crud trying to
> get a platform to boot, and working out how to debug an ARM64 platform
> that even earlycon doesn't work on... no printascii() types of easy
> debug facilities on ARM64 make this job several orders of magnitude
> harder than it needs to be...)

Thanks all the more for taking time to reply.

> It prevents a magenta line down the left hand side of the screen, which
> is caused when the frame composer in the HDMI Tx gets confused -
> according to the errata, it does a load of maths when you write to the
> frame composer registers, and sometimes it doesn't update properly.
> 
> So, the four writes (and the number is critical) is there to persuade
> the IP to do the maths with the right values so the internal timings
> are correct.
> 
> The rather confusing thing is - it's actually IMX6Q which has the more
> severe errata, not IMX6DL - the workaround of four writes is applied
> in the 6Q case.
> 
> It's covered by ERR004308 in the IMX6Q Errata document (search for
> IMX6DQCE).  It isn't mentioned in the IMX6DL documentation, but it
> seems that similar workaround of one write is necessary there.
> 
> Some of this was determined by experimentation in conjunction with the
> errata documentation - I remember it took a while to get it right so
> that we didn't ever see the magenta line.

That's interesting. I'll test the different options on my Renesas platform (no 
write, one write, four writes) and see what is needed. Could anyone perform 
the same tests on a Rockchip RK3288 system ?

-- 
Regards,

Laurent Pinchart

[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs

[Laurent Pinchart]

Hi Tomi,

On Friday 02 Dec 2016 17:55:10 Tomi Valkeinen wrote:
> On 02/12/16 17:42, Laurent Pinchart wrote:
> > I can understand that (even if I'm not sure it's really an issue, and we
> > should really clean up the CRTC creation code at some point), but how
> > about adding a possible_crtcs field to the priv structure then ? I don't
> > really like having to pass it around through a bunch of functions.
> 
> It is passed to two functions, I'm not sure if that's a bunch =).
> 
> I can do as you suggest, but I don't like adding fields to structs for
> things that we only need once.

I'm not too fond of that either, hence my first suggestion :-)

> I think local variables and function parameters are for that.
> 
> But I agree that the patch would be quite a bit smaller with the field,
> so...

I won't nack any solution you end up selecting even if I have my preferences.

-- 
Regards,

Laurent Pinchart

[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs

[Tomi Valkeinen]

On 02/12/16 17:42, Laurent Pinchart wrote:

> I can understand that (even if I'm not sure it's really an issue, and we 
> should really clean up the CRTC creation code at some point), but how about 
> adding a possible_crtcs field to the priv structure then ? I don't really 
> like 
> having to pass it around through a bunch of functions.

It is passed to two functions, I'm not sure if that's a bunch =).

I can do as you suggest, but I don't like adding fields to structs for
things that we only need once. I think local variables and function
parameters are for that.

But I agree that the patch would be quite a bit smaller with the field,
so...

 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/20161202/dd3a6a30/attachment.sig>

[PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

[Laurent Pinchart]

Hi Russell,

On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> > From: Kieran Bingham 
> > 
> > The current code hard codes the call of hdmi_phy_configure() to be 8bpp
> > and provides extraneous error checking to verify that this hardcoded
> > value is correct.
> > 
> > Simplify the passing of the data by setting the parameter to be of the
> > enum type it represents rather than converting and then verifying the
> > value. This will allow the compiler to check the value is acceptable
> > based on the type, and remove the dead code that we currently have.
> 
> I think you're expecting too much of the compiler there.  There's no
> requirement for the compiler to check that an enum type is passed one
> of it's defined values.

You're right.

Given that the current driver hardcodes the resolution value to 8bpp, how 
about just dropping the argument ? We can always add it back later if/when 
needed.

> Try building this and see if it even produces a warning:
> 
> enum foo {
>   FOO_1,
>   FOO_2,
> };
> 
> int func(enum foo foo)
> {
>   return foo;
> }
> 
> int test_1(void)
> {
>   return func(FOO_1);
> }
> 
> int test_2(void)
> {
>   return func(5);
> }

-- 
Regards,

Laurent Pinchart

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

[Laurent Pinchart]

Hi Russell,

On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
> > From: Kieran Bingham 
> > 
> > The dw-hdmi driver declares a dev_type to distinguish platform specific
> > changes. Replace this with a quirk field, so that the platform can
> > specify the required quirks for the driver, rather than the driver
> > becoming conditional on multiple platforms.
> > 
> > As part of this, we rename the dw-hdmi 'spare' which is defined as the
> > SVSRET bit in later documentation.
> 
> I'd really prefer that we did not go down the broken route of adding
> a set of "quirk" flags - look at what a mess SDHCI has become through
> allowing that kind of practice.
> 
> I'd much rather we find a saner structure to this - and we know that
> the hardware has ID registers in it which can be used (so far) to
> identify the buggy hardware.

I'd much prefer something that would allow runtime identification of the 
device and the corresponding actions to be taken. However, the amount of 
documentation we have on the DWC HDMI TX IP core (and the associated PHY) is 
pretty limited, given that Synopsys doesn't make the documentation available 
publicly. Changes made to the IP core by integrators could complicate this 
further. I'm trying to gather as much information as possible to make clean 
the code up, for instance by trying to identify the PHYs used on the various 
platforms we support. Progress is slow on that front, there isn't enough 
leaked information available online :-) I haven't given up though, but I'll 
need more time.

I don't like quirks much either. They are however already used today, even if 
we trigger them through dev_type instead of quirk flags. This patch came from 
a previous version found in a BSP that simply sprinkled several if (hdmi-
>dev_type == RCAR_HDMI) through the code. For instance,

-   if (hdmi->dev_type == RK3288_HDMI)
+   if (hdmi->dev_type == RK3288_HDMI || hdmi->dev_type == RCAR_HDMI)
dw_hdmi_phy_enable_spare(hdmi, 1);

which I think is worse than flags as it would quickly degenerate to spaghetti 
code.

For this specific case, we've managed to identify that on Renesas platforms 
the bit set by this function is called SVSRET. Its usage isn't clear yet, but 
I suspect it to control one of the PHY input control signals, like the other 
bits in the same register. I'm trying to get more information to clean the 
implementation further, hopefully with a way to determine whether the signal 
is used based on PHY identification.

This is all work in progress, and if anyone has access to any documentation 
and can provide additional information I'll be grateful.

> > Signed-off-by: Kieran Bingham 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/bridge/dw-hdmi.c| 14 ++
> >  drivers/gpu/drm/bridge/dw-hdmi.h|  4 ++--
> >  drivers/gpu/drm/imx/dw_hdmi-imx.c   |  3 +--
> >  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
> >  include/drm/bridge/dw_hdmi.h| 12 +---
> >  5 files changed, 15 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/dw-hdmi.c index 06a44a2cdf3b..26607185722f
> > 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> > @@ -118,7 +118,6 @@ struct dw_hdmi {
> > struct drm_bridge bridge;
> > struct platform_device *audio;
> > 
> > -   enum dw_hdmi_devtype dev_type;
> > struct device *dev;
> > struct clk *isfr_clk;
> > struct clk *iahb_clk;
> > @@ -896,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi
> > *hdmi, u8 enable)
> >  HDMI_PHY_CONF0_ENTMDS_MASK);
> >  }
> > 
> > -static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
> > +static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
> >  {
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> > -HDMI_PHY_CONF0_SPARECTRL_OFFSET,
> > -HDMI_PHY_CONF0_SPARECTRL_MASK);
> > +HDMI_PHY_CONF0_SVSRET_OFFSET,
> > +HDMI_PHY_CONF0_SVSRET_MASK);
> >  }
> >  
> >  static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > @@ -1031,8 +1030,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> > dw_hdmi_phy_gen2_txpwron(hdmi, 1);
> > dw_hdmi_phy_gen2_pddq(hdmi, 0);
> > 
> > -   if (hdmi->dev_type == RK3288_HDMI)
> > -   dw_hdmi_phy_enable_spare(hdmi, 1);
> > +   if (pdata->quirks & DW_HDMI_QUIRK_PHY_SVSRET)
> > +   dw_hdmi_phy_enable_svsret(hdmi, 1);
> 
> If we get a proper split between the encoder and the PHY, this should be
> dealt with at the PHY side of the driver.

That's possible, and some other 

[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs

[Laurent Pinchart]

Hi Tomi,

On Friday 02 Dec 2016 16:22:18 Tomi Valkeinen wrote:
> On 02/12/16 16:16, Laurent Pinchart wrote:
> > On Friday 02 Dec 2016 16:07:11 Tomi Valkeinen wrote:
> >> We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
> >> which is fine as the HW planes can be used fro all crtcs. However, when
> >> we're doing that, we are still incrementing 'num_crtcs', and we'll end
> >> up with bad possible_crtcs, preventing the use of the primary planes.
> >> 
> >> This patch passes a possible_crtcs mask to plane init function so that
> >> we get correct possible_crtc.
> >> 
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >> 
> >> v2: use correct possible_crtcs value
> >> 
> >>  drivers/gpu/drm/omapdrm/omap_drv.c   | 17 -
> >>  drivers/gpu/drm/omapdrm/omap_drv.h   |  3 ++-
> >>  drivers/gpu/drm/omapdrm/omap_plane.c |  6 +++---
> >>  3 files changed, 17 insertions(+), 9 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> >> b/drivers/gpu/drm/omapdrm/omap_drv.c index 39c5312b466c..fdc83cbcde61
> >> 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> >> @@ -267,13 +267,15 @@ static int omap_connect_dssdevs(void)
> >>  }
> >>  
> >>  static int omap_modeset_create_crtc(struct drm_device *dev, int id,
> >> -  enum omap_channel channel)
> >> +  enum omap_channel channel,
> >> +  u32 possible_crtcs)
> >>  {
> >>struct omap_drm_private *priv = dev->dev_private;
> >>struct drm_plane *plane;
> >>struct drm_crtc *crtc;
> >> 
> >> -  plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY);
> >> +  plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY,
> >> +  possible_crtcs);
> >>if (IS_ERR(plane))
> >>return PTR_ERR(plane);
> > 
> > If you removed the priv->num_crtcs++ a bit below in this function...
> > 
> >> @@ -309,6 +311,7 @@ static int omap_modeset_init(struct drm_device *dev)
> >>int num_crtcs;
> >>int i, id = 0;
> >>int ret;
> >> +  u32 possible_crtcs;
> >> 
> >>drm_mode_config_init(dev);
> >> 
> >> @@ -325,6 +328,7 @@ static int omap_modeset_init(struct drm_device *dev)
> >> * We use the num_crtc argument to limit the number of crtcs we
> >> create.
> >> */
> >>
> >>num_crtcs = min3(num_crtc, num_mgrs, num_ovls);
> > 
> > and assigned priv->num_crtcs here and replaced the channel_used() function
> > with a simple bitmask private to omap_modeset_init() you would end up with
> > a much simpler implementation that wouldn't require passing
> > possible_crtcs through a bunch of functions.
> 
> Yes, I almost did that.
> 
> But priv-num_crtcs tells the amount of crtcs in priv->crtcs. If we set
> priv->num_crtcs before actually creating those crtcs, I fear we could
> easily create a bug. The crtc+plane creation code is not the shortest
> one, so even if we wouldn't have a bug right now, I imagine it could be
> easy to write a helper func or such later, which uses priv->num_crtcs,
> and which gets called at some point when creating crtcs and planes...
> 
> So I went the safe way.

I can understand that (even if I'm not sure it's really an issue, and we 
should really clean up the CRTC creation code at some point), but how about 
adding a possible_crtcs field to the priv structure then ? I don't really like 
having to pass it around through a bunch of functions.

-- 
Regards,

Laurent Pinchart

[Bug 98975] Wasteland 2 Directors Cut: Hangs. GPU fault

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

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

Bug ID: 98975
   Summary: Wasteland 2 Directors Cut: Hangs. GPU fault
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: sa at whiz.se
QA Contact: dri-devel at lists.freedesktop.org

I'm having trouble with the game Wasteland 2 Directors Cut.

It sporadically freezes (most often when loading new areas) sometimes right
away after starting a new game sometimes after several hours of gameplay. 

I'm getting a massive log of VM fault, GPU_fault_detected as soon as the game
is launched.

#98183 and #98619 seems similar.

Probably not a regression, it's present with 4.7.0 and Mesa 12.

I also tried recording with apitrace, the trace itself doesn't seem to trigger
the VM fault stuff, but I do get these warnings:


809169: message: major shader compiler issue 29: 0:14(18): warning: `tmpvar_1'
used uninitialized
809169 @1 glCompileShaderARB(shaderObj = 1243)
809169: warning: 0:14(18): warning: `tmpvar_1' used uninitialized

809961: message: shader compiler issue 1: Shader Stats: SGPRS: 80 VGPRS: 16
Code Size: 92 LDS: 0 Scratch: 0 Max Waves: 10 Spilled SGPRs: 0 Spilled VGPRs: 0

System environment:
-- system architecture: 64-bit
-- Linux distribution: Debian unstable
-- GPU: TONGA
-- Model: Asus Strix R9 285 2GB
-- Display connector: DVI
-- xf86-video-amdgpu: 1.2.0
-- xserver: 1.19.0
-- mesa: c45d84ad8349d0c69893458d6c58eb5f6f1609c4
-- drm: 2.4.74
-- kernel: 4.8.0
-- dri3

dmesg:
[  409.259720] VM fault (0x04, vmid 1) at page 1653855, read from 'TC7'
(0x54433700) (68)
[  409.259722] amdgpu :01:00.0: GPU fault detected: 146 0x03188404
[  409.259723] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00193C5B
[  409.259724] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02048004
[  409.259724] VM fault (0x04, vmid 1) at page 1653851, read from 'TC6'
(0x54433600) (72)
[  409.259727] amdgpu :01:00.0: GPU fault detected: 146 0x03188004
[  409.259727] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00193C57
[  409.259728] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02048004
[  409.259729] VM fault (0x04, vmid 1) at page 1653847, read from 'TC6'
(0x54433600) (72)
[  409.259731] amdgpu :01:00.0: GPU fault detected: 146 0x0318c404
[  409.259732] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00193C53
[  409.259732] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02084004
[  409.259733] VM fault (0x04, vmid 1) at page 1653843, read from 'TC10'
(0x54433130) (132)
[  409.259735] amdgpu :01:00.0: GPU fault detected: 146 0x03384004
[  409.259736] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00193C53
[  409.259737] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02044004
[  409.259737] VM fault (0x04, vmid 1) at page 1653843, read from 'TC7'
(0x54433700) (68)
[  409.259739] amdgpu :01:00.0: GPU fault detected: 146 0x03384804
[  409.259740] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00193C4B
[  409.259741] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02004004
[  409.259741] VM fault (0x04, vmid 1) at page 1653835, read from 'TC1'
(0x54433100) (4)
[  409.259743] amdgpu :01:00.0: GPU fault detected: 146 0x03180004
[  409.259744] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00193C4B
[  409.259745] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02084004
[  409.259745] VM fault (0x04, vmid 1) at page 1653835, read from 'TC10'
(0x54433130) (132)

-- 
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/20161202/24332e18/attachment.html>

[Bug 98974] Can't see borders/empires in Stellaris

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

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

Bug ID: 98974
   Summary: Can't see borders/empires in Stellaris
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: lukas.fuernkranz+bugzilla2 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

I'm using Ubuntu 16.04 and an AMD Radeon 6870 with the drivers from
https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers.

In Stellaris (a video game) I can't see the borders/empires on the map.  Unless
I set the graphics quality to low that is.

(Temporarily I used an AMD R9 270x---also with the drivers from the oibaf PPA;
radeonsi though---and there I didn't have that problem.)

In case more infos are needed please say so and I'll do my best to provide it.

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

[Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status

[Daniel Vetter]

On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduced, but we can't reduce
> the link below the requirements of the mode. Black screen follows.
> 
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would
> also conflict with the idea of making setcrtc asynchronous in the
> future, returning before the actual mode setting and link training.
> 
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on
> practical not theoretical capabilities. However, the changes for link
> training are pretty drastic, all for the sake of error handling and
> DP compliance, when the most common happy day scenario is the current
> approach of link training at mode setting time, using the optimal
> parameters for the mode. It is also not certain all hardware could do
> this without the pipe on; not even all our hardware can do this. Some
> of this can be solved, but not trivially.
> 
> Both of the above ideas also fail to address link degradation *during*
> operation.
> 
> The solution is to add a new "link-status" connector property in order
> to address link training failure in a way that:
> a) changes the current happy day scenario as little as possible, to
> avoid regressions, b) can be implemented the same way by all drm
> drivers, c) is still opt-in for the drivers and userspace, and opting
> out doesn't regress the user experience, d) doesn't prevent drivers
> from implementing better or alternate approaches, possibly without
> userspace involvement. And, of course, handles all the issues presented.
> In the usual happy day scenario, this is always "good". If something
> fails during or after a mode set, the kernel driver can set the link
> status to "bad" and issue a hotplug uevent for userspace to have it
> re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> again. If the theoretical capabilities of the link can't be reached,
> the mode list is trimmed based on that.
> 
> v4:
> * Add comments in kernel-doc format (Daniel Vetter)
> * Update the kernel-doc for link-status (Sean Paul)
> v3:
> * Fixed a build error (Jani Saarinen)
> v2:
> * Removed connector->link_status (Daniel Vetter)
> * Set connector->state->link_status in 
> drm_mode_connector_set_link_status_property
> (Daniel Vetter)
> * Set the connector_changed flag to true if connector->state->link_status 
> changed.
> * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
> 
> Acked-by: Tony Cheng 
> Acked-by: Harry Wentland 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Chris Wilson 
> Cc: Sean Paul 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_atomic.c| 10 +++
>  drivers/gpu/drm/drm_atomic_helper.c |  8 ++
>  drivers/gpu/drm/drm_connector.c | 54 
> -
>  include/drm/drm_connector.h | 19 +
>  include/drm/drm_mode_config.h   |  5 
>  include/uapi/drm/drm_mode.h |  4 +++
>  6 files changed, 99 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 89737e4..990f013 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>* now?) atomic writes to DPMS property:
>*/
>   return -EINVAL;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request here,
> +  * only hw issues can do that.
> +  */
> + if (state->link_status == DRM_LINK_STATUS_GOOD)
> + return 0;
> + state->link_status = val;
> + return 0;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct 
> drm_printer *p,
>   *val = (state->crtc) ? state->crtc->base.id : 0;
>   } else if (property == config->dpms_property) {
>   *val = connector->dpms;
> + } else if (property == config->link_status_property) {
> + *val = state->link_status;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git 

[PATCH libdrm 5/5] tests/drmdevice: use drmGetDevice[s]2

[Emil Velikov]

From: Emil Velikov 

Pass along DRM_DEVICE_GET_PCI_REVISION only when the individual nodes
are opened and update the printed messages accordingly.

v2: Attribute for the flag rename, call drmGetDevices2 w/o the flag.

Signed-off-by: Emil Velikov 
Reviewed-by: Michel Dänzer 
---
 tests/drmdevice.c | 23 ++-
 xf86drm.c |  2 +-
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/tests/drmdevice.c b/tests/drmdevice.c
index 72e7066..8c4f091 100644
--- a/tests/drmdevice.c
+++ b/tests/drmdevice.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +33,7 @@


 static void
-print_device_info(drmDevicePtr device, int i)
+print_device_info(drmDevicePtr device, int i, bool print_revision)
 {
 printf("device[%i]\n", i);
 printf("\tavailable_nodes %04x\n", device->available_nodes);
@@ -56,7 +57,11 @@ print_device_info(drmDevicePtr device, int i)
 printf("\t\t\tdevice_id\t%04x\n", device->deviceinfo.pci->device_id);
 printf("\t\t\tsubvendor_id\t%04x\n", 
device->deviceinfo.pci->subvendor_id);
 printf("\t\t\tsubdevice_id\t%04x\n", 
device->deviceinfo.pci->subdevice_id);
-printf("\t\t\trevision_id\t%02x\n", 
device->deviceinfo.pci->revision_id);
+if (print_revision)
+printf("\t\t\trevision_id\t%02x\n", 
device->deviceinfo.pci->revision_id);
+else
+printf("\t\t\trevision_id\tIGNORED\n");
+
 } else {
 printf("Unknown/unhandled bustype\n");
 }
@@ -70,10 +75,10 @@ main(void)
 drmDevicePtr device;
 int fd, ret, max_devices;

-max_devices = drmGetDevices(NULL, 0);
+max_devices = drmGetDevices2(0, NULL, 0);

 if (max_devices <= 0) {
-printf("drmGetDevices() has returned %d\n", max_devices);
+printf("drmGetDevices2() has returned %d\n", max_devices);
 return -1;
 }

@@ -83,15 +88,15 @@ main(void)
 return -1;
 }

-ret = drmGetDevices(devices, max_devices);
+ret = drmGetDevices2(0, devices, max_devices);
 if (ret < 0) {
-printf("drmGetDevices() returned an error %d\n", ret);
+printf("drmGetDevices2() returned an error %d\n", ret);
 free(devices);
 return -1;
 }

 for (int i = 0; i < ret; i++) {
-print_device_info(devices[i], i);
+print_device_info(devices[i], i, false);

 for (int j = 0; j < DRM_NODE_MAX; j++) {
 if (devices[i]->available_nodes & 1 << j) {
@@ -102,8 +107,8 @@ main(void)
 continue;
 }

-if (drmGetDevice(fd, ) == 0) {
-print_device_info(device, i);
+if (drmGetDevice2(fd, DRM_DEVICE_GET_PCI_REVISION, ) == 
0) {
+print_device_info(device, i, true);
 drmFreeDevice();
 }
 close(fd);
diff --git a/xf86drm.c b/xf86drm.c
index 52e9b9f..a886768 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3019,7 +3019,7 @@ static int drmParsePciDeviceInfo(int maj, int min,
  uint32_t flags)
 {
 #ifdef __linux__
-if (flags & DRM_DEVICE_GET_PCI_REVISION == 0)
+if (!(flags & DRM_DEVICE_GET_PCI_REVISION))
 return parse_separate_sysfs_files(maj, min, device, true);

 if (parse_separate_sysfs_files(maj, min, device, false))
-- 
2.10.2

[PATCH libdrm 4/5] xf86drm: introduce drmGetDevice[s]2

[Emil Velikov]

From: Emil Velikov 

Relative to the original version, here one can provide a flags bitmask.
Currently only DRM_DEVICE_IGNORE_PCI_REVISION is supported.

Implementation detail:
If it's set, we will only parse the separate sysfs files and we won't
touch the config one. The latter awakes the device (causing delays)
which is the core reason why this API was introduced.

v2:
 - Initialize revision to 0xff if it's unread.
 - Change DRM_DEVICE_IGNORE_PCI_REVISION to DRM_DEVICE_GET_PCI_REVISION
 - Add explicit note that drmGetDevice[s]2 does not retrieve the
revision by default.

Cc: Michel Dänzer 
Cc: Nicolai Hähnle 
Cc: Mauro Santos 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Signed-off-by: Emil Velikov 
Reviewed-by: Michel Dänzer 
---
 xf86drm.c | 70 +++
 xf86drm.h |  4 
 2 files changed, 66 insertions(+), 8 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 701cf29..52e9b9f 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2948,7 +2948,8 @@ static int drmGetMaxNodeName(void)

 #ifdef __linux__
 static int parse_separate_sysfs_files(int maj, int min,
-  drmPciDeviceInfoPtr device)
+  drmPciDeviceInfoPtr device,
+  bool ignore_revision)
 {
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
 static const char *attrs[] = {
@@ -2963,7 +2964,7 @@ static int parse_separate_sysfs_files(int maj, int min,
 FILE *fp;
 int ret;

-for (unsigned i = 0; i < ARRAY_SIZE(attrs); i++) {
+for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) {
 snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device/%s", maj, min,
  attrs[i]);
 fp = fopen(path, "r");
@@ -2977,7 +2978,7 @@ static int parse_separate_sysfs_files(int maj, int min,

 }

-device->revision_id = data[0] & 0xff;
+device->revision_id = ignore_revision ? 0xff : data[0] & 0xff;
 device->vendor_id = data[1] & 0x;
 device->device_id = data[2] & 0x;
 device->subvendor_id = data[3] & 0x;
@@ -3018,7 +3019,10 @@ static int drmParsePciDeviceInfo(int maj, int min,
  uint32_t flags)
 {
 #ifdef __linux__
-if (parse_separate_sysfs_files(maj, min, device))
+if (flags & DRM_DEVICE_GET_PCI_REVISION == 0)
+return parse_separate_sysfs_files(maj, min, device, true);
+
+if (parse_separate_sysfs_files(maj, min, device, false))
 return parse_config_sysfs_file(maj, min, device);

 return 0;
@@ -3125,16 +3129,27 @@ static void drmFoldDuplicatedDevices(drmDevicePtr 
local_devices[], int count)
 }
 }

+/* Check that the given flags are valid returning 0 on success */
+static int
+drm_device_validate_flags(uint32_t flags)
+{
+return (flags & ~DRM_DEVICE_GET_PCI_REVISION);
+}
+
 /**
  * Get information about the opened drm device
  *
  * \param fd file descriptor of the drm device
+ * \param flags feature/behaviour bitmask
  * \param device the address of a drmDevicePtr where the information
  *   will be allocated in stored
  *
  * \return zero on success, negative error code otherwise.
+ *
+ * \note Unlike drmGetDevice it does not retrieve the pci device revision field
+ * unless the DRM_DEVICE_GET_PCI_REVISION \p flag is set.
  */
-int drmGetDevice(int fd, drmDevicePtr *device)
+int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr *device)
 {
 drmDevicePtr *local_devices;
 drmDevicePtr d;
@@ -3147,7 +3162,9 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 int ret, i, node_count;
 int max_count = 16;
 dev_t find_rdev;
-uint32_t flags = 0;
+
+if (drm_device_validate_flags(flags))
+return -EINVAL;

 if (fd == -1 || device == NULL)
 return -EINVAL;
@@ -3246,8 +3263,23 @@ free_locals:
 }

 /**
+ * Get information about the opened drm device
+ *
+ * \param fd file descriptor of the drm device
+ * \param device the address of a drmDevicePtr where the information
+ *   will be allocated in stored
+ *
+ * \return zero on success, negative error code otherwise.
+ */
+int drmGetDevice(int fd, drmDevicePtr *device)
+{
+return drmGetDevice2(fd, DRM_DEVICE_GET_PCI_REVISION, device);
+}
+
+/**
  * Get drm devices on the system
  *
+ * \param flags feature/behaviour bitmask
  * \param devices the array of devices with drmDevicePtr elements
  *can be NULL to get the device number first
  * \param max_devices the maximum number of devices for the array
@@ -3256,8 +3288,11 @@ free_locals:
  * if devices is NULL - total number of devices available on the 
system,
  * alternatively the number of devices stored in devices[], which is
  * capped by the max_devices.
+ *
+ * \note Unlike drmGetDevices it does not retrieve the pci device revision 
field
+ * unless the DRM_DEVICE_GET_PCI_REVISION \p flag is set.
  

[PATCH libdrm 3/5] xf86drm: parse the separate sysfs files for vendor... info

[Emil Velikov]

From: Emil Velikov 

Up-to recently (patch should land in 4.10) the kernel did not expose the
PCI device revision field as a separate sysfs file.

Thus one needed too parse the config file to retrieve it. This in
itself wakes up the device, which in some cases can be quite slow.

To avoid that, just check for the separate files and fall-back to the
original if kernel is not new enough.

v3: rework alongside drmGetDevice[s]2

Cc: Michel Dänzer 
Cc: Nicolai Hähnle 
Cc: Mauro Santos 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Signed-off-by: Emil Velikov 
Reviewed-by: Michel Dänzer 
---
 xf86drm.c | 58 ++
 1 file changed, 54 insertions(+), 4 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index ddb8f9f..701cf29 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2946,11 +2946,49 @@ static int drmGetMaxNodeName(void)
3 /* length of the node number */;
 }

-static int drmParsePciDeviceInfo(int maj, int min,
- drmPciDeviceInfoPtr device,
- uint32_t flags)
-{
 #ifdef __linux__
+static int parse_separate_sysfs_files(int maj, int min,
+  drmPciDeviceInfoPtr device)
+{
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
+static const char *attrs[] = {
+  "revision", /* Older kernels are missing the file, so check for it first 
*/
+  "vendor",
+  "device",
+  "subsystem_vendor",
+  "subsystem_device",
+};
+char path[PATH_MAX + 1];
+unsigned int data[ARRAY_SIZE(attrs)];
+FILE *fp;
+int ret;
+
+for (unsigned i = 0; i < ARRAY_SIZE(attrs); i++) {
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device/%s", maj, min,
+ attrs[i]);
+fp = fopen(path, "r");
+if (!fp)
+return -errno;
+
+ret = fscanf(fp, "%x", [i]);
+fclose(fp);
+if (ret != 1)
+return -errno;
+
+}
+
+device->revision_id = data[0] & 0xff;
+device->vendor_id = data[1] & 0x;
+device->device_id = data[2] & 0x;
+device->subvendor_id = data[3] & 0x;
+device->subdevice_id = data[4] & 0x;
+
+return 0;
+}
+
+static int parse_config_sysfs_file(int maj, int min,
+   drmPciDeviceInfoPtr device)
+{
 char path[PATH_MAX + 1];
 unsigned char config[64];
 int fd, ret;
@@ -2972,6 +3010,18 @@ static int drmParsePciDeviceInfo(int maj, int min,
 device->subdevice_id = config[46] | (config[47] << 8);

 return 0;
+}
+#endif
+
+static int drmParsePciDeviceInfo(int maj, int min,
+ drmPciDeviceInfoPtr device,
+ uint32_t flags)
+{
+#ifdef __linux__
+if (parse_separate_sysfs_files(maj, min, device))
+return parse_config_sysfs_file(maj, min, device);
+
+return 0;
 #else
 #warning "Missing implementation of drmParsePciDeviceInfo"
 return -EINVAL;
-- 
2.10.2

[PATCH libdrm 2/5] xf86drm: add plumbing to not retrieve PCI device revision

[Emil Velikov]

From: Emil Velikov 

Will be used with the drmGetDevice[s]2 API.

Cc: Michel Dänzer 
Cc: Nicolai Hähnle 
Cc: Mauro Santos 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Signed-off-by: Emil Velikov 
---
 xf86drm.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index c788c93..ddb8f9f 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2947,7 +2947,8 @@ static int drmGetMaxNodeName(void)
 }

 static int drmParsePciDeviceInfo(int maj, int min,
- drmPciDeviceInfoPtr device)
+ drmPciDeviceInfoPtr device,
+ uint32_t flags)
 {
 #ifdef __linux__
 char path[PATH_MAX + 1];
@@ -3000,7 +3001,8 @@ void drmFreeDevices(drmDevicePtr devices[], int count)

 static int drmProcessPciDevice(drmDevicePtr *device,
const char *node, int node_type,
-   int maj, int min, bool fetch_deviceinfo)
+   int maj, int min, bool fetch_deviceinfo,
+   uint32_t flags)
 {
 const int max_node_str = ALIGN(drmGetMaxNodeName(), sizeof(void *));
 int ret, i;
@@ -3039,7 +3041,7 @@ static int drmProcessPciDevice(drmDevicePtr *device,
 addr += sizeof(drmPciBusInfo);
 (*device)->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;

-ret = drmParsePciDeviceInfo(maj, min, (*device)->deviceinfo.pci);
+ret = drmParsePciDeviceInfo(maj, min, (*device)->deviceinfo.pci, 
flags);
 if (ret)
 goto free_device;
 }
@@ -3095,6 +3097,7 @@ int drmGetDevice(int fd, drmDevicePtr *device)
 int ret, i, node_count;
 int max_count = 16;
 dev_t find_rdev;
+uint32_t flags = 0;

 if (fd == -1 || device == NULL)
 return -EINVAL;
@@ -3142,7 +3145,7 @@ int drmGetDevice(int fd, drmDevicePtr *device)

 switch (subsystem_type) {
 case DRM_BUS_PCI:
-ret = drmProcessPciDevice(, node, node_type, maj, min, true);
+ret = drmProcessPciDevice(, node, node_type, maj, min, true, 
flags);
 if (ret)
 goto free_devices;

@@ -3216,6 +3219,7 @@ int drmGetDevices(drmDevicePtr devices[], int max_devices)
 int maj, min;
 int ret, i, node_count, device_count;
 int max_count = 16;
+uint32_t flags = 0;

 local_devices = calloc(max_count, sizeof(drmDevicePtr));
 if (local_devices == NULL)
@@ -3251,7 +3255,7 @@ int drmGetDevices(drmDevicePtr devices[], int max_devices)
 switch (subsystem_type) {
 case DRM_BUS_PCI:
 ret = drmProcessPciDevice(, node, node_type,
-  maj, min, devices != NULL);
+  maj, min, devices != NULL, flags);
 if (ret)
 goto free_devices;

-- 
2.10.2

[PATCH libdrm 1/5] xf86drm: use maj/min in drmParsePciDeviceInfo()

[Emil Velikov]

From: Emil Velikov 

Be consistent with drmParsePciBusInfo() and use solely the device
major/minor pair.

Cc: Jonathan Gray 
Signed-off-by: Emil Velikov 
---
Jonathan, please respin your patches on top of this series.
---
 xf86drm.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index ed924a7..c788c93 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2946,7 +2946,7 @@ static int drmGetMaxNodeName(void)
3 /* length of the node number */;
 }

-static int drmParsePciDeviceInfo(const char *d_name,
+static int drmParsePciDeviceInfo(int maj, int min,
  drmPciDeviceInfoPtr device)
 {
 #ifdef __linux__
@@ -2954,7 +2954,7 @@ static int drmParsePciDeviceInfo(const char *d_name,
 unsigned char config[64];
 int fd, ret;

-snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/config", d_name);
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device/config", maj, min);
 fd = open(path, O_RDONLY);
 if (fd < 0)
 return -errno;
@@ -2998,7 +2998,7 @@ void drmFreeDevices(drmDevicePtr devices[], int count)
 drmFreeDevice([i]);
 }

-static int drmProcessPciDevice(drmDevicePtr *device, const char *d_name,
+static int drmProcessPciDevice(drmDevicePtr *device,
const char *node, int node_type,
int maj, int min, bool fetch_deviceinfo)
 {
@@ -3039,7 +3039,7 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
const char *d_name,
 addr += sizeof(drmPciBusInfo);
 (*device)->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;

-ret = drmParsePciDeviceInfo(d_name, (*device)->deviceinfo.pci);
+ret = drmParsePciDeviceInfo(maj, min, (*device)->deviceinfo.pci);
 if (ret)
 goto free_device;
 }
@@ -3142,8 +3142,7 @@ int drmGetDevice(int fd, drmDevicePtr *device)

 switch (subsystem_type) {
 case DRM_BUS_PCI:
-ret = drmProcessPciDevice(, dent->d_name, node, node_type,
-  maj, min, true);
+ret = drmProcessPciDevice(, node, node_type, maj, min, true);
 if (ret)
 goto free_devices;

@@ -3251,7 +3250,7 @@ int drmGetDevices(drmDevicePtr devices[], int max_devices)

 switch (subsystem_type) {
 case DRM_BUS_PCI:
-ret = drmProcessPciDevice(, dent->d_name, node, node_type,
+ret = drmProcessPciDevice(, node, node_type,
   maj, min, devices != NULL);
 if (ret)
 goto free_devices;
-- 
2.10.2

[Bug 189451] UVD not responding with Mobility Radeon HD 5650

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

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

--- Comment #2 from Raffaele  ---
HI,
I don't know if it worked. I didn't really used linux until recentely

The PC boots and work as expected.

But i think it slows down boot time (I discovered it while trying to reduce
boot time) and I cannot use hardware accelerated video decoding, can I?

What can I do to provide further information to you about my hardware and about
my error?

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

[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs

[Tomi Valkeinen]

On 02/12/16 16:16, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Friday 02 Dec 2016 16:07:11 Tomi Valkeinen wrote:
>> We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
>> which is fine as the HW planes can be used fro all crtcs. However, when
>> we're doing that, we are still incrementing 'num_crtcs', and we'll end
>> up with bad possible_crtcs, preventing the use of the primary planes.
>>
>> This patch passes a possible_crtcs mask to plane init function so that
>> we get correct possible_crtc.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>
>> v2: use correct possible_crtcs value
>>
>>  drivers/gpu/drm/omapdrm/omap_drv.c   | 17 -
>>  drivers/gpu/drm/omapdrm/omap_drv.h   |  3 ++-
>>  drivers/gpu/drm/omapdrm/omap_plane.c |  6 +++---
>>  3 files changed, 17 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>> b/drivers/gpu/drm/omapdrm/omap_drv.c index 39c5312b466c..fdc83cbcde61
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> @@ -267,13 +267,15 @@ static int omap_connect_dssdevs(void)
>>  }
>>
>>  static int omap_modeset_create_crtc(struct drm_device *dev, int id,
>> -enum omap_channel channel)
>> +enum omap_channel channel,
>> +u32 possible_crtcs)
>>  {
>>  struct omap_drm_private *priv = dev->dev_private;
>>  struct drm_plane *plane;
>>  struct drm_crtc *crtc;
>>
>> -plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY);
>> +plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY,
>> +possible_crtcs);
>>  if (IS_ERR(plane))
>>  return PTR_ERR(plane);
> 
> If you removed the priv->num_crtcs++ a bit below in this function...
> 
>> @@ -309,6 +311,7 @@ static int omap_modeset_init(struct drm_device *dev)
>>  int num_crtcs;
>>  int i, id = 0;
>>  int ret;
>> +u32 possible_crtcs;
>>
>>  drm_mode_config_init(dev);
>>
>> @@ -325,6 +328,7 @@ static int omap_modeset_init(struct drm_device *dev)
>>   * We use the num_crtc argument to limit the number of crtcs we 
> create.
>>   */
>>  num_crtcs = min3(num_crtc, num_mgrs, num_ovls);
> 
> and assigned priv->num_crtcs here and replaced the channel_used() function 
> with a simple bitmask private to omap_modeset_init() you would end up with a 
> much simpler implementation that wouldn't require passing possible_crtcs 
> through a bunch of functions.

Yes, I almost did that.

But priv-num_crtcs tells the amount of crtcs in priv->crtcs. If we set
priv->num_crtcs before actually creating those crtcs, I fear we could
easily create a bug. The crtc+plane creation code is not the shortest
one, so even if we wouldn't have a bug right now, I imagine it could be
easy to write a helper func or such later, which uses priv->num_crtcs,
and which gets called at some point when creating crtcs and planes...

So I went the safe way.

 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/20161202/b0084dd5/attachment.sig>

[Bug 98578] AMDGPU white glitches in some games

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

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

Nicolai Hähnle  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #10 from Nicolai Hähnle  ---
Fixed in LLVM trunk r288506.

-- 
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/20161202/e7d2d9fb/attachment.html>

[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Friday 02 Dec 2016 16:07:11 Tomi Valkeinen wrote:
> We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
> which is fine as the HW planes can be used fro all crtcs. However, when
> we're doing that, we are still incrementing 'num_crtcs', and we'll end
> up with bad possible_crtcs, preventing the use of the primary planes.
> 
> This patch passes a possible_crtcs mask to plane init function so that
> we get correct possible_crtc.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
> 
> v2: use correct possible_crtcs value
> 
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 17 -
>  drivers/gpu/drm/omapdrm/omap_drv.h   |  3 ++-
>  drivers/gpu/drm/omapdrm/omap_plane.c |  6 +++---
>  3 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 39c5312b466c..fdc83cbcde61
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -267,13 +267,15 @@ static int omap_connect_dssdevs(void)
>  }
> 
>  static int omap_modeset_create_crtc(struct drm_device *dev, int id,
> - enum omap_channel channel)
> + enum omap_channel channel,
> + u32 possible_crtcs)
>  {
>   struct omap_drm_private *priv = dev->dev_private;
>   struct drm_plane *plane;
>   struct drm_crtc *crtc;
> 
> - plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY);
> + plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY,
> + possible_crtcs);
>   if (IS_ERR(plane))
>   return PTR_ERR(plane);

If you removed the priv->num_crtcs++ a bit below in this function...

> @@ -309,6 +311,7 @@ static int omap_modeset_init(struct drm_device *dev)
>   int num_crtcs;
>   int i, id = 0;
>   int ret;
> + u32 possible_crtcs;
> 
>   drm_mode_config_init(dev);
> 
> @@ -325,6 +328,7 @@ static int omap_modeset_init(struct drm_device *dev)
>* We use the num_crtc argument to limit the number of crtcs we 
create.
>*/
>   num_crtcs = min3(num_crtc, num_mgrs, num_ovls);

and assigned priv->num_crtcs here and replaced the channel_used() function 
with a simple bitmask private to omap_modeset_init() you would end up with a 
much simpler implementation that wouldn't require passing possible_crtcs 
through a bunch of functions.

> + possible_crtcs = (1 << num_crtcs) - 1;
> 
>   dssdev = NULL;
> 
> @@ -388,7 +392,8 @@ static int omap_modeset_init(struct drm_device *dev)
>* allocated crtc, we create a new crtc for it
>*/
>   if (!channel_used(dev, channel)) {
> - ret = omap_modeset_create_crtc(dev, id, channel);
> + ret = omap_modeset_create_crtc(dev, id, channel,
> + possible_crtcs);
>   if (ret < 0) {
>   dev_err(dev->dev,
>   "could not create CRTC (channel 
%u)\n",
> @@ -418,7 +423,8 @@ static int omap_modeset_init(struct drm_device *dev)
>   return -ENOMEM;
>   }
> 
> - ret = omap_modeset_create_crtc(dev, id, i);
> + ret = omap_modeset_create_crtc(dev, id, i,
> + possible_crtcs);
>   if (ret < 0) {
>   dev_err(dev->dev,
>   "could not create CRTC (channel %u)\n", i);
> @@ -432,7 +438,8 @@ static int omap_modeset_init(struct drm_device *dev)
>   for (; id < num_ovls; id++) {
>   struct drm_plane *plane;
> 
> - plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_OVERLAY);
> + plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_OVERLAY,
> + possible_crtcs);
>   if (IS_ERR(plane))
>   return PTR_ERR(plane);
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h index 4c51135eb9a6..7d9dd5400cef
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -157,7 +157,8 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>  int omap_crtc_wait_pending(struct drm_crtc *crtc);
> 
>  struct drm_plane *omap_plane_init(struct drm_device *dev,
> - int id, enum drm_plane_type type);
> + int id, enum drm_plane_type type,
> + u32 possible_crtcs);
>  void omap_plane_install_properties(struct drm_plane *plane,
>   struct drm_mode_object *obj);
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c index 9c43cb481e62..82b2c23d6769
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -356,9 +356,9 @@ static const uint32_t error_irqs[] = {
> 
>  /* initialize plane */
>  struct drm_plane 

[PATCH 1/2] drm: fix possible_crtc's type

[Ville Syrjälä]

On Fri, Dec 02, 2016 at 04:07:10PM +0200, Tomi Valkeinen wrote:
> drm_universal_plane_init() and drm_plane_init() take "unsigned long
> possible_crtcs" parameter, but then stuff it into uint32_t. Change the
> parameter to uint32_t.
> 
> Signed-off-by: Tomi Valkeinen 
> Cc: Ville Syrjälä 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_plane.c | 4 ++--
>  include/drm/drm_plane.h | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 419ac313c36f..3bf9276f5bcf 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -79,7 +79,7 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>   * Zero on success, error code on failure.
>   */
>  int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> -  unsigned long possible_crtcs,
> +  uint32_t possible_crtcs,
>const struct drm_plane_funcs *funcs,
>const uint32_t *formats, unsigned int format_count,
>enum drm_plane_type type,
> @@ -196,7 +196,7 @@ void drm_plane_unregister_all(struct drm_device *dev)
>   * Zero on success, error code on failure.
>   */
>  int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> -unsigned long possible_crtcs,
> +uint32_t possible_crtcs,
>  const struct drm_plane_funcs *funcs,
>  const uint32_t *formats, unsigned int format_count,
>  bool is_primary)
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 5b38eb94783b..db3bbdeb36d5 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -513,7 +513,7 @@ struct drm_plane {
>  extern __printf(8, 9)
>  int drm_universal_plane_init(struct drm_device *dev,
>struct drm_plane *plane,
> -  unsigned long possible_crtcs,
> +  uint32_t possible_crtcs,
>const struct drm_plane_funcs *funcs,
>const uint32_t *formats,
>unsigned int format_count,
> @@ -521,7 +521,7 @@ int drm_universal_plane_init(struct drm_device *dev,
>const char *name, ...);
>  extern int drm_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> -   unsigned long possible_crtcs,
> +   uint32_t possible_crtcs,
> const struct drm_plane_funcs *funcs,
> const uint32_t *formats, unsigned int format_count,
> bool is_primary);
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC

[PATCH 1/2] drm: fix possible_crtc's type

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Friday 02 Dec 2016 16:07:10 Tomi Valkeinen wrote:
> drm_universal_plane_init() and drm_plane_init() take "unsigned long
> possible_crtcs" parameter, but then stuff it into uint32_t. Change the
> parameter to uint32_t.
> 
> Signed-off-by: Tomi Valkeinen 
> Cc: Ville Syrjälä 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_plane.c | 4 ++--
>  include/drm/drm_plane.h | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 419ac313c36f..3bf9276f5bcf 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -79,7 +79,7 @@ static unsigned int drm_num_planes(struct drm_device *dev)
> * Zero on success, error code on failure.
>   */
>  int drm_universal_plane_init(struct drm_device *dev, struct drm_plane
> *plane, -  unsigned long possible_crtcs,
> +  uint32_t possible_crtcs,
>const struct drm_plane_funcs *funcs,
>const uint32_t *formats, unsigned int 
format_count,
>enum drm_plane_type type,
> @@ -196,7 +196,7 @@ void drm_plane_unregister_all(struct drm_device *dev)
>   * Zero on success, error code on failure.
>   */
>  int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> -unsigned long possible_crtcs,
> +uint32_t possible_crtcs,
>  const struct drm_plane_funcs *funcs,
>  const uint32_t *formats, unsigned int format_count,
>  bool is_primary)
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 5b38eb94783b..db3bbdeb36d5 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -513,7 +513,7 @@ struct drm_plane {
>  extern __printf(8, 9)
>  int drm_universal_plane_init(struct drm_device *dev,
>struct drm_plane *plane,
> -  unsigned long possible_crtcs,
> +  uint32_t possible_crtcs,
>const struct drm_plane_funcs *funcs,
>const uint32_t *formats,
>unsigned int format_count,
> @@ -521,7 +521,7 @@ int drm_universal_plane_init(struct drm_device *dev,
>const char *name, ...);
>  extern int drm_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> -   unsigned long possible_crtcs,
> +   uint32_t possible_crtcs,
> const struct drm_plane_funcs *funcs,
> const uint32_t *formats, unsigned int format_count,
> bool is_primary);

-- 
Regards,

Laurent Pinchart

[PATCH 12/22] drm: bridge: dw-hdmi: Abstract the platform PHY configuration

[Laurent Pinchart]

Hi Jose,

On Friday 02 Dec 2016 11:15:19 Jose Abreu wrote:
> On 01-12-2016 23:43, Laurent Pinchart wrote:
> > From: Kieran Bingham 
> > 
> > Platforms implement the dw-hdmi with a separate PHY entity. It is
> > configured over it's own I2C bus. To allow for different PHY's to be
> > configured from the dw-hdmi driver, abstract the actual programming of
> > the PHY to its own functions, as configured by the platform.
> > 
> > Signed-off-by: Kieran Bingham 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> > drivers/gpu/drm/bridge/dw-hdmi.c| 79 +++-
> > drivers/gpu/drm/imx/dw_hdmi-imx.c   |  2 +
> > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  1 +
> > include/drm/bridge/dw_hdmi.h| 12 +
> > 4 files changed, 63 insertions(+), 31 deletions(-)

[snip]

> > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> > index e551b457c100..fa7655836c81 100644
> > --- a/include/drm/bridge/dw_hdmi.h
> > +++ b/include/drm/bridge/dw_hdmi.h
> > @@ -52,6 +52,10 @@ struct dw_hdmi_plat_data {
> > const struct dw_hdmi_mpll_config *mpll_cfg;
> > const struct dw_hdmi_curr_ctrl *cur_ctr;
> > const struct dw_hdmi_phy_config *phy_config;
> > +   int (*configure_phy)(struct dw_hdmi *hdmi,
> > +const struct dw_hdmi_plat_data *pdata,
> > +unsigned long mpixelclock,
> > +enum dw_hdmi_resolution resolution);
> 
> I think the name of this callback here is a little bit misleading
> because you are only configuring the phy pll. Maybe
> .configure_phy_pll() would be more suitable.

Isn't there more than the PLL ? For instance register TXTERM configures the 
transmission line termination.

> > enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
> > 
> >struct drm_display_mode *mode);
> >  
> >  };

-- 
Regards,

Laurent Pinchart

[PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

[Russell King - ARM Linux]

On Fri, Dec 02, 2016 at 05:51:18PM +0200, Laurent Pinchart wrote:
> Hi Russell,
> 
> On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote:
> > On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> > > From: Kieran Bingham 
> > > 
> > > The current code hard codes the call of hdmi_phy_configure() to be 8bpp
> > > and provides extraneous error checking to verify that this hardcoded
> > > value is correct.
> > > 
> > > Simplify the passing of the data by setting the parameter to be of the
> > > enum type it represents rather than converting and then verifying the
> > > value. This will allow the compiler to check the value is acceptable
> > > based on the type, and remove the dead code that we currently have.
> > 
> > I think you're expecting too much of the compiler there.  There's no
> > requirement for the compiler to check that an enum type is passed one
> > of it's defined values.
> 
> You're right.
> 
> Given that the current driver hardcodes the resolution value to 8bpp, how 
> about just dropping the argument ? We can always add it back later if/when 
> needed.

Definitely - there's no point having features in the driver which no one
uses.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

[Russell King - ARM Linux]

On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote:
> DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that.
> 
> Do you know why this function needs to write to the HDMI_FC_INVIDCONF
> register  four times in the normal case, and once only for IMX6DL ?

(I don't have much time at present, I'm buried in ARM64 crud trying to
get a platform to boot, and working out how to debug an ARM64 platform
that even earlycon doesn't work on... no printascii() types of easy
debug facilities on ARM64 make this job several orders of magnitude
harder than it needs to be...)

It prevents a magenta line down the left hand side of the screen, which
is caused when the frame composer in the HDMI Tx gets confused -
according to the errata, it does a load of maths when you write to the
frame composer registers, and sometimes it doesn't update properly.

So, the four writes (and the number is critical) is there to persuade
the IP to do the maths with the right values so the internal timings
are correct.

The rather confusing thing is - it's actually IMX6Q which has the more
severe errata, not IMX6DL - the workaround of four writes is applied
in the 6Q case.

It's covered by ERR004308 in the IMX6Q Errata document (search for
IMX6DQCE).  It isn't mentioned in the IMX6DL documentation, but it
seems that similar workaround of one write is necessary there.

Some of this was determined by experimentation in conjunction with the
errata documentation - I remember it took a while to get it right so
that we didn't ever see the magenta line.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCHv2 2/2] drm/omap: fix primary-plane's possible_crtcs

[Tomi Valkeinen]

We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1",
which is fine as the HW planes can be used fro all crtcs. However, when
we're doing that, we are still incrementing 'num_crtcs', and we'll end
up with bad possible_crtcs, preventing the use of the primary planes.

This patch passes a possible_crtcs mask to plane init function so that
we get correct possible_crtc.

Signed-off-by: Tomi Valkeinen 
---

v2: use correct possible_crtcs value

 drivers/gpu/drm/omapdrm/omap_drv.c   | 17 -
 drivers/gpu/drm/omapdrm/omap_drv.h   |  3 ++-
 drivers/gpu/drm/omapdrm/omap_plane.c |  6 +++---
 3 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 39c5312b466c..fdc83cbcde61 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -267,13 +267,15 @@ static int omap_connect_dssdevs(void)
 }

 static int omap_modeset_create_crtc(struct drm_device *dev, int id,
-   enum omap_channel channel)
+   enum omap_channel channel,
+   u32 possible_crtcs)
 {
struct omap_drm_private *priv = dev->dev_private;
struct drm_plane *plane;
struct drm_crtc *crtc;

-   plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY);
+   plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY,
+   possible_crtcs);
if (IS_ERR(plane))
return PTR_ERR(plane);

@@ -309,6 +311,7 @@ static int omap_modeset_init(struct drm_device *dev)
int num_crtcs;
int i, id = 0;
int ret;
+   u32 possible_crtcs;

drm_mode_config_init(dev);

@@ -325,6 +328,7 @@ static int omap_modeset_init(struct drm_device *dev)
 * We use the num_crtc argument to limit the number of crtcs we create.
 */
num_crtcs = min3(num_crtc, num_mgrs, num_ovls);
+   possible_crtcs = (1 << num_crtcs) - 1;

dssdev = NULL;

@@ -388,7 +392,8 @@ static int omap_modeset_init(struct drm_device *dev)
 * allocated crtc, we create a new crtc for it
 */
if (!channel_used(dev, channel)) {
-   ret = omap_modeset_create_crtc(dev, id, channel);
+   ret = omap_modeset_create_crtc(dev, id, channel,
+   possible_crtcs);
if (ret < 0) {
dev_err(dev->dev,
"could not create CRTC (channel %u)\n",
@@ -418,7 +423,8 @@ static int omap_modeset_init(struct drm_device *dev)
return -ENOMEM;
}

-   ret = omap_modeset_create_crtc(dev, id, i);
+   ret = omap_modeset_create_crtc(dev, id, i,
+   possible_crtcs);
if (ret < 0) {
dev_err(dev->dev,
"could not create CRTC (channel %u)\n", i);
@@ -432,7 +438,8 @@ static int omap_modeset_init(struct drm_device *dev)
for (; id < num_ovls; id++) {
struct drm_plane *plane;

-   plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_OVERLAY);
+   plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_OVERLAY,
+   possible_crtcs);
if (IS_ERR(plane))
return PTR_ERR(plane);

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 4c51135eb9a6..7d9dd5400cef 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -157,7 +157,8 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
 int omap_crtc_wait_pending(struct drm_crtc *crtc);

 struct drm_plane *omap_plane_init(struct drm_device *dev,
-   int id, enum drm_plane_type type);
+   int id, enum drm_plane_type type,
+   u32 possible_crtcs);
 void omap_plane_install_properties(struct drm_plane *plane,
struct drm_mode_object *obj);

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 9c43cb481e62..82b2c23d6769 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -356,9 +356,9 @@ static const uint32_t error_irqs[] = {

 /* initialize plane */
 struct drm_plane *omap_plane_init(struct drm_device *dev,
-   int id, enum drm_plane_type type)
+   int id, enum drm_plane_type type,
+   u32 possible_crtcs)
 {
-   struct omap_drm_private *priv = dev->dev_private;
struct drm_plane *plane;
struct omap_plane *omap_plane;
int ret;
@@ -381,7 +381,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
omap_plane->error_irq.irq = omap_plane_error_irq;
omap_irq_register(dev, _plane->error_irq);

-   ret = 

[PATCH 1/2] drm: fix possible_crtc's type

[Tomi Valkeinen]

drm_universal_plane_init() and drm_plane_init() take "unsigned long
possible_crtcs" parameter, but then stuff it into uint32_t. Change the
parameter to uint32_t.

Signed-off-by: Tomi Valkeinen 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_plane.c | 4 ++--
 include/drm/drm_plane.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 419ac313c36f..3bf9276f5bcf 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -79,7 +79,7 @@ static unsigned int drm_num_planes(struct drm_device *dev)
  * Zero on success, error code on failure.
  */
 int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
-unsigned long possible_crtcs,
+uint32_t possible_crtcs,
 const struct drm_plane_funcs *funcs,
 const uint32_t *formats, unsigned int format_count,
 enum drm_plane_type type,
@@ -196,7 +196,7 @@ void drm_plane_unregister_all(struct drm_device *dev)
  * Zero on success, error code on failure.
  */
 int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
-  unsigned long possible_crtcs,
+  uint32_t possible_crtcs,
   const struct drm_plane_funcs *funcs,
   const uint32_t *formats, unsigned int format_count,
   bool is_primary)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 5b38eb94783b..db3bbdeb36d5 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -513,7 +513,7 @@ struct drm_plane {
 extern __printf(8, 9)
 int drm_universal_plane_init(struct drm_device *dev,
 struct drm_plane *plane,
-unsigned long possible_crtcs,
+uint32_t possible_crtcs,
 const struct drm_plane_funcs *funcs,
 const uint32_t *formats,
 unsigned int format_count,
@@ -521,7 +521,7 @@ int drm_universal_plane_init(struct drm_device *dev,
 const char *name, ...);
 extern int drm_plane_init(struct drm_device *dev,
  struct drm_plane *plane,
- unsigned long possible_crtcs,
+ uint32_t possible_crtcs,
  const struct drm_plane_funcs *funcs,
  const uint32_t *formats, unsigned int format_count,
  bool is_primary);
-- 
2.7.4

[PATCH v2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

[Hans de Goede]

Looking at the ADF code from the Android kernel sources for a
cherrytrail tablet I noticed that it is calling the
MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.

Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
in panel prepare/unprepare hooks") the mainline i915 code was doing the
same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
MIPI_SEQ_DEASSERT_RESET.

Looking at the naming of the sequences that is the right thing to do,
but the problem is, that the old mainline code and the ADF code was
actually calling the right sequence (tested on a cube iwork8 air tablet),
and the swapping of the calling breaks things.

This breakage was likely not noticed in testing because on cherrytrail,
currently chv_exec_gpio ends up disabling the gpio pins rather then
setting them (this is fixed in the next patch in this patch-set).

This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
places in the enum defining them, so that their (new) names match their
actual use.

Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Hans de Goede 
Acked-by: Jani Nikula 
---
Changes in v2:
-Add a comment to the enum explaining that the assert/reassert names
 are swapped in the spec
---
 drivers/gpu/drm/i915/intel_bios.h  | 12 +---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |  4 ++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 8405b5a..7e3545f 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -46,14 +46,20 @@ struct edp_power_seq {
u16 t11_t12;
 } __packed;

-/* MIPI Sequence Block definitions */
+/*
+ * MIPI Sequence Block definitions
+ *
+ * Note the VBT spec has AssertReset / DeassertReset swapped from their
+ * usual naming, we use the proper names here to avoid confusion when
+ * reading the code.
+ */
 enum mipi_seq {
MIPI_SEQ_END = 0,
-   MIPI_SEQ_ASSERT_RESET,
+   MIPI_SEQ_DEASSERT_RESET,/* Spec says MipiAssertResetPin */
MIPI_SEQ_INIT_OTP,
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
-   MIPI_SEQ_DEASSERT_RESET,
+   MIPI_SEQ_ASSERT_RESET,  /* Spec says MipiDeassertResetPin */
MIPI_SEQ_BACKLIGHT_ON,  /* sequence block v2+ */
MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
MIPI_SEQ_TEAR_ON,   /* sequence block v2+ */
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 0d8ff00..579d2f5 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
  */

 static const char * const seq_name[] = {
-   [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
+   [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
[MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
[MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
[MIPI_SEQ_DISPLAY_OFF]  = "MIPI_SEQ_DISPLAY_OFF",
-   [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
+   [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
[MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
[MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
[MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
-- 
2.9.3

[PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences

[Jani Nikula]

On Fri, 02 Dec 2016, Hans de Goede  wrote:
> Hi,
>
> On 02-12-16 11:31, Jani Nikula wrote:
>> On Thu, 01 Dec 2016, Hans de Goede  wrote:
>>> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
>>> not fine grained enough to abstract all the different steps we need to
>>> take (and VBT sequences we need to exec) properly. So simply remove the
>>> panel _enable/disable and prepare/unprepare callbacks and instead
>>> export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c
>>> and call that from intel_dsi_enable/disable().
>>>
>>> No functional changes.
>>
>> No functional changes, but this is quite a big design change between
>> intel_dsi.c and intel_dsi_panel_vbt.c.
>
> True, I did this because adding a callback per init step to the
> drm_panel interface felt like it will result in a game of
> whack a mole (adding more and more callbacks). See the end of
> this mail for a proposal with leaves the drm_panel interface
> in place, while also avoiding this problem.
>
>> Originally the idea was to
>> separate the dsi core code and the panel specific code, letting one
>> write a panel driver that was not based on values in VBT. This patch
>> changes that.
>
> I see, I was not aware of this history.
>
>> Now I'm not sure if there'll ever be a panel driver not based on VBT,
>> and perhaps the current drm_panel based interface between two is not
>> enough in the end, nor prettiest. But after this patch, we might just as
>> well throw out the drm_panel interface, and refactor the division
>> between the two files completely. Indeed, if we accept the direction set
>> in this patch, that refactoring would be the logical next step.
>
> Is intel_dsi.c the only user of the drm_panel interface ? The name
> suggests it is not intel specific.

Just a quick note here, it's not i915 specific, it's used in other
drivers.

BR,
Jani.

>
>> I have not made up my mind about this yet. An alternative would be to
>> amend the drm_panel interface to achieve the kind of granularity you're
>> after in the follow-up patches. Indeed, such patches have been sent in
>> the past.
>
> How about we add a "drm_panel_exec_sequence" callback to the
> drm_panel interface, which takes an enum argument which (de)init
> step to do ?
>
> Then we can easily add extra init steps later by extending the
> enum, and panel implementations which do not care about certain
> steps can simply treat these as nops. This avoids the need
> to add a ton of callbacks to the drm_panel struct.
>
> If there are no other users, we could then also remove the
> enable/disable and prepare/unprepare pairs from drm_panel
> now, I left those in place assuming that intel_dsi.c was
> not the only user of drm_panel.
>
> Regards,
>
> Hans
>
>
>
>
>>
>> BR,
>> Jani.
>>
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  drivers/gpu/drm/i915/intel_dsi.c   | 14 +++---
>>>  drivers/gpu/drm/i915/intel_dsi.h   |  3 +++
>>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 
>>> ++
>>>  3 files changed, 15 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>>> b/drivers/gpu/drm/i915/intel_dsi.c
>>> index 85b748d..cf761e8 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>>> @@ -656,7 +656,10 @@ static void intel_dsi_pre_enable(struct intel_encoder 
>>> *encoder,
>>> /* put device in ready state */
>>> intel_dsi_device_ready(encoder);
>>>
>>> -   drm_panel_prepare(intel_dsi->panel);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
>>>
>>> /* Enable port in pre-enable phase itself because as per hw team
>>>  * recommendation, port should be enabled befor plane & pipe */
>>> @@ -669,7 +672,8 @@ static void intel_dsi_pre_enable(struct intel_encoder 
>>> *encoder,
>>> dpi_send_cmd(intel_dsi, TURN_ON, false, port);
>>> msleep(100);
>>>
>>> -   drm_panel_enable(intel_dsi->panel);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>>>
>>> intel_dsi_port_enable(encoder);
>>> }
>>> @@ -732,7 +736,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
>>> *encoder,
>>>  * if disable packets are sent before sending shutdown packet then in
>>>  * some next enable sequence send turn on packet error is observed
>>>  */
>>> -   drm_panel_disable(intel_dsi->panel);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>>>
>>> intel_dsi_clear_device_ready(encoder);
>>>
>>> @@ -746,7 +751,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
>>> 

[RESEND PATCH v2 0/7] drm/vc4: VEC (SDTV) output support

[Eric Anholt]

Boris Brezillon  writes:

> Sorry for the noise, but I forgot to Cc the DT maintainers.
>
> Here is the 2nd version of the VC4/VEC series.
>
> We still miss the two clock patches mentioned by Eric in the first
> version to make the encoder work no matter the setting applied by the
> bootloader.

I'm happy with the series and I'm just waiting for the DT ack.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/77c81c09/attachment.sig>

[PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

[Ville Syrjälä]

On Fri, Dec 02, 2016 at 02:34:01PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 02-12-16 13:37, Ville Syrjälä wrote:
> > On Thu, Dec 01, 2016 at 09:29:08PM +0100, Hans de Goede wrote:
> >> Looking at the ADF code from the Android kernel sources for a
> >> cherrytrail tablet I noticed that it is calling the
> >> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
> >>
> >> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> >> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> >> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> >> MIPI_SEQ_DEASSERT_RESET.
> >>
> >> Looking at the naming of the sequences that is the right thing to do,
> >> but the problem is, that the old mainline code and the ADF code was
> >> actually calling the right sequence (tested on a cube iwork8 air tablet),
> >> and the swapping of the calling breaks things.
> >>
> >> This breakage was likely not noticed in testing because on cherrytrail,
> >> currently chv_exec_gpio ends up disabling the gpio pins rather then
> >> setting them (this is fixed in the next patch in this patch-set).
> >>
> >> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> >> places in the enum defining them, so that their (new) names match their
> >> actual use.
> >>
> >> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> >> Cc: Jani Nikula 
> >> Cc: Ville Syrjälä 
> >> Signed-off-by: Hans de Goede 
> >> ---
> >>  drivers/gpu/drm/i915/intel_bios.h  | 4 ++--
> >>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
> >>  2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> >> b/drivers/gpu/drm/i915/intel_bios.h
> >> index 8405b5a..642a5eb 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.h
> >> +++ b/drivers/gpu/drm/i915/intel_bios.h
> >> @@ -49,11 +49,11 @@ struct edp_power_seq {
> >>  /* MIPI Sequence Block definitions */
> >>  enum mipi_seq {
> >>MIPI_SEQ_END = 0,
> >> -  MIPI_SEQ_ASSERT_RESET,
> >> +  MIPI_SEQ_DEASSERT_RESET,
> >>MIPI_SEQ_INIT_OTP,
> >>MIPI_SEQ_DISPLAY_ON,
> >>MIPI_SEQ_DISPLAY_OFF,
> >> -  MIPI_SEQ_DEASSERT_RESET,
> >> +  MIPI_SEQ_ASSERT_RESET,
> >
> > I think we'll still want to keep to the names as they are in the
> > spec, and instead we'll just call them in the order that looks
> > wrong + add a comment explaining why we do that.
> 
> I really want the i915 driver to use the correct names, anything
> else will lead to no amount of confusion for people who have
> experience with embedded stuff.
> 
> How about adding a comment here in the enum, as well as in
> patch 8: "drm/i915/dsi: Document the panel enable / disable sequences from 
> the spec"
> That the spec has assert / deassert the wrong way around and that
> the i915 code is using the correct names ?

Sure, I could live with that. We definitely need to have that
comment somewhere.

> 
> Most people will not even have access to the spec, so it seems to
> me that having this right in the code, with a comment to warn
> people who do have access to the spec is better then the other
> way around.
> 
> Regards,
> 
> Hans
> 
> 
> 
> >
> >>MIPI_SEQ_BACKLIGHT_ON,  /* sequence block v2+ */
> >>MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
> >>MIPI_SEQ_TEAR_ON,   /* sequence block v2+ */
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> index 0d8ff00..579d2f5 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
> >>   */
> >>
> >>  static const char * const seq_name[] = {
> >> -  [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> >> +  [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> >>[MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
> >>[MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
> >>[MIPI_SEQ_DISPLAY_OFF]  = "MIPI_SEQ_DISPLAY_OFF",
> >> -  [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> >> +  [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> >>[MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
> >>[MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
> >>[MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
> >> --
> >> 2.9.3
> >

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

[Ville Syrjälä]

On Fri, Dec 02, 2016 at 02:27:43PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 02-12-16 13:40, Ville Syrjälä wrote:
> > On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
> >> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
> >> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
> >> Once the i915 driver has successfully loaded, the panel can be disabled /
> >> enabled without hitting this issue.
> >>
> >> The getting stuck is caused by vlv_init_display_clock_gating() clearing
> >> the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
> >> chv_pipe_power_well_ops.enable() on driver load, while PIPE-A is enabled
> >> driving the DSI LCD by the BIOS.
> >>
> >> Clearing this bit while DSI is in use is a known issue and
> >> intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
> >> as appropriate.
> >>
> >> This commit modifies vlv_init_display_clock_gating() to leave the
> >> DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing PIPE-A getting stuck.
> >>
> >> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
> >> Cc: stable at vger.kernel.org
> >> Signed-off-by: Hans de Goede 
> >> ---
> >>  drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
> >>  1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> >> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> index 356c662..b5ce7cb 100644
> >> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> @@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct 
> >> drm_i915_private *dev_priv,
> >>
> >>  static void vlv_init_display_clock_gating(struct drm_i915_private 
> >> *dev_priv)
> >>  {
> >> -  I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
> >> +  u32 val;
> >> +
> >> +  /*
> >> +   * When on driver load, PIPE A may be active and driving a DSI display.
> >> +   * Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid PIPE A getting stuck
> >> +   * (and never recovering) in this case. intel_dsi_post_disable() will
> >> +   * clear it when we turn off the display.
> >
> > Why are you talking only about pipe A here?
> 
> Because that is the pipe which was getting stuck on my tablet. I see that
> the comment for the same workaround in intel_dsi.c just says:
> " Disable DPOunit clock gating, can stall pipe" so I guess I should
> update the comment s/PIPE A/pipe(s)/. Any other remarks before I send a v2 ?

Nope. With that this is

Reviewed-by: Ville Syrjälä 


> 
> Regards,
> 
> Hans
> 
> 
> 
> >
> >> +   */
> >> +  val = I915_READ(DSPCLK_GATE_D);
> >> +  val &= DPOUNIT_CLOCK_GATE_DISABLE;
> >> +  val |= VRHUNIT_CLOCK_GATE_DISABLE;
> >> +  I915_WRITE(DSPCLK_GATE_D, val);
> >>
> >>/*
> >> * Disable trickle feed and enable pnd deadline calculation
> >> --
> >> 2.9.3
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >

-- 
Ville Syrjälä
Intel OTC

[PATCH v2] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

[Hans de Goede]

On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.

The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled
driving the DSI LCD by the BIOS.

Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.

This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
Cc: stable at vger.kernel.org
Signed-off-by: Hans de Goede 
Reviewed-by: Ville Syrjälä 
---
Changes in v2:
-Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 356c662..87b4af0 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct 
drm_i915_private *dev_priv,

 static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
 {
-   I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
+   u32 val;
+
+   /*
+* On driver load, a pipe may be active and driving a DSI display.
+* Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid the pipe getting stuck
+* (and never recovering) in this case. intel_dsi_post_disable() will
+* clear it when we turn off the display.
+*/
+   val = I915_READ(DSPCLK_GATE_D);
+   val &= DPOUNIT_CLOCK_GATE_DISABLE;
+   val |= VRHUNIT_CLOCK_GATE_DISABLE;
+   I915_WRITE(DSPCLK_GATE_D, val);

/*
 * Disable trickle feed and enable pnd deadline calculation
-- 
2.9.3

[RESEND PATCH v2 7/7] ARM: bcm/dt: Enable the VEC IP on all RaspberryPi boards

[Boris Brezillon]

Enable the VEC IP on all RaspberryPi boards.

Signed-off-by: Boris Brezillon 
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index e9b47b2bbc33..8893240da5f6 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -84,3 +84,8 @@
power-domains = < RPI_POWER_DOMAIN_HDMI>;
status = "okay";
 };
+
+ {
+   power-domains = < RPI_POWER_DOMAIN_VEC>;
+   status = "okay";
+};
-- 
2.7.4

[RESEND PATCH v2 6/7] ARM: bcm/dt: Add VEC node in bcm283x.dtsi

[Boris Brezillon]

Add the VEC (Video EnCoder) node definition in bcm283x.dtsi.

Signed-off-by: Boris Brezillon 
---
 arch/arm/boot/dts/bcm283x.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 46d46d894a44..44a9c0539437 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -266,6 +266,14 @@
status = "disabled";
};

+   vec: vec at 7e806000 {
+   compatible = "brcm,bcm2835-vec";
+   reg = <0x7e806000 0x1000>;
+   clocks = < BCM2835_CLOCK_VEC>;
+   interrupts = <2 27>;
+   status = "disabled";
+   };
+
pixelvalve at 7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
reg = <0x7e807000 0x100>;
-- 
2.7.4

[RESEND PATCH v2 5/7] drm/vc4: Document VEC DT binding

[Boris Brezillon]

Document the DT binding for the VEC (Video EnCoder) IP.

Signed-off-by: Boris Brezillon 
---
 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index a5ea451e67fc..e2768703ac2b 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -43,6 +43,13 @@ Required properties for DPI:
 - port:Port node with a single endpoint connecting to the panel
  device, as defined in [1]

+Required properties for VEC:
+- compatible:  Should be "brcm,bcm2835-vec"
+- reg: Physical base address and length of the registers
+- clocks:  The core clock the unit runs on
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
 Required properties for V3D:
 - compatible:  Should be "brcm,bcm2835-v3d"
 - reg: Physical base address and length of the V3D's registers
@@ -92,6 +99,13 @@ dpi: dpi at 7e208000 {
};
 };

+vec: vec at 7e806000 {
+   compatible = "brcm,bcm2835-vec";
+   reg = <0x7e806000 0x1000>;
+   clocks = < BCM2835_CLOCK_VEC>;
+   interrupts = <2 27>;
+};
+
 v3d: v3d at 7ec0 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec0 0x1000>;
-- 
2.7.4

[RESEND PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP

[Boris Brezillon]

The VEC IP is a TV DAC, providing support for PAL and NTSC standards.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/Makefile  |   1 +
 drivers/gpu/drm/vc4/vc4_debugfs.c |   1 +
 drivers/gpu/drm/vc4/vc4_drv.c |   1 +
 drivers/gpu/drm/vc4/vc4_drv.h |   5 +
 drivers/gpu/drm/vc4/vc4_vec.c | 657 ++
 5 files changed, 665 insertions(+)
 create mode 100644 drivers/gpu/drm/vc4/vc4_vec.c

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index fb77db755e0a..7757f69a8a77 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -11,6 +11,7 @@ vc4-y := \
vc4_kms.o \
vc4_gem.o \
vc4_hdmi.o \
+   vc4_vec.o \
vc4_hvs.o \
vc4_irq.o \
vc4_plane.o \
diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c 
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index 245115d49c46..caf817bac885 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -19,6 +19,7 @@ static const struct drm_info_list vc4_debugfs_list[] = {
{"bo_stats", vc4_bo_stats_debugfs, 0},
{"dpi_regs", vc4_dpi_debugfs_regs, 0},
{"hdmi_regs", vc4_hdmi_debugfs_regs, 0},
+   {"vec_regs", vc4_vec_debugfs_regs, 0},
{"hvs_regs", vc4_hvs_debugfs_regs, 0},
{"crtc0_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)0},
{"crtc1_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)1},
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 8703f56b7947..3e6cb78f7381 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -289,6 +289,7 @@ static const struct component_master_ops vc4_drm_ops = {

 static struct platform_driver *const component_drivers[] = {
_hdmi_driver,
+   _vec_driver,
_dpi_driver,
_hvs_driver,
_crtc_driver,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 946d48c33668..b3a46a51f9d0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -17,6 +17,7 @@ struct vc4_dev {
struct vc4_crtc *crtc[3];
struct vc4_v3d *v3d;
struct vc4_dpi *dpi;
+   struct vc4_vec *vec;

struct drm_fbdev_cma *fbdev;

@@ -484,6 +485,10 @@ int vc4_queue_seqno_cb(struct drm_device *dev,
 extern struct platform_driver vc4_hdmi_driver;
 int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused);

+/* vc4_hdmi.c */
+extern struct platform_driver vc4_vec_driver;
+int vc4_vec_debugfs_regs(struct seq_file *m, void *unused);
+
 /* vc4_irq.c */
 irqreturn_t vc4_irq(int irq, void *arg);
 void vc4_irq_preinstall(struct drm_device *dev);
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
new file mode 100644
index ..2d4256fcc6f2
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -0,0 +1,657 @@
+/*
+ * Copyright (C) 2016 Broadcom Limited
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/**
+ * DOC: VC4 SDTV module
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vc4_drv.h"
+#include "vc4_regs.h"
+
+/* WSE Registers */
+#define VEC_WSE_RESET  0xc0
+
+#define VEC_WSE_CONTROL0xc4
+#define VEC_WSE_WSS_ENABLE BIT(7)
+
+#define VEC_WSE_WSS_DATA   0xc8
+#define VEC_WSE_VPS_DATA1  0xcc
+#define VEC_WSE_VPS_CONTROL0xd0
+
+/* VEC Registers */
+#define VEC_REVID  0x100
+
+#define VEC_CONFIG00x104
+#define VEC_CONFIG0_YDEL_MASK  GENMASK(28, 26)
+#define VEC_CONFIG0_YDEL(x)((x) << 26)
+#define VEC_CONFIG0_CDEL_MASK  GENMASK(25, 24)
+#define VEC_CONFIG0_CDEL(x)((x) << 24)
+#define VEC_CONFIG0_PBPR_FIL   BIT(18)
+#define VEC_CONFIG0_CHROMA_GAIN_MASK   GENMASK(17, 16)
+#define VEC_CONFIG0_CHROMA_GAIN_UNITY  (0 << 16)
+#define VEC_CONFIG0_CHROMA_GAIN_1_32   (1 << 16)
+#define VEC_CONFIG0_CHROMA_GAIN_1_16   (2 << 16)
+#define VEC_CONFIG0_CHROMA_GAIN_1_8(3 << 16)
+#define VEC_CONFIG0_CBURST_GAIN_MASK   GENMASK(14, 13)
+#define VEC_CONFIG0_CBURST_GAIN_UNITY  (0 << 13)
+#define VEC_CONFIG0_CBURST_GAIN_1_128  (1 << 13)
+#define VEC_CONFIG0_CBURST_GAIN_1_64   (2 << 13)
+#define VEC_CONFIG0_CBURST_GAIN_1_32   (3 << 13)
+#define VEC_CONFIG0_CHRBW1 BIT(11)
+#define VEC_CONFIG0_CHRBW0

[RESEND PATCH v2 3/7] drm: Add TV connector states to drm_connector_state

[Boris Brezillon]

Some generic TV connector properties are exposed in drm_mode_config, but
they are currently handled independently in each DRM encoder driver.

Extend the drm_connector_state to store TV related states, and modify the
drm_atomic_connector_{set,get}_property() helpers to fill the connector
state accordingly.

Each driver is then responsible for checking and applying the new config
in its ->atomic_mode_{check,set}() operations.

Signed-off-by: Boris Brezillon 
Reviewed-by: Daniel Vetter 
---
Changes in v2
- fix copy/paste errors
- use an enum for the subconnector field
- switch all fields to unsigned int
---
 drivers/gpu/drm/drm_atomic.c | 50 
 include/drm/drm_connector.h  | 32 
 2 files changed, 82 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e6862a744210..f93395c3c181 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -989,12 +989,38 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 * now?) atomic writes to DPMS property:
 */
return -EINVAL;
+   } else if (property == config->tv_select_subconnector_property) {
+   state->tv.subconnector = val;
+   } else if (property == config->tv_left_margin_property) {
+   state->tv.margins.left = val;
+   } else if (property == config->tv_right_margin_property) {
+   state->tv.margins.right = val;
+   } else if (property == config->tv_top_margin_property) {
+   state->tv.margins.top = val;
+   } else if (property == config->tv_bottom_margin_property) {
+   state->tv.margins.bottom = val;
+   } else if (property == config->tv_mode_property) {
+   state->tv.mode = val;
+   } else if (property == config->tv_brightness_property) {
+   state->tv.brightness = val;
+   } else if (property == config->tv_contrast_property) {
+   state->tv.contrast = val;
+   } else if (property == config->tv_flicker_reduction_property) {
+   state->tv.flicker_reduction = val;
+   } else if (property == config->tv_overscan_property) {
+   state->tv.overscan = val;
+   } else if (property == config->tv_saturation_property) {
+   state->tv.saturation = val;
+   } else if (property == config->tv_hue_property) {
+   state->tv.hue = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
} else {
return -EINVAL;
}
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_connector_set_property);

@@ -1025,6 +1051,30 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->dpms_property) {
*val = connector->dpms;
+   } else if (property == config->tv_select_subconnector_property) {
+   *val = state->tv.subconnector;
+   } else if (property == config->tv_left_margin_property) {
+   *val = state->tv.margins.left;
+   } else if (property == config->tv_right_margin_property) {
+   *val = state->tv.margins.right;
+   } else if (property == config->tv_top_margin_property) {
+   *val = state->tv.margins.top;
+   } else if (property == config->tv_bottom_margin_property) {
+   *val = state->tv.margins.bottom;
+   } else if (property == config->tv_mode_property) {
+   *val = state->tv.mode;
+   } else if (property == config->tv_brightness_property) {
+   *val = state->tv.brightness;
+   } else if (property == config->tv_contrast_property) {
+   *val = state->tv.contrast;
+   } else if (property == config->tv_flicker_reduction_property) {
+   *val = state->tv.flicker_reduction;
+   } else if (property == config->tv_overscan_property) {
+   *val = state->tv.overscan;
+   } else if (property == config->tv_saturation_property) {
+   *val = state->tv.saturation;
+   } else if (property == config->tv_hue_property) {
+   *val = state->tv.hue;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ac9d7d8e0e43..2645e8038572 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -194,10 +194,40 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 unsigned int num_formats);

 /**
+ * struct drm_tv_connector_state - TV connector related states
+ * 

[RESEND PATCH v2 2/7] drm: Turn DRM_MODE_SUBCONNECTOR_xx definitions into an enum

[Boris Brezillon]

List of values like the DRM_MODE_SUBCONNECTOR_xx ones are better
represented with enums.

Turn the DRM_MODE_SUBCONNECTOR_xx macros into an enum.

Signed-off-by: Boris Brezillon 
Suggested-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 include/uapi/drm/drm_mode.h | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index df0e3504c349..970bfc0d7107 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -220,14 +220,16 @@ struct drm_mode_get_encoder {

 /* This is for connectors with multiple signal types. */
 /* Try to match DRM_MODE_CONNECTOR_X as closely as possible. */
-#define DRM_MODE_SUBCONNECTOR_Automatic0
-#define DRM_MODE_SUBCONNECTOR_Unknown  0
-#define DRM_MODE_SUBCONNECTOR_DVID 3
-#define DRM_MODE_SUBCONNECTOR_DVIA 4
-#define DRM_MODE_SUBCONNECTOR_Composite5
-#define DRM_MODE_SUBCONNECTOR_SVIDEO   6
-#define DRM_MODE_SUBCONNECTOR_Component8
-#define DRM_MODE_SUBCONNECTOR_SCART9
+enum drm_mode_subconnector {
+   DRM_MODE_SUBCONNECTOR_Automatic = 0,
+   DRM_MODE_SUBCONNECTOR_Unknown = 0,
+   DRM_MODE_SUBCONNECTOR_DVID = 3,
+   DRM_MODE_SUBCONNECTOR_DVIA = 4,
+   DRM_MODE_SUBCONNECTOR_Composite = 5,
+   DRM_MODE_SUBCONNECTOR_SVIDEO = 6,
+   DRM_MODE_SUBCONNECTOR_Component = 8,
+   DRM_MODE_SUBCONNECTOR_SCART = 9,
+};

 #define DRM_MODE_CONNECTOR_Unknown 0
 #define DRM_MODE_CONNECTOR_VGA 1
-- 
2.7.4

[RESEND PATCH v2 1/7] drm/vc4: Fix ->clock_select setting for the VEC encoder

[Boris Brezillon]

PV_CONTROL_CLK_SELECT_VEC is actually 2 and not 0. Fix the definition and
rework the vc4_set_crtc_possible_masks() to cover the full range of the
PV_CONTROL_CLK_SELECT field.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 38 +++---
 drivers/gpu/drm/vc4/vc4_drv.h  |  1 +
 drivers/gpu/drm/vc4/vc4_regs.h |  3 ++-
 3 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 7f08d681a74b..c317e9103f9b 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -83,8 +83,7 @@ struct vc4_crtc_data {
/* Which channel of the HVS this pixelvalve sources from. */
int hvs_channel;

-   enum vc4_encoder_type encoder0_type;
-   enum vc4_encoder_type encoder1_type;
+   enum vc4_encoder_type encoder_types[4];
 };

 #define CRTC_WRITE(offset, val) writel(val, vc4_crtc->regs + (offset))
@@ -859,20 +858,26 @@ static const struct drm_crtc_helper_funcs 
vc4_crtc_helper_funcs = {

 static const struct vc4_crtc_data pv0_data = {
.hvs_channel = 0,
-   .encoder0_type = VC4_ENCODER_TYPE_DSI0,
-   .encoder1_type = VC4_ENCODER_TYPE_DPI,
+   .encoder_types = {
+   [PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI0,
+   [PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_DPI,
+   },
 };

 static const struct vc4_crtc_data pv1_data = {
.hvs_channel = 2,
-   .encoder0_type = VC4_ENCODER_TYPE_DSI1,
-   .encoder1_type = VC4_ENCODER_TYPE_SMI,
+   .encoder_types = {
+   [PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI1,
+   [PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_SMI,
+   },
 };

 static const struct vc4_crtc_data pv2_data = {
.hvs_channel = 1,
-   .encoder0_type = VC4_ENCODER_TYPE_VEC,
-   .encoder1_type = VC4_ENCODER_TYPE_HDMI,
+   .encoder_types = {
+   [PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_HDMI,
+   [PV_CONTROL_CLK_SELECT_VEC] = VC4_ENCODER_TYPE_VEC,
+   },
 };

 static const struct of_device_id vc4_crtc_dt_match[] = {
@@ -886,17 +891,20 @@ static void vc4_set_crtc_possible_masks(struct drm_device 
*drm,
struct drm_crtc *crtc)
 {
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   const struct vc4_crtc_data *crtc_data = vc4_crtc->data;
+   const enum vc4_encoder_type *encoder_types = crtc_data->encoder_types;
struct drm_encoder *encoder;

drm_for_each_encoder(encoder, drm) {
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
-
-   if (vc4_encoder->type == vc4_crtc->data->encoder0_type) {
-   vc4_encoder->clock_select = 0;
-   encoder->possible_crtcs |= drm_crtc_mask(crtc);
-   } else if (vc4_encoder->type == vc4_crtc->data->encoder1_type) {
-   vc4_encoder->clock_select = 1;
-   encoder->possible_crtcs |= drm_crtc_mask(crtc);
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(crtc_data->encoder_types); i++) {
+   if (vc4_encoder->type == encoder_types[i]) {
+   vc4_encoder->clock_select = i;
+   encoder->possible_crtcs |= drm_crtc_mask(crtc);
+   break;
+   }
}
}
 }
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 7c1e4d97486f..946d48c33668 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -194,6 +194,7 @@ to_vc4_plane(struct drm_plane *plane)
 }

 enum vc4_encoder_type {
+   VC4_ENCODER_TYPE_NONE,
VC4_ENCODER_TYPE_HDMI,
VC4_ENCODER_TYPE_VEC,
VC4_ENCODER_TYPE_DSI0,
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index 1aa44c2db556..39f6886b2410 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -177,8 +177,9 @@
 # define PV_CONTROL_WAIT_HSTARTBIT(12)
 # define PV_CONTROL_PIXEL_REP_MASK VC4_MASK(5, 4)
 # define PV_CONTROL_PIXEL_REP_SHIFT4
-# define PV_CONTROL_CLK_SELECT_DSI_VEC 0
+# define PV_CONTROL_CLK_SELECT_DSI 0
 # define PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI1
+# define PV_CONTROL_CLK_SELECT_VEC 2
 # define PV_CONTROL_CLK_SELECT_MASKVC4_MASK(3, 2)
 # define PV_CONTROL_CLK_SELECT_SHIFT   2
 # define PV_CONTROL_FIFO_CLR   BIT(1)
-- 
2.7.4

[RESEND PATCH v2 0/7] drm/vc4: VEC (SDTV) output support

[Boris Brezillon]

Sorry for the noise, but I forgot to Cc the DT maintainers.

Here is the 2nd version of the VC4/VEC series.

We still miss the two clock patches mentioned by Eric in the first
version to make the encoder work no matter the setting applied by the
bootloader.

Regards,

Boris

Boris Brezillon (7):
  drm/vc4: Fix ->clock_select setting for the VEC encoder
  drm: Turn DRM_MODE_SUBCONNECTOR_xx definitions into an enum
  drm: Add TV connector states to drm_connector_state
  drm/vc4: Add support for the VEC (Video Encoder) IP
  drm/vc4: Document VEC DT binding
  ARM: bcm/dt: Add VEC node in bcm283x.dtsi
  ARM: bcm/dt: Enable the VEC IP on all RaspeberryPi boards

 .../devicetree/bindings/display/brcm,bcm-vc4.txt   |  14 +
 arch/arm/boot/dts/bcm2835-rpi.dtsi |   5 +
 arch/arm/boot/dts/bcm283x.dtsi |   8 +
 drivers/gpu/drm/drm_atomic.c   |  50 ++
 drivers/gpu/drm/vc4/Makefile   |   1 +
 drivers/gpu/drm/vc4/vc4_crtc.c |  38 +-
 drivers/gpu/drm/vc4/vc4_debugfs.c  |   1 +
 drivers/gpu/drm/vc4/vc4_drv.c  |   1 +
 drivers/gpu/drm/vc4/vc4_drv.h  |   6 +
 drivers/gpu/drm/vc4/vc4_regs.h |   3 +-
 drivers/gpu/drm/vc4/vc4_vec.c  | 657 +
 include/drm/drm_connector.h|  32 +
 include/uapi/drm/drm_mode.h|  18 +-
 13 files changed, 810 insertions(+), 24 deletions(-)
 create mode 100644 drivers/gpu/drm/vc4/vc4_vec.c

-- 
2.7.4

[PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences

[Hans de Goede]

Hi,

On 02-12-16 11:31, Jani Nikula wrote:
> On Thu, 01 Dec 2016, Hans de Goede  wrote:
>> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
>> not fine grained enough to abstract all the different steps we need to
>> take (and VBT sequences we need to exec) properly. So simply remove the
>> panel _enable/disable and prepare/unprepare callbacks and instead
>> export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c
>> and call that from intel_dsi_enable/disable().
>>
>> No functional changes.
>
> No functional changes, but this is quite a big design change between
> intel_dsi.c and intel_dsi_panel_vbt.c.

True, I did this because adding a callback per init step to the
drm_panel interface felt like it will result in a game of
whack a mole (adding more and more callbacks). See the end of
this mail for a proposal with leaves the drm_panel interface
in place, while also avoiding this problem.

> Originally the idea was to
> separate the dsi core code and the panel specific code, letting one
> write a panel driver that was not based on values in VBT. This patch
> changes that.

I see, I was not aware of this history.

> Now I'm not sure if there'll ever be a panel driver not based on VBT,
> and perhaps the current drm_panel based interface between two is not
> enough in the end, nor prettiest. But after this patch, we might just as
> well throw out the drm_panel interface, and refactor the division
> between the two files completely. Indeed, if we accept the direction set
> in this patch, that refactoring would be the logical next step.

Is intel_dsi.c the only user of the drm_panel interface ? The name
suggests it is not intel specific.

> I have not made up my mind about this yet. An alternative would be to
> amend the drm_panel interface to achieve the kind of granularity you're
> after in the follow-up patches. Indeed, such patches have been sent in
> the past.

How about we add a "drm_panel_exec_sequence" callback to the
drm_panel interface, which takes an enum argument which (de)init
step to do ?

Then we can easily add extra init steps later by extending the
enum, and panel implementations which do not care about certain
steps can simply treat these as nops. This avoids the need
to add a ton of callbacks to the drm_panel struct.

If there are no other users, we could then also remove the
enable/disable and prepare/unprepare pairs from drm_panel
now, I left those in place assuming that intel_dsi.c was
not the only user of drm_panel.

Regards,

Hans




>
> BR,
> Jani.
>
>>
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/intel_dsi.c   | 14 +++---
>>  drivers/gpu/drm/i915/intel_dsi.h   |  3 +++
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 
>> ++
>>  3 files changed, 15 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 85b748d..cf761e8 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -656,7 +656,10 @@ static void intel_dsi_pre_enable(struct intel_encoder 
>> *encoder,
>>  /* put device in ready state */
>>  intel_dsi_device_ready(encoder);
>>
>> -drm_panel_prepare(intel_dsi->panel);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
>>
>>  /* Enable port in pre-enable phase itself because as per hw team
>>   * recommendation, port should be enabled befor plane & pipe */
>> @@ -669,7 +672,8 @@ static void intel_dsi_pre_enable(struct intel_encoder 
>> *encoder,
>>  dpi_send_cmd(intel_dsi, TURN_ON, false, port);
>>  msleep(100);
>>
>> -drm_panel_enable(intel_dsi->panel);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>>
>>  intel_dsi_port_enable(encoder);
>>  }
>> @@ -732,7 +736,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
>> *encoder,
>>   * if disable packets are sent before sending shutdown packet then in
>>   * some next enable sequence send turn on packet error is observed
>>   */
>> -drm_panel_disable(intel_dsi->panel);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>>
>>  intel_dsi_clear_device_ready(encoder);
>>
>> @@ -746,7 +751,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
>> *encoder,
>>  I915_WRITE(DSPCLK_GATE_D, val);
>>  }
>>
>> -drm_panel_unprepare(intel_dsi->panel);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
>> +intel_dsi_exec_vbt_sequence(intel_dsi, 

[PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

[Ville Syrjälä]

On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
> Once the i915 driver has successfully loaded, the panel can be disabled /
> enabled without hitting this issue.
> 
> The getting stuck is caused by vlv_init_display_clock_gating() clearing
> the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
> chv_pipe_power_well_ops.enable() on driver load, while PIPE-A is enabled
> driving the DSI LCD by the BIOS.
> 
> Clearing this bit while DSI is in use is a known issue and
> intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
> as appropriate.
> 
> This commit modifies vlv_init_display_clock_gating() to leave the
> DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing PIPE-A getting stuck.
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
> Cc: stable at vger.kernel.org
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 356c662..b5ce7cb 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct 
> drm_i915_private *dev_priv,
>  
>  static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
>  {
> - I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
> + u32 val;
> +
> + /*
> +  * When on driver load, PIPE A may be active and driving a DSI display.
> +  * Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid PIPE A getting stuck
> +  * (and never recovering) in this case. intel_dsi_post_disable() will
> +  * clear it when we turn off the display.

Why are you talking only about pipe A here?

> +  */
> + val = I915_READ(DSPCLK_GATE_D);
> + val &= DPOUNIT_CLOCK_GATE_DISABLE;
> + val |= VRHUNIT_CLOCK_GATE_DISABLE;
> + I915_WRITE(DSPCLK_GATE_D, val);
>  
>   /*
>* Disable trickle feed and enable pnd deadline calculation
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

[Ville Syrjälä]

On Thu, Dec 01, 2016 at 09:29:08PM +0100, Hans de Goede wrote:
> Looking at the ADF code from the Android kernel sources for a
> cherrytrail tablet I noticed that it is calling the
> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
> 
> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
> in panel prepare/unprepare hooks") the mainline i915 code was doing the
> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
> MIPI_SEQ_DEASSERT_RESET.
> 
> Looking at the naming of the sequences that is the right thing to do,
> but the problem is, that the old mainline code and the ADF code was
> actually calling the right sequence (tested on a cube iwork8 air tablet),
> and the swapping of the calling breaks things.
> 
> This breakage was likely not noticed in testing because on cherrytrail,
> currently chv_exec_gpio ends up disabling the gpio pins rather then
> setting them (this is fixed in the next patch in this patch-set).
> 
> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
> places in the enum defining them, so that their (new) names match their
> actual use.
> 
> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_bios.h  | 4 ++--
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> b/drivers/gpu/drm/i915/intel_bios.h
> index 8405b5a..642a5eb 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -49,11 +49,11 @@ struct edp_power_seq {
>  /* MIPI Sequence Block definitions */
>  enum mipi_seq {
>   MIPI_SEQ_END = 0,
> - MIPI_SEQ_ASSERT_RESET,
> + MIPI_SEQ_DEASSERT_RESET,
>   MIPI_SEQ_INIT_OTP,
>   MIPI_SEQ_DISPLAY_ON,
>   MIPI_SEQ_DISPLAY_OFF,
> - MIPI_SEQ_DEASSERT_RESET,
> + MIPI_SEQ_ASSERT_RESET,

I think we'll still want to keep to the names as they are in the
spec, and instead we'll just call them in the order that looks
wrong + add a comment explaining why we do that.

>   MIPI_SEQ_BACKLIGHT_ON,  /* sequence block v2+ */
>   MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
>   MIPI_SEQ_TEAR_ON,   /* sequence block v2+ */
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 0d8ff00..579d2f5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
>   */
>  
>  static const char * const seq_name[] = {
> - [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
> + [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
>   [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
>   [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
>   [MIPI_SEQ_DISPLAY_OFF]  = "MIPI_SEQ_DISPLAY_OFF",
> - [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
> + [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
>   [MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
>   [MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
>   [MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
> -- 
> 2.9.3

-- 
Ville Syrjälä
Intel OTC

[PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

[Hans de Goede]

Hi,

On 02-12-16 13:37, Ville Syrjälä wrote:
> On Thu, Dec 01, 2016 at 09:29:08PM +0100, Hans de Goede wrote:
>> Looking at the ADF code from the Android kernel sources for a
>> cherrytrail tablet I noticed that it is calling the
>> MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
>>
>> Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
>> in panel prepare/unprepare hooks") the mainline i915 code was doing the
>> same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET /
>> MIPI_SEQ_DEASSERT_RESET.
>>
>> Looking at the naming of the sequences that is the right thing to do,
>> but the problem is, that the old mainline code and the ADF code was
>> actually calling the right sequence (tested on a cube iwork8 air tablet),
>> and the swapping of the calling breaks things.
>>
>> This breakage was likely not noticed in testing because on cherrytrail,
>> currently chv_exec_gpio ends up disabling the gpio pins rather then
>> setting them (this is fixed in the next patch in this patch-set).
>>
>> This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's
>> places in the enum defining them, so that their (new) names match their
>> actual use.
>>
>> Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...")
>> Cc: Jani Nikula 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/intel_bios.h  | 4 ++--
>>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
>> b/drivers/gpu/drm/i915/intel_bios.h
>> index 8405b5a..642a5eb 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.h
>> +++ b/drivers/gpu/drm/i915/intel_bios.h
>> @@ -49,11 +49,11 @@ struct edp_power_seq {
>>  /* MIPI Sequence Block definitions */
>>  enum mipi_seq {
>>  MIPI_SEQ_END = 0,
>> -MIPI_SEQ_ASSERT_RESET,
>> +MIPI_SEQ_DEASSERT_RESET,
>>  MIPI_SEQ_INIT_OTP,
>>  MIPI_SEQ_DISPLAY_ON,
>>  MIPI_SEQ_DISPLAY_OFF,
>> -MIPI_SEQ_DEASSERT_RESET,
>> +MIPI_SEQ_ASSERT_RESET,
>
> I think we'll still want to keep to the names as they are in the
> spec, and instead we'll just call them in the order that looks
> wrong + add a comment explaining why we do that.

I really want the i915 driver to use the correct names, anything
else will lead to no amount of confusion for people who have
experience with embedded stuff.

How about adding a comment here in the enum, as well as in
patch 8: "drm/i915/dsi: Document the panel enable / disable sequences from the 
spec"
That the spec has assert / deassert the wrong way around and that
the i915 code is using the correct names ?

Most people will not even have access to the spec, so it seems to
me that having this right in the code, with a comment to warn
people who do have access to the spec is better then the other
way around.

Regards,

Hans



>
>>  MIPI_SEQ_BACKLIGHT_ON,  /* sequence block v2+ */
>>  MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
>>  MIPI_SEQ_TEAR_ON,   /* sequence block v2+ */
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index 0d8ff00..579d2f5 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -376,11 +376,11 @@ static const fn_mipi_elem_exec exec_elem[] = {
>>   */
>>
>>  static const char * const seq_name[] = {
>> -[MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
>> +[MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
>>  [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
>>  [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
>>  [MIPI_SEQ_DISPLAY_OFF]  = "MIPI_SEQ_DISPLAY_OFF",
>> -[MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
>> +[MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
>>  [MIPI_SEQ_BACKLIGHT_ON] = "MIPI_SEQ_BACKLIGHT_ON",
>>  [MIPI_SEQ_BACKLIGHT_OFF] = "MIPI_SEQ_BACKLIGHT_OFF",
>>  [MIPI_SEQ_TEAR_ON] = "MIPI_SEQ_TEAR_ON",
>> --
>> 2.9.3
>

[PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

[Hans de Goede]

Hi,

On 02-12-16 13:40, Ville Syrjälä wrote:
> On Thu, Dec 01, 2016 at 04:39:57PM +0100, Hans de Goede wrote:
>> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
>> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
>> Once the i915 driver has successfully loaded, the panel can be disabled /
>> enabled without hitting this issue.
>>
>> The getting stuck is caused by vlv_init_display_clock_gating() clearing
>> the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
>> chv_pipe_power_well_ops.enable() on driver load, while PIPE-A is enabled
>> driving the DSI LCD by the BIOS.
>>
>> Clearing this bit while DSI is in use is a known issue and
>> intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
>> as appropriate.
>>
>> This commit modifies vlv_init_display_clock_gating() to leave the
>> DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing PIPE-A getting stuck.
>>
>> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97330
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Hans de Goede 
>> ---
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 356c662..b5ce7cb 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -1039,7 +1039,18 @@ static bool vlv_power_well_enabled(struct 
>> drm_i915_private *dev_priv,
>>
>>  static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
>>  {
>> -I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
>> +u32 val;
>> +
>> +/*
>> + * When on driver load, PIPE A may be active and driving a DSI display.
>> + * Preserve DPOUNIT_CLOCK_GATE_DISABLE to avoid PIPE A getting stuck
>> + * (and never recovering) in this case. intel_dsi_post_disable() will
>> + * clear it when we turn off the display.
>
> Why are you talking only about pipe A here?

Because that is the pipe which was getting stuck on my tablet. I see that
the comment for the same workaround in intel_dsi.c just says:
" Disable DPOunit clock gating, can stall pipe" so I guess I should
update the comment s/PIPE A/pipe(s)/. Any other remarks before I send a v2 ?

Regards,

Hans



>
>> + */
>> +val = I915_READ(DSPCLK_GATE_D);
>> +val &= DPOUNIT_CLOCK_GATE_DISABLE;
>> +val |= VRHUNIT_CLOCK_GATE_DISABLE;
>> +I915_WRITE(DSPCLK_GATE_D, val);
>>
>>  /*
>>   * Disable trickle feed and enable pnd deadline calculation
>> --
>> 2.9.3
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

[Russell King - ARM Linux]

On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
> From: Kieran Bingham 
> 
> The dw-hdmi driver declares a dev_type to distinguish platform specific
> changes. Replace this with a quirk field, so that the platform can
> specify the required quirks for the driver, rather than the driver
> becoming conditional on multiple platforms.
> 
> As part of this, we rename the dw-hdmi 'spare' which is defined as the
> SVSRET bit in later documentation.

I'd really prefer that we did not go down the broken route of adding
a set of "quirk" flags - look at what a mess SDHCI has become through
allowing that kind of practice.

I'd much rather we find a saner structure to this - and we know that
the hardware has ID registers in it which can be used (so far) to
identify the buggy hardware.


> 
> Signed-off-by: Kieran Bingham 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c| 14 ++
>  drivers/gpu/drm/bridge/dw-hdmi.h|  4 ++--
>  drivers/gpu/drm/imx/dw_hdmi-imx.c   |  3 +--
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
>  include/drm/bridge/dw_hdmi.h| 12 +---
>  5 files changed, 15 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 06a44a2cdf3b..26607185722f 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -118,7 +118,6 @@ struct dw_hdmi {
>   struct drm_bridge bridge;
>  
>   struct platform_device *audio;
> - enum dw_hdmi_devtype dev_type;
>   struct device *dev;
>   struct clk *isfr_clk;
>   struct clk *iahb_clk;
> @@ -896,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi 
> *hdmi, u8 enable)
>HDMI_PHY_CONF0_ENTMDS_MASK);
>  }
>  
> -static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
> +static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> -  HDMI_PHY_CONF0_SPARECTRL_OFFSET,
> -  HDMI_PHY_CONF0_SPARECTRL_MASK);
> +  HDMI_PHY_CONF0_SVSRET_OFFSET,
> +  HDMI_PHY_CONF0_SVSRET_MASK);
>  }
>  
>  static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> @@ -1031,8 +1030,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
>   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
>   dw_hdmi_phy_gen2_pddq(hdmi, 0);
>  
> - if (hdmi->dev_type == RK3288_HDMI)
> - dw_hdmi_phy_enable_spare(hdmi, 1);
> + if (pdata->quirks & DW_HDMI_QUIRK_PHY_SVSRET)
> + dw_hdmi_phy_enable_svsret(hdmi, 1);

If we get a proper split between the encoder and the PHY, this should be
dealt with at the PHY side of the driver.

>  
>   /*Wait for PHY PLL lock */
>   msec = 5;
> @@ -1348,7 +1347,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
>   hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
>  
>   val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
> - if (hdmi->dev_type == IMX6DL_HDMI) {
> + if (hdmi->plat_data->quirks & DW_HDMI_QUIRK_FC_INVIDCONF) {
>   hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
>   return;
>   }

This is a bug found on iMX6DL versions of the IP - I don't have a 6DL
board powered up at the moment to grab its revision information, but
it would be nice to make that conditional on the revision.  From what
I gather, it's a workaround issued by Synopsis rather than specific
to the (ex)FSL implementation.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

[Russell King - ARM Linux]

On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> From: Kieran Bingham 
> 
> The current code hard codes the call of hdmi_phy_configure() to be 8bpp
> and provides extraneous error checking to verify that this hardcoded
> value is correct.
> 
> Simplify the passing of the data by setting the parameter to be of the
> enum type it represents rather than converting and then verifying the
> value. This will allow the compiler to check the value is acceptable
> based on the type, and remove the dead code that we currently have.

I think you're expecting too much of the compiler there.  There's no
requirement for the compiler to check that an enum type is passed one
of it's defined values.

Try building this and see if it even produces a warning:

enum foo {
FOO_1,
FOO_2,
};

int func(enum foo foo)
{
return foo;
}

int test_1(void)
{
return func(FOO_1);
}

int test_2(void)
{
return func(5);
}

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[i.MX6 DRM IPUv3] Regression 4.9-rc5: greenish screen with YUV420 video

[Krzysztof Hałasa]

Philipp Zabel  writes:

> I had already (accidentally) fixed this with 3fd8b292ae6b ("drm/imx:
> ipuv3-plane: merge ipu_plane_atomic_set_base into atomic_update").

Thanks, I've merged your pza/imx-drm/next and it now works.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH v3 01/13] drm: Don't include in

[Sinclair Yeh]

vmwgfx part:  Reviewed-by: Sinclair Yeh 

On Tue, Nov 29, 2016 at 11:04:31AM +0200, Laurent Pinchart wrote:
>  used to define most of the in-kernel KMS API. It has
> now been split into separate files for each object type, but still
> includes most other KMS headers to avoid breaking driver compilation.
> 
> As a step towards fixing that problem, remove the inclusion of
>  from  and include it instead where
> appropriate. Also remove the forward declarations of the drm_encoder and
> drm_encoder_helper_funcs structures from  as they're not
> needed in the header.
> 
>  now has to include  and contain a
> forward declaration of struct drm_encoder in order to allow including it
> as the first header in a compilation unit.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 1 +
>  drivers/gpu/drm/ast/ast_drv.h   | 1 +
>  drivers/gpu/drm/bochs/bochs.h   | 1 +
>  drivers/gpu/drm/cirrus/cirrus_drv.h | 1 +
>  drivers/gpu/drm/drm_connector.c | 1 +
>  drivers/gpu/drm/drm_crtc_helper.c   | 1 +
>  drivers/gpu/drm/drm_edid.c  | 1 +
>  drivers/gpu/drm/drm_mode_config.c   | 1 +
>  drivers/gpu/drm/drm_of.c| 1 +
>  drivers/gpu/drm/drm_plane_helper.c  | 1 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h   | 2 ++
>  drivers/gpu/drm/gma500/psb_intel_drv.h  | 1 +
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/mgag200/mgag200_drv.h   | 1 +
>  drivers/gpu/drm/nouveau/nouveau_connector.h | 1 +
>  drivers/gpu/drm/qxl/qxl_drv.h   | 1 +
>  drivers/gpu/drm/radeon/radeon_mode.h| 1 +
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.h   | 1 +
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.h   | 1 +
>  drivers/gpu/drm/tegra/drm.h | 1 +
>  drivers/gpu/drm/vc4/vc4_drv.h   | 2 ++
>  drivers/gpu/drm/virtio/virtgpu_drv.h| 1 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 +
>  include/drm/drm_crtc.h  | 3 ---
>  include/drm/drm_encoder.h   | 3 +++
>  include/drm/drm_encoder_slave.h | 1 +
>  include/drm/drm_modeset_helper_vtables.h| 1 +
>  27 files changed, 30 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 1e23334b07fb..fac06064a8f5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -32,6 +32,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 908011d2c8f5..6f3b6f50cf52 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -28,6 +28,7 @@
>  #ifndef __AST_DRV_H__
>  #define __AST_DRV_H__
>  
> +#include 
>  #include 
>  
>  #include 
> diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
> index 32dfe418cc98..f626bab7f5e3 100644
> --- a/drivers/gpu/drm/bochs/bochs.h
> +++ b/drivers/gpu/drm/bochs/bochs.h
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h 
> b/drivers/gpu/drm/cirrus/cirrus_drv.h
> index 2188d6b61b3e..b59aeef4635a 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.h
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
> @@ -13,6 +13,7 @@
>  
>  #include 
>  
> +#include 
>  #include 
>  
>  #include 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b5c6a8ee831e..5f1e1f190d30 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 5d2cb138eba6..b3fc23313cc3 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7eec18925b70..a9e3cc3990c1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define version_greater(edid, maj, min) \
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index 2735a5847ffa..09b1d8f267a6 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -20,6 +20,7 @@
>   * OF THIS SOFTWARE.
>   */
>  
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 47848ed8ca48..b5f2f0fece99 100644
> --- 

[PATCH] drm/etnaviv: move linear window on MC1.0 parts if necessary

[Marek Vasut]

On 12/02/2016 12:29 PM, Lucas Stach wrote:
> On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU
> linear window has to be moved for the GPU to work at all. This doesn't
> mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear
> window offset into account and will corrupt memory when used with a
> non-zero offset.
> 
> Move the linear window if it's necessary for the GPU to work, but avoid
> announcing FAST_CLEAR support to userspace in this case.
> 
> Signed-off-by: Lucas Stach 

On MX6SX:
Tested-by: Marek Vasut 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index b1254f885fed..4b697ad8bd64 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -639,6 +639,10 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>   gpu->memory_base = PHYS_OFFSET;
>   else
>   gpu->memory_base = dma_mask - SZ_2G + 1;
> + } else if (PHYS_OFFSET >= SZ_2G) {
> + dev_info(gpu->dev, "Need to move linear window on MC1.0, 
> disabling TS\n");
> + gpu->memory_base = PHYS_OFFSET;
> + gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
>   }
>  
>   ret = etnaviv_hw_reset(gpu);
> 


-- 
Best regards,
Marek Vasut

[PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight

[Jani Nikula]

On Fri, 02 Dec 2016, Hans de Goede  wrote:
> The primary consumer of the lpss pwm is the i915 kms driver, but
> currently that driver cannot get the pwm because i915 platforms are
> not using devicetree and pwm-lpss does not call pwm_add_table.
>
> Another problem is that i915 does not support get_pwm returning
> -EPROBE_DEFER and i915's init is very complex and this is almost
> impossible to fix.
>
> This commit changes the PWM_LPSS Kconfig from a tristate to a bool, so
> that when the i915 driver loads the lpss pwm will be available avoiding
> the -EPROBE_DEFER issue. Note that this is identical to how the same
> problem was solved for the pwm-crc driver.

Arguably this solution was worse for pwm-crc than pwm-lpss here, because
bool CONFIG_PWM_CRC depends on INTEL_SOC_PMIC which depends on I2C being
built-in. This one doesn't have all that bad dependencies.

FWIW, both patches are

Acked-by: Jani Nikula 



>
> Being builtin also allows calling pwm_add_table directly from the
> pwm-lpss code, otherwise the pwm_add_table call would need to be put
> somewhere else to ensure it happens before i915 calls pwm_get,
> even if i915 would support -EPROBE_DEFER.
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/pwm/Kconfig| 12 +++-
>  drivers/pwm/pwm-lpss.c | 11 +++
>  2 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index bf01288..cda31ea 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -240,28 +240,22 @@ config PWM_LPC32XX
> will be called pwm-lpc32xx.
>  
>  config PWM_LPSS
> - tristate
> + bool
>  
>  config PWM_LPSS_PCI
> - tristate "Intel LPSS PWM PCI driver"
> + bool "Intel LPSS PWM PCI driver"
>   depends on X86 && PCI
>   select PWM_LPSS
>   help
> The PCI driver for Intel Low Power Subsystem PWM controller.
>  
> -   To compile this driver as a module, choose M here: the module
> -   will be called pwm-lpss-pci.
> -
>  config PWM_LPSS_PLATFORM
> - tristate "Intel LPSS PWM platform driver"
> + bool "Intel LPSS PWM platform driver"
>   depends on X86 && ACPI
>   select PWM_LPSS
>   help
> The platform driver for Intel Low Power Subsystem PWM controller.
>  
> -   To compile this driver as a module, choose M here: the module
> -   will be called pwm-lpss-platform.
> -
>  config PWM_MESON
>   tristate "Amlogic Meson PWM driver"
>   depends on ARCH_MESON
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 72c0bce..b4d8835 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -161,6 +161,12 @@ static const struct pwm_ops pwm_lpss_ops = {
>   .owner = THIS_MODULE,
>  };
>  
> +/* PWM consumed by the Intel GFX */
> +static struct pwm_lookup pwm_lpss_lookup[] = {
> + PWM_LOOKUP("pwm-lpss", 0, ":00:02.0", "pwm_backlight", 0,
> +PWM_POLARITY_NORMAL),
> +};
> +
>  struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
>const struct pwm_lpss_boardinfo *info)
>  {
> @@ -193,12 +199,17 @@ struct pwm_lpss_chip *pwm_lpss_probe(struct device 
> *dev, struct resource *r,
>   return ERR_PTR(ret);
>   }
>  
> + /* Add lookup table for pwm_backlight */
> + pwm_lpss_lookup[0].provider = dev_name(dev);
> + pwm_add_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
> +
>   return lpwm;
>  }
>  EXPORT_SYMBOL_GPL(pwm_lpss_probe);
>  
>  int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
>  {
> + pwm_remove_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
>   return pwmchip_remove(>chip);
>  }
>  EXPORT_SYMBOL_GPL(pwm_lpss_remove);

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 08/18] drm/i915/dsi: Document the panel enable / disable sequences from the spec

[Jani Nikula]

On Thu, 01 Dec 2016, Hans de Goede  wrote:
> Document the DSI panel enable / disable sequences from the spec,
> for easy comparison between the code and the spec.
>
> Signed-off-by: Hans de Goede 

I haven't done a proper review, but patches 1-8 are

Acked-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 64 
> 
>  1 file changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 229..85b748d 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -555,6 +555,70 @@ static void intel_dsi_prepare(struct intel_encoder 
> *intel_encoder,
> struct intel_crtc_state *pipe_config);
>  static void intel_dsi_unprepare(struct intel_encoder *encoder);
>  
> +/*
> + * Panel enable/disable sequences from the spec:
> + *
> + * v2 sequence for video mode:
> + * - power on
> + * - wait t1+t2
> + * - MIPIDeassertResetPin
> + * - clk/data lines to lp-11
> + * - MIPISendInitialDcsCmds
> + * - turn on DPI
> + * - MIPIDisplayOn
> + * - wait t5
> + * - backlight on
> + * ...
> + * - backlight off
> + * - wait t6
> + * - MIPIDisplayOff
> + * - turn off DPI
> + * - clk/data lines to lp-00
> + * - MIPIAssertResetPin
> + * - wait t3
> + * - power off
> + * - wait t4
> + *
> + * v3 sequence for video mode:
> + * - MIPIPanelPowerOn
> + * - MIPIDeassertResetPin
> + * - set clk/data lines to lp-11
> + * - MIPISendInitialDcsCmds (LP)
> + * - turn on DPI
> + * - MIPITearOn (command mode only) + MIPIDisplayOn (LP and HS)
> + * - MIPIBacklightOn
> + * ...
> + * - MIPIBacklightOff
> + * - turn off DPI
> + * - MIPITearOff + MIPIDisplayOff (LP)
> + * - clk/data lines to lp-00
> + * - MIPIAssertResetPin
> + * - MIPIPanelPowerOff
> + *
> + * sequence for command mode:
> + * - power on
> + * - wait t1+t2
> + * - MIPIDeassertResetPin
> + * - clk/data lines to lp-11
> + * - MIPISendInitialDcsCmds
> + * - MIPITearOn
> + * - MIPIDisplayOn
> + * - set pipe to dsr mode
> + * - wait t5
> + * - backlight on
> + * ... issue write_mem_start/write_mem_continue commands ...
> + * - backlight off
> + * - wait t6
> + * - disable pipe dsr mode
> + * - MIPITearOff
> + * - MIPIDisplayOff
> + * - clk/data lines to lp-00
> + * - MIPIAssertResetPin
> + * - wait t3
> + * - power off
> + * - wait t4
> + */
> +
>  static void intel_dsi_pre_enable(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config,
>struct drm_connector_state *conn_state)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences

[Jani Nikula]

On Thu, 01 Dec 2016, Hans de Goede  wrote:
> The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
> not fine grained enough to abstract all the different steps we need to
> take (and VBT sequences we need to exec) properly. So simply remove the
> panel _enable/disable and prepare/unprepare callbacks and instead
> export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c
> and call that from intel_dsi_enable/disable().
>
> No functional changes.

No functional changes, but this is quite a big design change between
intel_dsi.c and intel_dsi_panel_vbt.c. Originally the idea was to
separate the dsi core code and the panel specific code, letting one
write a panel driver that was not based on values in VBT. This patch
changes that.

Now I'm not sure if there'll ever be a panel driver not based on VBT,
and perhaps the current drm_panel based interface between two is not
enough in the end, nor prettiest. But after this patch, we might just as
well throw out the drm_panel interface, and refactor the division
between the two files completely. Indeed, if we accept the direction set
in this patch, that refactoring would be the logical next step.

I have not made up my mind about this yet. An alternative would be to
amend the drm_panel interface to achieve the kind of granularity you're
after in the follow-up patches. Indeed, such patches have been sent in
the past.

BR,
Jani.

>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c   | 14 +++---
>  drivers/gpu/drm/i915/intel_dsi.h   |  3 +++
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 
> ++
>  3 files changed, 15 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 85b748d..cf761e8 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -656,7 +656,10 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> *encoder,
>   /* put device in ready state */
>   intel_dsi_device_ready(encoder);
>  
> - drm_panel_prepare(intel_dsi->panel);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
>  
>   /* Enable port in pre-enable phase itself because as per hw team
>* recommendation, port should be enabled befor plane & pipe */
> @@ -669,7 +672,8 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> *encoder,
>   dpi_send_cmd(intel_dsi, TURN_ON, false, port);
>   msleep(100);
>  
> - drm_panel_enable(intel_dsi->panel);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>  
>   intel_dsi_port_enable(encoder);
>   }
> @@ -732,7 +736,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
> *encoder,
>* if disable packets are sent before sending shutdown packet then in
>* some next enable sequence send turn on packet error is observed
>*/
> - drm_panel_disable(intel_dsi->panel);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>  
>   intel_dsi_clear_device_ready(encoder);
>  
> @@ -746,7 +751,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
> *encoder,
>   I915_WRITE(DSPCLK_GATE_D, val);
>   }
>  
> - drm_panel_unprepare(intel_dsi->panel);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
>  
>   msleep(intel_dsi->panel_off_delay);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
> b/drivers/gpu/drm/i915/intel_dsi.h
> index d567823..5486491 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -132,6 +132,9 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct 
> drm_encoder *encoder)
>  
>  void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port);
>  
> +void intel_dsi_exec_vbt_sequence(struct intel_dsi *intel_dsi,
> +  enum mipi_seq seq_id);
> +
>  bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
>  int intel_compute_dsi_pll(struct intel_encoder *encoder,
> struct intel_crtc_state *config);
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index b5a02c6..f71f913 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -400,10 +400,9 @@ static const char *sequence_name(enum mipi_seq seq_id)
>   return "(unknown)";
>  }
>  
> -static void 

[PATCH] drm/etnaviv: move linear window on MC1.0 parts if necessary

[Lucas Stach]

On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU
linear window has to be moved for the GPU to work at all. This doesn't
mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear
window offset into account and will corrupt memory when used with a
non-zero offset.

Move the linear window if it's necessary for the GPU to work, but avoid
announcing FAST_CLEAR support to userspace in this case.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index b1254f885fed..4b697ad8bd64 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -639,6 +639,10 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
gpu->memory_base = PHYS_OFFSET;
else
gpu->memory_base = dma_mask - SZ_2G + 1;
+   } else if (PHYS_OFFSET >= SZ_2G) {
+   dev_info(gpu->dev, "Need to move linear window on MC1.0, 
disabling TS\n");
+   gpu->memory_base = PHYS_OFFSET;
+   gpu->identity.features &= ~chipFeatures_FAST_CLEAR;
}

ret = etnaviv_hw_reset(gpu);
-- 
2.10.2

[PATCH] drm: allow changing DPMS mode for non-CRTC displays

[Eric Engestrom]

On Thursday, 2016-12-01 14:15:05 +, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 03:30:01PM +0200, Marta Lofstedt wrote:
> > For non-CRTC displays,
> 
> A connector not attached to a CRTC works. It is the active connectors
> that were broken.
> 
> > the drm_atomic_helper_connector_dpms
> > will always set the connector back the old DPMS state
> > before returning. This makes it impossible to change
> > DPMS state.
> > 
> > fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd
> > 
> > Signed-off-by: Marta Lofstedt 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 494680c..6a5acb9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2885,8 +2885,8 @@ int drm_atomic_helper_connector_dpms(struct 
> > drm_connector *connector,
> >  fail:
> > if (ret == -EDEADLK)
> > goto backoff;
> > -
> > -   connector->dpms = old_mode;
> > +   if (ret != 0)
> > +   connector->dpms = old_mode;
> 
> Patch however is correct.
> 
> Fix the subject line to reflect the impact correctly, amend the fixes
> tag and add the appropriate CCs
> 
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Eric Engestrom 

Good catch!
Reviewed-by: Eric Engestrom 

I just had another look at the change (0853695c3ba4) and I don't believe
there was any other unintended behaviour change.

> Cc: Sean Paul 
> Cc: dri-devel at lists.freedesktop.org
> Cc: 
> 
> And mention if there was a testcase exercising the failure. If not
> please suggest one.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/vmwgfx: Switch to mode_cmd2

[Ville Syrjälä]

On Fri, Dec 02, 2016 at 08:07:40AM +0100, Daniel Vetter wrote:
> Surprisingly few changes needed to make it happen. Compile-tested
> only. The idea is that this replaces the 2 patches from Ville's big
> fb->format patch series as a prep patch. Only impact to later patches
> should be the one instace added in this patch where we look at
> fb->pixel_format (instead of fb->bpp and fb->depth), so minor
> adjustements in the cocci-generated patches needed.
> 
> v2: Restore pitch computation in vmw_fb_kms_framebuffer (Sinclair).
> 
> Cc: ville.syrjala at linux.intel.com
> Cc: Laurent Pinchart 
> Cc: linux-graphics-maintainer at vmware.com
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Reviewed-by: Sinclair Yeh 
> Signed-off-by: Daniel Vetter 

Ack from my side to merge this before my format dedup stuff. Means I can
just drop the vmwgfx patches from that series.

Acked-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |  19 +++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 116 
> +---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   2 +-
>  3 files changed, 53 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index d2d93959b119..723fd763da8e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -465,33 +465,34 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,
>  
>  static int vmw_fb_kms_framebuffer(struct fb_info *info)
>  {
> - struct drm_mode_fb_cmd mode_cmd;
> + struct drm_mode_fb_cmd2 mode_cmd;
>   struct vmw_fb_par *par = info->par;
>   struct fb_var_screeninfo *var = >var;
>   struct drm_framebuffer *cur_fb;
>   struct vmw_framebuffer *vfb;
> - int ret = 0;
> + int ret = 0, depth;
>   size_t new_bo_size;
>  
> - ret = vmw_fb_compute_depth(var, _cmd.depth);
> + ret = vmw_fb_compute_depth(var, );
>   if (ret)
>   return ret;
>  
>   mode_cmd.width = var->xres;
>   mode_cmd.height = var->yres;
> - mode_cmd.bpp = var->bits_per_pixel;
> - mode_cmd.pitch = ((mode_cmd.bpp + 7) / 8) * mode_cmd.width;
> + mode_cmd.pitches[0] = ((var->bits_per_pixel + 7) / 8) * mode_cmd.width;
> + mode_cmd.pixel_format =
> + drm_mode_legacy_fb_format(var->bits_per_pixel,
> + ((var->bits_per_pixel + 7) / 8) * mode_cmd.width);
>  
>   cur_fb = par->set_fb;
>   if (cur_fb && cur_fb->width == mode_cmd.width &&
>   cur_fb->height == mode_cmd.height &&
> - cur_fb->bits_per_pixel == mode_cmd.bpp &&
> - cur_fb->depth == mode_cmd.depth &&
> - cur_fb->pitches[0] == mode_cmd.pitch)
> + cur_fb->pixel_format == mode_cmd.pixel_format &&
> + cur_fb->pitches[0] == mode_cmd.pitches[0])
>   return 0;
>  
>   /* Need new buffer object ? */
> - new_bo_size = (size_t) mode_cmd.pitch * (size_t) mode_cmd.height;
> + new_bo_size = (size_t) mode_cmd.pitches[0] * (size_t) mode_cmd.height;
>   ret = vmw_fb_kms_detach(par,
>   par->bo_size < new_bo_size ||
>   par->bo_size > 2*new_bo_size,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index e3f68cc9bb4b..e7daf59bac80 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -516,7 +516,7 @@ static const struct drm_framebuffer_funcs 
> vmw_framebuffer_surface_funcs = {
>  static int vmw_kms_new_framebuffer_surface(struct vmw_private *dev_priv,
>  struct vmw_surface *surface,
>  struct vmw_framebuffer **out,
> -const struct drm_mode_fb_cmd
> +const struct drm_mode_fb_cmd2
>  *mode_cmd,
>  bool is_dmabuf_proxy)
>  
> @@ -525,6 +525,7 @@ static int vmw_kms_new_framebuffer_surface(struct 
> vmw_private *dev_priv,
>   struct vmw_framebuffer_surface *vfbs;
>   enum SVGA3dSurfaceFormat format;
>   int ret;
> + struct drm_format_name_buf format_name;
>  
>   /* 3D is only supported on HWv8 and newer hosts */
>   if (dev_priv->active_display_unit == vmw_du_legacy)
> @@ -548,21 +549,22 @@ static int vmw_kms_new_framebuffer_surface(struct 
> vmw_private *dev_priv,
>   return -EINVAL;
>   }
>  
> - switch (mode_cmd->depth) {
> - case 32:
> + switch (mode_cmd->pixel_format) {
> + case DRM_FORMAT_ARGB:
>   format = SVGA3D_A8R8G8B8;
>   break;
> - case 24:
> + case DRM_FORMAT_XRGB:
>   format = SVGA3D_X8R8G8B8;
>   break;
> - case 16:
> + case DRM_FORMAT_RGB565:
>   format = SVGA3D_R5G6B5;
>   break;
> - case 15:
> + case 

[PATCH] drm/etnaviv: don't invoke OOM killer from dump code

[Lucas Stach]

The dumper is only a debugging aid so we don't want to invoke the OOM
killer if buffer for the potentially large GPU state can't be vmalloced.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_dump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c 
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 2bef501d4a17..af65491a78e2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -160,7 +160,8 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
file_size += sizeof(*iter.hdr) * n_obj;

/* Allocate the file in vmalloc memory, it's likely to be big */
-   iter.start = vmalloc(file_size);
+   iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_HIGHMEM |
+  __GFP_NOWARN | __GFP_NORETRY, PAGE_KERNEL);
if (!iter.start) {
dev_warn(gpu->dev, "failed to allocate devcoredump file\n");
return;
-- 
2.10.2

[PATCH] drm: allow changing DPMS mode for non-CRTC displays

[Lofstedt, Marta]

> -Original Message-
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Thursday, December 1, 2016 4:15 PM
> To: Lofstedt, Marta 
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH] drm: allow changing DPMS mode for non-CRTC displays
> 
> On Thu, Dec 01, 2016 at 03:30:01PM +0200, Marta Lofstedt wrote:
> > For non-CRTC displays,
> 
> A connector not attached to a CRTC works. It is the active connectors that
> were broken.
> 
> > the drm_atomic_helper_connector_dpms
> > will always set the connector back the old DPMS state before
> > returning. This makes it impossible to change DPMS state.
> >
> > fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd
> >
> > Signed-off-by: Marta Lofstedt 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 494680c..6a5acb9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2885,8 +2885,8 @@ int drm_atomic_helper_connector_dpms(struct
> > drm_connector *connector,
> >  fail:
> > if (ret == -EDEADLK)
> > goto backoff;
> > -
> > -   connector->dpms = old_mode;
> > +   if (ret != 0)
> > +   connector->dpms = old_mode;
> 
> Patch however is correct.
> 
> Fix the subject line to reflect the impact correctly, amend the fixes tag and
> add the appropriate CCs
> 
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Eric Engestrom 
> Cc: Sean Paul 
> Cc: dri-devel at lists.freedesktop.org
> Cc: 
> 
> And mention if there was a testcase exercising the failure. If not please
> suggest one.


Thanks for the comments Chris.

About tests, I can't seem to find any test that is actually checking that we 
entered DPMS mode. The suggestion is to extend the kms_properties test, or 
maybe we should have a new dpms test. I CC Petri, so he can take part in such a 
discussion. 

/Marta

> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

[Lucas Stach]

Am Donnerstag, den 01.12.2016, 15:11 +0100 schrieb Michal Hocko:
> Let's also CC Marek
> 
> On Thu 01-12-16 08:43:40, Vlastimil Babka wrote:
> > On 12/01/2016 08:21 AM, Michal Hocko wrote:
> > > Forgot to CC Joonsoo. The email thread starts more or less here
> > > http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz
> > > 
> > > On Thu 01-12-16 08:15:07, Michal Hocko wrote:
> > > > On Wed 30-11-16 20:19:03, Robin H. Johnson wrote:
> > > > [...]
> > > > > alloc_contig_range: [83f2a3, 83f2a4) PFNs busy
> > > > 
> > > > Huh, do I get it right that the request was for a _single_ page? Why do
> > > > we need CMA for that?
> > 
> > Ugh, good point. I assumed that was just the PFNs that it failed to migrate
> > away, but it seems that's indeed the whole requested range. Yeah sounds some
> > part of the dma-cma chain could be smarter and attempt CMA only for e.g.
> > costly orders.
> 
> Is there any reason why the DMA api doesn't try the page allocator first
> before falling back to the CMA? I simply have a hard time to see why the
> CMA should be used (and fragment) for small requests size.

On x86 that is true, but on ARM CMA is the only (low memory) region that
can change the memory attributes, by being excluded from the lowmem
section mapping. Changing the memory attributes to
uncached/writecombined for DMA is crucial on ARM to fulfill the
requirement that no there aren't any conflicting mappings of the same
physical page.

On ARM we can possibly do the optimization of asking the page allocator,
but only if we can request _only_ highmem pages.

Regards,
Lucas

[PATCH 2/2] pwm: lpss: Add get_state callback

[Hans de Goede]

Add a get_state callback so that the initial state correctly reflects
the actual hardware state.

Signed-off-by: Hans de Goede 
---
 drivers/pwm/pwm-lpss.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index b4d8835..f5603c0 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -135,6 +135,33 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
return 0;
 }

+static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+  struct pwm_state *state)
+{
+   struct pwm_lpss_chip *lpwm = to_lpwm(chip);
+   unsigned long base_unit_range, freq;
+   unsigned long long base_unit, on_time_div;
+   u32 ctrl;
+
+   base_unit_range = BIT(lpwm->info->base_unit_bits);
+
+   ctrl = pwm_lpss_read(pwm);
+   on_time_div = ctrl & PWM_ON_TIME_DIV_MASK;
+   base_unit = (ctrl >> PWM_BASE_UNIT_SHIFT) & (base_unit_range - 1);
+
+   freq = base_unit * lpwm->info->clk_rate / base_unit_range;
+   if (freq == 0)
+   freq = 1;
+
+   state->period = NSEC_PER_SEC / freq;
+   state->duty_cycle = state->period * on_time_div / 255ULL;
+   state->polarity = PWM_POLARITY_NORMAL;
+   state->enabled = (ctrl & PWM_ENABLE) ? true : false;
+
+   if (state->enabled)
+   pm_runtime_get_sync(chip->dev);
+}
+
 static int pwm_lpss_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
pm_runtime_get_sync(chip->dev);
@@ -156,6 +183,7 @@ static void pwm_lpss_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)

 static const struct pwm_ops pwm_lpss_ops = {
.config = pwm_lpss_config,
+   .get_state = pwm_lpss_get_state,
.enable = pwm_lpss_enable,
.disable = pwm_lpss_disable,
.owner = THIS_MODULE,
-- 
2.9.3

[PATCH 1/2] pwm: lpss: Make builtin and add lookup-table so that i915 can find the pwm_backlight

[Hans de Goede]

The primary consumer of the lpss pwm is the i915 kms driver, but
currently that driver cannot get the pwm because i915 platforms are
not using devicetree and pwm-lpss does not call pwm_add_table.

Another problem is that i915 does not support get_pwm returning
-EPROBE_DEFER and i915's init is very complex and this is almost
impossible to fix.

This commit changes the PWM_LPSS Kconfig from a tristate to a bool, so
that when the i915 driver loads the lpss pwm will be available avoiding
the -EPROBE_DEFER issue. Note that this is identical to how the same
problem was solved for the pwm-crc driver.

Being builtin also allows calling pwm_add_table directly from the
pwm-lpss code, otherwise the pwm_add_table call would need to be put
somewhere else to ensure it happens before i915 calls pwm_get,
even if i915 would support -EPROBE_DEFER.

Signed-off-by: Hans de Goede 
---
 drivers/pwm/Kconfig| 12 +++-
 drivers/pwm/pwm-lpss.c | 11 +++
 2 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index bf01288..cda31ea 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -240,28 +240,22 @@ config PWM_LPC32XX
  will be called pwm-lpc32xx.

 config PWM_LPSS
-   tristate
+   bool

 config PWM_LPSS_PCI
-   tristate "Intel LPSS PWM PCI driver"
+   bool "Intel LPSS PWM PCI driver"
depends on X86 && PCI
select PWM_LPSS
help
  The PCI driver for Intel Low Power Subsystem PWM controller.

- To compile this driver as a module, choose M here: the module
- will be called pwm-lpss-pci.
-
 config PWM_LPSS_PLATFORM
-   tristate "Intel LPSS PWM platform driver"
+   bool "Intel LPSS PWM platform driver"
depends on X86 && ACPI
select PWM_LPSS
help
  The platform driver for Intel Low Power Subsystem PWM controller.

- To compile this driver as a module, choose M here: the module
- will be called pwm-lpss-platform.
-
 config PWM_MESON
tristate "Amlogic Meson PWM driver"
depends on ARCH_MESON
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 72c0bce..b4d8835 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -161,6 +161,12 @@ static const struct pwm_ops pwm_lpss_ops = {
.owner = THIS_MODULE,
 };

+/* PWM consumed by the Intel GFX */
+static struct pwm_lookup pwm_lpss_lookup[] = {
+   PWM_LOOKUP("pwm-lpss", 0, ":00:02.0", "pwm_backlight", 0,
+  PWM_POLARITY_NORMAL),
+};
+
 struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, struct resource *r,
 const struct pwm_lpss_boardinfo *info)
 {
@@ -193,12 +199,17 @@ struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev, 
struct resource *r,
return ERR_PTR(ret);
}

+   /* Add lookup table for pwm_backlight */
+   pwm_lpss_lookup[0].provider = dev_name(dev);
+   pwm_add_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
+
return lpwm;
 }
 EXPORT_SYMBOL_GPL(pwm_lpss_probe);

 int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
 {
+   pwm_remove_table(pwm_lpss_lookup, ARRAY_SIZE(pwm_lpss_lookup));
return pwmchip_remove(>chip);
 }
 EXPORT_SYMBOL_GPL(pwm_lpss_remove);
-- 
2.9.3

[PATCH 12/22] drm: bridge: dw-hdmi: Abstract the platform PHY configuration

[Jose Abreu]

Hi Laurent,


On 01-12-2016 23:43, Laurent Pinchart wrote:
> From: Kieran Bingham 
>
> Platforms implement the dw-hdmi with a separate PHY entity. It is
> configured over it's own I2C bus. To allow for different PHY's to be
> configured from the dw-hdmi driver, abstract the actual programming of
> the PHY to its own functions, as configured by the platform.
>
> Signed-off-by: Kieran Bingham 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c| 79 
> ++---
>  drivers/gpu/drm/imx/dw_hdmi-imx.c   |  2 +
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  1 +
>  include/drm/bridge/dw_hdmi.h| 12 +
>  4 files changed, 63 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 074ceb1e4897..06a44a2cdf3b 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -867,8 +867,8 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, 
> int msec)
>   return true;
>  }
>  
> -static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> -  unsigned char addr)
> +void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
> +unsigned char addr)
>  {
>   hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
>   hdmi_writeb(hdmi, addr, HDMI_PHY_I2CM_ADDRESS_ADDR);
> @@ -880,6 +880,7 @@ static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
> unsigned short data,
>   HDMI_PHY_I2CM_OPERATION_ADDR);
>   hdmi_phy_wait_i2c_done(hdmi, 1000);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
>  
>  static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
>  {
> @@ -930,38 +931,61 @@ static void dw_hdmi_phy_sel_interface_control(struct 
> dw_hdmi *hdmi, u8 enable)
>HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
>  
> -static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> -   enum dw_hdmi_resolution res_idx, int cscon)
> +int dw_hdmi_phy_configure_synopsys(struct dw_hdmi *hdmi,
> +const struct dw_hdmi_plat_data *pdata,
> +unsigned long mpixelclock,
> +enum dw_hdmi_resolution resolution)
> +
>  {
> - u8 val, msec;
> - const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
>   const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
>   const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
>   const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
>  
>   /* PLL/MPLL Cfg - always match on final entry */
>   for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - mpll_config->mpixelclock)
> + if (mpixelclock <= mpll_config->mpixelclock)
>   break;
>  
>   for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - curr_ctrl->mpixelclock)
> + if (mpixelclock <= curr_ctrl->mpixelclock)
>   break;
>  
>   for (; phy_config->mpixelclock != ~0UL; phy_config++)
> - if (hdmi->hdmi_data.video_mode.mpixelclock <=
> - phy_config->mpixelclock)
> + if (mpixelclock <= phy_config->mpixelclock)
>   break;
>  
>   if (mpll_config->mpixelclock == ~0UL ||
>   curr_ctrl->mpixelclock == ~0UL ||
> - phy_config->mpixelclock == ~0UL) {
> - dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
> - hdmi->hdmi_data.video_mode.mpixelclock);
> + phy_config->mpixelclock == ~0UL)
>   return -EINVAL;
> - }
> +
> + dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[resolution].cpce, 0x06);
> + dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[resolution].gmp, 0x15);
> +
> + /* CURRCTRL */
> + dw_hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[resolution], 0x10);
> +
> + dw_hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
> + dw_hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
> +
> + dw_hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19); /* TXTERM */
> + dw_hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL 
> */
> + dw_hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
> +
> + /* REMOVE CLK TERM */
> + dw_hdmi_phy_i2c_write(hdmi, 0x8000, 0x05); /* CKCALCTRL */
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_configure_synopsys);
> +
> +static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> +   enum dw_hdmi_resolution resolution, int cscon)
> +{
> + const struct 

[PATCH 00/22] R-Car Gen3 HDMI output support

[Jose Abreu]

Hi Laurent,


On 01-12-2016 23:43, Laurent Pinchart wrote:
> Hello,
>
> This patch series implements support for the HDMI output on Renesas R-Car Gen3
> SoCs, and more specifically on the R-Car H3.
>
> R-Car Gen3 SoCs include one or multiple Synopsys DWC HDMI TX controllers. The
> series thus starts with 13 cleanup or feature patches for the dw-hdmi driver.
> Patches 01/22 to 05/22 are small miscellaneous cleanups. Patch 06/22 fixes a
> crash when the HPD interrupt is generated before the bridge gets attached to a
> DRM device.
>
> Patch 07/22 then starts refactoring the API towards platform glue by moving
> common I/O and clock resource allocation to common code. Patches 08/22 and
> 09/22 continue by moving connector creation to the bridge attach operation to
> comply with the DRM bridge API. Patch 10/22 implements a new API for platform
> glue to register the bridge with the DRM core, for platform that doesn't use
> the component framework. Patches 11/22 to 13/22 finally abstract PHY setup to
> allow platforms to implement configuration for custom PHYs.
>
> The next three patches add glue code for the DWC HDMI on Renesas R-Car Gen3
> platforms. Patch 14/22 rework the DWC HDMI DT bindings to make them more
> modular, and patch 15/22 makes use of them to document the R-Car Gen DWC HDMI
> TX DT bindings. Patch 16/22 then implements the platform glue code.
>
> The next three patches implement support for the R8A7795 HDMI outputs in the
> R-Car DU driver. Patch 17/22 fixes a bug that makes the driver defer probe
> forever if an encoder is disabled. Patch 18/22 implement DPLL support to
> generate more precise clocks required by the HDMI controller, and patch 19/22
> then enables the two HDMI output on the R-Car H3 SoC.
>
> The last three patches enable the HDMI outputs on the H3 Salvator-X board by
> adding the HDMI encoders to the R-Car H3 DT (20/22), adding HDMI connectors
> and enabling the encoders (21/22) and adding the external dot clocks (22/22).
>
> The code has been tested on a Renesas Salvator-X H3 board, and modifications
> to the dw-hdmi Freescale and Rockchip platform glues have been compile-tested.
>
> More improvements to the dw-hdmi driver would be beneficial. The PHY
> modularization is based on the limited understanding of the HDMI PHYs used on
> the three supported platforms and will possibly be enhanced later when adding
> support for more platforms. The DT bindings would also benefit from a
> standardized definition of the ports, and the reg-io-width property could
> possibly be deprecated in favour of encoding the information in platform glue
> code. The patch series is however big enough as is to be submitted for review
> and merge before the dw-hdmi driver achieves perfection.
>
> Kieran Bingham (4):
>   drm: bridge: dw-hdmi: Remove unused function parameter
>   drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter
>   drm: bridge: dw-hdmi: Abstract the platform PHY configuration
>   drm: bridge: dw-hdmi: Replace device type with platform quirks
>
> Koji Matsuoka (4):
>   drm: rcar-du: Add Gen3 HDMI encoder support
>   drm: rcar-du: Add DPLL support
>   drm: rcar-du: Add HDMI outputs to R8A7795 device description
>   arm64: dts: r8a7795: salvator-x: Enable HDMI outputs
>
> Laurent Pinchart (13):
>   drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and
> hdmi_phy_i2c_write
>   drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind
> functions
>   drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi
>   drm: bridge: dw-hdmi: Remove encoder field from struct dw_hdmi
>   drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before
> attach
>   drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common
> code
>   drm: bridge: dw-hdmi: Reorder functions to prepare for next commit
>   drm: bridge: dw-hdmi: Create connector in the bridge attach operation
>   drm: bridge: dw-hdmi: Implement DRM bridge registration
>   dt-bindings: display: dw-hdmi: Clean up DT bindings documentation
>   dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings
>   drm: rcar-du: Skip disabled outputs
>   arm64: dts: r8a7795: salvator-x: Add DU1 and DU2 external dot clocks
>
> Ulrich Hecht (1):
>   arm64: dts: r8a7795: Add HDMI encoder support
>
>  .../devicetree/bindings/display/bridge/dw_hdmi.txt |  85 ++---
>  .../bindings/display/bridge/renesas,dw-hdmi.txt|  75 +
>  .../devicetree/bindings/display/imx/hdmi.txt   |  51 +--
>  .../bindings/display/rockchip/dw_hdmi-rockchip.txt |  43 ++-
>  MAINTAINERS|   1 +
>  arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  73 +
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  50 +++
>  drivers/gpu/drm/bridge/dw-hdmi.c   | 364 
> -
>  drivers/gpu/drm/bridge/dw-hdmi.h   |   4 +-
>  drivers/gpu/drm/imx/dw_hdmi-imx.c  |  19 +-
>  drivers/gpu/drm/rcar-du/Kconfig  

[PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

[Sean Paul]

On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja  
wrote:
> Hi,
>
> On 12/02/2016 08:02 AM, zain wang wrote:
>>
>> We will ignored PSR setting if panel not support it. So, in this case, we
>> should
>> return from analogix_dp_enable/disable_psr() without any error code.
>> Let's retrun 0 instead of -EINVAL when panel not support PSR in
>> analogix_dp_enable/disable_psr().
>>
>> Signed-off-by: zain wang 
>> ---
>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 6e0447f..0cb3695 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -112,7 +112,7 @@ int analogix_dp_enable_psr(struct device *dev)
>> struct edp_vsc_psr psr_vsc;
>>
>> if (!dp->psr_support)
>> -   return -EINVAL;
>> +   return 0;
>
>
> Looking at the rockchip analogix dp code, in analogix_dp_psr_set, the worker
> that calls
> analogix_dp_enable/disable_psr isn't even if psr isn't enabled. So, the
> bridge funcs
> shouldn't be called in the first place. I think the error handling is fine
> to have
> here.
>

Hi Archit,

This was my first impression, too, and the complexity of the various
psr abstraction layers don't help :)

However, this code path will be hit if the source supports psr, but
the sink doesn't. The rockchip_drm_psr code doesn't know if the sink
supports psr, so it will end up calling this.

Sean


>>
>> /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>> memset(_vsc, 0, sizeof(psr_vsc));
>> @@ -135,7 +135,7 @@ int analogix_dp_disable_psr(struct device *dev)
>> struct edp_vsc_psr psr_vsc;
>>
>> if (!dp->psr_support)
>> -   return -EINVAL;
>> +   return 0;
>>
>> /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>> memset(_vsc, 0, sizeof(psr_vsc));
>> @@ -878,6 +878,8 @@ static void analogix_dp_commit(struct
>> analogix_dp_device *dp)
>> dp->psr_support = analogix_dp_detect_sink_psr(dp);
>> if (dp->psr_support)
>> analogix_dp_enable_sink_psr(dp);
>> +   else
>> +   dev_warn(dp->dev, "Sink not support PSR\n");
>
>
> This doesn't seem beneficial either. There seems to be a debug
> print already in analogix_dp_detect_sink_psr which reports PSR
> related info.
>
> Archit
>
>>  }
>>
>>  /*
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

[PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

[zain wang]

We will ignored PSR setting if panel not support it. So, in this case, we should
return from analogix_dp_enable/disable_psr() without any error code.
Let's retrun 0 instead of -EINVAL when panel not support PSR in
analogix_dp_enable/disable_psr().

Signed-off-by: zain wang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6e0447f..0cb3695 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -112,7 +112,7 @@ int analogix_dp_enable_psr(struct device *dev)
struct edp_vsc_psr psr_vsc;

if (!dp->psr_support)
-   return -EINVAL;
+   return 0;

/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
memset(_vsc, 0, sizeof(psr_vsc));
@@ -135,7 +135,7 @@ int analogix_dp_disable_psr(struct device *dev)
struct edp_vsc_psr psr_vsc;

if (!dp->psr_support)
-   return -EINVAL;
+   return 0;

/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
memset(_vsc, 0, sizeof(psr_vsc));
@@ -878,6 +878,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
dp->psr_support = analogix_dp_detect_sink_psr(dp);
if (dp->psr_support)
analogix_dp_enable_sink_psr(dp);
+   else
+   dev_warn(dp->dev, "Sink not support PSR\n");
 }

 /*
-- 
1.9.1

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

[Jerome Glisse]

On Fri, Dec 02, 2016 at 11:26:02AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 01.12.2016, 15:11 +0100 schrieb Michal Hocko:
> > Let's also CC Marek
> > 
> > On Thu 01-12-16 08:43:40, Vlastimil Babka wrote:
> > > On 12/01/2016 08:21 AM, Michal Hocko wrote:
> > > > Forgot to CC Joonsoo. The email thread starts more or less here
> > > > http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz
> > > > 
> > > > On Thu 01-12-16 08:15:07, Michal Hocko wrote:
> > > > > On Wed 30-11-16 20:19:03, Robin H. Johnson wrote:
> > > > > [...]
> > > > > > alloc_contig_range: [83f2a3, 83f2a4) PFNs busy
> > > > > 
> > > > > Huh, do I get it right that the request was for a _single_ page? Why 
> > > > > do
> > > > > we need CMA for that?
> > > 
> > > Ugh, good point. I assumed that was just the PFNs that it failed to 
> > > migrate
> > > away, but it seems that's indeed the whole requested range. Yeah sounds 
> > > some
> > > part of the dma-cma chain could be smarter and attempt CMA only for e.g.
> > > costly orders.
> > 
> > Is there any reason why the DMA api doesn't try the page allocator first
> > before falling back to the CMA? I simply have a hard time to see why the
> > CMA should be used (and fragment) for small requests size.
> 
> On x86 that is true, but on ARM CMA is the only (low memory) region that
> can change the memory attributes, by being excluded from the lowmem
> section mapping. Changing the memory attributes to
> uncached/writecombined for DMA is crucial on ARM to fulfill the
> requirement that no there aren't any conflicting mappings of the same
> physical page.
> 
> On ARM we can possibly do the optimization of asking the page allocator,
> but only if we can request _only_ highmem pages.
> 

So this memory allocation strategy should only apply to ARM and not x86 we
already had fall out couple year ago when Ubuntu decided to enable CMA on
x86 where it does not make sense as i don't think we have any single device
we care that is not behind an IOMMU and thus does not require contiguous
memory allocation.

The DMA API should only use CMA on architecture where it is necessary not
on all of them.

Cheers,
Jérôme

[PATCH 2/2] drm/panel: simple: Add support for Tianma TM070JDHG30

[Gary Bisson]

The Tianma TM070JDHG30 is a 7" LVDS display with a resolution of
1280x800.
http://usa.tianma.com/products-technology/product/tm070jdhg30-00

You can also find this product along with a FT5x06 touch controller
from Boundary Devices:
https://boundarydevices.com/product/bd070lic2/

Signed-off-by: Gary Bisson 
---
 .../bindings/display/panel/tianma,tm070jdhg30.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt 
b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt
new file mode 100644
index 000..eb9501a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt
@@ -0,0 +1,7 @@
+Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "tianma,tm070jdhg30"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..bc3dd46 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1471,6 +1471,30 @@ static const struct panel_desc starry_kr122ea0sra = {
},
 };

+static const struct display_timing tianma_tm070jdhg30_timing = {
+   .pixelclock = { 6260, 6820, 7810 },
+   .hactive = { 1280, 1280, 1280 },
+   .hfront_porch = { 15, 64, 159 },
+   .hback_porch = { 5, 5, 5 },
+   .hsync_len = { 1, 1, 256 },
+   .vactive = { 800, 800, 800 },
+   .vfront_porch = { 3, 40, 99 },
+   .vback_porch = { 2, 2, 2 },
+   .vsync_len = { 1, 1, 128 },
+   .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc tianma_tm070jdhg30 = {
+   .timings = _tm070jdhg30_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 151,
+   .height = 95,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+};
+
 static const struct drm_display_mode tpk_f07a_0102_mode = {
.clock = 33260,
.hdisplay = 800,
@@ -1689,6 +1713,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "starry,kr122ea0sra",
.data = _kr122ea0sra,
}, {
+   .compatible = "tianma,tm070jdhg30",
+   .data = _tm070jdhg30,
+   }, {
.compatible = "tpk,f07a-0102",
.data = _f07a_0102,
}, {
-- 
2.9.3

[PATCH 1/2] of: Add vendor prefix for Tianma Micro-electronics

[Gary Bisson]

Tianma Micro-electronics Co., Ltd. (Tianma) specializes in providing
display solutions and efficient support services worldwide.

More info:
http://en.tianma.com/about.shtml

Signed-off-by: Gary Bisson 
---
 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 163f84b..3d1ec68 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -291,6 +291,7 @@ technologic Technologic Systems
 terasicTerasic Inc.
 thine  THine Electronics, Inc.
 ti Texas Instruments
+tianma Tianma Micro-electronics Co., Ltd.
 tlmTrusted Logic Mobility
 topeet  Topeet
 toradexToradex AG
-- 
2.9.3

[PATCH 0/2] Add support for Tianma TM070JDHG30 display

[Gary Bisson]

Hi all,

This series adds support for the Tianma TM070JDHG30 7" display (1280x800).
http://usa.tianma.com/products-technology/product/tm070jdhg30-00
https://boundarydevices.com/product/bd070lic2/

The first patch adds Tianma as a new vendor prefix whereas the second patch
adds the display to the simple panel driver.

Regards,
Gary

Gary Bisson (2):
  of: Add vendor prefix for Tianma Micro-electronics
  drm/panel: simple: Add support for Tianma TM070JDHG30

 .../bindings/display/panel/tianma,tm070jdhg30.txt  |  7 ++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 3 files changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt

-- 
2.9.3

[PATCH] drm/vmwgfx: Switch to mode_cmd2

[Sinclair Yeh]

On Fri, Dec 02, 2016 at 08:00:22AM +0100, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 03:09:40PM -0800, Sinclair Yeh wrote:
> > One defect below otherwise:  Reviewed-by: Sinclair Yeh 
> > 
> > On Wed, Nov 30, 2016 at 06:00:04PM +0100, Daniel Vetter wrote:
> > > Surprisingly few changes needed to make it happen. Compile-tested
> > > only. The idea is that this replaces the 2 patches from Ville's big
> > > fb->format patch series as a prep patch. Only impact to later patches
> > > should be the one instace added in this patch where we look at
> > > fb->pixel_format (instead of fb->bpp and fb->depth), so minor
> > > adjustements in the cocci-generated patches needed.
> > > 
> > > Cc: ville.syrjala at linux.intel.com
> > > Cc: Laurent Pinchart 
> > > Cc: linux-graphics-maintainer at vmware.com
> > > Cc: Sinclair Yeh 
> > > Cc: Thomas Hellstrom 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |  18 +++---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 116 
> > > +---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   2 +-
> > >  3 files changed, 52 insertions(+), 84 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > > index d2d93959b119..4b1defc7aa6d 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > > @@ -465,33 +465,33 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,
> > >  
> > >  static int vmw_fb_kms_framebuffer(struct fb_info *info)
> > >  {
> > > - struct drm_mode_fb_cmd mode_cmd;
> > > + struct drm_mode_fb_cmd2 mode_cmd;
> > >   struct vmw_fb_par *par = info->par;
> > >   struct fb_var_screeninfo *var = >var;
> > >   struct drm_framebuffer *cur_fb;
> > >   struct vmw_framebuffer *vfb;
> > > - int ret = 0;
> > > + int ret = 0, depth;
> > >   size_t new_bo_size;
> > >  
> > > - ret = vmw_fb_compute_depth(var, _cmd.depth);
> > > + ret = vmw_fb_compute_depth(var, );
> > >   if (ret)
> > >   return ret;
> > >  
> > >   mode_cmd.width = var->xres;
> > >   mode_cmd.height = var->yres;
> > > - mode_cmd.bpp = var->bits_per_pixel;
> > > - mode_cmd.pitch = ((mode_cmd.bpp + 7) / 8) * mode_cmd.width;
> > 
> > mode_cmd.pitches[0] needs to be initialized before being used below.
> > 
> > Maybe something like:
> > mode_cmd.pitches[0] = ((var->bits_per_pixel + 7) / 8) * mode_cmd.width;
> 
> Oh right, I deleted a bit too much here. Once fixed, ok if I merge this
> through drm-misc so that Ville can throw his fb->format conversion on top?

Sure, thanks for doing this!

[Intel-gfx] [PATCH 1/3] drm: Add a new connector atomic property for link status

[Manasi Navare]

On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's possible we can't reach this in practice. The DP
> > spec describes how the link should be reduced, but we can't reduce
> > the link below the requirements of the mode. Black screen follows.
> > 
> > One idea would be to have setcrtc return a failure. However, it
> > already should not fail as the atomic checks have passed. It would
> > also conflict with the idea of making setcrtc asynchronous in the
> > future, returning before the actual mode setting and link training.
> > 
> > Another idea is to train the link "upfront" at hotplug time, before
> > pruning the mode list, so that we can do the pruning based on
> > practical not theoretical capabilities. However, the changes for link
> > training are pretty drastic, all for the sake of error handling and
> > DP compliance, when the most common happy day scenario is the current
> > approach of link training at mode setting time, using the optimal
> > parameters for the mode. It is also not certain all hardware could do
> > this without the pipe on; not even all our hardware can do this. Some
> > of this can be solved, but not trivially.
> > 
> > Both of the above ideas also fail to address link degradation *during*
> > operation.
> > 
> > The solution is to add a new "link-status" connector property in order
> > to address link training failure in a way that:
> > a) changes the current happy day scenario as little as possible, to
> > avoid regressions, b) can be implemented the same way by all drm
> > drivers, c) is still opt-in for the drivers and userspace, and opting
> > out doesn't regress the user experience, d) doesn't prevent drivers
> > from implementing better or alternate approaches, possibly without
> > userspace involvement. And, of course, handles all the issues presented.
> > In the usual happy day scenario, this is always "good". If something
> > fails during or after a mode set, the kernel driver can set the link
> > status to "bad" and issue a hotplug uevent for userspace to have it
> > re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> > again. If the theoretical capabilities of the link can't be reached,
> > the mode list is trimmed based on that.
> > 
> > v4:
> > * Add comments in kernel-doc format (Daniel Vetter)
> > * Update the kernel-doc for link-status (Sean Paul)
> > v3:
> > * Fixed a build error (Jani Saarinen)
> > v2:
> > * Removed connector->link_status (Daniel Vetter)
> > * Set connector->state->link_status in 
> > drm_mode_connector_set_link_status_property
> > (Daniel Vetter)
> > * Set the connector_changed flag to true if connector->state->link_status 
> > changed.
> > * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> > * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
> > 
> > Acked-by: Tony Cheng 
> > Acked-by: Harry Wentland 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Cc: Chris Wilson 
> > Cc: Sean Paul 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 10 +++
> >  drivers/gpu/drm/drm_atomic_helper.c |  8 ++
> >  drivers/gpu/drm/drm_connector.c | 54 
> > -
> >  include/drm/drm_connector.h | 19 +
> >  include/drm/drm_mode_config.h   |  5 
> >  include/uapi/drm/drm_mode.h |  4 +++
> >  6 files changed, 99 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 89737e4..990f013 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> >  * now?) atomic writes to DPMS property:
> >  */
> > return -EINVAL;
> > +   } else if (property == config->link_status_property) {
> > +   /* Never downgrade from GOOD to BAD on userspace's request here,
> > +* only hw issues can do that.
> > +*/
> > +   if (state->link_status == DRM_LINK_STATUS_GOOD)
> > +   return 0;
> > +   state->link_status = val;
> > +   return 0;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct 
> > drm_printer *p,
> > *val = (state->crtc) ? state->crtc->base.id : 0;
> > } else if (property == config->dpms_property) {
> > *val = connector->dpms;
> > +   } else if (property == config->link_status_property) {
> > +   *val = 

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

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

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

Zoltán Böszörményi  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/DRI/i965
 QA Contact|dri-devel at lists.freedesktop |intel-3d-bugs at 
lists.freedes
   |.org|ktop.org
   Assignee|dri-devel at lists.freedesktop |intel-3d-bugs at 
lists.freedes
   |.org|ktop.org

-- 
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/20161202/6461598c/attachment-0001.html>

[Bug 98964] Chromium complains about glXGetSyncValuesOML in 13.0.2

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

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

Bug ID: 98964
   Summary: Chromium complains about glXGetSyncValuesOML in 13.0.2
   Product: Mesa
   Version: 13.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: zboszor at pr.hu
QA Contact: dri-devel at lists.freedesktop.org

Hi,

I am running Chromium 52.0.2743.76 on Yocto with Mesa 13.0.2 / libdrm 2.4.73.

It occasionally complains about this:

[1347:1347:1202/032132:ERROR:sync_control_vsync_provider.cc(64)]
glXGetSyncValuesOML should not return TRUE with a media stream counter of 0.

Conformance 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/20161202/46dbbfaa/attachment.html>

[PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

[Archit Taneja]

Hi,

On 12/02/2016 08:02 AM, zain wang wrote:
> We will ignored PSR setting if panel not support it. So, in this case, we 
> should
> return from analogix_dp_enable/disable_psr() without any error code.
> Let's retrun 0 instead of -EINVAL when panel not support PSR in
> analogix_dp_enable/disable_psr().
>
> Signed-off-by: zain wang 
> ---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 6e0447f..0cb3695 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -112,7 +112,7 @@ int analogix_dp_enable_psr(struct device *dev)
>   struct edp_vsc_psr psr_vsc;
>
>   if (!dp->psr_support)
> - return -EINVAL;
> + return 0;

Looking at the rockchip analogix dp code, in analogix_dp_psr_set, the worker 
that calls
analogix_dp_enable/disable_psr isn't even if psr isn't enabled. So, the bridge 
funcs
shouldn't be called in the first place. I think the error handling is fine to 
have
here.

>
>   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>   memset(_vsc, 0, sizeof(psr_vsc));
> @@ -135,7 +135,7 @@ int analogix_dp_disable_psr(struct device *dev)
>   struct edp_vsc_psr psr_vsc;
>
>   if (!dp->psr_support)
> - return -EINVAL;
> + return 0;
>
>   /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>   memset(_vsc, 0, sizeof(psr_vsc));
> @@ -878,6 +878,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>   dp->psr_support = analogix_dp_detect_sink_psr(dp);
>   if (dp->psr_support)
>   analogix_dp_enable_sink_psr(dp);
> + else
> + dev_warn(dp->dev, "Sink not support PSR\n");

This doesn't seem beneficial either. There seems to be a debug
print already in analogix_dp_detect_sink_psr which reports PSR
related info.

Archit

>  }
>
>  /*
>

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

[Bug 189451] UVD not responding with Mobility Radeon HD 5650

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

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

Christian König  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #1 from Christian König  ---
Could be that HP wired up the hardware in a special way or even disabled the
block for some reason. I would need access to the hardware to figure out in
detail what is going wrong here.

Did that ever worked? If yes bisecting when it started to fail might be a good
idea.

Apart from that while it is a bit annoying, the error message is harmless
otherwise isn't it?

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

[PATCH v2 2/7] drm: Turn DRM_MODE_SUBCONNECTOR_xx definitions into an enum

[Daniel Vetter]

On Thu, Dec 01, 2016 at 09:09:25PM +0100, Boris Brezillon wrote:
> List of values like the DRM_MODE_SUBCONNECTOR_xx ones are better
> represented with enums.
> 
> Turn the DRM_MODE_SUBCONNECTOR_xx macros into an enum.
> 
> Signed-off-by: Boris Brezillon 
> Suggested-by: Daniel Vetter 

Yeah, this is new and maybe we'll regret it, but I think it's worth a
shot. And would make kernel internal code look prettier. If it works out
we can roll it out as a new best practice everywhere.

Reviewed-by: Daniel Vetter 

> ---
>  include/uapi/drm/drm_mode.h | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index df0e3504c349..970bfc0d7107 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -220,14 +220,16 @@ struct drm_mode_get_encoder {
>  
>  /* This is for connectors with multiple signal types. */
>  /* Try to match DRM_MODE_CONNECTOR_X as closely as possible. */
> -#define DRM_MODE_SUBCONNECTOR_Automatic  0
> -#define DRM_MODE_SUBCONNECTOR_Unknown0
> -#define DRM_MODE_SUBCONNECTOR_DVID   3
> -#define DRM_MODE_SUBCONNECTOR_DVIA   4
> -#define DRM_MODE_SUBCONNECTOR_Composite  5
> -#define DRM_MODE_SUBCONNECTOR_SVIDEO 6
> -#define DRM_MODE_SUBCONNECTOR_Component  8
> -#define DRM_MODE_SUBCONNECTOR_SCART  9
> +enum drm_mode_subconnector {
> + DRM_MODE_SUBCONNECTOR_Automatic = 0,
> + DRM_MODE_SUBCONNECTOR_Unknown = 0,
> + DRM_MODE_SUBCONNECTOR_DVID = 3,
> + DRM_MODE_SUBCONNECTOR_DVIA = 4,
> + DRM_MODE_SUBCONNECTOR_Composite = 5,
> + DRM_MODE_SUBCONNECTOR_SVIDEO = 6,
> + DRM_MODE_SUBCONNECTOR_Component = 8,
> + DRM_MODE_SUBCONNECTOR_SCART = 9,
> +};
>  
>  #define DRM_MODE_CONNECTOR_Unknown   0
>  #define DRM_MODE_CONNECTOR_VGA   1
> -- 
> 2.7.4
> 

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

[PATCH] drm/vmwgfx: Switch to mode_cmd2

[Daniel Vetter]

Surprisingly few changes needed to make it happen. Compile-tested
only. The idea is that this replaces the 2 patches from Ville's big
fb->format patch series as a prep patch. Only impact to later patches
should be the one instace added in this patch where we look at
fb->pixel_format (instead of fb->bpp and fb->depth), so minor
adjustements in the cocci-generated patches needed.

v2: Restore pitch computation in vmw_fb_kms_framebuffer (Sinclair).

Cc: ville.syrjala at linux.intel.com
Cc: Laurent Pinchart 
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |  19 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 116 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   2 +-
 3 files changed, 53 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index d2d93959b119..723fd763da8e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -465,33 +465,34 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,

 static int vmw_fb_kms_framebuffer(struct fb_info *info)
 {
-   struct drm_mode_fb_cmd mode_cmd;
+   struct drm_mode_fb_cmd2 mode_cmd;
struct vmw_fb_par *par = info->par;
struct fb_var_screeninfo *var = >var;
struct drm_framebuffer *cur_fb;
struct vmw_framebuffer *vfb;
-   int ret = 0;
+   int ret = 0, depth;
size_t new_bo_size;

-   ret = vmw_fb_compute_depth(var, _cmd.depth);
+   ret = vmw_fb_compute_depth(var, );
if (ret)
return ret;

mode_cmd.width = var->xres;
mode_cmd.height = var->yres;
-   mode_cmd.bpp = var->bits_per_pixel;
-   mode_cmd.pitch = ((mode_cmd.bpp + 7) / 8) * mode_cmd.width;
+   mode_cmd.pitches[0] = ((var->bits_per_pixel + 7) / 8) * mode_cmd.width;
+   mode_cmd.pixel_format =
+   drm_mode_legacy_fb_format(var->bits_per_pixel,
+   ((var->bits_per_pixel + 7) / 8) * mode_cmd.width);

cur_fb = par->set_fb;
if (cur_fb && cur_fb->width == mode_cmd.width &&
cur_fb->height == mode_cmd.height &&
-   cur_fb->bits_per_pixel == mode_cmd.bpp &&
-   cur_fb->depth == mode_cmd.depth &&
-   cur_fb->pitches[0] == mode_cmd.pitch)
+   cur_fb->pixel_format == mode_cmd.pixel_format &&
+   cur_fb->pitches[0] == mode_cmd.pitches[0])
return 0;

/* Need new buffer object ? */
-   new_bo_size = (size_t) mode_cmd.pitch * (size_t) mode_cmd.height;
+   new_bo_size = (size_t) mode_cmd.pitches[0] * (size_t) mode_cmd.height;
ret = vmw_fb_kms_detach(par,
par->bo_size < new_bo_size ||
par->bo_size > 2*new_bo_size,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index e3f68cc9bb4b..e7daf59bac80 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -516,7 +516,7 @@ static const struct drm_framebuffer_funcs 
vmw_framebuffer_surface_funcs = {
 static int vmw_kms_new_framebuffer_surface(struct vmw_private *dev_priv,
   struct vmw_surface *surface,
   struct vmw_framebuffer **out,
-  const struct drm_mode_fb_cmd
+  const struct drm_mode_fb_cmd2
   *mode_cmd,
   bool is_dmabuf_proxy)

@@ -525,6 +525,7 @@ static int vmw_kms_new_framebuffer_surface(struct 
vmw_private *dev_priv,
struct vmw_framebuffer_surface *vfbs;
enum SVGA3dSurfaceFormat format;
int ret;
+   struct drm_format_name_buf format_name;

/* 3D is only supported on HWv8 and newer hosts */
if (dev_priv->active_display_unit == vmw_du_legacy)
@@ -548,21 +549,22 @@ static int vmw_kms_new_framebuffer_surface(struct 
vmw_private *dev_priv,
return -EINVAL;
}

-   switch (mode_cmd->depth) {
-   case 32:
+   switch (mode_cmd->pixel_format) {
+   case DRM_FORMAT_ARGB:
format = SVGA3D_A8R8G8B8;
break;
-   case 24:
+   case DRM_FORMAT_XRGB:
format = SVGA3D_X8R8G8B8;
break;
-   case 16:
+   case DRM_FORMAT_RGB565:
format = SVGA3D_R5G6B5;
break;
-   case 15:
+   case DRM_FORMAT_XRGB1555:
format = SVGA3D_A1R5G5B5;
break;
default:
-   DRM_ERROR("Invalid color depth: %d\n", mode_cmd->depth);
+   DRM_ERROR("Invalid pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format, 
_name));

[PATCH] drm/vmwgfx: Switch to mode_cmd2

[Daniel Vetter]

On Thu, Dec 01, 2016 at 03:09:40PM -0800, Sinclair Yeh wrote:
> One defect below otherwise:  Reviewed-by: Sinclair Yeh 
> 
> On Wed, Nov 30, 2016 at 06:00:04PM +0100, Daniel Vetter wrote:
> > Surprisingly few changes needed to make it happen. Compile-tested
> > only. The idea is that this replaces the 2 patches from Ville's big
> > fb->format patch series as a prep patch. Only impact to later patches
> > should be the one instace added in this patch where we look at
> > fb->pixel_format (instead of fb->bpp and fb->depth), so minor
> > adjustements in the cocci-generated patches needed.
> > 
> > Cc: ville.syrjala at linux.intel.com
> > Cc: Laurent Pinchart 
> > Cc: linux-graphics-maintainer at vmware.com
> > Cc: Sinclair Yeh 
> > Cc: Thomas Hellstrom 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |  18 +++---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 116 
> > +---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   2 +-
> >  3 files changed, 52 insertions(+), 84 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > index d2d93959b119..4b1defc7aa6d 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > @@ -465,33 +465,33 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,
> >  
> >  static int vmw_fb_kms_framebuffer(struct fb_info *info)
> >  {
> > -   struct drm_mode_fb_cmd mode_cmd;
> > +   struct drm_mode_fb_cmd2 mode_cmd;
> > struct vmw_fb_par *par = info->par;
> > struct fb_var_screeninfo *var = >var;
> > struct drm_framebuffer *cur_fb;
> > struct vmw_framebuffer *vfb;
> > -   int ret = 0;
> > +   int ret = 0, depth;
> > size_t new_bo_size;
> >  
> > -   ret = vmw_fb_compute_depth(var, _cmd.depth);
> > +   ret = vmw_fb_compute_depth(var, );
> > if (ret)
> > return ret;
> >  
> > mode_cmd.width = var->xres;
> > mode_cmd.height = var->yres;
> > -   mode_cmd.bpp = var->bits_per_pixel;
> > -   mode_cmd.pitch = ((mode_cmd.bpp + 7) / 8) * mode_cmd.width;
> 
> mode_cmd.pitches[0] needs to be initialized before being used below.
> 
> Maybe something like:
> mode_cmd.pitches[0] = ((var->bits_per_pixel + 7) / 8) * mode_cmd.width;

Oh right, I deleted a bit too much here. Once fixed, ok if I merge this
through drm-misc so that Ville can throw his fb->format conversion on top?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/drm_bridge: adjust bridge module's refcount

[Andrzej Hajda]

On 01.12.2016 16:12, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 02:22:18PM +0100, Andrzej Hajda wrote:
>> On 01.12.2016 08:18, Daniel Vetter wrote:
>>> On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
 On 30.11.2016 14:09, Daniel Vetter wrote:
> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
>> On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
>>> Why exactly do you want to hotplug encoders? Or bridges fwiw ... since 
>>> at
>>> least only making those hotpluggable will make the uabi story easier 
>>> since
>>> they're not exposed.
>> Ideally to avoid disabling the whole display engine when one encoder 
>> isn't 
>> available/operational. Right now we're waiting for all pieces to be 
>> available 
>> (using deferred probing or the component framework) before registering 
>> the DRM 
>> device. This means that if one bridge can't be probed successfully for 
>> any 
>> reason we'll end up having not display at all. This includes the case 
>> where 
>> the driver for the bridge is not available. If we could support dynamic 
>> hotplug of bridges, we could start with a display engine that supports a 
>> subset of the outputs, and add new outputs as they become operational.
>>
>> We have a similar issue when unbinding bridge devices from their driver. 
>> They 
>> obviously can't be used anymore, but we have no solution to handle that 
>> apart 
>> from unregistering the DRM device completely, as otherwise rebinding the 
>> bridge to the driver later can't be handled.
> This all sounds pretty cool, but does anyone care? Like what's the
> real-world use-case here? Some cosmic ray destroyed the bridge driver on
> your android phone and now you want it to magically fall back to hdmi that
> no one ever plugs in? Or someone misconfigures their kernel and gets
> greeted with a black screen, instead of a ... black screen?
 Real use case is that we need to always load hdmi path drivers at phone
 startup just in case somebody will use it.
 This way we are wasting space and more importantly boot time, for code
 which won't be used by 99% users of phones.
 Putting them into modules an loading on MHL/HDMI cable plug-in would be
 more optimal, I guess.
>>> Do we have numbers for this?
>> For number of HDMI/MHL users in mobiles, I have no stats :)
>> For display boot delay due to deferring hdmi driver is 2.5-3.5 seconds
>> on peach-pi board for example [1].
> That sounds horrible. We load our entire driver in that time, and it has 3
> hdmi ports. What exactly is that thing doing for 3 seconds?! Until we know
> what's going on I'm not sure it's just a driver that has a dead-slow init
> function ...

As I wrote it is due to deferring probe of hdmi driver. It has nothing
to do with device initialization.

>
>> [1]:
>> https://storage.kernelci.org/ulfh/v4.9-rc7-120-g38cdf7e0bfee/arm-exynos_defconfig/lab-baylibre-seattle/boot-exynos5800-peach-pi.html
>>
>>
>>>  What part of the overhead is the edid probing
>>> and reading, which we probably should optimize either way ... optimize as
>>> in make sure we never ever stall anything for edid reads.
>> As EDID probing should be performed only after detecting sink it seems
>> irrelevant here.
>>
>>> And if you never load the hdmi driver, how do you know when to load it
>>> because the user plugged in the cable?
>> Mobiles often have detection which cable is plugged in. However I am not
>> sure if kernel sends such events to userspace,
>> but this should be simple to do.
> Well, to do that (at least with drm) you need the driver loaded, or at
> least the stuff it supports registered.
> -Daniel

Fortunately, in case of mobiles, cable detection is usually done outside
of DRM
via extcon driver.

Regards
Andrzej

linux-next: problems fetching the drm-intel, etc trees

[Stephen Rothwell]

Hi Daniel,

On Thu, 01 Dec 2016 11:02:26 + Daniel Stone  
wrote:
>
> On Nov 30 2016, at 10:49 pm, Rob Clark  wrote:  
> 
> > yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
> git urls for folks who have push access work fine).. although it has  
> worked for me a couple times today, given enough time.
> >  
> > (not sure if we have github/etc mirrors somewhere? I do have a github
> clone of mesa which is up to date as of ~10min ago.. I could do the  
> same for other git trees if someone somewhere is stuck)
> 
> Sorry about this, it is quite bad. I think having mirrors for the key DRM
> trees on GitHub is a good idea though, and I can get to setting that up.
> Stephen, you need DRM (airlied), drm-misc, drm-panel, drm-intel, drm-tegra,
> drm-exynos and drm-msm, right?

Well, here are the trees I fetch from *.freedesktop.org:

drm-intel-fixes git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
drm-misc-fixes  git://anongit.freedesktop.org/drm/drm-misc  
for-linux-next-fixes
drm git://people.freedesktop.org/~airlied/linux.git drm-next
drm-panel   git://anongit.freedesktop.org/tegra/linux.git   
drm/panel/for-next
drm-intel   git://anongit.freedesktop.org/drm-intel for-linux-next
drm-tegra   git://anongit.freedesktop.org/tegra/linux.git   
drm/tegra/for-next
drm-miscgit://anongit.freedesktop.org/drm/drm-misc  for-linux-next
drm-msm git://people.freedesktop.org/~robclark/linuxmsm-next

I did not have any trouble with the people.fd.o ones.

> Though, whilst you're at it, I noticed that the drm-misc tree needs updating:
> it's now at git://anongit.freedesktop.org/drm/drm-misc, rather than a branch
> of drm-intel.

I was informed, thanks.

Having mirrors is probably more effort for me than the slight outage
was (I would have to modify my control file for the outage period).  I
can merely use the version of a tree I already have if I can't fetch it
for a day or so.  If you were to have official mirrors, then
git.kernel.org makes more sense for the kernel parts anyway.

-- 
Cheers,
Stephen Rothwell

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

[Vlastimil Babka]

On 12/01/2016 10:02 PM, Michal Nazarewicz wrote:
> On Thu, Dec 01 2016, Michal Hocko wrote:
>> I am not familiar with this code so I cannot really argue but a quick
>> look at rmem_cma_setup doesn't suggest any speicific placing or
>> anything...
>
> early_cma parses ‘cma’ command line argument which can specify where
> exactly the default CMA area is to be located.  Furthermore, CMA areas
> can be assigned per-device (via the Device Tree IIRC).

OK, but the context of this bug report is a generic cma pool and generic 
dma alloc, which tries cma first and then fallback to 
alloc_pages_node(). If a device really requires specific placing as you 
suggest, then it probably uses a different allocation interface, 
otherwise there would be some flag to disallow the alloc_pages_node() 
fallback?

[PATCH v2 0/7] Tests for sync infrastructure

[Shuah Khan]

On 12/01/2016 06:17 PM, Shuah Khan wrote:
> On 10/19/2016 06:49 AM, Emilio López wrote:
>> Hello everyone,
>>
>> This is a series of tests to exercise the sync kernel infrastructure. It is
>> meant to be a test suite for the work Gustavo has been doing to destage it.
>>
>> These tests were originally part of a battery of tests shipping with
>> Android's libsync that were rewritten to use the new userspace interfaces.
>>
>> This is the second iteration of the test suite. Main changes over v1 are
>> a reworked Makefile and small code style fixes.
>>
>> If you are testing this on v4.9-rc1, do note that the last test will
>> currently fail due to a regression[0].
> 
> Hi Emilio,
> 
> Thanks. I will apply these to linux-kselftest next for 4.10-rc1
> 
> -- Shuah
>>
>> As usual, all comments are welcome.
>>

Hi Emilio,

Applied to linux-kselftest next. Could you take a look at the output
and see if it can be refined. Does [BAD] mean the test failed? Results
could refined to help user understand if a test failed or not clearly.
This can be done in a separate patch as a fix in one of the 4.01-rcs

thanks,
-- Shuah

[drm-intel:drm-intel-next-queued 3/10] htmldocs: drivers/gpu/drm/i915/intel_guc_loader.c:779: warning: No description found for parameter 'dev_priv'

[kbuild test robot]

0  785 
i915_guc_submission_fini(dev_priv);
bac427f8 Alex Dai   2015-08-12  786  
33a732f4 Alex Dai   2015-08-12  787 if (guc_fw->guc_fw_obj)

:: The code at line 779 was first introduced by commit
:: 33a732f407fed464df687370d7bb4d64533f9920 drm/i915: GuC-specific firmware 
loader

:: TO: Alex Dai 
:: CC: Daniel Vetter 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161202/be873276/attachment.gz>

[Bug 98931] radeonsi: Very low shader performance

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

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

Bug ID: 98931
   Summary: radeonsi: Very low shader performance
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: cristiano04 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

This shader https://gist.github.com/igv/a015fc885d5c22e6891820ad89555637 (5th
of September revision, crossbilateral only) used to crash the radeon driver and
bring the whole system down, whilst the previous version did not. 
After this was magically fixed, the only issue has been extremely low
performance, visible through low render times and a few dropped frames.

Test case: https://www.youtube.com/watch?v=6v2L2UGZJAM (it is important that
you use my settings for the 1080p version to be selected)

Using any revision of this shader after the introduction of the 5th of
September commit, on mpv, I get render times in the order of 31000 and lots of
dropped, mistimed frames (as per lua-stats). Using the version immediately
before this one (
https://gist.github.com/igv/a015fc885d5c22e6891820ad89555637/15a6623d61b4030ed4d8dce637e509b7433f39c2
) I get 6700 on the same video.

CPU+GPU: i5-4690, R9-280x
mpv, ffmpeg, mesa, llvm and xf86-video-ati are all git.

SSIMsuperres can be found here
https://gist.github.com/igv/2364ffa6e81540f29cb7ab4c9bc05b6b
Relevant bits of mpv.conf for reproduction purposes:


profile=opengl-hq
opengl-pbo=yes

# Scaling
scale=ewa_lanczossharp
opengl-shaders="~~/shaders/ssimsuperres.glsl,~~/shaders/crossbilateral.glsl"
#cscale

# Interpolation
tscale=sinc
interpolation=yes
video-sync=display-resample
tscale-clamp=yes

# Misc
temporal-dither=yes
dither-depth=8
deband-iterations=2
deband-range=12
blend-subtitles=no
hwdec=no
framedrop=vo

# Web media
ytdl=yes
ytdl-format=0/(bestvideo[vcodec=vp9]/bestvideo[height>720]/bestvideo[fps>30])[tbr<13000]+(bestaudio[acodec=opus]/bestaudio)/best

-- 
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/20161202/9371e36f/attachment.html>

[PATCH 22/22] arm64: dts: r8a7795: salvator-x: Add DU1 and DU2 external dot clocks

[Laurent Pinchart]

The DU1 and DU2 external dot clocks are fixed frequency clock generators
running at 33MHz.

Signed-off-by: Laurent Pinchart 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 23 ++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 08554b4d7e86..b6dc6f5188d6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -147,6 +147,19 @@
};
};

+   /* External DU dot clocks */
+   x21_clk: x21-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <3300>;
+   };
+
+   x22_clk: x22-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <3300>;
+   };
+
hdmi0-out {
compatible = "hdmi-connector";
label = "HDMI0 OUT";
@@ -245,6 +258,16 @@
pinctrl-names = "default";
status = "okay";

+   clocks = < CPG_MOD 724>,
+< CPG_MOD 723>,
+< CPG_MOD 722>,
+< CPG_MOD 721>,
+< CPG_MOD 727>,
+<_clk>,
+<_clk>;
+   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+ "dclkin.1", "dclkin.2";
+
ports {
port at 0 {
endpoint {
-- 
Regards,

Laurent Pinchart

[PATCH 21/22] arm64: dts: r8a7795: salvator-x: Enable HDMI outputs

[Laurent Pinchart]

From: Koji Matsuoka 

Instantiate the HDMI connectors and enable the encoders.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Ulrich Hecht 
Signed-off-by: Laurent Pinchart 
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 73a22b93f7b1..08554b4d7e86 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -147,6 +147,30 @@
};
};

+   hdmi0-out {
+   compatible = "hdmi-connector";
+   label = "HDMI0 OUT";
+   type = "a";
+
+   port {
+   hdmi0_con: endpoint {
+   remote-endpoint = <_dw_hdmi0_out>;
+   };
+   };
+   };
+
+   hdmi1-out {
+   compatible = "hdmi-connector";
+   label = "HDMI1 OUT";
+   type = "a";
+
+   port {
+   hdmi1_con: endpoint {
+   remote-endpoint = <_dw_hdmi1_out>;
+   };
+   };
+   };
+
vga-encoder {
compatible = "adi,adv7123";

@@ -190,6 +214,32 @@
};
 };

+ {
+   status = "okay";
+
+   ports {
+   port at 1 {
+   reg = <1>;
+   rcar_dw_hdmi0_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port at 1 {
+   reg = <1>;
+   rcar_dw_hdmi1_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+};
+
  {
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-- 
Regards,

Laurent Pinchart

[PATCH 20/22] arm64: dts: r8a7795: Add HDMI encoder support

[Laurent Pinchart]

From: Ulrich Hecht 

Add DT nodes for the two HDMI encoders in disabled state.

Based on work by Koji Matsuoka.

Signed-off-by: Ulrich Hecht 
Signed-off-by: Laurent Pinchart 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 50 
 1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 9b717dee1f7b..eceb62ee88df 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1590,11 +1590,13 @@
port at 1 {
reg = <1>;
du_out_hdmi0: endpoint {
+   remote-endpoint = 
<_hdmi0_in>;
};
};
port at 2 {
reg = <2>;
du_out_hdmi1: endpoint {
+   remote-endpoint = 
<_hdmi1_in>;
};
};
port at 3 {
@@ -1604,5 +1606,53 @@
};
};
};
+
+   hdmi0: hdmi0 at fead {
+   compatible = "renesas,r8a7795-hdmi", 
"renesas,rcar-gen3-hdmi";
+   reg = <0 0xfead 0 0x1>;
+   interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < CPG_CORE R8A7795_CLK_S0D4>, < 
CPG_MOD 729>;
+   clock-names = "iahb", "isfr";
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   dw_hdmi0_in: endpoint {
+   remote-endpoint = 
<_out_hdmi0>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   };
+   };
+   };
+
+   hdmi1: hdmi1 at feae {
+   compatible = "renesas,r8a7795-hdmi", 
"renesas,rcar-gen3-hdmi";
+   reg = <0 0xfeae 0 0x1>;
+   interrupts = <0 436 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < CPG_CORE R8A7795_CLK_S0D4>, < 
CPG_MOD 728>;
+   clock-names = "iahb", "isfr";
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   dw_hdmi1_in: endpoint {
+   remote-endpoint = 
<_out_hdmi1>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   };
+   };
+   };
};
 };
-- 
Regards,

Laurent Pinchart

[PATCH 19/22] drm: rcar-du: Add HDMI outputs to R8A7795 device description

[Laurent Pinchart]

From: Koji Matsuoka 

Update the device description with the two available HDMI outputs.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  4 +++-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 12 ++--
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 6f08b7e7db06..459e5390d6e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -1,7 +1,7 @@
 /*
  * rcar_du_crtc.h  --  R-Car Display Unit CRTCs
  *
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2015 Renesas Electronics Corporation
  *
  * Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
  *
@@ -61,6 +61,8 @@ enum rcar_du_output {
RCAR_DU_OUTPUT_DPAD1,
RCAR_DU_OUTPUT_LVDS0,
RCAR_DU_OUTPUT_LVDS1,
+   RCAR_DU_OUTPUT_HDMI0,
+   RCAR_DU_OUTPUT_HDMI1,
RCAR_DU_OUTPUT_TCON,
RCAR_DU_OUTPUT_MAX,
 };
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 74352140f55f..3107719c4653 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -150,13 +150,21 @@ static const struct rcar_du_device_info 
rcar_du_r8a7795_info = {
  | RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 4,
.routes = {
-   /* R8A7795 has one RGB output, one LVDS output and two
-* (currently unsupported) HDMI outputs.
+   /* R8A7795 has one RGB output, two HDMI outputs and one
+* LVDS output.
 */
[RCAR_DU_OUTPUT_DPAD0] = {
.possible_crtcs = BIT(3),
.port = 0,
},
+   [RCAR_DU_OUTPUT_HDMI0] = {
+   .possible_crtcs = BIT(1),
+   .port = 1,
+   },
+   [RCAR_DU_OUTPUT_HDMI1] = {
+   .possible_crtcs = BIT(2),
+   .port = 2,
+   },
[RCAR_DU_OUTPUT_LVDS0] = {
.possible_crtcs = BIT(0),
.port = 3,
-- 
Regards,

Laurent Pinchart

[PATCH 18/22] drm: rcar-du: Add DPLL support

[Laurent Pinchart]

From: Koji Matsuoka 

The implementation hardcodes a workaround for the H3 ES1.x SoC
regardless of the SoC revision, as the workaround can be safely applied
on all devices in the Gen3 family without any side effect.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Ulrich Hecht 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 81 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_regs.h | 23 ++
 4 files changed, 105 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index a2ec6d8796a0..cec20abd61aa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -106,9 +106,62 @@ static void rcar_du_crtc_put(struct rcar_du_crtc *rcrtc)
  * Hardware Setup
  */

+struct dpll_info {
+   unsigned int output;
+   unsigned int fdpll;
+   unsigned int n;
+   unsigned int m;
+};
+
+static void rcar_du_dpll_divider(struct rcar_du_crtc *rcrtc,
+struct dpll_info *dpll,
+unsigned long input,
+unsigned long target)
+{
+   unsigned long best_diff = (unsigned long)-1;
+   unsigned long diff;
+   unsigned int fdpll;
+   unsigned int m;
+   unsigned int n;
+
+   for (n = 39; n < 120; n++) {
+   for (m = 0; m < 4; m++) {
+   for (fdpll = 1; fdpll < 32; fdpll++) {
+   unsigned long output;
+
+   /* 1/2 (FRQSEL=1) for duty rate 50% */
+   output = input * (n + 1) / (m + 1)
+  / (fdpll + 1) / 2;
+
+   if (output >= 4)
+   continue;
+
+   diff = abs((long)output - (long)target);
+   if (best_diff > diff) {
+   best_diff = diff;
+   dpll->n = n;
+   dpll->m = m;
+   dpll->fdpll = fdpll;
+   dpll->output = output;
+   }
+
+   if (diff == 0)
+   goto done;
+   }
+   }
+   }
+
+done:
+   dev_dbg(rcrtc->group->dev->dev,
+   "output:%u, fdpll:%u, n:%u, m:%u, diff:%lu\n",
+dpll->output, dpll->fdpll, dpll->n, dpll->m,
+best_diff);
+}
+
 static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
+   struct rcar_du_device *rcdu = rcrtc->group->dev;
unsigned long mode_clock = mode->clock * 1000;
unsigned long clk;
u32 value;
@@ -124,12 +177,18 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
escr = div | ESCR_DCLKSEL_CLKS;

if (rcrtc->extclock) {
+   struct dpll_info dpll = { 0 };
unsigned long extclk;
unsigned long extrate;
unsigned long rate;
u32 extdiv;

extclk = clk_get_rate(rcrtc->extclock);
+   if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
+   rcar_du_dpll_divider(rcrtc, , extclk, mode_clock);
+   extclk = dpll.output;
+   }
+
extdiv = DIV_ROUND_CLOSEST(extclk, mode_clock);
extdiv = clamp(extdiv, 1U, 64U) - 1;

@@ -140,7 +199,27 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
abs((long)rate - (long)mode_clock)) {
dev_dbg(rcrtc->group->dev->dev,
"crtc%u: using external clock\n", rcrtc->index);
-   escr = extdiv | ESCR_DCLKSEL_DCLKIN;
+
+   if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
+   u32 dpllcr = DPLLCR_CODE | DPLLCR_CLKE
+  | DPLLCR_FDPLL(dpll.fdpll)
+  | DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
+  | DPLLCR_STBY;
+
+   if (rcrtc->index == 1)
+   dpllcr |= DPLLCR_PLCS1
+  |  DPLLCR_INCS_DOTCLKIN1;
+   else
+   dpllcr |= DPLLCR_PLCS0
+  |  DPLLCR_INCS_DOTCLKIN0;
+
+ 

[PATCH 17/22] drm: rcar-du: Skip disabled outputs

[Laurent Pinchart]

When a DT node connected to a DU output is disabled no bridge will ever
be instantiated for it. Skip the output in that case.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index aa84689043ae..7a6bd8bdba05 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -384,6 +384,13 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
return -ENODEV;
}

+   if (!of_device_is_available(entity)) {
+   dev_dbg(rcdu->dev,
+   "connected entity %s is disabled, skipping\n",
+   entity->full_name);
+   return -ENODEV;
+   }
+
entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);

for_each_endpoint_of_node(entity, ep_node) {
-- 
Regards,

Laurent Pinchart

[PATCH 16/22] drm: rcar-du: Add Gen3 HDMI encoder support

[Laurent Pinchart]

From: Koji Matsuoka 

The R-Car Gen3 SoCs include on-chip DesignWare HDMI encoders. Support
them with a platform driver to provide platform glue data to the dw-hdmi
driver.

The driver is a complete rewrite of code coming from the Renesas BSP,
save for the values in the PHY parameters table.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Ulrich Hecht 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/Kconfig|   8 +++
 drivers/gpu/drm/rcar-du/Makefile   |   1 +
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 105 +
 3 files changed, 114 insertions(+)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 06121eeba9e5..a356d2f2f6d6 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,6 +11,14 @@ config DRM_RCAR_DU
  Choose this option if you have an R-Car chipset.
  If M is selected the module will be called rcar-du-drm.

+config DRM_RCAR_DW_HDMI
+   bool "R-Car DU Gen3 HDMI Encoder Support"
+   depends on DRM_RCAR_DU
+   depends on OF
+   select DRM_DW_HDMI
+   help
+ Enable support for R-Car Gen3 internal HDMI encoder.
+
 config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index a492e6858691..2131e722de3b 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -11,3 +11,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)   += rcar_du_lvdsenc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o

 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
+obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c 
b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
new file mode 100644
index ..1921d7aa6aed
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
@@ -0,0 +1,105 @@
+/*
+ * R-Car Gen3 HDMI PHY
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ *
+ * Contact: Laurent Pinchart (laurent.pinchart at ideasonboard.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+
+#include 
+
+#define RCAR_HDMI_PHY_OPMODE_PLLCFG0x06/* Mode of operation and PLL 
dividers */
+#define RCAR_HDMI_PHY_PLLCURRGMPCTRL   0x10/* PLL current and Gmp 
(conductance) */
+#define RCAR_HDMI_PHY_PLLDIVCTRL   0x11/* PLL dividers */
+
+struct rcar_hdmi_phy_params {
+   unsigned long mpixelclock;
+   u16 opmode_div; /* Mode of operation and PLL dividers */
+   u16 curr_gmp;   /* PLL current and Gmp (conductance) */
+   u16 div;/* PLL dividers */
+};
+
+static const struct rcar_hdmi_phy_params rcar_hdmi_phy_params[] = {
+   { 3550,  0x0003, 0x0344, 0x0328 },
+   { 4490,  0x0003, 0x0285, 0x0128 },
+   { 7100,  0x0002, 0x1184, 0x0314 },
+   { 9000,  0x0002, 0x1144, 0x0114 },
+   { 14025, 0x0001, 0x20c4, 0x030a },
+   { 18275, 0x0001, 0x2084, 0x010a },
+   { 28125, 0x, 0x0084, 0x0305 },
+   { 29700, 0x, 0x0084, 0x0105 },
+   { ~0UL,  0x, 0x, 0x },
+};
+
+static int rcar_hdmi_phy_configure(struct dw_hdmi *hdmi,
+  const struct dw_hdmi_plat_data *pdata,
+  unsigned long mpixelclock,
+  enum dw_hdmi_resolution resolution)
+{
+   const struct rcar_hdmi_phy_params *params = rcar_hdmi_phy_params;
+
+   if (resolution != DW_HDMI_RES_8)
+   return -EINVAL;
+
+   for (; params && params->mpixelclock != ~0UL; ++params) {
+   if (mpixelclock <= params->mpixelclock)
+   break;
+   }
+
+   if (params->mpixelclock == ~0UL)
+   return -EINVAL;
+
+   dw_hdmi_phy_i2c_write(hdmi, params->opmode_div,
+ RCAR_HDMI_PHY_OPMODE_PLLCFG);
+   dw_hdmi_phy_i2c_write(hdmi, params->curr_gmp,
+ RCAR_HDMI_PHY_PLLCURRGMPCTRL);
+   dw_hdmi_phy_i2c_write(hdmi, params->div, RCAR_HDMI_PHY_PLLDIVCTRL);
+
+   return 0;
+}
+
+static const struct dw_hdmi_plat_data rcar_dw_hdmi_plat_data = {
+   .configure_phy  = rcar_hdmi_phy_configure,
+   .quirks = DW_HDMI_QUIRK_PHY_SVSRET,
+};
+
+static int rcar_dw_hdmi_probe(struct platform_device *pdev)
+{
+   return dw_hdmi_probe(pdev, _dw_hdmi_plat_data);
+}
+
+static int rcar_dw_hdmi_remove(struct 

[PATCH 15/22] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings

[Laurent Pinchart]

The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
corresponding device tree bindings based on the DWC HDMI TX bindings
model.

Signed-off-by: Laurent Pinchart 
---
 .../bindings/display/bridge/renesas,dw-hdmi.txt| 75 ++
 MAINTAINERS|  1 +
 2 files changed, 76 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
new file mode 100644
index ..f6b3f36d422b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
@@ -0,0 +1,75 @@
+Renesas Gen3 DWC HDMI TX Encoder
+
+
+The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+with a companion PHY IP.
+
+These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
+Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
+following device-specific properties.
+
+
+Required properties:
+
+- compatible : Shall contain one or more of
+  - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
+  - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX
+
+When compatible with generic versions, nodes must list the SoC-specific
+version corresponding to the platform first, followed by the
+family-specific version.
+
+- reg: See dw_hdmi.txt.
+- interrupts: HDMI interrupt number
+- clocks: See dw_hdmi.txt.
+- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
+- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
+  corresponding to the video input of the controller and one port numbered 1
+  corresponding to its HDMI output. Each port shall have a single endpoint.
+
+Optional properties:
+
+- power-domains: Shall reference the power domain that contains the DWC HDMI,
+  if any.
+
+
+Example:
+
+   hdmi0: hdmi0 at fead {
+   compatible = "renesas,r8a7795-dw-hdmi";
+   reg = <0 0xfead 0 0x1>;
+   interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < CPG_CORE R8A7795_CLK_S0D4>, < CPG_MOD 729>;
+   clock-names = "iahb", "isfr";
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   dw_hdmi0_in: endpoint {
+   remote-endpoint = <_out_hdmi0>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   rcar_dw_hdmi0_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+
+   hdmi0-out {
+   compatible = "hdmi-connector";
+   label = "HDMI0 OUT";
+   type = "a";
+
+   port {
+   hdmi0_con: endpoint {
+   remote-endpoint = <_dw_hdmi0_out>;
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 30c873192458..a513fda157d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4231,6 +4231,7 @@ S:Supported
 F: drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
+F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt

 DRM DRIVER FOR QXL VIRTUAL GPU
-- 
Regards,

Laurent Pinchart

[PATCH 14/22] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

[Laurent Pinchart]

Make it clear that the core bridge/dw_hdmi.txt document isn't a device
tree binding by itself but is meant to be referenced by platform device
tree bindings, and update the Rockchip and Freescale DWC HDMI TX
bindings to reference it.

Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 +-
 .../devicetree/bindings/display/imx/hdmi.txt   | 51 +++--
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++
 3 files changed, 91 insertions(+), 88 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
index 5e9a84d6e5f1..33bf981fbe33 100644
--- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
@@ -1,52 +1,33 @@
-DesignWare HDMI bridge bindings
-
-Required properties:
-- compatible: platform specific such as:
-   * "snps,dw-hdmi-tx"
-   * "fsl,imx6q-hdmi"
-   * "fsl,imx6dl-hdmi"
-   * "rockchip,rk3288-dw-hdmi"
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The HDMI interrupt number
-- clocks, clock-names : must have the phandles to the HDMI iahb and isfr 
clocks,
-  as described in Documentation/devicetree/bindings/clock/clock-bindings.txt,
-  the clocks are soc specific, the clock-names should be "iahb", "isfr"
--port@[X]: SoC specific port nodes with endpoint definitions as defined
-   in Documentation/devicetree/bindings/media/video-interfaces.txt,
-   please refer to the SoC specific binding document:
-* Documentation/devicetree/bindings/display/imx/hdmi.txt
-* Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
-
-Optional properties
-- reg-io-width: the width of the reg:1,4, default set to 1 if not present
-- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing,
-  if the property is omitted, a functionally reduced I2C bus
-  controller on DW HDMI is probed
-- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
-
-Example:
-   hdmi: hdmi at 012 {
-   compatible = "fsl,imx6q-hdmi";
-   reg = <0x0012 0x9000>;
-   interrupts = <0 115 0x04>;
-   gpr = <>;
-   clocks = < 123>, < 124>;
-   clock-names = "iahb", "isfr";
-   ddc-i2c-bus = <>;
-
-   port at 0 {
-   reg = <0>;
-
-   hdmi_mux_0: endpoint {
-   remote-endpoint = <_di0_hdmi>;
-   };
-   };
-
-   port at 1 {
-   reg = <1>;
-
-   hdmi_mux_1: endpoint {
-   remote-endpoint = <_di1_hdmi>;
-   };
-   };
-   };
+Synopsys DesignWare HDMI TX Encoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding
+specification by itself but is meant to be referenced by platform-specific
+device tree bindings.
+
+When referenced from platform device tree bindings the properties defined in
+this document are defined as follows. The platform device tree bindings are
+responsible for defining whether each property is required or optional.
+
+- reg: Memory mapped base address and length of the DWC HDMI TX registers.
+
+- reg-io-width: Width of the registers specified by the reg property. The
+  value is expressed in bytes and must be equal to 1 or 4 if specified. The
+  register width defaults to 1 if the property is not present.
+
+- interrupts: Reference to the DWC HDMI TX interrupt.
+
+- clocks: References to all the clocks specified in the clock-names property
+  as specified in Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+- clock-names: The DWC HDMI TX uses the following clocks.
+
+  - "iahb" is the bus clock for either AHB and APB (mandatory).
+  - "isfr" is the internal register configuration clock (mandatory).
+  - "cec" is the HDMI CEC controller main clock (optional).
+
+- ports: The connectivity of the DWC HDMI TX with the rest of the system is
+  expressed in using ports as specified in the device graph bindings defined
+  in Documentation/devicetree/bindings/graph.txt. The numbering of the ports
+  is platform-specific.
diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt 
b/Documentation/devicetree/bindings/display/imx/hdmi.txt
index 1b756cf9afb0..66a8f86e5d12 100644
--- a/Documentation/devicetree/bindings/display/imx/hdmi.txt
+++ b/Documentation/devicetree/bindings/display/imx/hdmi.txt
@@ -1,29 +1,36 @@
-Device-Tree bindings for HDMI Transmitter
+Freescale i.MX6 DWC HDMI TX Encoder
+===

-HDMI Transmitter
-
+The HDMI