public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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: Thu, 15 Sep 2011 09:32:51 +0300	[thread overview]
Message-ID: <1316068371.1880.25.camel@deskari> (raw)
In-Reply-To: <CAP5A+B_WvtNTi9ckyor-+5bo7n6GkeTSAvhDsrGQxhPZWgXO0w@mail.gmail.com>

On Thu, 2011-09-15 at 11:54 +0530, K, Mythri P wrote:
> Hi,
> 
> On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote:
> >> Hi,
> >>
> >> On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >
> >> > 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.
> >> >
> >> If it is needed for DRM then it is fine, but with detect renamed to
> >> poll. By next week i should have a patch ready for HPD event
> >> mechanism.
> >
> > What is wrong with "detect"? It detects if there's a display connected.
> > It can be used in polling manner, trying it every n seconds, but it
> > should also be used even if you use HPD event. I think the normal
> > sequence would be something like:
> >
> > 1) register HPD event
> > 2) use detect() to see if a monitor is already connected
> >
> I guess polling ever few seconds to detect would be waste of CPU
> cycles when there is already a mechanism in the H/w to detect the
> connection.

Obviously. Polling is only used if hot-plug-detect is not available. But
detect function can be used even when HPD is available.

> Current sequence :
> Enable display ( Irrespective of whether the cable is connected on not)
> 
> Sequence with HPD:
> 1.Register for HPD connect.
> 2.Enable display
> 3.Notify DRM/Audio/Kernel component that wants to listen to this event.

Why would you enable the display even if there's no monitor connected?

And when the DRM starts, how does DRM know if the display was already
connected? Would you send a HPD event when DRM registers to the event
even if there's no actual plug-in event done (i.e. user actually
connecting the cable)?

And just to clarify, my sequence example was from DRM's point of view.
The HDMI driver shouldn't do anything before DRM/omapfb asks it to do
something.

 Tomi



  reply	other threads:[~2011-09-15  6:32 UTC|newest]

Thread overview: 36+ 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 ` [PATCHv2 01/15] OMAP: DSS2: add read_edid() to omap_dss_driver struct Tomi Valkeinen
2011-09-12  9:13 ` [PATCHv2 02/15] OMAP: DSS2: add detect() " Tomi Valkeinen
2011-09-12  9:13 ` [PATCHv2 03/15] OMAP: DSS2: HDMI: make set_timing saner Tomi Valkeinen
2011-09-12  9:13 ` [PATCHv2 04/15] OMAP: DSS2: HDMI: implement read_edid() Tomi Valkeinen
2011-09-12  9:13 ` [PATCHv2 05/15] OMAP: DSS2: HDMI: remove edid parsing 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 ` [PATCHv2 07/15] OMAP: DSS2: HDMI: clean up edid reading & fix checksum 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 ` [PATCHv2 09/15] OMAP: DSS2: HDMI: implement detect() Tomi Valkeinen
2011-09-12 13:24   ` K, Mythri P
2011-09-12 16:18     ` Tomi Valkeinen
2011-09-12 16:46     ` Rob Clark
2011-09-14  5:34       ` K, Mythri P
2011-09-14  7:14         ` Tomi Valkeinen
2011-09-14  8:27           ` K, Mythri P
2011-09-14  8:34             ` Tomi Valkeinen
2011-09-14  8:48               ` K, Mythri P
2011-09-14  8:57                 ` Tomi Valkeinen
2011-09-14 12:20                   ` K, Mythri P
2011-09-14 14:11                     ` Tomi Valkeinen
2011-09-15  5:41                       ` K, Mythri P
2011-09-15  5:57                         ` Tomi Valkeinen
2011-09-15  6:24                           ` K, Mythri P
2011-09-15  6:32                             ` Tomi Valkeinen [this message]
2011-09-16 12:41                               ` K, Mythri P
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 ` [PATCHv2 11/15] OMAP: use dvi panel driver instead of generic-dpi 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 ` [PATCHv2 13/15] OMAP: DSS2: panel-generic-dpi: remove "generic" panel 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:58   ` Enric Balletbò i Serra
2011-09-12 10:17     ` Tomi Valkeinen
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

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=1316068371.1880.25.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox