From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] OMAPDSS: APPLY: make ovl_enable/disable synchronous
Date: Wed, 29 Feb 2012 10:13:04 +0000 [thread overview]
Message-ID: <4F4DFA30.2040503@gmx.de> (raw)
In-Reply-To: <1330505302-8258-3-git-send-email-tomi.valkeinen@ti.com>
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?
Best regards,
Florian Tobias Schandinat
>
> And, while not the main purpose of this patch, this will also remove the
> compile warning:
>
> drivers/video/omap2/dss/apply.c:350: warning:
> 'wait_pending_extra_info_updates' defined but not used
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/apply.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index 052dc87..87b3e25 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -1276,6 +1276,9 @@ int dss_ovl_enable(struct omap_overlay *ovl)
>
> spin_unlock_irqrestore(&data_lock, flags);
>
> + /* wait for overlay to be enabled */
> + wait_pending_extra_info_updates();
> +
> mutex_unlock(&apply_lock);
>
> return 0;
> @@ -1313,6 +1316,9 @@ int dss_ovl_disable(struct omap_overlay *ovl)
>
> spin_unlock_irqrestore(&data_lock, flags);
>
> + /* wait for the overlay to be disabled */
> + wait_pending_extra_info_updates();
> +
> mutex_unlock(&apply_lock);
>
> return 0;
next prev parent reply other threads:[~2012-02-29 10:13 UTC|newest]
Thread overview: 18+ 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 ` Tomi Valkeinen
2012-02-29 8:48 ` [PATCH 1/2] OMAPDSS: panel-dvi: Add Kconfig dependency on I2C Tomi Valkeinen
2012-02-29 8:48 ` Tomi Valkeinen
2012-02-29 10:03 ` Florian Tobias Schandinat
2012-02-29 10:21 ` Tomi Valkeinen
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 8:48 ` Tomi Valkeinen
2012-02-29 10:13 ` Florian Tobias Schandinat [this message]
2012-02-29 10:30 ` Tomi Valkeinen
2012-02-29 10:30 ` Tomi Valkeinen
2012-02-29 10:48 ` Florian Tobias Schandinat
2012-02-29 14:52 ` Rob Clark
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=4F4DFA30.2040503@gmx.de \
--to=florianschandinat@gmx.de \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tomi.valkeinen@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 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.