Garrett D'Amore wrote:
On Sun, 2010-07-11 at 02:22 +0100, J. J. Farrell wrote:
I'm finding the documentation for accessing device memory/registers in
Solaris cryptic to say the least; I'd welcome some clarification. I'd
like to map device register, memory, and PCI Config space into driver
memory space and access it like memory. The Solaris documentation
implies this can't be done, but I find that hard to believe.
Chapter 7 of Writing Device Drivers says that device memory/registers
must be mapped in using ddi_regs_map_setup() then accessed using the
ddi_getX/ddi_putX routines. These access routines can look after
ordering and endianness for me. There is no option offered for me to
just access the regions as mapped memory and deal with any such issues
myself.
You can. Use ddi_regs_map_setup() with DDI_NEVERSWAP_ACC (or whatever
it is, can't recall off the top of my head.)
Thanks Garrett; that's what common sense was telling me, good to have it
confirmed.
Relying on this is usually a bad idea, because the DDI routines, in
addition to handling endianness, also help ensure that caches are
handled properly, bridges, etc., and also can deal with the fact that on
some architectures you simply *can't* map devices directly. (E.g. on
some hardware I've seen -- not Solaris compatible -- the way you get at
PCI configuration requires indirect register access... and the way you
get at I/O space on x86 systems is through special x86 io instructions.
Well understood; using direct access implies taking responsibility for
all such issues.
...
In summary: my device has memory, registers, and config space which
appear in the processors' physical memory map. Does Solaris support
mapping these into kernel memory and accessing them like memory? I'll
look after any size/alignment/ordering/endian problems myself. If this
is supported, how do I do it and is there any documentation anywhere
which covers it?
Yes, you can do it. The ddi_regs_map_setup sets this up. The address
it returns is actually a pointer to the start of the mapping. Why do
you want to avoid using the DDI routines?
The question was partly about understanding just what was going on with
these routines - were things actually being done is some weird way which
really prevented normal memory-like access. Another part was being able
to explain what this is all about to a bunch of engineers used to
working more or less directly on the metal in an embedded environment.
Yet another part concerns porting quantities of code which currently
accesses devices directly like memory.
I fully understand the benefit of the access routines for hiding
differences in architectural and implementation requirements across a
range of platforms. The project I'm working on is targeting a precisely
defined hardware architecture and platform, and involves porting a chunk
of existing code which accesses memory-mapped devices directly. In these
circumstances, it's well worth at least exploring using direct
memory-mapped access on Solaris.
Thanks again for the clarification.
Regards,
jjf
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
