From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <a0393947@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data
Date: Tue, 08 May 2012 07:01:53 +0000 [thread overview]
Message-ID: <1336460513.1896.15.camel@lappyti> (raw)
In-Reply-To: <4FA8A00B.4040600@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3059 bytes --]
On Tue, 2012-05-08 at 09:54 +0530, Archit Taneja wrote:
> Hi,
>
> On Monday 07 May 2012 08:17 PM, Tomi Valkeinen wrote:
> > Hi,
> > dss_<ovl|mgr>_<enable|disable> functions handle GO, so you could have a
> > look at them. However, setting the timings is a bit different, so I'm
> > not sure how it should be done.
> >
> > I think we have a few different options:
> >
> > - Separate omapdss internal function (in apply.c) that can be used to
> > set GO after set_timings
> >
> > - set GO in dss_mgr_set_timings(), but don't block
> >
> > - set GO in dss_mgr_set_timings(), and block until the changes are in HW
> > (this is more or less what the dss_<ovl|mgr>_<enable|disable> functions
> > do).
> >
> > The first one would be good if the interface drivers would need to set
> > multiple configurations, and we don't want to block after each set call.
> > But we don't have anything like that, at least currently.
> >
> > The second one avoids blocking, but could perhaps cause problems because
> > the timings are not actually used yet when the function returns.
> >
> > I don't see any problem with the last option, so I'm slightly leaning
> > towards it.
>
> The 3rd option looks good to me too, but I'm wondering if we would need
> to do the same things with all manager parameters which are in shadow
> registers. Like in dpi.c, in dpi_set_mode() we set the DISPC_POL_FREQ
> and DISPC_DIVISORo registers, writing GO for each parameter would be in
> efficient, it's good that it doesn't happen much often. Maybe we could
> group the rest of these parameters.
Hmm, that's true.
We could make shortcuts with settings that are only changed while the
display is off. For example, currently DISPC_POL_FREQ cannot be changed
dynamically, so it could only be set when before enabling the output.
However, it seems we currently do call dispc_mgr_set_pol_freq() in
dpi_set_mode(), which could be called when the output is enabled. But
even then we always set the same values, so it doesn't matter.
For DISPC_DIVISORo, I guess we could make a shortcut with that also.
While it is a shadow register, when we are changing the dss clocks we
also set non-shadowed registers. So I think the best way to change clock
frequencies is to turn off the output temporarily.
Perhaps all the shadow registers currently being set directly from
interface drivers are such settings? The code should still be changed so
that we only touch the registers when enabling the output.
But, of course, a better design and also more future proof would be to
handle all shadow registers properly, even if we currently only set them
while the output is off. That may be left for future, though.
In any case, I think we should mark clearly the places where we set
shadow registers directly, without using the apply.c. Perhaps we should
even mark all the dispc functions that set shadow registers, like
dispc_mgr_set_pol_freq_sh(). But let's not do that now either, as we're
quite close to merge window.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-05-08 7:01 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-16 7:35 [PATCH 0/6] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers Archit Taneja
2012-04-16 7:35 ` [PATCH 1/6] OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size Archit Taneja
2012-04-16 7:35 ` [PATCH 2/6] OMAPDSS: DISPC: Use a common function to set manager timings Archit Taneja
2012-04-16 7:35 ` [PATCH 3/6] OMAPDSS: DISPC: Clean up manager timing/size functions Archit Taneja
2012-04-16 7:35 ` [PATCH 4/6] OMAPDSS: MANAGER: Make DISPC timings a manager_info parameter Archit Taneja
2012-04-18 14:58 ` Tomi Valkeinen
2012-04-19 6:25 ` Archit Taneja
2012-04-19 6:37 ` Tomi Valkeinen
2012-04-19 10:20 ` Archit Taneja
2012-04-19 11:37 ` Tomi Valkeinen
2012-04-16 7:35 ` [PATCH 5/6] OMAPDSS: MANAGER: Check validity of manager timings Archit Taneja
2012-04-16 7:35 ` [PATCH 6/6] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks Archit Taneja
2012-04-19 11:48 ` [PATCH 0/6] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers Tomi Valkeinen
2012-04-19 12:10 ` Archit Taneja
2012-04-19 12:00 ` Tomi Valkeinen
2012-05-03 7:19 ` [PATCH v2 0/4] " Archit Taneja
2012-05-03 7:19 ` [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data Archit Taneja
2012-05-07 14:47 ` Tomi Valkeinen
2012-05-08 4:36 ` Archit Taneja
2012-05-08 7:01 ` Tomi Valkeinen [this message]
2012-05-03 7:19 ` [PATCH v2 2/4] OMAPDSS: Apply manager timings instead of direct DISPC writes Archit Taneja
2012-05-03 7:19 ` [PATCH v2 3/4] OMAPDSS: MANAGER: Create a function to check manager timings Archit Taneja
2012-05-03 7:19 ` [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks Archit Taneja
2012-05-07 15:03 ` Tomi Valkeinen
2012-05-08 5:15 ` Archit Taneja
2012-05-08 7:16 ` Tomi Valkeinen
2012-05-08 7:50 ` Archit Taneja
2012-05-08 8:52 ` Tomi Valkeinen
2012-05-08 9:19 ` Archit Taneja
2012-05-08 10:10 ` [PATCH v3 0/5] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers Archit Taneja
2012-05-08 10:10 ` [PATCH v3 1/5] OMAPDSS: APPLY: Add manager timings as extra_info in private data Archit Taneja
2012-05-08 10:10 ` [PATCH v3 2/5] OMAPDSS: Apply manager timings instead of direct DISPC writes Archit Taneja
2012-05-08 10:59 ` Tomi Valkeinen
2012-05-08 10:10 ` [PATCH v3 3/5] OMAPDSS: MANAGER: Create a function to check manager timings Archit Taneja
2012-05-08 10:10 ` [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks Archit Taneja
2012-05-08 10:50 ` Tomi Valkeinen
2012-05-08 11:34 ` Archit Taneja
2012-05-08 11:55 ` Tomi Valkeinen
2012-05-08 12:47 ` Archit Taneja
2012-05-09 9:56 ` Archit Taneja
2012-05-09 10:15 ` Tomi Valkeinen
2012-05-08 10:10 ` [PATCH v3 5/5] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled Archit Taneja
2012-05-09 10:22 ` [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers Archit Taneja
2012-05-09 10:22 ` [PATCH v4 1/9] OMAPDSS: APPLY: Add manager timings as extra_info in private data Archit Taneja
2012-05-09 10:22 ` [PATCH v4 2/9] OMAPDSS: Apply manager timings instead of direct DISPC writes Archit Taneja
2012-05-09 10:22 ` [PATCH v4 3/9] OMAPDSS: MANAGER: Create a function to check manager timings Archit Taneja
2012-05-09 10:22 ` [PATCH v4 4/9] OMAPDSS: APPLY: Don't check manager settings if it is disabled Archit Taneja
2012-05-09 10:22 ` [PATCH v4 5/9] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks Archit Taneja
2012-05-09 10:22 ` [PATCH v4 6/9] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled Archit Taneja
2012-05-09 10:22 ` [PATCH v4 7/9] OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer Archit Taneja
2012-05-09 10:22 ` [PATCH v4 8/9] OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() Archit Taneja
2012-05-09 10:22 ` [PATCH v4 9/9] OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() Archit Taneja
2012-05-09 11:13 ` [PATCH v4 0/9] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers Tomi Valkeinen
2012-05-09 11:36 ` Archit Taneja
2012-05-09 11:51 ` 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=1336460513.1896.15.camel@lappyti \
--to=tomi.valkeinen@ti.com \
--cc=a0393947@ti.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.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).