Re: [Intel-gfx] v3.12 does not work on ByT-I
Thanks Jesse for you answer, but it brought more questions. On Thu, 2013-11-07 at 08:04 -0800, Jesse Barnes wrote: Hm, I wonder if this bug is also related to the backlight stuff Jani recently pushed fixes for. OK. It looks like you have an eDP panel here, No, we do not have it at all. but if for some reason it got bounced between two CRTCs due to bad detection on one, it could cause a blank screen issue. OK, not sure I understand what you mean, but yes, blank screen is something which we observe without your patch. commit 07bf139b906013ecef0c5e0441564d1ae10e974a Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Oct 31 18:55:50 2013 +0200 drm/i915/vlv: use per-pipe backlight controls v2 commit 752aa88a1e784c22d514db3b440e49427b58259e Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Oct 31 18:55:49 2013 +0200 drm/i915: make backlight functions take a connector commit 91a60f20712179e56b7a6c3d332a5f6f9a54aa11 Author: Jani Nikula jani.nik...@intel.com Date: Thu Oct 31 18:55:48 2013 +0200 drm/i915: move opregion asle request handling to a work queue are the relevant commits. Do you think I should try cherry-picking this to 3.12 and test if they help? Or this is more about for your reference? Many thanks! -- Best Regards, Artem Bityutskiy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT
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
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
