Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Thu, Jan 09, 2014 at 11:25:38PM +0800, Shawn Guo wrote: Yea, adding all four into imx-drm crtcs works for imx6q, but it doesn't for imx6dl, because ipu2 is unavailable for imx6dl at all. Here is how I get around it. Thanks, I've rolled your change into this commit now. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Tue, Jan 07, 2014 at 04:59:35PM +0800, Shawn Guo wrote:
On Thu, Jan 02, 2014 at 09:28:03PM +, Russell King wrote:
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index e75e11b36dff..0e005f21d241 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -62,6 +62,12 @@
};
};
+ imx-drm {
+ compatible = fsl,imx-drm;
+ crtcs = ipu1 0, ipu1 1;
+ connectors = ldb;
+ };
+
While the change works fine on imx6dl, it breaks LVDS support on imx6q
right away.
imx-ipuv3 240.ipu: IPUv3H probed
imx-ipuv3 280.ipu: IPUv3H probed
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
imx-drm imx-drm.16: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
imx-drm imx-drm.16: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops)
imx-drm imx-drm.16: failed to bind ldb.10 (ops imx_ldb_ops): -517
Because we have 4 crtcs for lvds-channel on imx6q while imx-drm master
defines only 2 in there, the imx_drm_encoder_parse_of() call from
imx_ldb_register() will always return -EPROBE_DEFER.
lvds-channel@0 {
crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
};
lvds-channel@1 {
crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
};
This is why some help would be useful here - I think I got these right
but I've no way to check them.
Can you confirm that adding all four is the right thing not only for
the imx6q but also the imx6dl sabresd please?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Tue, Jan 07, 2014 at 05:29:55PM +0100, Philipp Zabel wrote:
Thanky you. This is what I came up with so far:
From: Philipp Zabel p.za...@pengutronix.de
Subject: [PATCH 1/2] staging: imx-hdmi: use RX_SENSE0 for plug detection if
HPD is unreliable
On some boards HPD might not reliably detect DVI monitors. Allow to use
RX_SENSE0 as a workaround.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/staging/imx-drm/imx-hdmi.c | 45
+-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-hdmi.c
b/drivers/staging/imx-drm/imx-hdmi.c
index 7779337..cc305f3 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -139,6 +139,7 @@ struct imx_hdmi {
struct regmap *regmap;
struct i2c_adapter *ddc;
+ bool hpd_unreliable;
void __iomem *regs;
unsigned int sample_rate;
@@ -1309,6 +1310,14 @@ static int imx_hdmi_setup(struct imx_hdmi *hdmi,
struct drm_display_mode *mode)
/* Wait until we are registered to enable interrupts */
static int imx_hdmi_fb_registered(struct imx_hdmi *hdmi)
{
+ int stat_bit = HDMI_IH_PHY_STAT0_HPD;
+ int mask_bits = ~HDMI_PHY_HPD;
+
+ if (hdmi-hpd_unreliable) {
+ stat_bit = HDMI_IH_PHY_STAT0_RX_SENSE0;
+ mask_bits = ~HDMI_PHY_RX_SENSE0;
+ }
+
How about storing these in imx_hdmi instead, so we don't have to compute
them in each interrupt? Maybe sink_detect_status and sink_detect_mask?
Thanks.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was up to 13.2Mbit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Am Montag, den 06.01.2014, 19:31 -0700 schrieb Eric Nelson: Hi Russell, On 01/06/2014 10:46 AM, Russell King - ARM Linux wrote: On Mon, Jan 06, 2014 at 06:41:28PM +0100, Philipp Zabel wrote: Hi Eric, Am Freitag, den 03.01.2014, 12:14 -0700 schrieb Eric Nelson: This is an issue we've seen before. The SABRE Lite board has a voltage divider on the HPD pins and some monitors (esp. DVI monitors) either don't drive things high enough to assert HPD or bounce with connect/disconnect. Yes, I used a DVI monitor. We've instrumented our 3.0.35 kernels to use the RX_SENSE bits instead. Reacting to RX_SENSE0 instead of HPD seems to work. However, it's non-compliant, because HPD can be lowered and raised by the sink when it changes its EDID data (eg, because you're connected through a switch and the routing has been changed.) So, reacting to RX_SENSE0 instead of HPD has to be a work-around enabled only for those boards which are broken in this regard. I understand. We'll need to carry some patches for a while though, since there are lots of these boards in the wild. Could you point me to your changes? Maybe this could be added to mainline as a quirk enabled by a device tree property on sabrelite only. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Am Dienstag, den 07.01.2014, 08:30 -0700 schrieb Eric Nelson:
Hi Philipp,
On 01/07/2014 04:29 AM, Philipp Zabel wrote:
Am Montag, den 06.01.2014, 19:31 -0700 schrieb Eric Nelson:
Hi Russell,
On 01/06/2014 10:46 AM, Russell King - ARM Linux wrote:
On Mon, Jan 06, 2014 at 06:41:28PM +0100, Philipp Zabel wrote:
Hi Eric,
Am Freitag, den 03.01.2014, 12:14 -0700 schrieb Eric Nelson:
This is an issue we've seen before. The SABRE Lite board has
a voltage divider on the HPD pins and some monitors (esp. DVI
monitors) either don't drive things high enough to assert HPD or
bounce with connect/disconnect.
Yes, I used a DVI monitor.
We've instrumented our 3.0.35 kernels to use the RX_SENSE bits
instead.
Reacting to RX_SENSE0 instead of HPD seems to work.
However, it's non-compliant, because HPD can be lowered and raised by
the sink when it changes its EDID data (eg, because you're connected
through a switch and the routing has been changed.)
So, reacting to RX_SENSE0 instead of HPD has to be a work-around enabled
only for those boards which are broken in this regard.
I understand. We'll need to carry some patches for a while though,
since there are lots of these boards in the wild.
Could you point me to your changes? Maybe this could be added to
mainline as a quirk enabled by a device tree property on sabrelite only.
We only have them for 3.0.35 at the moment.
Here's the patch to use RXSENSE instead of HPD
https://github.com/boundarydevices/linux-imx6/commit/c0439e262bb6c23887d96466b2ab7916aa0488d9
A follow-up patch disables the disconnect detection entirely
unless requested:
https://github.com/boundarydevices/linux-imx6/commit/d9cd79d11ff9f7a7f89cbc94b68757b67cdfe5fc
Thanky you. This is what I came up with so far:
From: Philipp Zabel p.za...@pengutronix.de
Subject: [PATCH 1/2] staging: imx-hdmi: use RX_SENSE0 for plug detection if
HPD is unreliable
On some boards HPD might not reliably detect DVI monitors. Allow to use
RX_SENSE0 as a workaround.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/staging/imx-drm/imx-hdmi.c | 45 +-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-hdmi.c
b/drivers/staging/imx-drm/imx-hdmi.c
index 7779337..cc305f3 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -139,6 +139,7 @@ struct imx_hdmi {
struct regmap *regmap;
struct i2c_adapter *ddc;
+ bool hpd_unreliable;
void __iomem *regs;
unsigned int sample_rate;
@@ -1309,6 +1310,14 @@ static int imx_hdmi_setup(struct imx_hdmi *hdmi, struct
drm_display_mode *mode)
/* Wait until we are registered to enable interrupts */
static int imx_hdmi_fb_registered(struct imx_hdmi *hdmi)
{
+ int stat_bit = HDMI_IH_PHY_STAT0_HPD;
+ int mask_bits = ~HDMI_PHY_HPD;
+
+ if (hdmi-hpd_unreliable) {
+ stat_bit = HDMI_IH_PHY_STAT0_RX_SENSE0;
+ mask_bits = ~HDMI_PHY_RX_SENSE0;
+ }
+
hdmi_writeb(hdmi, HDMI_PHY_I2CM_INT_ADDR_DONE_POL,
HDMI_PHY_I2CM_INT_ADDR);
@@ -1317,10 +1326,10 @@ static int imx_hdmi_fb_registered(struct imx_hdmi *hdmi)
HDMI_PHY_I2CM_CTLINT_ADDR);
/* enable cable hot plug irq */
- hdmi_writeb(hdmi, (u8)~HDMI_PHY_RX_SENSE0, HDMI_PHY_MASK0);
+ hdmi_writeb(hdmi, (u8)mask_bits, HDMI_PHY_MASK0);
/* Clear Hotplug interrupts */
- hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_RX_SENSE0, HDMI_IH_PHY_STAT0);
+ hdmi_writeb(hdmi, stat_bit, HDMI_IH_PHY_STAT0);
return 0;
}
@@ -1524,25 +1533,32 @@ static irqreturn_t imx_hdmi_hardirq(int irq, void
*dev_id)
static irqreturn_t imx_hdmi_irq(int irq, void *dev_id)
{
struct imx_hdmi *hdmi = dev_id;
+ int stat_bit = HDMI_IH_PHY_STAT0_HPD;
+ int pol_bit = HDMI_PHY_HPD;
u8 intr_stat;
u8 phy_int_pol;
+ if (hdmi-hpd_unreliable) {
+ stat_bit = HDMI_IH_PHY_STAT0_RX_SENSE0;
+ pol_bit = HDMI_PHY_RX_SENSE0;
+ }
+
intr_stat = hdmi_readb(hdmi, HDMI_IH_PHY_STAT0);
phy_int_pol = hdmi_readb(hdmi, HDMI_PHY_POL0);
- if (intr_stat HDMI_IH_PHY_STAT0_RX_SENSE0) {
- if (phy_int_pol HDMI_PHY_RX_SENSE0) {
+ if (intr_stat stat_bit) {
+ if (phy_int_pol pol_bit) {
dev_dbg(hdmi-dev, EVENT=plugin\n);
- hdmi_modb(hdmi, 0, HDMI_PHY_RX_SENSE0, HDMI_PHY_POL0);
+ hdmi_modb(hdmi, 0, pol_bit, HDMI_PHY_POL0);
hdmi-connector_status = connector_status_connected;
imx_hdmi_poweron(hdmi);
} else {
dev_dbg(hdmi-dev, EVENT=plugout\n);
- hdmi_modb(hdmi, HDMI_PHY_RX_SENSE0, HDMI_PHY_RX_SENSE0,
HDMI_PHY_POL0);
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Eric, Am Freitag, den 03.01.2014, 12:14 -0700 schrieb Eric Nelson: This is an issue we've seen before. The SABRE Lite board has a voltage divider on the HPD pins and some monitors (esp. DVI monitors) either don't drive things high enough to assert HPD or bounce with connect/disconnect. Yes, I used a DVI monitor. We've instrumented our 3.0.35 kernels to use the RX_SENSE bits instead. Reacting to RX_SENSE0 instead of HPD seems to work. thanks Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Mon, Jan 06, 2014 at 06:41:28PM +0100, Philipp Zabel wrote: Hi Eric, Am Freitag, den 03.01.2014, 12:14 -0700 schrieb Eric Nelson: This is an issue we've seen before. The SABRE Lite board has a voltage divider on the HPD pins and some monitors (esp. DVI monitors) either don't drive things high enough to assert HPD or bounce with connect/disconnect. Yes, I used a DVI monitor. We've instrumented our 3.0.35 kernels to use the RX_SENSE bits instead. Reacting to RX_SENSE0 instead of HPD seems to work. However, it's non-compliant, because HPD can be lowered and raised by the sink when it changes its EDID data (eg, because you're connected through a switch and the routing has been changed.) So, reacting to RX_SENSE0 instead of HPD has to be a work-around enabled only for those boards which are broken in this regard. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Russell,
I've tested this series on a BD-SL (SabreLite) with HDMI. Right now
the HPD signal doesn't seem to work, but after overwriting the
connection check, I got a stable and correct picture on the monitor:
arch/arm/boot/dts/imx6q-sabrelite.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index f004913..cf9b3f5 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -50,6 +50,12 @@
};
};
+ imx-drm {
+ compatible = fsl,imx-drm;
+ crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+ connectors = hdmi;
+ };
+
sound {
compatible = fsl,imx6q-sabrelite-sgtl5000,
fsl,imx-audio-sgtl5000;
@@ -93,6 +99,12 @@
status = okay;
};
+hdmi {
+ status = okay;
+ ddc = i2c2;
+ crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+};
+
i2c1 {
status = okay;
clock-frequency = 10;
@@ -108,6 +120,13 @@
};
};
+i2c2 {
+ status = okay;
+ clock-frequency = 10;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c2_2;
+};
+
iomuxc {
pinctrl-names = default;
pinctrl-0 = pinctrl_hog;
--
1.8.5.1
Am Donnerstag, den 02.01.2014, 21:28 + schrieb Russell King:
Use the componentised device support for imx-drm. This requires all
the sub-components and the master device to register with the component
device support.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/boot/dts/imx51-babbage.dts| 10 ++-
arch/arm/boot/dts/imx53-m53evk.dts |8 ++-
arch/arm/boot/dts/imx53-mba53.dts |6 ++
arch/arm/boot/dts/imx53-qsb.dts|8 ++-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi |6 ++
drivers/staging/imx-drm/imx-drm-core.c | 105 ++-
drivers/staging/imx-drm/imx-ldb.c | 40 ---
drivers/staging/imx-drm/imx-tve.c | 63 +++--
drivers/staging/imx-drm/ipuv3-crtc.c | 46 +
drivers/staging/imx-drm/parallel-display.c | 30 ++--
10 files changed, 242 insertions(+), 80 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-babbage.dts
b/arch/arm/boot/dts/imx51-babbage.dts
index be1407cf5abd..6ff15a0eacb3 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -21,7 +21,7 @@
reg = 0x9000 0x2000;
};
- display@di0 {
+ display0: display@di0 {
compatible = fsl,imx-parallel-display;
crtcs = ipu 0;
[...]
Before moving imx-drm out of staging, I'd like to get rid of the
unfortunate 'crtcs' property. I'd rather prefer the components to be
connected with a device tree graph. I'm not quite sure if the DI0/1
should have their own device tree node inside the IPU node or if they
should just appear directly as two of four ports of the IPU (the other
two being CSI0/1). In the latter case, for example:
arch/arm/boot/dts/imx6q.dtsi | 32 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 33 -
drivers/staging/imx-drm/imx-drm-core.c | 44
3 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 187fe33..93f4721 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -132,13 +132,30 @@
};
ipu2: ipu@0280 {
- #crtc-cells = 1;
+ #address-cells = 1;
+ #size-cells = 0;
compatible = fsl,imx6q-ipu;
reg = 0x0280 0x40;
interrupts = 0 8 0x4 0 7 0x4;
clocks = clks 133, clks 134, clks 137;
clock-names = bus, di0, di1;
resets = src 4;
+
+ port@2 {
+ reg = 2;
+
+ ipu2_di0_hdmi: endpoint {
+ remote-endpoint = hdmi_mux_2;
+ };
+ };
+
+ port@3 {
+ reg = 3;
+
+ ipu2_di1_hdmi: endpoint {
+ remote-endpoint = hdmi_mux_3;
+ };
+ };
};
};
};
@@ -162,5 +179,16 @@
hdmi {
compatible = fsl,imx6q-hdmi;
- crtcs = ipu1 0, ipu1 1, ipu2 0, ipu2 1;
+
+ port@2 {
+ hdmi_mux_2: endpoint {
+ remote-endpoint = ipu2_di0_hdmi;
+ };
+ };
+
+ port@3 {
+
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM Linux: On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi Exactly. And while the RX_SENSE bits of HDMI_IH_PHY_STAT0 change when I (un)plug, the HPD bit stays zero. I'll check with other hardware. regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
On Fri, Jan 03, 2014 at 06:26:44PM +0100, Philipp Zabel wrote: Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM Linux: On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi Exactly. And while the RX_SENSE bits of HDMI_IH_PHY_STAT0 change when I (un)plug, the HPD bit stays zero. I'll check with other hardware. My guess would be that someone forgot to wire up the HPD line correctly. As ever, the documentation doesn't describe how this stuff works... -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Philipp, On 01/03/2014 10:26 AM, Philipp Zabel wrote: Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM Linux: On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: Hi Russell, I've tested this series on a BD-SL (SabreLite) with HDMI. Right now the HPD signal doesn't seem to work, but after overwriting the connection check, I got a stable and correct picture on the monitor: Hmm. Does this mean you're not getting any IRQs from the HDMI interface when you plug and unplug the monitor? 147:281 GIC 147 12.hdmi on turning the TV on: 147:282 GIC 147 12.hdmi on unplugging the HDMI cable: 147:283 GIC 147 12.hdmi on replugging the HDMI cable: 147:284 GIC 147 12.hdmi Exactly. And while the RX_SENSE bits of HDMI_IH_PHY_STAT0 change when I (un)plug, the HPD bit stays zero. I'll check with other hardware. This is an issue we've seen before. The SABRE Lite board has a voltage divider on the HPD pins and some monitors (esp. DVI monitors) either don't drive things high enough to assert HPD or bounce with connect/disconnect. We've instrumented our 3.0.35 kernels to use the RX_SENSE bits instead. Regards, Eric ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
