UartLite

[Grant Likely]

BTW, you should really be asking these questions on the linuxppc mailing list

On Sun, Apr 20, 2008 at 2:23 PM, David H. Lynch Jr. <dhlii at dlasys.net> wrote:
> I have been looking more and more at the kernel uartlite driver.
>  Somewhere along the line while I was not watching PK's driver has
>  developed alot stronger resemblance to most normal serial drivers. I am
>  seriously thinking of putting some effort into getting it working for
>  me, and then pushing my polling patch for interrupt free implimentations.
>
>  But I have tripped over several things that trouble me. Though I am not
>  a serial driver expert.
>
>  The first is that all the Uartlite related definitions tend to create a
>  BaseAddress+3 definition.
>  This really bothers me, it presumes that the registers are all 4 bytes
>  apart - I know that is the norm
>  and I have never actually seen a different implimentation, but I do not
>  think it is set in stone.
>  It also is basically a cleaver trick to get readb/writeb to work without
>  adjustment.
>  Endian issues tend to give me headaches, but somehow I think there is an
>  endian issue in this.
>  All the port offsets are defined with the presumption the registers are
>  4 bytes apart.
>  Despite the fact that all the offsets masks and bits are needed in
>  several files, they are not in a header.

Yes, I'm not a big fan of the +3 either; but it is expedient.  I think
the best solution is to encode it into the device tree by adding
optional "reg-stride" and "reg-offset" properties (at least for memory
mapped implementations).

We can define another binding for the DCR version.

>  If I can manage to get the thing to work for me,
>  Am I going to be stepping on any toes if I make changes to adress my
>  concerns above ?

I've got no problem reworking the register accessor functions.

>  I really want to migrate all the direct IO to a ulite_in() and
>  ulite_out() routine.
>  Letting those two routines deal with all the issues of BaseAddress,
>  register size, endianness, register shift,
>  and even whether access is via DCR - I have seen atleast one
>  implimentation that was DCR.
>
>  I would like to remove the +3 from all the macro's etc. as it seems to
>  me to confuse what is actually going on.
>
>  I did a diff merge against my own driver a few days ago and aside from
>  these issues, order of functions, some naming issues, the absence of OF
>  support in my driver, and the presence of polling in mine, the code now
>  very very strongly parallels my code now. So it should not be alot of
>  work to merge  my code  into the  standard driver now.
>
>  I will be happy to do this - presuming I am not going to be stepping on
>  any toes.
>  I would be happy to not have to support a separate driver, but the stock
>  driver has to work with my hardware.
>  It still does not, but I think the code is now close enough for me to
>  track down and kill the problem.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.