headers
Derek Ou | 1 May 2009 01:10

Re: Disable features

Hi, Ben,

Ben Warren wrote:
> Do you have CONFIG_RESET_PHY_R defined?  It forces a call to eth_init(), 
> which most likely causes the delay you're seeing.  Try commenting it out 
> in your config file.
Yes, CONFIG_RESET_PHY_R is defined by default.  And I can see it linking to
the eth_init and then macb_init which results in the auto-negotiation.  
I am going to
comment it out and test it.  But what is the use for this config?  Why 
does ATMEL
define it in many of their boards?

Thanks,
Derek
Permalink | Reply | 4 comments |
headers
Anton Vorontsov | 1 May 2009 01:12

Re: [PATCH 1/8] Add simple hwconfig infrastructure

On Fri, May 01, 2009 at 12:31:54AM +0200, Wolfgang Denk wrote:
> Dear Anton,
> 
> In message <20090429215000.GA1092 <at> oksana.dev.rtsoft.ru> you wrote:
> > This patch implements simple hwconfig infrastructure: an
> > interface for software knobs to control a hardware.
> 
> Thanks a lot.
> 
> > 3. We support hwconfig options with arguments. For example,
> > 
> >    set hwconfig dr_usb,dr_usb_mode:peripheral,dr_usb_phy_type:ulpi
> > 
> >    There are three hwconfig options selected:
> >    1. dr_usb - enable Dual-Role USB controller;
> >    2. dr_usb_mode:peripheral - USB in Function mode;
> >    3. dr_usb_phy_type:ulpi - USB should work with ULPI PHYs.
> 
> That gives a lot of typing, which in turn results in lots of typing
> errors, which in this case are probably nasty to debug.
> 
> Suggestion: instead of
> 
> 	set hwconfig dr_usb,dr_usb_mode:peripheral,dr_usb_phy_type:ulpi
> 
> use:
> 
> 	set hwconfig dr_usb:mode=peripheral,phy_type=ulpi
> 
> What do you think?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Warren | 1 May 2009 02:22
Picon

Re: Disable features

Derek Ou wrote:
> Hi, Ben,
>
> Ben Warren wrote:
>> Do you have CONFIG_RESET_PHY_R defined?  It forces a call to 
>> eth_init(), which most likely causes the delay you're seeing.  Try 
>> commenting it out in your config file.
> Yes, CONFIG_RESET_PHY_R is defined by default.  And I can see it 
> linking to
> the eth_init and then macb_init which results in the 
> auto-negotiation.  I am going to
> comment it out and test it.  But what is the use for this config?  Why 
> does ATMEL
> define it in many of their boards?
>
Two good questions.  I don't know why, but seem to remember it coming up 
in this very forum.
> Thanks,
> Derek
regards,
Ben
Permalink | Reply | 0 comments |
headers
Shinya Kuribayashi | 1 May 2009 02:56
Picon
Favicon

Re: [PATCH] include/ns16550.h: Unify structure declaration for registers

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 postpad_rbr[12];
                                   15?
> ...
> 
> doesn't.  If we regard only the "significant" 8-bits, the first layout
> is congruent to the second shifted by 2 bytes (on big-endian machines).

I think you mean 'at offset 0x3', right?

My 16550 registers are like this:

        0    1    2    3
        +----+----+----+----+
0x00    |   reserved   |rbr |
        +----+----+----+----+
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Brownell | 1 May 2009 03:20

Re: [patch u-boot arm/next] davinci dm6446evm NAND update

On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> too long please split

Update below.

=== CUT HERE
From: David Brownell <dbrownell <at> users.sourceforge.net>

This updates the optional (non-default!) NAND support for the
DaVinci DM6446 EVM:

 - include MTD partitioning, defaulting to what Linux uses

 - use a flash-based BBT, which among other things speeds bootup

This matches code that's now queued for mainline Linux, and might
even merge in an upcoming 2.6.30-rc; and the MTIDS are set up so
that the U-Boot $mtdparts environment variable can be passed as-is
on the kernel command line as a cmdlinepart override.

Signed-off-by: David Brownell <dbrownell <at> users.sourceforge.net>
---
 include/configs/davinci_dvevm.h |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
 <at>  <at>  -119,6 +119,12  <at>  <at> 
 #ifdef CONFIG_SYS_NAND_SMALLPAGE
 #define CONFIG_ENV_SECT_SIZE	512	/* Env sector Size */
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brownell | 1 May 2009 03:23

