Re: [RFC][PATCH] Xilinx uartlite serial driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Peter Korsgaard wrote:
"David" == David H Lynch <dhlii@xxxxxxxxxx> writes:

Hi,

 David>     You force the port regshift value to 2 in your init code,
 David> but then you ignore it and hard code the register offsets
 David> preshifted.

Yes, the regshift value is not used by the driver, I just kept the
initialization as documentation. The Xilinx IP block afaik cannot be
configured with a different regshift value than 2, so I hardcoded
it.

We can change that if it would ever be a problem, but there's
unfortunately no clean way of representing this in the
device/ressource data, so I would prefer to leave that out unless it's
needed.
That is actually one of my more major issues. I am NOT the right person to speak for what direction things are going. But the majority of drivers - platform device based or otherwise, pass arround a uart_port structure with the irq, addresses, etc. the uart_port struct has provisions for a regshift - as well as other things.

DCR is another issue. I have never personally seen a UartLite DCR implimentation, but I have a driver from somebody else that started from mine, that assumes DCR instead of memory mapped ports. I think the Xilinx Gigabit Reference System Design connects the UartLite via DCR. I think DCR has to be a consideration. I do not KNOW that there is a UartLite implimentation with a regshift other than 2. But I have seen occasional code that uses different values - The GreenHills Integrity UartLite driver
   has it as a configurable parameter.



If your driver is going to become the officail UartLite driver, even if it does not already work with every UartLite implimentation, it still should not start with assumptions that
   are going to make supporting others difficult.
Given:

1). a resolution to the configuration issues - reconciling the IORESOURCE_MEM/IRQ stuff with the uart_port passing of early_serial_setup() and other drivers, as well as passing additional parameters such as a dcr option and a regshift - and I am NOT claiming to know that answer, only recognizing there is an issue.

2). figuring out why your driver drops outbound characters and fails to receive anything on my hardware.

I would be happy to provide patches to your driver to deal with the regshift issue, the early serial issue, and operating polled without an IRQ - the latter of which is critical atleast for my board, or you can pull them out of the patch I posted on linuxppc-embedded in January,
   or I will send you a current copy

But I spent 4 days trying to find just the dropped xmit character problem, without success. My driver works on my hardware doing polled IO - whether the firmware supports interrupts or not, and I the stock GreenHills integrity driver works interrupt driven on my hardware (with interrupt enabled firmware).

I would like to see a driver get into the kernel distribution that has boot-bash serial support, and polled IO, and works on my hardware. And I will provide my code as a resource and whatever time I can come up with to help get that. But anything less requires me to yank whatever is in the kernel and replace it with my driver. I have a real production board, with live clients, that uses the UartLite as the sole serial device, one way or another I have to have something that works for me.

Interrupt driven support, DCR, and regshift support are extras - but I am sure they matter to someone else.

 David> Also there is no provision for running the UartLite without
 David> using interrupts.  The Pico E12/E14 frequently use FPGA
 David> firmare that does not include a PIC.  Some implimentations of
 David> the UartLite use dcr instead of memory mapped ports.
No - again like the early serial stuff that's something that can be
added once the base driver is mainlined if there's demand.

Does polling even work decently with the small fifo size of the
uartlite?



--
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@xxxxxxxxxx 	  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

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux