From: John Williams <jwilliams@itee•uq.edu.au>
To: Grant Likely <grant.likely@secretlab•ca>
Cc: Peter Korsgaard <jacmet@sunsite•dk>, linuxppc-embedded@ozlabs•org
Subject: Re: [RFC] uartlite driver MicroBlaze compatability
Date: Wed, 02 May 2007 16:18:47 +1000 [thread overview]
Message-ID: <46382D47.1090109@itee.uq.edu.au> (raw)
In-Reply-To: <528646bc0705012247p4a0fff63oa8d98364d5f639b0@mail.gmail.com>
Grant Likely wrote:
> On 5/1/07, John Williams <jwilliams@itee•uq.edu.au> wrote:
>
>> Grant Likely wrote:
>> > However, the uartlite is *not* an 8250. The 8250 turns up all over
>> > the place and it's registers are defined as 8 bit wide. The
>> > offset-by-3 stuff is part of the plat_serial8250_port structure which
>> > is also used to specify .regshift (increment between registers).
>> > Whereas the UARTLITE is defined as a 32 bit device and it doesn't show
>> > up in anywhere near as many designs. Registers are always 4 bytes
>> > wide and are always located at multiples of 4 bytes off the base
>
> Hmm, I think I was smoking something last night. Address used for 8
> bit access should not be affected by CPU endianess. After David's
> comments, I reread the uartlite documentation. The current design is
> definately for 32bit OPB bus connections, but it looks like there is a
> posibility for xilinx to add a 16 or 8 bit attachment. Since the
> uartlite design explicitly supports 8, 16 and 32 bit access, sticking
> with 8 bit io may be the safest.
To be honest I don't think that will ever happen - just because the OPB
bus data width is parameterisable, doesn't mean that it actually *works*
or has been tested on anything other than 32-bits wide. I've certainly
never heard of anyone doing so, on either MicroBlaze or PPC.
but, I won't fight over it :)
Either way, it will still require a code change if/when someone does a
16/8 bit wide OPB bus. Whether they change the IO access operation, or
a hardcoded constant, it's still not perfect.
Of course the real solution here is to create an OPB bus driver, with a
'width' field that you can pull out of XPAR, and so on... Use that
instead of platform bus, and all this rubbish can be dealt with cleanly.
> However, I still think the
> application of the 3 byte offset should be done in the driver, and not
> in the platform bus registration.
If it has to be done, I agree the driver is the place to put it.
> I've reworked the patch with the following changes
> - remove 3 byte offset from platform bus registration.
> - added ulite_in/ulite_out macros to make changing bus attachment
> details simpler if xilinx changes the uartlite design.
> - stick with 8 bit IO.
It works fine, however perhaps a comment explaining the +3 offset might
be appreciated by those who follow.
> Tested on PPC. John, can you please test on microblaze?
Acked-by: John Williams <jwilliams@itee•uq.edu.au>
John
next prev parent reply other threads:[~2007-05-02 6:18 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 [this message]
2007-05-02 14:09 ` Peter Korsgaard
2007-05-02 15:59 ` Grant Likely
2007-05-02 13:59 ` Peter Korsgaard
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=46382D47.1090109@itee.uq.edu.au \
--to=jwilliams@itee$(echo .)uq.edu.au \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=jacmet@sunsite$(echo .)dk \
--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