From mboxrd@z Thu Jan 1 00:00:00 1970 From: "K, Mythri P" Date: Wed, 14 Sep 2011 12:32:03 +0000 Subject: Re: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect() Message-Id: List-Id: References: <1315818818-18733-1-git-send-email-tomi.valkeinen@ti.com> <1315818818-18733-10-git-send-email-tomi.valkeinen@ti.com>

<1315984468.2172.10.camel@deskari> <1315989282.2172.36.camel@deskari> <1315990630.2172.51.camel@deskari> In-Reply-To: <1315990630.2172.51.camel@deskari> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Tomi Valkeinen Cc: Rob Clark , linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, archit@ti.com Hi, On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen wro= te: > On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote: >> On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen = wrote: >> > On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote: >> >> On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen wrote: > > > >> > I don't understand this one. How could this be more dynamic? The >> > function checks the HPD bit, which (based on my observation) shows the >> > status whether a display is connected or not. >> There is a GPIO which detects the +3.3V on the line and detects the >> cable connect , there is also an interrupt based way.This is ideally >> called a Hot-plug detect event according to the spec in HDMI terms. >> But what you are saying here is that it is just a poll on the state? > > Yes, it's just for polling, but I don't quite see the difference. A > hot-plug event notifies when the display is connected or disconnected, > and detect() tells if a display is connected. They are all about the > same thing. > >> >> So I said if the purpose of this function is only to check for the HPD >> >> state bit it is fine. >> > >> > What does HPD bit tell us then? >> >> HPD state bit tells whether the cable is connected and whether EDID is > > This sounds like a good bit to test then. So is there something wrong > with using HPD? How does the GPIO differ from HPD bit? > >> ready to be read, But this is a static check that is done in this >> function. > > I don't understand what you mean with "static". The bit changes > dynamically according to the connect/disconnect state, and the bit is > checked dynamically when detect() is called. > Well ! Who would call the detect and why ? By Dynamic i meant when the cable is physically disconnected and connected there is detection logic which can be implemented either by GPIo/Interrupts. When you say the cable is connected , what happens in this case when the cable is connected to say monitor of one resolution and then plugged out and put to the other. Instead with dynamic method the based on the physical connect and disconnect the notification would be sent to any listener. Thanks and regards, Mythri. > =A0Tomi > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "K, Mythri P" Subject: Re: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect() Date: Wed, 14 Sep 2011 17:50:03 +0530 Message-ID: References: <1315818818-18733-1-git-send-email-tomi.valkeinen@ti.com> <1315818818-18733-10-git-send-email-tomi.valkeinen@ti.com>

<1315984468.2172.10.camel@deskari> <1315989282.2172.36.camel@deskari> <1315990630.2172.51.camel@deskari> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from na3sys009aog109.obsmtp.com ([74.125.149.201]:51891 "EHLO na3sys009aog109.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756475Ab1INMUY convert rfc822-to-8bit (ORCPT ); Wed, 14 Sep 2011 08:20:24 -0400 In-Reply-To: <1315990630.2172.51.camel@deskari> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tomi Valkeinen Cc: Rob Clark , linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, archit@ti.com Hi, On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen = wrote: > On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote: >> On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen wrote: >> > On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote: >> >> On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen wrote: > > > >> > I don't understand this one. How could this be more dynamic? The >> > function checks the HPD bit, which (based on my observation) shows= the >> > status whether a display is connected or not. >> There is a GPIO which detects the +3.3V on the line and detects the >> cable connect , there is also an interrupt based way.This is ideally >> called a Hot-plug detect event according to the spec in HDMI terms. >> But what you are saying here is that it is just a poll on the state? > > Yes, it's just for polling, but I don't quite see the difference. A > hot-plug event notifies when the display is connected or disconnected= , > and detect() tells if a display is connected. They are all about the > same thing. > >> >> So I said if the purpose of this function is only to check for th= e HPD >> >> state bit it is fine. >> > >> > What does HPD bit tell us then? >> >> HPD state bit tells whether the cable is connected and whether EDID = is > > This sounds like a good bit to test then. So is there something wrong > with using HPD? How does the GPIO differ from HPD bit? > >> ready to be read, But this is a static check that is done in this >> function. > > I don't understand what you mean with "static". The bit changes > dynamically according to the connect/disconnect state, and the bit is > checked dynamically when detect() is called. > Well ! Who would call the detect and why ? By Dynamic i meant when the cable is physically disconnected and connected there is detection logic which can be implemented either by GPIo/Interrupts. When you say the cable is connected , what happens in this case when the cable is connected to say monitor of one resolution and then plugged out and put to the other. Instead with dynamic method the based on the physical connect and disconnect the notification would be sent to any listener. Thanks and regards, Mythri. > =A0Tomi > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html