From: anarsoul@gmail.com (Vasily Khoruzhick)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] s3c24xx-adc: resume convertions interrupted by going to suspend
Date: Fri, 23 Oct 2009 08:57:26 +0300 [thread overview]
Message-ID: <200910230857.35780.anarsoul@gmail.com> (raw)
In-Reply-To: <20091022190524.GB8096@trinity.fluff.org>
? ????????? ?? 22 ??????? 2009 22:05:24 ????? Ben Dooks ???????:
> > - client->select_cb(client, 1);
> > + if (!client->selected) {
> > + client->selected = 1;
> > + client->select_cb(client, 1);
> > + }
>
> You seem to have added something other than just a bugfix to this patch,
> you've changed the behaviour of the select callback. Is this really
> necessary for the function of the fix or something that dropped in by
> accident?
No, select callback behaviour is not changed, this check is necessary to avoid
calling select callback when client was already selected (for example, after
resuming from suspend)
> > writel(adc->prescale | S3C2410_ADCCON_PRSCEN,
> > adc->regs + S3C2410_ADCCON);
> > + /* Schedule task if there are clients pending. */
> > + if (!list_empty(&adc_pending) || adc_dev->ts_pend) {
> > + INIT_WORK(&resume_work, adc_resume_work);
> > + if (!schedule_work(&resume_work))
> > + dev_err(&pdev->dev,
> > + "Failed to schedule adc_resume work!\n");
> > + }
>
> Is the work being used here to avoid trying to do things that may
> sleep? IIRC, none of the calls should need to sleep.
It's used to prevent calling callbacks (that may sleep) in atomic context
(AFAIK resume handler is in atomic context)
> I was just wondering whether it would be better to abort any calls in
> progress before sleep and get the clients themselves to restart once
> they themselves have been resumed. We may end up with the case where the
> callbacks are being triggered before the client has been resumed.
Maybe, but sometimes it's tricky to abort waiting for callback in client
driver. Anyway, resume_work will be called only after all drivers has been
resumed, so situation when callbacks are being triggered before the client has
been resumed is impossible.
Regards,
Vasily
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20091023/d2de15d2/attachment.sig>
prev parent reply other threads:[~2009-10-23 5:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 14:19 [PATCH] s3c24xx-adc: resume convertions interrupted by going to suspend Vasily Khoruzhick
2009-10-22 11:10 ` Vasily Khoruzhick
2009-10-22 11:46 ` Mark Brown
2009-10-22 18:59 ` Ben Dooks
2009-10-23 6:01 ` Vasily Khoruzhick
2009-10-24 6:59 ` Nelson Castillo
2009-10-29 7:49 ` Vasily Khoruzhick
2009-11-04 18:27 ` Vasily Khoruzhick
2009-10-22 19:05 ` Ben Dooks
2009-10-23 5:57 ` Vasily Khoruzhick [this message]
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=200910230857.35780.anarsoul@gmail.com \
--to=anarsoul@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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 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.