From: Tomi Valkeinen <tomi.valkeinen@ti.com> To: Jassi Brar <jaswinder.singh@linaro.org> Cc: mythripk@ti.com, linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, andy.green@linaro.org, n-dechesne@ti.com, patches@linaro.org Subject: Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID Date: Thu, 28 Jun 2012 11:04:16 +0000 [thread overview] Message-ID: <1340881456.5037.47.camel@deskari> (raw) In-Reply-To: <CAJe_Zhc_ye1f=hOVd=AJ7rmCQ_vwDtjQOKsufPYmV1o-58jyAA@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1732 bytes --] On Thu, 2012-06-28 at 16:17 +0530, Jassi Brar wrote: > On 28 June 2012 15:44, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > > When the display device is disabled, we're not listening to the hpd > > interrupt anymore. So when it's disabled, the cable can be replugged and > > the monitor changed, and the driver won't know about it. And so it'll > > return the old EDID for the new monitor. > > > If that could be a problem, then we already have some problem with > current omapdss. > > I think among the first things, while enabling HDMI, should be to see > if there is really some display connected on the port i.e, HPD > asserted. Only if ti_hdmi_4xxx_detect() returned true, should we > proceed otherwise wait for HPQ irq. I'm not sure I understand. The HDMI driver does just that. It calls hdmi_check_hpd_state when it's being enabled to see if there's a display connected. > Unconditionally invalidating edid really seems like a regression - we > impose atleast 50ms (edid read) as extra cost on > hdmi_check_hpd_state(), which kills half the purpose of this patch. If the HDMI hardware is turned off, we should unconditionally invalidate the EDID. We have no way to keep track if the same monitor is kept plugged in or not. So what exactly is the purpose of this patch, what kind of scenario? I thought it's to cache the EDID, so that if it will be read multiple times while the same monitor is connected, we'll just return the cached value. Of course, I don't know why the upper layers would read the EDID multiple times, because I think they should read it only once. So perhaps I'm either not understanding something, or it's the omapdrm layer that should be fixed? Tomi [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com> To: Jassi Brar <jaswinder.singh@linaro.org> Cc: mythripk@ti.com, linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, andy.green@linaro.org, n-dechesne@ti.com, patches@linaro.org Subject: Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID Date: Thu, 28 Jun 2012 14:04:16 +0300 [thread overview] Message-ID: <1340881456.5037.47.camel@deskari> (raw) In-Reply-To: <CAJe_Zhc_ye1f=hOVd=AJ7rmCQ_vwDtjQOKsufPYmV1o-58jyAA@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1732 bytes --] On Thu, 2012-06-28 at 16:17 +0530, Jassi Brar wrote: > On 28 June 2012 15:44, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > > When the display device is disabled, we're not listening to the hpd > > interrupt anymore. So when it's disabled, the cable can be replugged and > > the monitor changed, and the driver won't know about it. And so it'll > > return the old EDID for the new monitor. > > > If that could be a problem, then we already have some problem with > current omapdss. > > I think among the first things, while enabling HDMI, should be to see > if there is really some display connected on the port i.e, HPD > asserted. Only if ti_hdmi_4xxx_detect() returned true, should we > proceed otherwise wait for HPQ irq. I'm not sure I understand. The HDMI driver does just that. It calls hdmi_check_hpd_state when it's being enabled to see if there's a display connected. > Unconditionally invalidating edid really seems like a regression - we > impose atleast 50ms (edid read) as extra cost on > hdmi_check_hpd_state(), which kills half the purpose of this patch. If the HDMI hardware is turned off, we should unconditionally invalidate the EDID. We have no way to keep track if the same monitor is kept plugged in or not. So what exactly is the purpose of this patch, what kind of scenario? I thought it's to cache the EDID, so that if it will be read multiple times while the same monitor is connected, we'll just return the cached value. Of course, I don't know why the upper layers would read the EDID multiple times, because I think they should read it only once. So perhaps I'm either not understanding something, or it's the omapdrm layer that should be fixed? Tomi [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-28 11:04 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-06-27 14:05 [PATCH 3/3] OMAPDSS: HDMI: Cache EDID jaswinder.singh 2012-06-27 14:17 ` jaswinder.singh 2012-06-28 7:48 ` Tomi Valkeinen 2012-06-28 7:48 ` Tomi Valkeinen 2012-06-28 9:48 ` Jassi Brar 2012-06-28 9:51 ` Jassi Brar 2012-06-28 10:14 ` Tomi Valkeinen 2012-06-28 10:14 ` Tomi Valkeinen 2012-06-28 10:47 ` Jassi Brar 2012-06-28 10:59 ` Jassi Brar 2012-06-28 10:58 ` Jassi Brar 2012-06-28 11:10 ` Jassi Brar 2012-06-28 11:10 ` Tomi Valkeinen 2012-06-28 11:10 ` Tomi Valkeinen 2012-06-28 11:38 ` Tomi Valkeinen 2012-06-28 11:38 ` Tomi Valkeinen 2012-06-28 12:15 ` Andy Green 2012-06-28 12:15 ` Andy Green 2012-06-28 12:03 ` Andy Green 2012-06-28 12:03 ` Andy Green 2012-06-28 13:08 ` Tomi Valkeinen 2012-06-28 13:08 ` Tomi Valkeinen 2012-06-28 13:13 ` Jassi Brar 2012-06-28 13:25 ` Jassi Brar 2012-06-28 13:31 ` Tomi Valkeinen 2012-06-28 13:31 ` Tomi Valkeinen 2012-06-28 15:14 ` Jassi Brar 2012-06-28 15:26 ` Jassi Brar 2012-06-28 15:27 ` Tomi Valkeinen 2012-06-28 15:27 ` Tomi Valkeinen 2012-06-28 15:48 ` Jassi Brar 2012-06-28 15:51 ` Jassi Brar 2012-06-28 16:20 ` Jassi Brar 2012-06-28 16:32 ` Jassi Brar 2012-06-28 15:14 ` Tomi Valkeinen 2012-06-28 15:14 ` Tomi Valkeinen 2012-06-28 15:18 ` Jassi Brar 2012-06-28 15:30 ` Jassi Brar 2012-06-28 12:31 ` Jassi Brar 2012-06-28 12:43 ` Jassi Brar 2012-06-28 13:35 ` Tomi Valkeinen 2012-06-28 13:35 ` Tomi Valkeinen 2012-06-28 11:04 ` Tomi Valkeinen [this message] 2012-06-28 11:04 ` 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=1340881456.5037.47.camel@deskari \ --to=tomi.valkeinen@ti.com \ --cc=andy.green@linaro.org \ --cc=jaswinder.singh@linaro.org \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=mythripk@ti.com \ --cc=n-dechesne@ti.com \ --cc=patches@linaro.org \ /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: linkBe 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.