Hi Shinya,
Wolfgang Denk wrote:
We can easily ignore such boards of course, but it would be very nice
for U-Boot if it could provide easy configurable drivers and could
support as many hardwares as possible.
Currently it seems that all in-tree boards can be accomodated with the
construct
Hi Shinya,
I see. Actually I was looking a lot at the Linux driver but was hoping
that we could away without introducing serial_{in,out}...
In my horrible opinion, the combinations of base addres + reg_shift
+ iotype (char, long, or whatever), are simpler, more configurable,
more slid, easy
On Mon, May 04, 2009 at 05:40:37PM +0200, Detlev Zundel wrote:
static unsigned int serial_in(struct uart_8250_port *up, int offset)
[snip]
}
to be simpler and more solid readb(struct-field) (which is
effectively what we have in the current implementation)? You consider
more
Dear Detlev,
In message m2zldsanbe@ohwell.denx.de you wrote:
to be simpler and more solid readb(struct-field) (which is
effectively what we have in the current implementation)? You consider
more configurable to be a good in its own?
Yes.
Wow. As a rhetorical question - where
Wolfgang Denk wrote:
We can easily ignore such boards of course, but it would be very nice
for U-Boot if it could provide easy configurable drivers and could
support as many hardwares as possible.
Currently it seems that all in-tree boards can be accomodated with the
construct that I
Hello Shinya,
Detlev Zundel wrote:
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
Detlev Zundel wrote:
Hello Shinya,
Detlev Zundel wrote:
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
I might be unclear. I used to use REG_SIZE =
Hello Shinya,
I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
are located at 0, +0x10, +0x20, ..., .
Actually, come to think of it, I have never seen what you used to use,
as the REG_SIZE = -16 case was never in the official U-Boot sources.
Theoretically extending the -4
Hi Jerry,
Detlev Zundel wrote:
Hello Shinya,
Detlev Zundel wrote:
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
I might be unclear. I used to use
Detlev Zundel d...@denx.de writes:
So what about using +16 for your board and lower the base address by 2?
Ugh. Increasing by 2 would be more in line with my reasongin...
Does that work? What is your base address? Is that 64-bit aligned?
This is somewhat hypothetical and outright ugly,
Hi Jerry,
16 byte stride. That is seriously odd.
Isn't this natural for a 64-bitter?
No, of course not. That would be still another generation of course.
Makes this look all the more weird.
Cheers
Detlev
--
Each language has its purpose, however humble. Each language expresses
the Yin
Detlev Zundel wrote:
Hi Jerry,
Detlev Zundel wrote:
Hello Shinya,
Detlev Zundel wrote:
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
I might be
Hi,
Detlev Zundel wrote:
Thinking about it some more, I wonder about the following. You said,
this would work for you:
struct NS16550 {
unsigned long rbr;
unsigned long postpad_rbr[3];
while
struct NS16550 {
unsigned char rbr;
unsigned char
Hi,
Detlev Zundel wrote:
I see. Actually I was looking a lot at the Linux driver but was hoping
that we could away without introducing serial_{in,out}...
In my horrible opinion, the combinations of base addres + reg_shift
+ iotype (char, long, or whatever), are simpler, more configurable,
Hi Jerry-san,
Jerry Van Baren wrote:
I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
are located at 0, +0x10, +0x20, ..., .
16 byte stride. That is seriously odd.
Well, 8 or 16 byte stride is not so odd, IMHO.
I don't know much about precise hardware logics, but the
Shinya Kuribayashi wrote:
As for my hardware, however, this still doesn't work. My processor
(MIPS 4KEc) of couse supports byte read/write, on the other hand,
the address decoder at UART module can not handle byte addresses
properly; all byte read/write accesses with +1/+2/+3 offset, will
be
Detlev Zundel wrote:
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
are located at 0,
Shinya Kuribayashi wrote:
Detlev Zundel wrote:
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
I might be unclear. I used to use REG_SIZE = -16, as
Dear Shinya,
Detlev Zundel wrote:
Instead of special casing the different access patterns, use common
code with light macros sprinkled in to accomodate for the different
layouts of the register structure.
Note that this also changes the types of the registers for the
positively packed (1)
Detlev Zundel wrote:
To be honest, I did not expect such problems, as I saw no hints from
comments on why this code was needed. Thinking afresh, it now makes at
least some sense why the code was. It nevertheless was inconsistent, as
the word access was only done in an asymmetric way
Hello Shinya,
Detlev Zundel wrote:
To be honest, I did not expect such problems, as I saw no hints from
comments on why this code was needed. Thinking afresh, it now makes at
least some sense why the code was. It nevertheless was inconsistent, as
the word access was only done in an
Detlev-san,
Detlev Zundel wrote:
Instead of special casing the different access patterns, use common
code with light macros sprinkled in to accomodate for the different
layouts of the register structure.
Note that this also changes the types of the registers for the
positively packed (1)
Instead of special casing the different access patterns, use common
code with light macros sprinkled in to accomodate for the different
layouts of the register structure.
Note that this also changes the types of the registers for the
positively packed (1) cases. As the registers truly are
Detlev Zundel d...@denx.de writes:
Instead of special casing the different access patterns, use common
code with light macros sprinkled in to accomodate for the different
layouts of the register structure.
Note that this also changes the types of the registers for the
positively packed (1)
Dear Detlev Zundel,
In message 1238769946-30370-1-git-send-email-...@denx.de you wrote:
Instead of special casing the different access patterns, use common
code with light macros sprinkled in to accomodate for the different
layouts of the register structure.
Note that this also changes the
25 matches
Mail list logo
