lkml.org 
[lkml]   [2001]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] I/O Access Abstractions
Date
>> > Last time I checked, ioremap didn't work for inb() and outb().
>>
>> It should :)
>
>it doesnt need to.
>
>pci_find_device returns the io address and can return a cookie, ditto
>isapnp etc

Yes, but doing that require 2 annoying things:

- Parsing of this cookie on each inx/outx access, which can
take a bit of time (typically looking up the host bridge)

- On machines with PIO mapped in CPU mem space and several
(or large) IO regions, they must all be mapped all the time,
which is a waste of kernel virtual space.

Why not, at least for 2.5, define a kind of pioremap that
would be the equivalent of ioremap for PIO ?

In fact, I'd rather have all this abstracted in a

ioremap_resource(struct resource *, int flags)
iounmap_resource(struct resource *)

("flags" is just an idea that could be used to pass things
like specific caching attributes, or whatever makes sense to
a given arch).

The distinction between inx/oux & readx/writex would still
make sense at least for x86.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.099 / U:24.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site