linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 10:14:21 +0000	[thread overview]
Message-ID: <1340878461.5037.30.camel@deskari> (raw)
In-Reply-To: <CAJe_ZhcWSYhRWSW0v9OqsHRXASsQ8i2P8F8OS+jXkyadoRM9iA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3356 bytes --]

On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
> On 28 June 2012 13:18, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Wed, 2012-06-27 at 19:35 +0530, jaswinder.singh@linaro.org wrote:
> >> From: Jassi Brar <jaswinder.singh@linaro.org>
> >>
> >> We can easily keep track of latest EDID from the display and hence avoid
> >> expensive EDID re-reads over I2C.
> >> This could also help some cheapo displays that provide EDID reliably only
> >> immediately after asserting HPD and not later.
> >> Even with good displays, there is something in OMAPDSS that apparantly
> >> messes up DDC occasionally while EDID is being read, giving the
> >>   "operation stopped when reading edid" error.
> >
> > Btw, this is in nitpicking area, but what editor do you use? I find it
> > difficult to read text that is not formatted properly =). At least vim
> > formats text nicely with its formating commands.
> >
> Indeed a nitpick :)
> I use vim and, iirc, checkpatch.pl gave 0 warning. Perhaps my poor
> cmoposition. Please do tell how I could I make it more appealing to
> you ?

Like:

---

We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C. This could also help some cheapo displays
that provide EDID reliably only immediately after asserting HPD and not later.

Even with good displays, there is something in OMAPDSS that apparantly messes
up DDC occasionally while EDID is being read, giving the "operation stopped
when reading edid" error.

---

So basically two things: properly formatted paragraphs and an empty line
between paragraphs. With "properly formatted" I mean that that the text
goes from the beginning of the line to the end, so that the text fills
the whole line. This can be done easily in vim with first painting the
paragraph (or multiple paragraphs), and then then press g and w.

I think those simple rules make the text much easier to read.

> >> --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> >> +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> >> @@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
> >>
> >>       hpd = gpio_get_value(ip_data->hpd_gpio);
> >>
> >> -     if (hpd)
> >> +     if (hpd) {
> >>               r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
> >> -     else
> >> +     } else {
> >> +             /* Invalidate EDID Cache */
> >> +             ip_data->edid_len = 0;
> >>               r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
> >> +     }
> >
> > There's a problem with this patch, which leaves a wrong EDID in the
> > cache: if you first have the cable connected and hdmi is enabled, you
> > then turn off the HDMI display device via sysfs, we do not go to
> > hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
> > the plug-in event, and thus EDID cache is never invalidated.
> >
> If the hdmi cable is not replugged during that period, I don't see why
> would you want the EDID invalidated ?

I wasn't very clear with my comment.

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.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-06-28 10:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 14:17 [PATCH 3/3] OMAPDSS: HDMI: Cache EDID jaswinder.singh
2012-06-28  7:48 ` Tomi Valkeinen
2012-06-28  9:51   ` Jassi Brar
2012-06-28 10:14     ` Tomi Valkeinen [this message]
2012-06-28 10:59       ` Jassi Brar
2012-06-28 11:04         ` Tomi Valkeinen
2012-06-28 11:10         ` Jassi Brar
2012-06-28 11:10           ` Tomi Valkeinen
2012-06-28 11:38             ` Tomi Valkeinen
2012-06-28 12:15               ` Andy Green
2012-06-28 12:03             ` Andy Green
2012-06-28 13:08               ` Tomi Valkeinen
2012-06-28 13:25               ` Jassi Brar
2012-06-28 13:31                 ` Tomi Valkeinen
2012-06-28 15:26                   ` Jassi Brar
2012-06-28 15:27                     ` Tomi Valkeinen
2012-06-28 15:51                       ` Jassi Brar
2012-06-28 16:32                         ` Jassi Brar
2012-06-28 15:14                 ` Tomi Valkeinen
2012-06-28 15:30                   ` Jassi Brar
2012-06-28 12:43             ` Jassi Brar
2012-06-28 13:35           ` 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=1340878461.5037.30.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: 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;
as well as URLs for NNTP newsgroup(s).