| Message ID | E1WsudP-0003TB-R1@rmk-PC.arm.linux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Russell, On Fri, Jun 6, 2014 at 10:56 AM, Russell King <rmk+kernel@arm.linux.org.uk> wrote: > The initial state at boot is assumed to be disconnected, and we hope > to receive an interrupt to update the status. Let's be more explicit > about the current state - reading the PHY status register tells us > the current level of the hotplug signal, which we can report back in > the _detect() method. > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> I have applied this patch against 3.15 and I still have the following issue on a mx6qsabresd: If I boot the kernel with the HDMI cable connected, no HDMI image comes up. In order to get HDMI working I need to remove and then reconnect the cable. Still haven't had a chance to debug this though.
On Mon, Jun 09, 2014 at 10:44:14AM -0300, Fabio Estevam wrote: > Russell, > > On Fri, Jun 6, 2014 at 10:56 AM, Russell King > <rmk+kernel@arm.linux.org.uk> wrote: > > The initial state at boot is assumed to be disconnected, and we hope > > to receive an interrupt to update the status. Let's be more explicit > > about the current state - reading the PHY status register tells us > > the current level of the hotplug signal, which we can report back in > > the _detect() method. > > > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > > I have applied this patch against 3.15 and I still have the following > issue on a mx6qsabresd: > > If I boot the kernel with the HDMI cable connected, no HDMI image > comes up. In order to get HDMI working I need to remove and then > reconnect the cable. > > Still haven't had a chance to debug this though. Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This should report the current state of the hotplug detection. Remember that this code detects off the HPD signal - if the HPD signal has not been correctly wired up, this patch is not going to help (really it comes down to a hardware fault, which I'm not trying to solve with this patch.) What I'm trying to resolve with this patch is that the state detected on properly wired up systems corresponds with the real initial state of the interface at initialisation time. The problem with the current code is that we start off assuming that the interface is disconnected, and we rely on an interrupt arriving to change that state. If for whatever reason that interrupt does not arrive, then, even if the HPD signal is active, we continue believing that the interface is not connected. I seem to remember discussion in the past that the HPD signal is not wired up on SabreSD. Really, this needs to be a DT flag to indicate that the connectivity on the platform is not correct, and we should fallback to using RXSENSE detection and/or DDC polling (both of which are sub-standard and incorrect to the HDMI spec.) I'd suggest a standard HDMI interface property like: hotplug-detect = "hpd" | "rxsense" | "ddc" defaulting to the standard hpd method. As I've said in the past, my problem with just going with DDC polling for everything is that the connected HDMI sink is permitted to update the EDID EEPROM (when it does, it is required to lower and re-raise the HPD signal.) If we are polling DDC, we may hit the situation where the EDID EEPROM is mid-update and possibly end up with corrupted data (though there's a checksum to save us from this.) While I2C is multi-master, we're talking about consumer stuff here, and I bet I2C arbitration on the DDC bus is not something that is tested. I would not be surprised if the assumption is made that when HPD is lowered, the HDMI sink has exclusive access to the EEPROM and doesn't need to be concerned with arbitration. RXSENSE has the problem that it doesn't detect EDID updates (there's no requirement for a HDMI sink to make RXSENSE on a source go inactive across an EDID update.) So, I would much rather go by the spec, using the HPD signal on devices where that signal is correctly wired, and only fall back to other methods (which cause us to go against the standard) where the hardware is buggy.
On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This > should report the current state of the hotplug detection. /sys/class/drm/card0-HDMI-A-1/status returns the correct state for HDMI cable connection. > Remember that this code detects off the HPD signal - if the HPD signal > has not been correctly wired up, this patch is not going to help (really > it comes down to a hardware fault, which I'm not trying to solve with > this patch.) > > What I'm trying to resolve with this patch is that the state detected > on properly wired up systems corresponds with the real initial state of > the interface at initialisation time. > > The problem with the current code is that we start off assuming that the > interface is disconnected, and we rely on an interrupt arriving to change > that state. If for whatever reason that interrupt does not arrive, then, > even if the HPD signal is active, we continue believing that the interface > is not connected. > > I seem to remember discussion in the past that the HPD signal is not > wired up on SabreSD. Really, this needs to be a DT flag to indicate It is sabrelite board that does not have HPD signal not wired up. sabresd does have HPD signal connected. The HDMI undetected issue I am seeing on sabresd seems to be related to the simultaneous usage of HDMI and LVDS. If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI cable is correctly detected and HDMI is shown right after boot.
On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote: > On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This > > should report the current state of the hotplug detection. > > /sys/class/drm/card0-HDMI-A-1/status returns the correct state for > HDMI cable connection. > > > Remember that this code detects off the HPD signal - if the HPD signal > > has not been correctly wired up, this patch is not going to help (really > > it comes down to a hardware fault, which I'm not trying to solve with > > this patch.) > > > > What I'm trying to resolve with this patch is that the state detected > > on properly wired up systems corresponds with the real initial state of > > the interface at initialisation time. > > > > The problem with the current code is that we start off assuming that the > > interface is disconnected, and we rely on an interrupt arriving to change > > that state. If for whatever reason that interrupt does not arrive, then, > > even if the HPD signal is active, we continue believing that the interface > > is not connected. > > > > I seem to remember discussion in the past that the HPD signal is not > > wired up on SabreSD. Really, this needs to be a DT flag to indicate > > It is sabrelite board that does not have HPD signal not wired up. > > sabresd does have HPD signal connected. > > The HDMI undetected issue I am seeing on sabresd seems to be related > to the simultaneous usage of HDMI and LVDS. > > If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI > cable is correctly detected and HDMI is shown right after boot. This is a known limitation. http://thread.gmane.org/gmane.linux.ports.arm.kernel/315968/focus=318559 Shawn
On Mon, Jun 9, 2014 at 11:33 AM, Shawn Guo <shawn.guo@freescale.com> wrote: > On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote: >> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> >> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This >> > should report the current state of the hotplug detection. >> >> /sys/class/drm/card0-HDMI-A-1/status returns the correct state for >> HDMI cable connection. >> >> > Remember that this code detects off the HPD signal - if the HPD signal >> > has not been correctly wired up, this patch is not going to help (really >> > it comes down to a hardware fault, which I'm not trying to solve with >> > this patch.) >> > >> > What I'm trying to resolve with this patch is that the state detected >> > on properly wired up systems corresponds with the real initial state of >> > the interface at initialisation time. >> > >> > The problem with the current code is that we start off assuming that the >> > interface is disconnected, and we rely on an interrupt arriving to change >> > that state. If for whatever reason that interrupt does not arrive, then, >> > even if the HPD signal is active, we continue believing that the interface >> > is not connected. >> > >> > I seem to remember discussion in the past that the HPD signal is not >> > wired up on SabreSD. Really, this needs to be a DT flag to indicate >> >> It is sabrelite board that does not have HPD signal not wired up. >> >> sabresd does have HPD signal connected. >> >> The HDMI undetected issue I am seeing on sabresd seems to be related >> to the simultaneous usage of HDMI and LVDS. >> >> If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI >> cable is correctly detected and HDMI is shown right after boot. > > This is a known limitation. > > http://thread.gmane.org/gmane.linux.ports.arm.kernel/315968/focus=318559 There were versions of linux-next that hdmi and lvds works at the same time without problems.
On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote: > On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This > > should report the current state of the hotplug detection. > > /sys/class/drm/card0-HDMI-A-1/status returns the correct state for > HDMI cable connection. Good, so that means we're reporting the correct status to the DRM layer. Please post the kernel boot messages, one with the HDMI cable disconnected, and one with a HDMI sink connected. > The HDMI undetected issue I am seeing on sabresd seems to be related > to the simultaneous usage of HDMI and LVDS. > > If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI > cable is correctly detected and HDMI is shown right after boot. I wonder if the problem is that HDMI and LVDS are interfering with each other wrt the required pixel clock, and LVDS is winning. If we have HDMI enabled, many HDMI sinks will only work if we set one of their supported modes (with the dot clock within 1% - though some sinks are more lenient). I think the Novena people have run into this issue, but I've not seen much in the way of contributions back, despite them making use of my patches...
On Mon, Jun 9, 2014 at 2:49 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Jun 09, 2014 at 11:29:28AM -0300, Fabio Estevam wrote: >> On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> >> > Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This >> > should report the current state of the hotplug detection. >> >> /sys/class/drm/card0-HDMI-A-1/status returns the correct state for >> HDMI cable connection. > > Good, so that means we're reporting the correct status to the DRM layer. > Please post the kernel boot messages, one with the HDMI cable disconnected, > and one with a HDMI sink connected. With HDMI cable connected (no image is seen on HDMI, only on lvds cable): imx-ipuv3 2400000.ipu: IPUv3H probed imx-ipuv3 2800000.ipu: IPUv3H probed [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). mmcblk0: mmc1:0007 SD4GB 3.70 GiB [drm] No driver support for vblank timestamp query. mmcblk0: unknown partition table imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) imx-drm display-subsystem.11: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops) imx-drm display-subsystem.11: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops) imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 imx-hdmi 120000.hdmi: hdmi_set_clk_regenerator: samplerate=48000 ratio=100 pixelclk=74250000 N=6144 cts=74250 imx-drm display-subsystem.11: bound 120000.hdmi (ops hdmi_ops) imx-hdmi 120000.hdmi: EVENT=plugin imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 0 imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops) imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode imx-hdmi 120000.hdmi: got edid: width[51] x height[28] imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 138500000 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 138500000 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode If I disconnect/reconnect the HDMI cable (then image is seen on both HDMI and LVDS): root@freescale /$ imx-hdmi 120000.hdmi: EVENT=plugout imx-hdmi 120000.hdmi: EVENT=plugin imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 138500000 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode imx-hdmi 120000.hdmi: got edid: width[51] x height[28] imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 138500000 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 138500000 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode Now booting the kernel with HDMI disconnected: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). mmcblk0: mmc1:0007 SD4GB 3.70 GiB [drm] No driver support for vblank timestamp query. mmcblk0: unknown partition table imx-drm display-subsystem.11: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) imx-drm display-subsystem.11: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) imx-drm display-subsystem.11: bound imx-ipuv3-crtc.2 (ops ipu_crtc_ops) imx-drm display-subsystem.11: bound imx-ipuv3-crtc.3 (ops ipu_crtc_ops) imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 imx-hdmi 120000.hdmi: hdmi_set_clk_regenerator: samplerate=48000 ratio=100 pixelclk=74250000 N=6144 cts=74250 imx-drm display-subsystem.11: bound 120000.hdmi (ops hdmi_ops) imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops) Console: switching to colour frame buffer device 128x48 imx-drm display-subsystem.11: fb0: frame buffer device imx-drm display-subsystem.11: registered panic notifier [drm] Initialized imx-drm 1.0.0 20120507 on minor 0 And after connecting the HDMI cable: imx-hdmi 120000.hdmi: EVENT=plugin imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 0 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode imx-hdmi 120000.hdmi: got edid: width[51] x height[28] imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 78800000 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI imx-hdmi 120000.hdmi: final pixclk = 78800000 imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode Image is seen on both LVDS and HDMI monitor, but HDMI resolution is not correct (this is a different bug though). > >> The HDMI undetected issue I am seeing on sabresd seems to be related >> to the simultaneous usage of HDMI and LVDS. >> >> If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI >> cable is correctly detected and HDMI is shown right after boot. > > I wonder if the problem is that HDMI and LVDS are interfering with each > other wrt the required pixel clock, and LVDS is winning. If we have > HDMI enabled, many HDMI sinks will only work if we set one of their > supported modes (with the dot clock within 1% - though some sinks are > more lenient). Yes, it seems this is the case. Thanks
On Mon, Jun 09, 2014 at 03:15:16PM -0300, Fabio Estevam wrote: > With HDMI cable connected (no image is seen on HDMI, only on lvds cable): > > imx-drm display-subsystem.11: bound 120000.hdmi (ops hdmi_ops) > imx-hdmi 120000.hdmi: EVENT=plugin > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 0 Right, so it does know that the HDMI sink is connected... > imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops) > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode > imx-hdmi 120000.hdmi: got edid: width[51] x height[28] > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 138500000 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 138500000 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode And the mode it's setting has a pixel clock frequency of 138.5MHz here. > If I disconnect/reconnect the HDMI cable (then image is seen on both > HDMI and LVDS): > > root@freescale /$ imx-hdmi 120000.hdmi: EVENT=plugout > imx-hdmi 120000.hdmi: EVENT=plugin > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 138500000 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode > imx-hdmi 120000.hdmi: got edid: width[51] x height[28] > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 138500000 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 138500000 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode And here it again configures 138.5MHz pixel clock - same as above. So, from this we can't see any difference in the setup, and we can say that it's not mode->clock which is the problem. > Now booting the kernel with HDMI disconnected: > > imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 > imx-hdmi 120000.hdmi: hdmi_set_clk_regenerator: samplerate=48000 > ratio=100 pixelclk=74250000 N=6144 cts=74250 > imx-drm display-subsystem.11: bound 120000.hdmi (ops hdmi_ops) Right, so here it knows that there's nothing connected. > imx-drm display-subsystem.11: bound ldb.10 (ops imx_ldb_ops) > Console: switching to colour frame buffer device 128x48 So it selects an initial mode based upon the LVDS device configuration. > And after connecting the HDMI cable: > > imx-hdmi 120000.hdmi: EVENT=plugin > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 0 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode > imx-hdmi 120000.hdmi: got edid: width[51] x height[28] > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 78800000 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode > imx-hdmi 120000.hdmi: Non-CEA mode used in HDMI > imx-hdmi 120000.hdmi: final pixclk = 78800000 > imx-hdmi 120000.hdmi: imx_hdmi_setup DVI mode > > Image is seen on both LVDS and HDMI monitor, but HDMI resolution is > not correct (this is a different bug though). I'm guessing that here, DRM kept the original configuration rather than selecting one appropriate to the newly connected device.
On Mon, Jun 9, 2014 at 7:29 AM, Fabio Estevam <festevam@gmail.com> wrote: > On Mon, Jun 9, 2014 at 11:06 AM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > >> Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This >> should report the current state of the hotplug detection. > > /sys/class/drm/card0-HDMI-A-1/status returns the correct state for > HDMI cable connection. > >> Remember that this code detects off the HPD signal - if the HPD signal >> has not been correctly wired up, this patch is not going to help (really >> it comes down to a hardware fault, which I'm not trying to solve with >> this patch.) >> >> What I'm trying to resolve with this patch is that the state detected >> on properly wired up systems corresponds with the real initial state of >> the interface at initialisation time. >> >> The problem with the current code is that we start off assuming that the >> interface is disconnected, and we rely on an interrupt arriving to change >> that state. If for whatever reason that interrupt does not arrive, then, >> even if the HPD signal is active, we continue believing that the interface >> is not connected. >> >> I seem to remember discussion in the past that the HPD signal is not >> wired up on SabreSD. Really, this needs to be a DT flag to indicate > > It is sabrelite board that does not have HPD signal not wired up. > > sabresd does have HPD signal connected. > > The HDMI undetected issue I am seeing on sabresd seems to be related > to the simultaneous usage of HDMI and LVDS. > > If I remove the ldb node from the imx6qdl-sabresd.dtsi, then the HDMI > cable is correctly detected and HDMI is shown right after boot. Fabio, I'm following along with this thread as I see the same thing you do on our Ventana boards that support both LVDS and HDMI: without hot-plugging the HDMI connector I get not HDMI out simply by having the LVDS node populated. I am curious however how you are getting simultaneous display on both LVDS and HDMI on a SabreSD board as the standard resistor loading would make the EDID's of both conflict (which causes EDID read failures) - perhaps you are using an LVDS display with no EDID or perhaps you have modified the resistor loading on a SabreSD to move them to different i2cs? Or is there some kernel param/config I don't see to tell the imx_hdmi driver to ignore EDID and force in a mode? Regards, Tim
Hi Tim, On Tue, Jun 10, 2014 at 3:54 PM, Tim Harvey <tharvey@gateworks.com> wrote: > Fabio, > > I'm following along with this thread as I see the same thing you do on > our Ventana boards that support both LVDS and HDMI: without > hot-plugging the HDMI connector I get not HDMI out simply by having > the LVDS node populated. > > I am curious however how you are getting simultaneous display on both > LVDS and HDMI on a SabreSD board as the standard resistor loading > would make the EDID's of both conflict (which causes EDID read > failures) - perhaps you are using an LVDS display with no EDID or Yes, there is no EDID in the LVDS I am using. imxqdl-sabresd.dtsi declares the LVDS resolution to be 1024x768 and it never changes.
diff --git a/drivers/staging/imx-drm/imx-hdmi.c b/drivers/staging/imx-drm/imx-hdmi.c index d47dedd2cdb4..6f5efcc89880 100644 --- a/drivers/staging/imx-drm/imx-hdmi.c +++ b/drivers/staging/imx-drm/imx-hdmi.c @@ -120,8 +120,6 @@ struct imx_hdmi { struct clk *isfr_clk; struct clk *iahb_clk; - enum drm_connector_status connector_status; - struct hdmi_data_info hdmi_data; int vic; @@ -1382,7 +1380,9 @@ static enum drm_connector_status imx_hdmi_connector_detect(struct drm_connector { struct imx_hdmi *hdmi = container_of(connector, struct imx_hdmi, connector); - return hdmi->connector_status; + + return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ? + connector_status_connected : connector_status_disconnected; } static int imx_hdmi_connector_get_modes(struct drm_connector *connector) @@ -1524,7 +1524,6 @@ static irqreturn_t imx_hdmi_irq(int irq, void *dev_id) hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0); - hdmi->connector_status = connector_status_connected; imx_hdmi_poweron(hdmi); } else { dev_dbg(hdmi->dev, "EVENT=plugout\n"); @@ -1532,7 +1531,6 @@ static irqreturn_t imx_hdmi_irq(int irq, void *dev_id) hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD, HDMI_PHY_POL0); - hdmi->connector_status = connector_status_disconnected; imx_hdmi_poweroff(hdmi); } drm_helper_hpd_irq_event(hdmi->connector.dev); @@ -1606,7 +1604,6 @@ static int imx_hdmi_bind(struct device *dev, struct device *master, void *data) return -ENOMEM; hdmi->dev = dev; - hdmi->connector_status = connector_status_disconnected; hdmi->sample_rate = 48000; hdmi->ratio = 100;
The initial state at boot is assumed to be disconnected, and we hope to receive an interrupt to update the status. Let's be more explicit about the current state - reading the PHY status register tells us the current level of the hotplug signal, which we can report back in the _detect() method. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> --- This fix should go in for -rc - though it's probably too late to get it in for 3.15, it may be considered as a potential stable candidate. If not, can we get this in for 3.16-rc1 please? Thanks. drivers/staging/imx-drm/imx-hdmi.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)