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 th
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 tha
Dear Detlev,
In message 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 do you ac
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 consi
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,
>>>
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
>
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
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 configu
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
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
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
Detlev Zundel 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, but I still
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 unc
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
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
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 re
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,
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
Hello Shinya,
>> If there's no good alternatives, I think reverting is a good idea
>> because there must be other platforms affected by this change.
I just checked again - the "problematic" cases can only be REG_SIZE 2
and 4:
[...@pollux u-boot-testing (master)]$ grep CONFIG_SYS_NS16550_REG_SIZE
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 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 regar
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
>> "positive
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
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 change
Detlev Zundel 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)" case
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 unsi
26 matches
Mail list logo
