From: David Hawkins <dwh@ovro•caltech.edu>
To: Kumar Gala <galak@kernel•crashing.org>
Cc: Chris Wyse <chris.wyse@windriver•com>,
"Linuxppc-Embedded \(\(E-Mail\)\)" <linuxppc-embedded@ozlabs•org>
Subject: Re: Memory mapping PCI memory region to user space
Date: Thu, 23 Mar 2006 09:46:39 -0800 [thread overview]
Message-ID: <4422DEFF.9070202@ovro.caltech.edu> (raw)
In-Reply-To: <CCA437BF-E204-4652-9E6D-25388225EFE8@kernel.crashing.org>
Hi Kumar,
>> When I was testing the Yosemite board as the host, I found
>> that I could set the endian flag on the mmapped page, which
>> then made the PCI device registers read as 32-bit quantities
>> read back with the same layout under both x86 and PPC
>> hosts.
>
> Hmm, I guess I would handle this like how the reset of the kernel
> handle is with the io routines handling the swapping. Not sure if
> there is any advantage to using the endian flag. I guess if you have
> something you are treating as just memory there would be.
I haven't used the feature, I just tested it to see what it did.
The application case I thought of was this; the PCI boards I built
(that I am revising, and replacing the DSP with a PPC) have an
8MB PCI region that I can mmap from the host. I have a test
suite that runs from the host that manipulates registers on the boards
to download FPGAs etc. When the boards are used in a real system,
the onboard DSP is generally used, and the host just talks to
the DSP.
However, for the test suite, if I have a header with definitions
like:
#define CONTROL_FPGA_ENABLE (1 << 0)
#define CONTROL_FPGA_DONE_BIT (1 << 1)
that correspond to bits in a 32-bit PCI mmapped register. Then
code in the user-space test suite that did something like
pci_addr[CONTROL_OFFSET] |= CONTROL_FPGA_ENABLE;
would instead need to be re-written, eg.,
write_le32(&pci_addr[CONTROL_OFFSET], CONTROL_FPGA_ENABLE);
to be portable.
I definitely agree that this is how kernel-level code should be
written, but user-space code ... well, if I want to reuse code
already written, setting the page endian flag and reusing the
code would seem like the way to go. (This isn't what I need
to do, since my host will still be an x86, the PPC will
be a target device, but I still need to think about the
endian issues).
Now of course that I have seen the consequences of my coding,
I'll be more careful to deal with endianness more appropriately.
Its a tricky trade-off though. I could define control ioctl's
that hide all the endianness issues ... but then the driver just
gets bigger. I think the appropriate solution for the user-space
test code would be to use CPU-to-little-endian routines, and
wrap the lot in a re-usable library that the test suite
links against.
> There isn't a sysfs flag for the endianness page attribute since thats
> a PPC book-e specific feature. We could possible expand things to
> support it but, I've been trying to actively avoid using the 'E' bit.
Ok, I haven't received the 8349E board that I am waiting
on, so I hadn't spotted that the PAGE_ENDIAN flag was
Book E specific.
Thanks for your insight.
Cheers
Dave
next prev parent reply other threads:[~2006-03-23 17:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 14:21 Memory mapping PCI memory region to user space Wyse, Chris
2006-03-23 15:44 ` Kumar Gala
2006-03-23 17:12 ` David Hawkins
2006-03-23 17:19 ` Kumar Gala
2006-03-23 17:43 ` Mark Chambers
2006-03-23 17:54 ` David Hawkins
2006-03-23 19:55 ` Mark Chambers
2006-03-23 20:26 ` David Hawkins
2006-03-23 17:46 ` David Hawkins [this message]
2006-03-27 8:02 ` Phil Nitschke
2006-03-27 16:05 ` David Hawkins
2006-03-28 4:21 ` Phil Nitschke
2006-03-28 4:55 ` David Hawkins
2006-03-28 6:44 ` Phil Nitschke
2006-03-28 16:35 ` David Hawkins
2006-03-27 16:18 ` Kumar Gala
2006-03-29 2:26 ` Phil Nitschke
2006-03-23 17:04 ` David Hawkins
-- strict thread matches above, loose matches on Subject: below --
2006-03-23 19:52 Wyse, Chris
2006-03-23 20:01 ` Kumar Gala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4422DEFF.9070202@ovro.caltech.edu \
--to=dwh@ovro$(echo .)caltech.edu \
--cc=chris.wyse@windriver$(echo .)com \
--cc=galak@kernel$(echo .)crashing.org \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox