patch: change in acpi taskq behavior
Jung-uk Kim
jkim at FreeBSD.org
Wed Oct 3 09:36:24 PDT 2007
On Wednesday 03 October 2007 12:04 pm, Nate Lawson wrote:
> Jung-uk Kim wrote:
> > On Sunday 30 September 2007 04:10 pm, Nate Lawson wrote:
> >> Attached is a patch (one for 6, one for 7) that shouldn't break
> >> anything for most people and may fix some battery status issues
> >> for others. It changes how we run tasks during boot. It seems
> >> some hardware expects synchronous access but our taskq is not
> >> running until after interrupts are enabled. This patch bounces
> >> calls through a wrapper that executes the callback directly if
> >> we're not booted yet.
> >
> > Sorry, I didn't test it but I have some questions. Why do you
> > add a wrapper and pollute all
> > AcpiOsQueueForExecution()/AcpiOsExecute() consumers? Isn't it
> > more simpler to let the function determine to queue or not to
> > queue? Why do you check cold and rebooting flags? If you wanted
> > to check the taskqueue is ready, you could check taskqueue_acpi
> > is NULL or not, instead.
>
> There are 2 different behaviors I'm trying to support and only the
> caller knows which one they want:
>
> 1. Run a task at some point in the future but "soon"
> 2. Queue a task to be run, definitely after boot is complete
>
> Notifies are in the first class. Initialization functions for the
> various drivers are in the second. ACPI-CA is moving to making all
> Notifies completely synchronous (i.e. they wait for the thread to
> run). So if we go to the model you describe (#1), this will work
> but suddenly the initialization of the drivers won't wait for boot.
> It will be run right away.
Understood. However, there are two conflicting Notify handler
implemtations, i.e., 'synchronous' type with a semaphore (which is in
newer unreleased ACPI-CA) and 'do not defer' type (which is in Linux
kernel source):
http://bugzilla.kernel.org/show_bug.cgi?id=5534
See the patches that are actually committed to Linux git tree:
http://bugzilla.kernel.org/attachment.cgi?id=10429&action=view
http://bugzilla.kernel.org/attachment.cgi?id=10430&action=view
I believe the vendor didn't finalize the design yet. For now, we may
have to try Linux way.
Thanks,
Jung-uk Kim
More information about the freebsd-current
mailing list