Roman Kononov wrote: > Peter Stuge wrote: >> But PCI config accesses are not atomic operations. Is there a >> guarantee that the other CPUs are not in the middle of doing a PCI >> access already? >> >> And even if they are actually doing something else, perhaps they >> (erroneously? but we don't want to break them anyway) rely on 0xcfc >> being what they set it to in the last PCI config access? >> > By making all the CPUs spinning inside your DPC you avoid these > problems. The Windoze kernel protects itself and does not execute > scheduled DPC when the CPU is in the middle of a PCI access or anything > similar. For sure, when a CPU makes a PCI access its "IRQL" is raised to > "HIGH_LEVEL", which means that a dedicated spin lock is acquired and > that CPU's interrupts are disabled. > > I did not take the above statement about IRQL from an official document, > I made it based on my experience and common sense. > > Regards, > > Roman >
Apparently, this is the only solution right now because the Hal***BusDataByOffset() function is _not_ working as expected. My latest test results with 2 different PCs with WIndows XP SP2 shows that HalGetBusDataByOffset() is not a stable function, it works in one of the test platform and crashes in others. While the HalSetBusDataByOffset() is _not_ working at all. I think the symbol is defined in the kernel but may not be implemented in Win XP SP2. Moreover, direct port I/O was working flawlessly with the older flashrom that I port to windows back then. I think the "DPC" trick will guarantee the atomic operation and will give us the level of confidence to do the direct port I/O. I'll be reporting as soon as the DPC version of the direct port I/O driver routine has been tested. Regards, Darmawan Salihun -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios