From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Ricardo Neri <ricardo.neri@ti.com>
Cc: archit@ti.com, s-guiriec@ti.com, linux-omap@vger.kernel.org
Subject: Re: [PATCH 0/2] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection
Date: Mon, 30 Jul 2012 14:11:56 +0300 [thread overview]
Message-ID: <1343646716.8019.22.camel@lappyti> (raw)
In-Reply-To: <1343434897-8444-1-git-send-email-ricardo.neri@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
On Fri, 2012-07-27 at 19:21 -0500, Ricardo Neri wrote:
> Hello,
>
> DSS code wrongly assumes that VENC is always available as source for the external
> sync signal for the display controller DIGIT channel. One cannot blindly
> rely only on the value of DSS_CONTROL register as certain processors may not
> have VENC (e.g., OMAP5).
>
> These patches add logic to correctly set/get the sync signal based on the
> available displays in the DIGIT channel.
>
> For the HDMI driver, handle the error in the selection of the source.
Is there an actual problem seen that this resolves? If so, It'd be nice
to have a brief description of the problem.
Does the bit 15 in DSS_CONTROL still exist on OMAP5? What does it return
on OMAP5?
I think it's clear that dss_get_hdmi_venc_clk_source() needs to return a
correct value so that DSS operates correctly. But I'm not sure we need
the extra code in dss_select_hdmi_venc_clk_source().
dss_select_hdmi_venc_clk_source() should be called by venc or hdmi, and
there should be any possibility of using it in the wrong way. For extra
sanity checking there could be a BUG_ON() check in the
dss_select_hdmi_venc_clk_source() to point out if there's a bad bug in
venc or hdmi.
I'd like to keep the lowest level dss-internal functions as simple as
possible, and written in the manner that they presume they are called
correctly. Otherwise we'll end up with lots of new code, checking for
errors that can never happen in practice.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-07-30 11:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-28 0:21 [PATCH 0/2] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection Ricardo Neri
2012-07-28 0:21 ` [PATCH 1/2] OMAPDSS: DISPC: Improve logic of selection of external sync signal Ricardo Neri
2012-07-28 0:21 ` [PATCH 2/2] OMAPDSS:HDMI: Improve error handling at power on Ricardo Neri
2012-07-30 11:11 ` Tomi Valkeinen [this message]
2012-07-30 11:48 ` [PATCH 0/2] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection Archit Taneja
2012-07-30 19:21 ` Ricardo Neri
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=1343646716.8019.22.camel@lappyti \
--to=tomi.valkeinen@ti.com \
--cc=archit@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=ricardo.neri@ti.com \
--cc=s-guiriec@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