From: Peter Korsgaard <peter.korsgaard@barco•com>
To: linuxppc-embedded@ozlabs•org
Subject: Re: [RFC] uartlite driver MicroBlaze compatability
Date: Wed, 02 May 2007 15:59:33 +0200 [thread overview]
Message-ID: <871whz5nsq.fsf@sleipner.barco.com> (raw)
In-Reply-To: <528646bc0704302255j3a825f10vbffd4bac961b28d7@mail.gmail.com> (Grant Likely's message of "Mon, 30 Apr 2007 23:55:52 -0600")
>>>>> "GL" == Grant Likely <grant.likely@secretlab•ca> writes:
Hi,
>> Can you please confirm if this works on PPC?
GL> Yes, I've confirmed this does work on PPC; but I don't think it's
GL> quite the correct fix.
GL> ioread/write32 is mapped to in/out_le32, yet the bootloader driver
GL> must use in/out_be32. This is because the uartlite driver follows
GL> the lead of 8250 and requires an offset of 3 from the base address
GL> in order to find the relevant byte wise address. In fact, I
GL> believe the driver should work as-is on microblaze if the
GL> offset-by-3 is not used when registering it to the platform bus.
Not used? Isn't the microblaze big endian as well?
GL> However, the uartlite is *not* an 8250. The 8250 turns up all
GL> over the place and it's registers are defined as 8 bit wide. The
GL> offset-by-3 stuff is part of the plat_serial8250_port structure
GL> which is also used to specify .regshift (increment between
GL> registers). Whereas the UARTLITE is defined as a 32 bit device
GL> and it doesn't show up in anywhere near as many designs.
GL> Registers are always 4 bytes wide and are always located at
GL> multiples of 4 bytes off the base address.
Well, yes and no - The registers physically contains 8 bit of
information, but are commonly located on the 32bit opb bus.
GL> The biggest problem with keeping the 3 byte offset and using
GL> ioread/write32 on it makes every register access straddle a 32-bit
GL> boundary. This means 2 bus transactions for every register
GL> access. Absolutely not what we want.
Exactly.
GL> The problem with keeping the byte-wise access as it is now is that
GL> it means the platform bus binding needs to explicitly know what
GL> the host access width is and add the 3 byte offset accordingly
GL> (rather than using the base address as specified in xparameters
GL> unmodified and using the in/out_be32 macro take care of reading it
GL> correctly & efficiently).
I don't think that's a big problem. Other reasons for using 8bit I/O
are:
- No endianness problems (besides setting the proper base
address). "There's no read/write register in native endianness"
interface in the kernel. readl is always little endian, and _be32
would be wrong/not available on all archs. The uartlite interface is
nice and simple - Who knows if someone would add a FPGA with a bunch
of uartlite's to an ARM/MIPS/whatever design?
- No bus width problems. We have designs which needed extra uarts late
in the design, and have implemented uartlite compatible firmware in
a SP3e FPGA connected over a 16bit bus (EMC). The uartlite driver
works nicely with that as it is. With 32bit access you would double
the bus transactions.
- It matches 8250.c
GL> (There are also annoyances that will come up when we move to
GL> arch/powerpc and hook it up to the of_platform_bus)
Ohh, like what?
>> I note that Grant's recent bootloader driver uses in_be32/out_be32
>> - would you prefer that instead of ioread32/iowrite32?
GL> I certainly think so. The device is documented as using 32 bit BE
GL> registers; so the driver should access them as 32bit BE registers
GL> IMHO. Or at least, if there is a good reason to continue the
GL> bytewise access, then the driver should contain the smarts to
GL> translate from documented base address to the appropriate offset.
How should it be able to do that? Using some magic #ifdef to know if
it's compiled for a big endian arch and do a +3? That seems ugly to
me.
In other words - I disagree.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2007-05-02 13:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 4:55 [RFC] uartlite driver MicroBlaze compatability John Williams
2007-05-01 5:55 ` Grant Likely
2007-05-01 6:42 ` John Williams
2007-05-02 5:47 ` Grant Likely
2007-05-02 6:18 ` John Williams
2007-05-02 14:09 ` Peter Korsgaard
2007-05-02 15:59 ` Grant Likely
2007-05-02 13:59 ` Peter Korsgaard [this message]
2007-05-02 13:45 ` Peter Korsgaard
2007-05-03 1:08 ` John Williams
2007-05-03 10:22 ` David H. Lynch Jr.
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=871whz5nsq.fsf@sleipner.barco.com \
--to=peter.korsgaard@barco$(echo .)com \
--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