Peter Stuge wrote:
On Thu, Jul 12, 2007 at 05:13:38PM +0700, Darmawan Salihun wrote:
As for the EPIA board, well, where is that base specified? In a PCI config register or where?
The base is in a PCI config register. Relevant code as follows:
base = pci_read_word(dev, 0x88) & 0xFF80; val = inb(base + 0x4D); val |= 0x80; outb(val, base + 0x4D);Ok! Put all of board_enable.c in the kernel driver and add some way for the app to call any function in the board_pciid_enables list, in the kernel driver. Sort of RPC but over a app/kernel split instead of over a network.
Then compile board_enable.c also into the app, but not to call any of the functions (which would fail anyway) but only to get the same board_pciid_enables list. The struct may have to be extended to have a unique index for each entry so that the driver and app can agree on which function is which.
All of the device detection should be done where it is easiest to do it. Since the driver will need to do safe PCI accesses for board enables perhaps it makes sense to contain all PCI accesses in the driver.
After reading through majority of flashrom code, I found out that the direct I/O port accesses reside in two files, as follows: - board_enable.c - chipset_enable.c
I'll try find a way to "move" the routine in these files into the kernel driver and provide a way to call them indirectly through the driver interface (the so-called I/O Request Packet).
Everything else other than the direct I/O port accesses are accomplished through memory-mapped I/O (MMIO) R/W transactions. Because the current code is already capable of mapping MMIO ranges that we need to the app, we can consider this problem solved.
--Darmawan Salihun