From: Andy Green <andy.green@linaro.org>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>,
mythripk@ti.com, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, n-dechesne@ti.com,
patches@linaro.org
Subject: Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
Date: Thu, 28 Jun 2012 20:15:56 +0800 [thread overview]
Message-ID: <4FEC4AFC.6060400@linaro.org> (raw)
In-Reply-To: <1340883482.5037.56.camel@deskari>
On 06/28/12 19:38, the mail apparently from Tomi Valkeinen included:
> On Thu, 2012-06-28 at 14:10 +0300, Tomi Valkeinen wrote:
>> On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
>
>>> Sorry a correction. Reading detect() won't work. I suggest we keep HPD
>>> IRQ enabled for the lifetime of the driver.
>>
>> Ok, I see. But that's not acceptable. It would require us to keep the
>> TPD12S015 always powered and enabled. Even if you're not interested in
>> using HDMI at all.
>
> Btw, a bigger problem that I see is how we have to do read_edid() (and
> detect(), if I recall correctly): we enable the whole video pipeline and
> output. We should only enable enough of the HW to be able to read the
> EDID or read the HPD GPIO.
>
> I've noticed that this leads to sync losts quite easily, as we switch
> the hdmi output on and off quickly multiple times. I couldn't figure out
> why the sync losts happen though, and I did try quite many different
> combinations how to handle it.
SYNC LOST is one evil lurking in there, the other evil is EDID fetch
"operation stopped" error. We were unable to figure out what was
trampling on what there without the SoC HDMI PHY IP data which we don't
have.
Also at the moment I think we depower / repower the internal SoC and
external PHY chip more than we need. Each time we remove the HDMI link
power, after a short time where the big capacitor at the charge pump
output decays enough (a time dependent on exact details of load
presented by the TV or monitor...), hpd from the monitor goes low and
remains there until we power the charge pump again. In turn the new hpd
recognition provokes a new edid fetch. Something about that sequence
provokes the "operation stopped" on EDID fetch, with Jassi's patches we
manage to avoid it.
Removing that syndrome, and just not enabling and disabling stuff like
SoC HDMI PHY willy nilly can maybe be something else targeted by this
proposed 4-state power scheme.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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
next prev parent reply other threads:[~2012-06-28 12:16 UTC|newest]
Thread overview: 22+ 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-28 7:48 ` Tomi Valkeinen
2012-06-28 9:48 ` Jassi Brar
2012-06-28 10:14 ` Tomi Valkeinen
2012-06-28 10:47 ` Jassi Brar
2012-06-28 10:58 ` Jassi Brar
2012-06-28 11:10 ` Tomi Valkeinen
2012-06-28 11:38 ` Tomi Valkeinen
2012-06-28 12:15 ` Andy Green [this message]
2012-06-28 12:03 ` Andy Green
2012-06-28 13:08 ` Tomi Valkeinen
2012-06-28 13:13 ` Jassi Brar
2012-06-28 13:31 ` Tomi Valkeinen
2012-06-28 15:14 ` Jassi Brar
2012-06-28 15:27 ` Tomi Valkeinen
2012-06-28 15:48 ` Jassi Brar
2012-06-28 16:20 ` Jassi Brar
2012-06-28 15:14 ` Tomi Valkeinen
2012-06-28 15:18 ` Jassi Brar
2012-06-28 12:31 ` Jassi Brar
2012-06-28 13:35 ` 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=4FEC4AFC.6060400@linaro.org \
--to=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 \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox