[LinuxBIOS] Winflashrom -- Current Status
kononov at dls.net
Mon Aug 20 19:01:27 CEST 2007
On 08/20/2007 10:05 AM, Darmawan Salihun wrote:
> According to the official documentation, DPC is running at
> IRQL_DISPATCH_LEVEL. Nonetheless, I think there is still problem because
> only one DPC object of one "type" can exist in the system at one
What do you mean by "type"?
If you have N CPUs:
KeInitializeDpc() initializes N DPC objects, each object has the same
KeSetTargetProcessorDpc() ties each DPC object with a CPU.
PCI Configuration Sequence:
IRQL is raised to DISPATCH_LEVEL.
KeGetCurrentProcessorNumber() tells which CPU it is.
KeInsertQueueDpc() schedules the N-1 DPCs to run. All but this CPU are
Spin waiting for the DeferredRoutines to enter phase A.
IRQL is raised to HIGH_LEVEL.
The DeferredRoutins are flagged to enter phase B.
Spin waiting for the DeferredRoutines to enter phase B.
Do the 3f8/3fc business.
The DeferredRoutins are flagged to finish.
Restore the IRQL.
Indicate that the phase is phase A.
Spin waiting for being flagged to enter phase B.
Raise IRQL to HICH_LEVEL.
Indicate that the phase is phase B.
Spin waiting for being flagged to finish.
Restore the IRQL.
This means we need to provide different DPC object "type" for
> different processor in multiprocessor environment to ensure "atomic"
> execution of the I/O code which seems to be an overkill and make the
> system too much loaded.
What is "too much"?
I found this when trying to code the "DPC
> approach" in my latest device driver. Perhaps, using a kernel mode
> spinlock is a better approach. To ensure an atomic execution of the I/O
A spin lock does not help. A CPU, which has acquired a spin lock, does not
prevent another CPU to mess with the cf8/cfc registers. You need to lock all
Seems to be the DPC approach is not the right solution for
> this type of problem.
You are the man, you make the decision.
More information about the coreboot