[LinuxBIOS] Winflashrom -- Current Status
darmawan.salihun at gmail.com
Mon Aug 20 17:05:21 CEST 2007
Roman Kononov wrote:
> On 08/14/2007 07:56 AM, Peter Stuge wrote:
>> Roman did make a good point about IRQL but that does not eliminate
>> the problem, we will still be changing hardware state underneath the
>> OS and that is ALWAYS a bad idea.
> The CF8/CFC sequence can preserve CF8 port value. What other hardware state
> would be changed?
> BTW, here is the "official" example:
> Unfortunately, AFAIK, this approach does not work for cases like yours. It
> requires the "DeviceObject", which MUST be associated with a PARTICULAR PCI
> Q: In the above links, among HtsReadWriteConfig() and WritePCIConfigSpace()
> argument lists, which arguments are bus number and device number?
> A: They are inside PDEVICE_OBJECT, which structure is "opaque".
> Regarding how long DPC method takes. A scheduled DPC is launched as soon as
> the CPU's IRQL drops below DISPATCH_LEVEL. The CPU can be at DISPATCH_LEVEL
> (and higher) only running kernel code. This can last many time slices. This
> means that the DPC method might be quite expensive.
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
instance. 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. 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
operation. Seems to be the DPC approach is not the right solution for
this type of problem.
I'm still working on this problem right now.
More information about the coreboot