DPRAM driver on 440gp

DPRAM driver on 440gp

[Bob White]

I've got a basic read/write driver working (thanks to O'reilly ldd2) on
the dpram on the peripheral bus.

I remap the physical addresses using "io_base = ioremap64(...)" in the
driver open call and then the user read and write functions can access
the dpram just fine.

I'd like the user to be able to access the dpram using a pointer, but I
am having trouble figuring out the mmap examples.

Given that the physical address has already been mapped, via
ioremap64(), do I need remap_page_range()?  Does anyone have any ideas
on what the mmap file_op for this driver would look like?  Do I even
need mmap() or should I just use an ioctl to return the pointer I've
already got to the user?

Bob
--
Robert B. White        Perigee, A Division of Sensis Corp
Software Design Engr   316 Commerce Blvd.
TEL: 315.453.7842x29   Liverpool, NY  13088
FAX: 315.453.7917      www.Perigee.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: DPRAM driver on 440gp

[Fillod Stephane]

>Given that the physical address has already been mapped, via
>ioremap64(), do I need remap_page_range()?  Does anyone have any ideas
>on what the mmap file_op for this driver would look like?  Do I even
>need mmap() or should I just use an ioctl to return the pointer I've
>already got to the user?

The ioctl won't do because the virtual address returned by the ioremap64
is not valid in process context. You could remap it through mmap file_op,
but why bother?
Rem: reading ioremap64 and drivers/char/mem.c is very instructive.

Since you're accessing your DPRAM guarded/uncached, you may simply
map it both in kernel with ioremap64 and in userland with mmap64
of /dev/mem.

For more information, search the archive (or DENX PPC FAQ) on userland
mapping of physical memory.


Regards,
Stephane

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/