Dino and Lasi
Okay, I've committed some small changes to dino and lasi that can easily be backed out.
some questions:
- what IRQ are we going to run LASI on? Is that something we just pick and hard code?
- I changed lasi.c and dino.c to only use readl() and writel(), and not readb and writew, etc. Was this a mistake?
- We really really need the IRQ bottom halfs setup. Any takers?
- Alex
Signature · 3 lines
Alex deVries Vice President of Engineering The Puffin Group
Quoted 9 lines · Alex deVries
Okay, I've committed some small changes to dino and lasi that can easily be backed out.
some questions:
- what IRQ are we going to run LASI on? Is that something we just pick and hard code?
Isn't LASI a PA (ie GSC bus) device?
If so, it can use any EIRR bit/HPA pair supported by the PA processor code. It needs to register an ISR with PA interrupt code and get the EIRR/HPA pair (commonly called EIM value).
Same is true for Dino.
Quoted 2 lines
- I changed
lasi.canddino.cto only usereadl()andwritel(), and not readb and writew, etc. Was this a mistake?
For Dino, I think so. On a reads, it shouldn't matter unless the reads have side effects (eg. clears the byte register). On writes too many byte enables will be set.
BTW, I assume you are talking about PCI MMIO/Port/Cfg space accessor functions.
Quoted 1 line
- We really really need the IRQ bottom halfs setup. Any takers?
What do you mean "bottom half"?dino_isr() to map DINO EIM registers to PCI IRQ lines (and thus PCI device ISRs)?
grant
Grant Grundler
+1.408.447.7253
Quoted 3 lines
What do you mean "bottom half"?
dino_isr()to map DINO EIM registers to PCI IRQ lines (and thus PCI device ISRs)?
The Linux bottom halves are closest in 'other unixen' to the software interrupt code run after the IRQ return.
Linux services any pending bottom halves after the irq completes but before returning to the scheduled task/scheduler. Its used for deferring processing from interrupt paths