Re: patch: change in acpi taskq behavior

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