From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <archit@ti.com>
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 2/3] OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions
Date: Fri, 17 Aug 2012 12:35:06 +0000 [thread overview]
Message-ID: <1345206906.3158.113.camel@deskari> (raw)
In-Reply-To: <1345200551-28712-3-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]
On Fri, 2012-08-17 at 16:19 +0530, Archit Taneja wrote:
> The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there
> is an enabled display connected to the manager before trying to see the state of
> the GO bit.
>
> The checks related to the display can be replaced by checking the state of the
> manager, i.e, whether the manager is enabled or not. This makes more sense than
> checking with the connected display as the GO bit behaviour is more connected
> with the manager state rather than the display state. A GO bit can only be set
> if the manager is enabled. If a manager isn't enabled, we can safely assume that
> the GO bit is not set.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/apply.c | 32 +++++++++++++++++++++-----------
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index 52a5940..74f1a58 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -424,17 +424,23 @@ static void wait_pending_extra_info_updates(void)
> int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
> {
> unsigned long timeout = msecs_to_jiffies(500);
> - struct mgr_priv_data *mp;
> + struct mgr_priv_data *mp = get_mgr_priv(mgr);
> u32 irq;
> + unsigned long flags;
> int r;
> int i;
> - struct omap_dss_device *dssdev = mgr->device;
>
> - if (!dssdev || dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
> + if (mgr_manual_update(mgr))
This needs to be inside the spinlock also.
> return 0;
>
> - if (mgr_manual_update(mgr))
> + spin_lock_irqsave(&data_lock, flags);
> +
> + if (!mp->enabled) {
> + spin_unlock_irqrestore(&data_lock, flags);
> return 0;
> + }
> +
> + spin_unlock_irqrestore(&data_lock, flags);
>
> r = dispc_runtime_get();
> if (r)
> @@ -442,10 +448,8 @@ int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
>
> irq = dispc_mgr_get_vsync_irq(mgr->id);
>
> - mp = get_mgr_priv(mgr);
> i = 0;
> while (1) {
> - unsigned long flags;
> bool shadow_dirty, dirty;
>
> spin_lock_irqsave(&data_lock, flags);
> @@ -489,21 +493,28 @@ int dss_mgr_wait_for_go_ovl(struct omap_overlay *ovl)
> {
> unsigned long timeout = msecs_to_jiffies(500);
> struct ovl_priv_data *op;
> - struct omap_dss_device *dssdev;
> + struct mgr_priv_data *mp;
> u32 irq;
> + unsigned long flags;
> int r;
> int i;
>
> if (!ovl->manager)
> return 0;
And this should be inside spinlock (yes, you didn't change that, but now
that you're changing these... =)
> - dssdev = ovl->manager->device;
> + mp = get_mgr_priv(ovl->manager);
>
> - if (!dssdev || dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
> + if (ovl_manual_update(ovl))
Inside spinlock here too.
Actually, shouldn't the whole wait_for functions be locked with the
apply mutex? Otherwise the output can be disabled/changed while waiting.
On the other hand, that could be quite a long lock, and I don't see
anything in the code that could really break if the output is disabled
or similar. Perhaps it's fine to just hit the timeout in case something
has been changed. If we add a mutex, we risk breaking something that
currently works =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-08-17 12:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <343817088-29645-1-git-send-email-archit@ti.com>
2012-08-16 7:48 ` [PATCH 0/6] OMAPDSS: Pass output specific parameters from panel driver to output Archit Taneja
2012-08-16 7:48 ` [PATCH 1/6] OMAPDSS: DSI: Maintain copy of operation mode in driver data Archit Taneja
2012-08-16 11:19 ` Tomi Valkeinen
2012-08-16 12:23 ` Archit Taneja
2012-08-16 12:23 ` Tomi Valkeinen
2012-08-16 7:48 ` [PATCH 2/6] OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings Archit Taneja
2012-08-16 7:48 ` [PATCH 3/6] OMAPDSS: DSI: Maintain copy of video mode timings in driver data Archit Taneja
2012-08-16 11:31 ` Tomi Valkeinen
2012-08-16 11:58 ` Archit Taneja
2012-08-16 12:14 ` Tomi Valkeinen
2012-08-16 7:48 ` [PATCH 4/6] OMAPDSS: RFBI: Maitain copy of rfbi " Archit Taneja
2012-08-16 7:48 ` [PATCH 5/6] OMAPDSS: VENC: Maintain copy of venc type " Archit Taneja
2012-08-16 7:48 ` [PATCH 6/6] OMAPDSS: VENC: Maintian copy of video output polarity in private data Archit Taneja
2012-08-16 11:38 ` Tomi Valkeinen
2012-08-16 12:39 ` Archit Taneja
2012-08-16 13:09 ` Tomi Valkeinen
2012-08-17 10:51 ` [PATCH 0/3] OMAPDSS: Miscellaneous cleanup patches Archit Taneja
2012-08-17 10:51 ` [PATCH 1/3] OMAPDSS: DSI: Pass dsi platform device wherever possible Archit Taneja
2012-08-17 10:51 ` [PATCH 2/3] OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions Archit Taneja
2012-08-17 12:35 ` Tomi Valkeinen [this message]
2012-08-17 10:51 ` [PATCH 3/3] OMAPDSS: Remove unnecessary acb/acbi pin fields from omap_dss_device Archit Taneja
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=1345206906.3158.113.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=archit@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).