From: "David H. Lynch Jr." <dhlii@dlasys.net>
To: Peter Korsgaard <jacmet@sunsite.dk>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] Xilinx UART Lite 2.6.18 driver
Date: Sun, 15 Oct 2006 17:02:09 -0400 [thread overview]
Message-ID: <4532A1D1.4040006@dlasys.net> (raw)
In-Reply-To: <8764eovg81.fsf@sleipner.barco.com>
[-- Attachment #1: Type: text/plain, Size: 4080 bytes --]
Peter Korsgaard wrote:
>>>>>> "David" == David H Lynch <dhlii@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@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
[-- Attachment #2: Type: text/html, Size: 5788 bytes --]
next prev parent reply other threads:[~2006-10-15 21:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-10 20:49 [PATCH] Xilinx UART Lite 2.6.18 driver David Bolcsfoldi
2006-10-10 22:04 ` Grant Likely
2006-10-11 22:06 ` David H. Lynch Jr.
2006-10-12 10:34 ` Peter Korsgaard
2006-10-12 21:12 ` David Bolcsfoldi
2006-10-13 5:21 ` David Bolcsfoldi
2006-10-13 7:04 ` David H. Lynch Jr.
2006-10-13 7:22 ` Peter Korsgaard
[not found] ` <45329C42.3030000@dlasys.net>
2006-10-16 19:42 ` Peter Korsgaard
2006-10-13 7:11 ` Peter Korsgaard
2006-10-15 23:48 ` David Bolcsfoldi
2006-10-20 19:41 ` Peter Korsgaard
2006-10-27 15:03 ` Peter Korsgaard
2006-10-28 3:29 ` David H. Lynch Jr.
2006-10-30 8:23 ` Peter Korsgaard
2006-10-31 17:26 ` David H. Lynch Jr.
2006-10-30 19:45 ` David Bolcsfoldi
2006-11-06 15:44 ` Peter Korsgaard
2006-10-13 6:48 ` David H. Lynch Jr.
2006-10-13 7:15 ` Peter Korsgaard
2006-10-15 21:02 ` David H. Lynch Jr. [this message]
2006-10-16 19:49 ` Peter Korsgaard
2006-10-16 19:52 ` Peter Korsgaard
2006-10-13 7:08 ` Peter Korsgaard
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=4532A1D1.4040006@dlasys.net \
--to=dhlii@dlasys.net \
--cc=jacmet@sunsite.dk \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).