linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Andy Green <andy.green@linaro.org>
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 13:08:23 +0000	[thread overview]
Message-ID: <1340888903.5037.76.camel@deskari> (raw)
In-Reply-To: <4FEC47FA.1040801@linaro.org>

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

On Thu, 2012-06-28 at 20:03 +0800, Andy Green wrote:
> On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included:

> > For this to work like you want we need a bigger restructuring of HDMI
> > and partly omapdss also. Currently we have just one big "enabled" or
> > "disabled" state. We need multiple states. Probably something like:
> >
> > - disabled, everything totally off
> > - low power, hotplug detection enabled
> > - powered on, but no video
> > - video enabled
> >
> > Been long in my mind, but I'm not very familiar with HDMI so I could get
> > my simple prototypes to work when I tried something like this once.
> 
> That doesn't sound too hard since the difference between the first three 
> states at the HDMI chip is just whether the two gpio controlling it are 
> 00, 10 or 11.

I don't think it's that simple. We should be able to do EDID read on one
of the states, perhaps second or third. For that we need parts of the
HDMI IP to be enabled.

Also, the third state should be something where the IP is fully
functional. For DSI this would mean that you can communicate over DSI
bus etc. So I guess EDID read should be possible at this level.

> If Jassi's alright with it we might have a go at implementing this, but 
> can you define a bit more about how we logically tell DSS that we want 
> to, eg, disable HDMI totally?

Disabling HDMI is easy, it's already done by the disable call. And the
same for the video enabled mode. The middle ones are the ones that need
implementation.

And for HDMI, there's currently no way to enable it partially. This is
what I tried with my quick hack, but I couldn't figure out what parts
need to be enabled (but I didn't spend much time on it).

This is something that should be implemented for all outputs, obviously,
but we could approach it bit by bit. For example, implement it first for
HDMI, and all other outputs just consider anything else than "disabled"
as full enable.

 Tomi


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

  reply	other threads:[~2012-06-28 13:08 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
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 [this message]
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=1340888903.5037.76.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).