From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "K, Mythri P" <mythripk@ti.com>
Cc: Rob Clark <robdclark@gmail.com>,
linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
archit@ti.com
Subject: Re: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect()
Date: Wed, 14 Sep 2011 14:11:49 +0000 [thread overview]
Message-ID: <1316009509.2118.6.camel@deskari> (raw)
In-Reply-To: <CAP5A+B9Me0RX3PY7Uwf=VuaHzaPtoNY0q9gxFg9H-Q3N2giC2Q@mail.gmail.com>
On Wed, 2011-09-14 at 17:50 +0530, K, Mythri P wrote:
> Hi,
>
> On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> 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 <tomi.valkeinen@ti.com> 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 <tomi.valkeinen@ti.com> wrote:
> >
> > <snip>
> >
> >> > 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.
Ok, I see now what you mean.
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
Tomi
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "K, Mythri P" <mythripk@ti.com>
Cc: Rob Clark <robdclark@gmail.com>,
linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
archit@ti.com
Subject: Re: [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect()
Date: Wed, 14 Sep 2011 17:11:49 +0300 [thread overview]
Message-ID: <1316009509.2118.6.camel@deskari> (raw)
In-Reply-To: <CAP5A+B9Me0RX3PY7Uwf=VuaHzaPtoNY0q9gxFg9H-Q3N2giC2Q@mail.gmail.com>
On Wed, 2011-09-14 at 17:50 +0530, K, Mythri P wrote:
> Hi,
>
> On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> 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 <tomi.valkeinen@ti.com> 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 <tomi.valkeinen@ti.com> wrote:
> >
> > <snip>
> >
> >> > 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.
Ok, I see now what you mean.
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
Tomi
next prev parent reply other threads:[~2011-09-14 14:11 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-12 9:13 [PATCHv2 00/15] OMAP: DSS2: EDID & detect support Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 01/15] OMAP: DSS2: add read_edid() to omap_dss_driver struct Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 02/15] OMAP: DSS2: add detect() " Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 03/15] OMAP: DSS2: HDMI: make set_timing saner Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 04/15] OMAP: DSS2: HDMI: implement read_edid() Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 05/15] OMAP: DSS2: HDMI: remove edid parsing Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 06/15] OMAP: DSS2: HDMI: split hdmi_core_ddc_edid Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 07/15] OMAP: DSS2: HDMI: clean up edid reading & fix checksum Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 08/15] OMAP: DSS2: HDMI: remove error prints in check_timings Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect() Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 13:24 ` K, Mythri P
2011-09-12 13:36 ` K, Mythri P
2011-09-12 16:18 ` Tomi Valkeinen
2011-09-12 16:18 ` Tomi Valkeinen
2011-09-12 16:46 ` Rob Clark
2011-09-12 16:46 ` Rob Clark
2011-09-14 5:34 ` K, Mythri P
2011-09-14 5:46 ` K, Mythri P
2011-09-14 7:14 ` Tomi Valkeinen
2011-09-14 7:14 ` Tomi Valkeinen
2011-09-14 8:27 ` K, Mythri P
2011-09-14 8:39 ` K, Mythri P
2011-09-14 8:34 ` Tomi Valkeinen
2011-09-14 8:34 ` Tomi Valkeinen
2011-09-14 8:48 ` K, Mythri P
2011-09-14 8:48 ` K, Mythri P
2011-09-14 8:57 ` Tomi Valkeinen
2011-09-14 8:57 ` Tomi Valkeinen
2011-09-14 12:20 ` K, Mythri P
2011-09-14 12:32 ` K, Mythri P
2011-09-14 14:11 ` Tomi Valkeinen [this message]
2011-09-14 14:11 ` Tomi Valkeinen
2011-09-15 5:41 ` K, Mythri P
2011-09-15 5:53 ` K, Mythri P
2011-09-15 5:57 ` Tomi Valkeinen
2011-09-15 5:57 ` Tomi Valkeinen
2011-09-15 6:24 ` K, Mythri P
2011-09-15 6:36 ` K, Mythri P
2011-09-15 6:32 ` Tomi Valkeinen
2011-09-15 6:32 ` Tomi Valkeinen
2011-09-16 12:41 ` K, Mythri P
2011-09-16 12:53 ` K, Mythri P
2011-09-19 6:50 ` Tomi Valkeinen
2011-09-19 6:50 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 10/15] OMAP: DSS2: add panel-dvi driver Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 11/15] OMAP: use dvi panel driver instead of generic-dpi Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 12/15] OMAP: stalker: Remove LCD device from board file Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 13/15] OMAP: DSS2: panel-generic-dpi: remove "generic" panel Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:13 ` [PATCHv2 14/15] OMAP: Panda, Beagle, Overo: DVI: Add i2c_bus_num Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
2011-09-12 9:58 ` Enric Balletbò i Serra
2011-09-12 9:58 ` Enric Balletbò i Serra
2011-09-12 10:17 ` [PATCHv2 14/15] OMAP: Panda, Beagle, Overo: DVI: Add Tomi Valkeinen
2011-09-12 10:17 ` [PATCHv2 14/15] OMAP: Panda, Beagle, Overo: DVI: Add i2c_bus_num Tomi Valkeinen
2011-09-12 11:13 ` Enric Balletbò i Serra
2011-09-12 11:13 ` Enric Balletbò i Serra
2011-09-12 9:13 ` [PATCHv2 15/15] OMAPFB: find best mode from edid Tomi Valkeinen
2011-09-12 9:13 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1316009509.2118.6.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=archit@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mythripk@ti.com \
--cc=robdclark@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.