[PATCH] Xilinx UART Lite 2.6.18 driver

[David H. Lynch Jr.]

Peter Korsgaard wrote:
>>>>>> "David" == David H Lynch <dhlii at dlasys.net> writes:
>>>>>>             
>
> Hi,
>
> David>    Peter's driver uses the IORESOURCE requests to pull platform
> David> data.  Most other serial platformdevices pull a uart_port
> David> object.  My limited understanding of IORESOURCE is that it is
> David> not sufficiently deep to support the parameters that are needed
> David> to support UartLite such as a DCR flag and a regoffset.
>
> I'm still not convinced that DCR access and variable register offsets
> are needed - But it can always be added (through a seperate struct in
> platform_data) - Patches are welcome.
>   
    It does not matter whether you or I are convinced. It matters 
whether there are people that need it.
    Xilinx has a reference design that uses DCR. While I have never 
tripped over an actual implimentation that uses
    DCR there are others on this list that have.

> The same with interrupt-less support if the changes are not too
> intrusive.
>
>   
    Right now I can not get your driver to work. I spent alot of time 
trying to fix it and got nowhere.
    I can not get it to receive at all, and I can not get it to send 
after switching from the console driver
    without dropping characters. I am very busy with other things right 
now and it is going to be a long
    time before I have time to look at your driver again.

    In the meantime, my own driver works - atleast for me. And it is out 
in the real world on production systems.
 
   The most instrusive changes is likely to be fixing whatever is 
causing yours to drop characters - the problem is
    worse when I patch your driver to be timer driven - but that is 
likely because your service routines blindly presume it is
    safe to transmit - true on a Tx empty interrupt, but  not on a timer 
tick.

    But what matters is not whether the changes are intrusive, but  
whether they produce a better result.









> David>    You are welcome to do that. I already patched his driver to
> David> work with my early console support as well as adding the
> David> boot-bash stuff similar to yours. But I gave up actually using
> David> it when I could not get it to work.
>
> Which is odd as I've gotten positive feedback from others.
>   
    I am glad somebody is using your driver and finding it works. But we 
are all better served by fixing the failure cases.

    It is not particularly odd at all. The UartLite despite its 
simplicity is   worse than a normal driver - different
    FPGA implimentations can vary. Normal drivers for fixed inflexible 
hardware often do not work accross
    differing implimentations, why would you expect something like 
UartLite to be invariant ?

    One of the other reasons for implimenting polling is because a 
polled driver tends to work accross
    wider hardware variations. You can not make state assumptions in a 
poll routine,
    and if the poll routine does nto run then the rest of the OS is hosed.

    Even today, flakey hardware interrupts are not unheard of.

    I would also ask what data rates you and others with Working 
UartLites are using ?
    The cases I am dealing with run at 57600 and 115200 respectively - 
it is not that odd for
    driver problems to manifest themselves only or more frequently at 
high baud rates.


> David>    Next time I get an opportunity I am going to try to setup an
> David> ml403 to atleast verify that Peter's driver is working there.
>
> Great.
>   
    Without being difficult - don't hold your breath. It is something I 
would like to do, but
 I do not have  infinite time.


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii at dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20061015/678fbd9f/attachment.htm