newbie physical address range question

John Berthels (john.berthels@nexor.co.uk)
Wed, 27 Jan 1999 09:56:19 +0000 (GMT)


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/