From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
Rob Clark <rob@ti.com>
Subject: Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
Date: Wed, 29 Feb 2012 10:30:38 +0000 [thread overview]
Message-ID: <1330511438.1934.95.camel@deskari> (raw)
In-Reply-To: <4F4DFA30.2040503@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
On Wed, 2012-02-29 at 10:13 +0000, Florian Tobias Schandinat wrote:
> On 02/29/2012 08:48 AM, Tomi Valkeinen wrote:
> > ovl->enable/disable are meant to be synchronous so that they can handle
> > the configuration of fifo sizes. The current kernel doesn't configure
> > fifo sizes yet, and so the code doesn't need to block to function (from
> > omapdss driver's perspective).
> >
> > However, for the users of omapdss a non-blocking ovl->disable is
> > confusing, because they don't know when the memory area is not used
> > any more.
> >
> > Furthermore, when the fifo size configuration is added in the next merge
> > window, the change from non-blocking to blocking could cause side
> > effects to the users of omapdss. So by making the functions block
> > already will keep them behaving in the same manner.
>
> Is there any difference to doing it now?
> I agree that this should be fixed but if we can't avoid breaking users I'd
> prefer to break them in a merge window not in late rc stage. Or did we introduce
> these functions just in the last merge window?
Yes, these were introduced in the merge window. And I explicitly said
the functions are blocking so that they can perform their job. And just
to clarify, the functions already use a mutex, so in that sense they are
blocking. They just don't currently wait until the HW has finished with
the overlay.
The problem was raised by Rob Clark, who's writing the omapdrm driver,
as he doesn't have a way to ensure that the overlay has been truly
disabled and the memory is is no longer in use.
(I forgot to cc him for the patch, adding him now).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-02-29 10:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 8:48 [PATCH 0/2] OMAPDSS: small fixes for 3.3 rc Tomi Valkeinen
2012-02-29 8:48 ` [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C Tomi Valkeinen
2012-02-29 10:03 ` Florian Tobias Schandinat
2012-02-29 10:21 ` Tomi Valkeinen
2012-02-29 11:10 ` Florian Tobias Schandinat
2012-02-29 8:48 ` [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous Tomi Valkeinen
2012-02-29 10:13 ` Florian Tobias Schandinat
2012-02-29 10:30 ` Tomi Valkeinen [this message]
2012-02-29 10:48 ` Florian Tobias Schandinat
2012-02-29 14:52 ` Rob Clark
2012-02-29 9:56 ` [PATCH 0/2] OMAPDSS: small fixes for 3.3 rc Florian Tobias Schandinat
2012-03-01 5:38 ` Florian Tobias Schandinat
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=1330511438.1934.95.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=FlorianSchandinat@gmx.de \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=rob@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;
as well as URLs for NNTP newsgroup(s).