From: "David H. Lynch Jr." <dhlii@dlasys.net>
To: monstr@seznam.cz
Cc: Grant Likely <grant.likely@secretlab.ca>,
John Williams <john.williams@petalogix.com>,
Josh Boyer <jwboyer@linux.vnet.ibm.com>,
linux-serial@vger.kernel.org, jacmet@sunsite.dk,
Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Subject: Re: Uartlite driver
Date: Thu, 15 May 2008 10:31:41 -0400 [thread overview]
Message-ID: <482C494D.2050306@dlasys.net> (raw)
In-Reply-To: <4827E073.9020301@seznam.cz>
Michal Simek wrote:
>>
>> I fully understand the reason for the +3. What makes it 'magic' is
>> the fact that it is an undocumented value added to the base address
>> with no comment describing what it is for.
>>
>
> This is documented offset - look at uartlite manual - useful bits are 24-31.
> On big endian systems with 32bit access is everything ok because the least
> significant byte is the last in memory. But when you changed from 32bits to 8
> bits access than you have to move your base address to +3 offset.
>
> This is not undocumented value.
I do not buy that as any way documented.
Are there substantial numbers of other drivers for other devices
where a +3 jumps in from nowhere ?
I am also not happy with the register definitions hard coded as 0,4,8,12
I have not read the Xilinx UartLite docs recently, but there was older
Xilinx code that implied the registers could be 8, 16 or 32 bits.
There is also atleast one implimentation out there that accesses
the UartLite via DCR.
Can we just move all the in's and outs to something like:
static unsigned int
serial_in(struct uart_port *port, int offset) {
unsigned int value;
switch (port->iotype) {
case UPIO_PORT:
value = mfdcr(offset);
break;
default:
offset <<= port->regshift;
value = readb(port->membase + offset);
}
return value;
}
Then we can handle all the 8/16/32 BE/LE, DCR, .... in one place ?
I think that is what is done in other drivers.
--
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
next prev parent reply other threads:[~2008-05-15 14:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-11 14:01 Uartlite driver Michal Simek
2008-05-11 22:39 ` John Williams
2008-05-12 4:31 ` Grant Likely
2008-05-12 6:15 ` Michal Simek
2008-05-15 14:31 ` David H. Lynch Jr. [this message]
2008-05-15 16:39 ` Stephen Neuendorffer
2008-05-16 7:41 ` Peter Korsgaard
2008-05-15 14:45 ` Uartlite driver & CONFIG_CONSOLE_POLL David H. Lynch Jr.
2008-05-16 7:47 ` Peter Korsgaard
[not found] ` <482E5BD0.1080306@dlasys.net>
2008-05-18 19:04 ` Peter Korsgaard
2008-05-12 7:43 ` Uartlite driver 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=482C494D.2050306@dlasys.net \
--to=dhlii@dlasys.net \
--cc=grant.likely@secretlab.ca \
--cc=jacmet@sunsite.dk \
--cc=john.williams@petalogix.com \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linux-serial@vger.kernel.org \
--cc=monstr@seznam.cz \
--cc=stephen.neuendorffer@xilinx.com \
/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