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. -- NateReceived on Wed Oct 03 2007 - 14:04:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC