[Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT

2013-10-18 Thread Artem Bityutskiy
From: Artem Bityutskiy artem.bityuts...@linux.intel.com

This patch changes HDMI port registration order for the BayTrail platform.

The story is that in kernel version 3.11 i915 supported only one HDMI port -
the HDMIB port. So this port ended up being HDMI-1 in user-space.

But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT'
introduced HDMIC port support. And added HDMIC  registration prior to HDMIB,
so HDMIB became HDMI-2 and HDMIC became HDMI-1.

Well, this is fine as far as the kernel is concerned. i915 does not give any
guarantees to the numbering, and has never given them.

However, this breaks wayland setup in Tizen IVI. We have only one single HDMI
port on our hardware, and it is connected to HDMIB. Our configuration relies on
the fact that it is HDMI-1.

Well, certainly this is user-space problem which was exposed with Jesse's
patch. However, there is a reason why we have to do this assumption - we use
touchscreen monitors and we have to associate event devices with the monitors,
and this is not easy to do dynamically, so we just have a static setup.

Anyway, while the user-space setup will have to be fixed regardless, let's
chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it
was in 3.11. Simply because there is no strong reason for changing the order in
the kernel, and it'll help setups like ours in sense that we'll have more time
for fixing the issue properly.

Also amend the commentary which looks a bit out-of-date.

Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4f1b636..3fc8ae6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9880,7 +9880,14 @@ static void intel_setup_outputs(struct drm_device *dev)
if (I915_READ(PCH_DP_D)  DP_DETECTED)
intel_dp_init(dev, PCH_DP_D, PORT_D);
} else if (IS_VALLEYVIEW(dev)) {
-   /* Check for built-in panel first. Shares lanes with HDMI on 
SDVOC */
+   /* DP and HDMI share lanes on the SDVOC */
+   if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIB)  SDVO_DETECTED) {
+   intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIB,
+   PORT_B);
+   if (I915_READ(VLV_DISPLAY_BASE + DP_B)  DP_DETECTED)
+   intel_dp_init(dev, VLV_DISPLAY_BASE + DP_B, 
PORT_B);
+   }
+
if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIC)  SDVO_DETECTED) {
intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIC,
PORT_C);
@@ -9889,13 +9896,6 @@ static void intel_setup_outputs(struct drm_device *dev)
  PORT_C);
}
 
-   if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIB)  SDVO_DETECTED) {
-   intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIB,
-   PORT_B);
-   if (I915_READ(VLV_DISPLAY_BASE + DP_B)  DP_DETECTED)
-   intel_dp_init(dev, VLV_DISPLAY_BASE + DP_B, 
PORT_B);
-   }
-
intel_dsi_init(dev);
} else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
bool found = false;
-- 
1.8.1.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT

2013-10-17 Thread Artem Bityutskiy
On Wed, 2013-10-16 at 19:46 +0200, Daniel Vetter wrote:
 On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
  From: Artem Bityutskiy artem.bityuts...@linux.intel.com
  
  This patch changes HDMI port registration order for the BayTrail platform.
  
  The story is that in kernel version 3.11 i915 supported only one HDMI port -
  the HDMIB port. So this port ended up being HDMI-1 in user-space.
  
  But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT'
  introduced HDMIC port support. And added HDMIC  registration prior to HDMIB,
  so HDMIB became HDMI-2 and HDMIC became HDMI-1.
  
  Well, this is fine as far as the kernel is concerned. i915 does not give any
  guarantees to the numbering, and has never given them.
  
  However, this breaks wayland setup in Tizen IVI. We have only one single 
  HDMI
  port on our hardware, and it is connected to HDMIB. Our configuration 
  relies on
  the fact that it is HDMI-1.
  
  Well, certainly this is user-space problem which was exposed with Jesse's
  patch. However, there is a reason why we have to do this assumption - we use
  touchscreen monitors and we have to associate event devices with the 
  monitors,
  and this is not easy to do dynamically, so we just have a static setup.
  
  Anyway, while the user-space setup will have to be fixed regardless, let's
  chane the HDMI port registration order so that HDMIB stays HDMI-1, just 
  like it
  was in 3.11. Simply because there is no strong reason for changing the 
  order in
  the kernel, and it'll help setups like ours in sense that we'll have more 
  time
  for fixing the issue properly.
  
  Also amend the commentary which looks a bit out-of-date.
  
  Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
 
 This makes imo sense irrespective of any userspace issues. Queued for
 -next, thanks for the patch.
 -Daniel

Thanks Daniel! Although, '6f6005a drm/i915: expose HDMI connectors on
port C on BYT' is in 3.12-rc4, is it possible to have this patch in 3.12
release too?

-- 
Best Regards,
Artem Bityutskiy

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
 From: Artem Bityutskiy artem.bityuts...@linux.intel.com
 
 This patch changes HDMI port registration order for the BayTrail platform.
 
 The story is that in kernel version 3.11 i915 supported only one HDMI port -
 the HDMIB port. So this port ended up being HDMI-1 in user-space.
 
 But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT'
 introduced HDMIC port support. And added HDMIC  registration prior to HDMIB,
 so HDMIB became HDMI-2 and HDMIC became HDMI-1.
 
 Well, this is fine as far as the kernel is concerned. i915 does not give any
 guarantees to the numbering, and has never given them.
 
 However, this breaks wayland setup in Tizen IVI. We have only one single HDMI
 port on our hardware, and it is connected to HDMIB. Our configuration relies 
 on
 the fact that it is HDMI-1.
 
 Well, certainly this is user-space problem which was exposed with Jesse's
 patch. However, there is a reason why we have to do this assumption - we use
 touchscreen monitors and we have to associate event devices with the monitors,
 and this is not easy to do dynamically, so we just have a static setup.
 
 Anyway, while the user-space setup will have to be fixed regardless, let's
 chane the HDMI port registration order so that HDMIB stays HDMI-1, just like 
 it
 was in 3.11. Simply because there is no strong reason for changing the order 
 in
 the kernel, and it'll help setups like ours in sense that we'll have more time
 for fixing the issue properly.
 
 Also amend the commentary which looks a bit out-of-date.
 
 Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com

This makes imo sense irrespective of any userspace issues. Queued for
-next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT

2013-10-16 Thread Chris Wilson
On Wed, Oct 16, 2013 at 07:46:27PM +0200, Daniel Vetter wrote:
 On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
  Well, certainly this is user-space problem which was exposed with Jesse's
  patch. However, there is a reason why we have to do this assumption - we use
  touchscreen monitors and we have to associate event devices with the 
  monitors,
  and this is not easy to do dynamically, so we just have a static setup.

I'm sure I heard a rumour that there was an extension block in EDID to
assiocate touch devices with monitors. Does anyone know any firm details
about that?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx