All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David H. Lynch Jr." <dhlii@dlasys.net>
To: linux-serial@vger.kernel.org
Subject: Re: [RFC][PATCH] Xilinx uartlite serial driver
Date: Fri, 06 Oct 2006 00:14:36 -0400	[thread overview]
Message-ID: <4525D82C.7090200@dlasys.net> (raw)
In-Reply-To: <87hcykkrzu.fsf@slug.be.48ers.dk>

Peter Korsgaard wrote:
>>>>>> "David" == David H Lynch <dhlii@dlasys.net> 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.
   
  




>  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@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


  parent reply	other threads:[~2006-10-06  4:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-11 14:23 [RFC][PATCH] Xilinx uartlite serial driver Peter Korsgaard
2006-05-11 22:20 ` Russell King
2006-05-16  9:48   ` Peter Korsgaard
2006-05-16 12:09     ` Sylvain Munaut
2006-05-16 12:53     ` Russell King
2006-05-16 13:03       ` Peter Korsgaard
2006-06-02 16:47         ` Russell King
2006-05-16 13:03       ` Sylvain Munaut
2006-05-16 13:07         ` Peter Korsgaard
2006-08-22 15:13 ` Peter Korsgaard
2006-09-12 14:33   ` Olof Johansson
2006-09-13  5:56     ` Peter Korsgaard
2006-09-13 13:39       ` Peter Korsgaard
2006-09-13 15:01         ` Olof Johansson
2006-09-29 19:04           ` David H. Lynch Jr.
2006-09-29 19:57           ` David H. Lynch Jr.
2006-10-04 15:45             ` Peter Korsgaard
2006-10-06  4:14               ` David H. Lynch Jr.
2006-09-30  9:25           ` David H. Lynch Jr.
2006-10-04 16:01             ` Peter Korsgaard
2006-10-06  4:15               ` David H. Lynch Jr.
2006-10-03 10:27           ` David H. Lynch Jr.
     [not found]           ` <451CDA3D.2060109@dlasys.net>
2006-10-04 15:41             ` Peter Korsgaard
2006-10-06  4:13               ` David H. Lynch Jr.
2006-10-06  4:14               ` David H. Lynch Jr.
2006-10-06  4:14               ` David H. Lynch Jr. [this message]
2006-10-19 23:06         ` Olof Johansson
2006-10-20 12:22           ` Peter Korsgaard
2006-09-28 10:14       ` David H. Lynch Jr.
2006-10-04 15:34         ` Peter Korsgaard
  -- strict thread matches above, loose matches on Subject: below --
2006-10-13 14:12 David H. Lynch Jr.
2006-10-13 14:45 ` 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=4525D82C.7090200@dlasys.net \
    --to=dhlii@dlasys.net \
    --cc=linux-serial@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.