All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jassi Brar <jaswinder.singh@linaro.org>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
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:10:17 +0000	[thread overview]
Message-ID: <CAJe_ZhfehDquDcyefb7Z9odH+hfQTFiRAux_iyvAycs9Otovtw@mail.gmail.com> (raw)
In-Reply-To: <CAJe_Zhc_ye1f=hOVd=AJ7rmCQ_vwDtjQOKsufPYmV1o-58jyAA@mail.gmail.com>

On 28 June 2012 16:17, Jassi Brar <jaswinder.singh@linaro.org> wrote:
> On 28 June 2012 15:44, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
>
>>> >> --- 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.
>>
> 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_4_detect() returned true, should we
> proceed otherwise wait for HPQ irq.
>
> 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.
>
Sorry a correction. Reading detect() won't work. I suggest we keep HPD
IRQ enabled for the lifetime of the driver.

WARNING: multiple messages have this Message-ID (diff)
From: Jassi Brar <jaswinder.singh@linaro.org>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
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 16:28:17 +0530	[thread overview]
Message-ID: <CAJe_ZhfehDquDcyefb7Z9odH+hfQTFiRAux_iyvAycs9Otovtw@mail.gmail.com> (raw)
In-Reply-To: <CAJe_Zhc_ye1f=hOVd=AJ7rmCQ_vwDtjQOKsufPYmV1o-58jyAA@mail.gmail.com>

On 28 June 2012 16:17, Jassi Brar <jaswinder.singh@linaro.org> wrote:
> On 28 June 2012 15:44, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
>
>>> >> --- 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.
>>
> 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_4_detect() returned true, should we
> proceed otherwise wait for HPQ irq.
>
> 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.
>
Sorry a correction. Reading detect() won't work. I suggest we keep HPD
IRQ enabled for the lifetime of the driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-06-28 11:10 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 [this message]
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
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=CAJe_ZhfehDquDcyefb7Z9odH+hfQTFiRAux_iyvAycs9Otovtw@mail.gmail.com \
    --to=jaswinder.singh@linaro.org \
    --cc=andy.green@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 \
    --cc=tomi.valkeinen@ti.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.