Re: [patch u-boot git arm/next] davinci: display correct clock info

On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> cpu.c will be better

Here's a followup patch that applies on top of this one,
and creates the cpu.c you wanted.

=== CUT HERE
From: David Brownell <dbrownell <at> users.sourceforge.net>

Move the clock-rate dumping code into the cpu/.../davinci area
where it should have been, enabled by CONFIG_DISPLAY_CPUINFO,
updating the format and showing the DSP clock (where relevant).

Switch boards to use the cpuinfo() hook for this stuff.

Remove a few now-obsolete PLL #defines.

Signed-off-by: David Brownell <dbrownell <at> users.sourceforge.net>
---
 board/davinci/common/misc.c             |   89 --------------------
 board/davinci/common/misc.h             |    1 
 board/davinci/dvevm/dvevm.c             |    2 
 board/davinci/schmoogie/schmoogie.c     |    2 
 board/davinci/sffsdr/sffsdr.c           |    2 
 board/davinci/sonata/sonata.c           |    2 
 cpu/arm926ejs/davinci/Makefile          |    2 
 cpu/arm926ejs/davinci/cpu.c             |  131 ++++++++++++++++++++++++++++++
 include/asm-arm/arch-davinci/hardware.h |    5 -
 include/configs/davinci_dvevm.h         |    1 
 include/configs/davinci_schmoogie.h     |    1
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shinya Kuribayashi | 1 May 2009 03:59
Picon
Favicon

Re: [PATCH] include/ns16550.h: Unify structure declaration for registers

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,
>> more slid, easy to use, than what we used to have or what you
>> consolidated this time.
> 
> You lost me here.
> 
> You truly consider
> 
> 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 configurable" to be a good in its own?

Yes.

> If your answers to these questions are yes, then we have different ideas
> of writing code.

Please make sure we don't need full serial_{in,out} port from Linux
as-is.  As suggested, the combinations of base addres + reg_shift +
iotype, are rather reasonable to support various kind of hardwares.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Shinya Kuribayashi | 1 May 2009 04:21
Picon
Favicon

Re: [PATCH] include/ns16550.h: Unify structure declaration for registers

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 byte addresses
>>> under 16-bytes-border are ignored.  I'm using a big-endian mips machine.
>>
>> This does not make much sense to me, sorry.
> 
> The "16" of the "16-bytes-border" statement confuses me too.

Sorry for my poor vocabularies :-(

> It sounds like Shinya has some pretty odd (read "broken") hardware that 
> is decoding the registers with a 16 byte stride, although his example 
> above shows a 4 byte stride (less broken).

Let me reword:

* my UART registers are located with 16 byte stride.

* The address decoder in my UART block rounds +1/+2/+3 offsets down
  to zero offset.  Therefore we can't do byte read/write to ns16550
  registers properly; i.e. the return value of readb(x + 3) will be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shinya Kuribayashi | 1 May 2009 07:29
Picon
Favicon

Re: [PATCH] include/ns16550.h: Unify structure declaration for registers

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 round-down to +0.  Therefore, I can take 'offset +0x3' option.

Oops,                              s/can take/can not take/.

> This is the reasony I said 'my hardware requires 32-bit word access
> to NS16550 registers'.

  Shinya
Permalink | Reply | 0 comments |
headers
Dirk Behme | 1 May 2009 08:27

Re: OMAP3: Pending patches

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Dirk Behme,
> 
> In message <49F9F000.2060808 <at> googlemail.com> you wrote:
>> Short status update after recent ARM pull request
> 
> Thanks for keeping the summary up to date. This is really helpful in
> this complicated situation.
> 
> 
>>>> 1. OMAP3: Beagle: Set pinmux conditionally for Rev C boards
>>>> http://lists.denx.de/pipermail/u-boot/2009-April/051013.html
> ...
>> Applied to u-boot-arm next.
> 
> I cherry-picked it form there. It's in the master branch of the
> master repo now. [Well, give me 10 minutes until it makes it to the
> public server.]
> 
>>>> 2. OMAP3: Remove legacy NAND defines
>>>> http://lists.denx.de/pipermail/u-boot/2009-April/050882.html
>>> Applied to u-boot-arm next. Request to move to master by Wolfgang.
>> Copied to u-boot-arm master and part of above ARM pull request (still 
>> in u-boot-arm next, too?)
> 
> That should not matter. git will sort this out.
> 
>>>> 3. OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000
(Continue reading)

Permalink | Reply | 0 comments |

Gmane