All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: mythripk@ti.com
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAPDSS: HDMI: wait for RXDET before putting phy in TX_ON
Date: Thu, 01 Mar 2012 13:31:02 +0200	[thread overview]
Message-ID: <1330601462.2586.32.camel@deskari> (raw)
In-Reply-To: <1330589664-15755-1-git-send-email-mythripk@ti.com>

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

Hi,

On Thu, 2012-03-01 at 13:44 +0530, mythripk@ti.com wrote:
> From: Mythri P K <mythripk@ti.com>
> 
> Currently TX_PHY is put to TX_ON(transmission state) on receiving HPD.
> It just ensures that the TV is connected but does not guarantee
> that TMDS data lines and clock lines are up and ready for transmission.
> Which although is very rare scenario has a potential to  damage the HDMI
> port.(A use case where TV is connected to board but it is in different
> channel would still trigger a HPD but TMDS lines will be down).

When/how does the damaging happen? When the HDMI cable is disconnected
in the case above? Or does the damage just happen by having the cable
connected, but the TV on different channel?

> Thus this patch adds a rxdet check on getting a HPD which ensures that
> TMDS lines are UP before changing the PHY state from LDO_ON to TX_ON.
> 
> Signed-off-by: Mythri P K <mythripk@ti.com>
> ---
>  drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   37 +++++++++++++++++++++++++++-
>  drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |    2 +
>  2 files changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> index bb784d2..bc55528 100644
> --- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> +++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
> @@ -224,6 +224,30 @@ void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data *ip_data)
>  	hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
>  }
>  
> +int hdmi_ti_4xxx_rxdet(struct hdmi_ip_data *ip_data)
> +{
> +	int loop = 0, tmds_data0, tmds_data1, tmds_data2, tmds_clk;
> +
> +	hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_WP_DEBUG_CFG, 4);
> +
> +	do {
> +		tmds_data0 = hdmi_read_reg(hdmi_wp_base(ip_data),
> +					HDMI_WP_WP_DEBUG_DATA);
> +		tmds_data1 = hdmi_read_reg(hdmi_wp_base(ip_data),
> +					HDMI_WP_WP_DEBUG_DATA);
> +		tmds_data2 = hdmi_read_reg(hdmi_wp_base(ip_data),
> +					HDMI_WP_WP_DEBUG_DATA);
> +		tmds_clk = hdmi_read_reg(hdmi_wp_base(ip_data),
> +					HDMI_WP_WP_DEBUG_DATA);
> +		udelay(15);

This code doesn't make any sense, or the HDMI TRM is wrong. You read the
same register, HDMI_WP_WP_DEBUG_DATA, four times, assigning the value to
data0-2/clk. The TRM I have doesn't talk about anything like that. What
is the code supposed to do?

The register HDMI_TXPHY_PAD_CONFIG_CONTROL also has bits for RXDET_LINE.
Is that something different?

> +	} while ((tmds_data0 != tmds_data1 || tmds_data1 != tmds_data2
> +			|| tmds_data1 != tmds_clk) && (loop < 500));

This is a rather confusing way to do the loop. Why not just use for-loop
with the timeout, and check the tmds variables inside the loop. Much
easier to read.

In the worst case the above causes a 7.5ms busy loop in an interrupt
handler. That's not very good thing. Why is there a need for the loop?

> +	hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_WP_DEBUG_CFG, 0);
> +
> +	return ((loop == 500) ? -1 : (tmds_data0 & 1)) ;

This is also confusing. And you should return a proper error value, not
-1. Perhaps:

if (loop == 500)
	return -ETIMEDOUT;

return tmds_data0 & 1;

> +}
> +
>  static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
>  {
>  	unsigned long flags;
> @@ -241,10 +265,19 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
>  		return 0;
>  	}
>  
> -	if (hpd)
> +	if (hpd) {
> +		/* before putting the phy in TX_ON,ensure that TMDS lanes
> +		 * are pulled up .
> +		 */
> +		r = hdmi_ti_4xxx_rxdet(ip_data);
> +		if (r <= 0) {
> +			DSSERR("rxdet not set\n");
> +			return r;
> +		}

Does this mean that if the user connects a TV which is in a different
channel than HDMI, the only way for the user to get an image is to
disconnect the cable and connect it again?

 Tomi


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

  reply	other threads:[~2012-03-01 11:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-01  8:14 [PATCH] OMAPDSS: HDMI: wait for RXDET before putting phy in TX_ON mythripk
2012-03-01 11:31 ` Tomi Valkeinen [this message]
2012-03-02  8:05   ` K, Mythri P
2012-03-02 10:52     ` Tomi Valkeinen
2012-03-02 11:25       ` K, Mythri P
2012-03-02 11:38         ` 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=1330601462.2586.32.camel@deskari \
    --to=tomi.valkeinen@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=mythripk@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.