Messages in this thread | | | Date | Wed, 27 Jan 1999 09:56:19 +0000 (GMT) | From | John Berthels <> | Subject | newbie physical address range question |
| |
Hello folks,
I'm trying to get at a PCI device from a driver and am busy trying to learn the ins and outs of doing so.
From Documentation/pci.txt:
3. Addresses and interrupts ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Memory and port addresses and interrupt numbers should NOT be read from the config space. You should use the values in the pci_dev structure as they might have been remapped by the kernel.
However, when I look at the pci_dev structure for my device, all relevant addresses are zero (presumably because nothing else has messed with this device yet). So I think I'll need to do something about it.
What I think (well, have been told :-) I have to do about it is write+read the address register to get the size + alignement restrictions and then write out a physical address (I want to do memory mapped, rather than io mapped) to put the card at a certain address.
And then I need to ioremap this base physical address into a kernel vm address, after which I can twiddle the contents to me heart's content.
This seems reasonable, but leads me to ask the question - how do I determine what is a suitable address to assign to the card? The only constraints I can see are that it must be > physical RAM, appropriately aligned and (here is the kicker) not collide with anything used by another device.
Will ioremap (well, actually remap_area_pages - but that messes with pmd's and suchlike and as such seems beyond me) give me back an error (NULL) if I collide, so that my best strategy is just to loop upwards from virt_to_phys(high_memory) until I get a slot?
Or is there some darker secret lurking here?
Hope this question isn't too annoying/boring.
regards,
jb
PS. Would it be an entirely stupid idea to put an 'eg' driver (perhaps not even compiled in by default) into the kernel tree? I've (recently) found its pretty easy to put together a character driver from looking at others, but a block driver seems more tricky. There are plenty of examples of real drivers to look at, but they all have their own needs and hence peculiarities. Would a canonical, trivial driver be a useful learning tool? [I'll hopefully have one finished soon ;-)]
PPS. Forgive slow response to list, I'm a digest person
-- John Berthels Email: j.berthels@nexor.co.uk X.400: /G=john/S=berthels/O=nexor/P=nexor/A=cwmail/C=gb/
- 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/
| |