Peter Korsgaard wrote:
It does not matter whether you or I are convinced. It matters whether there are people that need it."David" == David H Lynch <[EMAIL PROTECTED]> 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. 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. Right now I can not get your driver to work. I spent alot of time trying to fix it and got nowhere.The same with interrupt-less support if the changes are not too intrusive. 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. I am glad somebody is using your driver and finding it works. But we are all better served by fixing the failure cases.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. 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. Without being difficult - don't hold your breath. It is something I would like to do, butDavid> 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. I do not have infinite time. -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 [EMAIL PROTECTED] 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 |
_______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded
