From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Andy Green <andy.green@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 15:14:18 +0000 [thread overview]
Message-ID: <1340896458.5037.131.camel@deskari> (raw)
In-Reply-To: <CAJe_Zhdkhu4TciiwGJB2Kz8oZp2RQNZfESSr5Cfv0R1MNn=r9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
> A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during
> probe and disable during remove.
> HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
> HDMI_PHY on/off.
> The user selecting "Autodetect and Configure" option would then equate
> to "(un)loading" of the HDMI driver.
> Not to mean a trivial job.
One more thing I realized while thinking about this:
While it could be argued that the power draw from having the tpd12s015
always enabled is very small, I think it could matter. If you consider a
phone with HDMI output, it's likely that the phone is locked 99% of the
time. When the phone is locked, there's no need to keep the HDMI HPD
enabled. So this could add to a considerable amount of power wasted, if
the HPD was always enabled.
At least I can't figure out a reason why one would want the HPD to work
when the phone is locked. Also, I have never used the HDMI output on my
phone, so I'd be glad if it was totally powered off if it gave me more
standby hours =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Andy Green <andy.green@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 18:14:18 +0300 [thread overview]
Message-ID: <1340896458.5037.131.camel@deskari> (raw)
In-Reply-To: <CAJe_Zhdkhu4TciiwGJB2Kz8oZp2RQNZfESSr5Cfv0R1MNn=r9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
> A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during
> probe and disable during remove.
> HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
> HDMI_PHY on/off.
> The user selecting "Autodetect and Configure" option would then equate
> to "(un)loading" of the HDMI driver.
> Not to mean a trivial job.
One more thing I realized while thinking about this:
While it could be argued that the power draw from having the tpd12s015
always enabled is very small, I think it could matter. If you consider a
phone with HDMI output, it's likely that the phone is locked 99% of the
time. When the phone is locked, there's no need to keep the HDMI HPD
enabled. So this could add to a considerable amount of power wasted, if
the HPD was always enabled.
At least I can't figure out a reason why one would want the HPD to work
when the phone is locked. Also, I have never used the HDMI output on my
phone, so I'd be glad if it was totally powered off if it gave me more
standby hours =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-28 15:14 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
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 [this message]
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=1340896458.5037.131.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 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.