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 Wed, Jan 08, 2014 at 09:32:58PM +, Russell King - ARM Linux wrote:
> 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?
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.
---8<---
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts
b/arch/arm/boot/dts/imx6q-sabresd.dts
index 9cbdfe7..66f220a 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -20,6 +20,10 @@
compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
};
+&imx_drm {
+ crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
+};
+
&sata {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 0e005f2..dfca3e0 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -62,7 +62,7 @@
};
};
- imx-drm {
+ imx_drm: imx-drm {
compatible = "fsl,imx-drm";
crtcs = <&ipu1 0>, <&ipu1 1>;
connectors = <&ldb>;
___
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
> 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
> ---
> 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
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
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
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
---
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->de
Re: [PATCH RFC 27/46] imx-drm: convert to componentised device support
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 Regards, Eric ___ 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
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>;
};
Shawn
> sound {
> compatible = "fsl,imx6q-sabresd-wm8962",
> "fsl,imx-audio-wm8962";
___
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, 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. Regards, Eric ___ 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 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
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
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
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 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
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
> ---
> 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_m
