linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: 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
Subject: Re: [PATCH] OMAPDSS: HDMI: Cache EDID
Date: Mon, 25 Jun 2012 06:35:54 +0000	[thread overview]
Message-ID: <1340606154.12683.34.camel@lappyti> (raw)
In-Reply-To: <1340438806-25622-1-git-send-email-jaswinder.singh@linaro.org>

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

On Sat, 2012-06-23 at 13:36 +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.
> 
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> ---
>  drivers/video/omap2/dss/hdmi.c            |    1 +
>  drivers/video/omap2/dss/ti_hdmi.h         |    2 ++
>  drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   23 ++++++++++++++++++++---
>  3 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index 900e621..0a8c825 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -764,6 +764,7 @@ static int __init omapdss_hdmihw_probe(struct platform_device *pdev)
>  	hdmi.ip_data.core_av_offset = HDMI_CORE_AV;
>  	hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
>  	hdmi.ip_data.phy_offset = HDMI_PHY;
> +	hdmi.ip_data.edid_len = 0; /* Invalidate EDID Cache */
>  	mutex_init(&hdmi.ip_data.lock);

Your HDMI patches seem to depend on each other. Please post them as a
proper patch series, instead of each one separately.

>  	hdmi_panel_init();
> diff --git a/drivers/video/omap2/dss/ti_hdmi.h b/drivers/video/omap2/dss/ti_hdmi.h
> index cc292b8..4735860 100644
> --- a/drivers/video/omap2/dss/ti_hdmi.h
> +++ b/drivers/video/omap2/dss/ti_hdmi.h
> @@ -178,6 +178,8 @@ struct hdmi_ip_data {
>  	/* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
>  	int hpd_gpio;
>  	struct mutex lock;
> +	u8 edid_cached[256];
> +	unsigned edid_len;
>  };
>  int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
>  void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
> diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> index 04acca9..2633ade 100644
> --- 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);
> +	}
>  
>  	if (r) {
>  		DSSERR("Failed to %s PHY TX power\n",
> @@ -454,6 +457,11 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
>  {
>  	int r, l;
>  
> +	if (ip_data->edid_len) {
> +		memcpy(edid, ip_data->edid_cached, ip_data->edid_len);
> +		return ip_data->edid_len;
> +	}
> +
>  	if (len < 128)
>  		return -EINVAL;
>  
> @@ -474,12 +482,21 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
>  		l += 128;
>  	}
>  
> +	ip_data->edid_len = l;
> +	memcpy(ip_data->edid_cached, edid, l);
> +
>  	return l;
>  }
>  
>  bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
>  {
> -	return gpio_get_value(ip_data->hpd_gpio);
> +	if (gpio_get_value(ip_data->hpd_gpio))
> +		return true;
> +
> +	/* Invalidate EDID Cache */
> +	ip_data->edid_len = 0;
> +
> +	return false;

Why is this needed? The HPD interrupt should handle this already. And if
the HPD interrupt doesn't work for some reason, this won't work either,
as the user can plug and unplug his HDMI monitors a thousand times
between two detect calls.

 Tomi


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

  reply	other threads:[~2012-06-25  6:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-23  8:18 [PATCH] OMAPDSS: HDMI: Cache EDID jaswinder.singh
2012-06-25  6:35 ` Tomi Valkeinen [this message]
2012-06-25  8:08   ` Jassi Brar
2012-06-25  8:11     ` Tomi Valkeinen
2012-06-25  9:16       ` Jassi Brar

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=1340606154.12683.34.camel@lappyti \
    --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 \
    /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).