I saw the smiley face, but I'm not smiling.
I've been reading documentation and this list for the past 3 months. The
problem is that there is a lot of conflicting documentation, spread between
even more locations. Even the sources aren't always helpful, considering how
lightly commented they are and how much of this area is architechure
dependent.
As for my patching the documentation, looks like I've still got too many
misunderstandings about how things are supposed to be done for me to do so.
FREX:
Are you supposed to do:
struct pci_dev *dev;
irq_value = irq_cannonicalize(dev->irq);
request_irq(irq_value, my_irq, SA_SHIRQ, "myIRQ", deviceID)
or is the value in dev->irq supposed to have already been cannonized?
In the 2.3 version of pci.txt (as viewed on kernel.org, since I don't have a
local copy) it makes reference to needing to call pci_set_master(). What (if
anything) do you have to do on a 2.2 kernel if you have a bus mastering
device? What LINUX_VERSION_CODE added this new routine?
Based on a lot of reading between the lines, I believe you do not have to
ever call check_region() or region_request() to claim your PCI address
space. I think these routines are only used for ISA.
Rules recently changed with respect to changing task state. Based on some
bugs on MP systems, I believe you are now always supposed to use
set_state(TASK_INTERRUPTIBLE);
instead of
current->state = TASK_INTERRUPTIBLE;
which was previously recommended. I have to check back though the archives
to find out exactly what the semantics are, above was from memory. I do
remember there was a race condition that required a memory barrior
instruction on MP systems.
-Bret
-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity
Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/