Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-11 Thread Guennadi Liakhovetski
On Sat, 9 Aug 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:

  +
  +void dcache_disable (void)
  +{
  +   ulong reg;
  +
  +   reg = read_p15_c1 ();
  +   cp_delay ();
  +   reg = ~C1_DC;
  +   write_p15_c1 (reg);
 why not  as the other implementation?

ok

  +   /*printf(Calculated %lu timer_load_val\n, timer_load_val);*/
 please remove if not need

ok

 please add some empty line to be more readable
  +   /* load value for 10 ms timeout */
  +   lastdec = timers-TCNTB4 = timer_load_val;
  +   /* auto load, manual update of Timer 4 */
  +   timers-TCON = (timers-TCON  ~0x0070) | TCON_4_AUTO |
  +   TCON_4_UPDATE;
  +   /* auto load, start Timer 4 */
  +   timers-TCON = (timers-TCON  ~0x0070) | TCON_4_AUTO | COUNT_4_ON;
  +   timestamp = 0;

ok

  +static ulong get_PLLCLK(int pllreg)
 please not uppercase

These are s3c* common functions declared in include/common.h, chenging 
their declarations is outside of the scope of this patchset (see below)

  +   if (pllreg == APLL)
  +   r = APLL_CON_REG;
  +   else if (pllreg == MPLL)
  +   r = MPLL_CON_REG;
  +   else if (pllreg == EPLL)
  +   r = EPLL_CON0_REG;
  +   else
  +   hang();
 please move to switch implementation

ok

  +   printf(\nCPU: [EMAIL PROTECTED], get_ARMCLK() / 100);
  +   printf( Fclk = %luMHz, Hclk = %luMHz, Pclk = %luMHz ,
  +  get_FCLK() / 100, get_HCLK() / 100,
  +  get_PCLK() / 100);
 maybe a macro like HZ_TO_MHZ(x) could be helpfull to avoid typo

Don't think such metric conversions deserve a macro.

 please add space between parameter
  +   mrs r0,cpsr
  +   bic r0,r0,#0x3f
  +   orr r0,r0,#0xd3
  +   msr cpsr,r0

ok

  diff --git a/include/common.h b/include/common.h
  index 06ed278..ba87322 100644
  --- a/include/common.h
  +++ b/include/common.h
  @@ -491,7 +491,8 @@ int prt_mpc8220_clks (void);
   ulong  get_OPB_freq (void);
   ulong  get_PCI_freq (void);
   #endif
  -#if defined(CONFIG_S3C2400) || defined(CONFIG_S3C2410) || 
  defined(CONFIG_LH7A40X)
  +#if defined(CONFIG_S3C2400) || defined(CONFIG_S3C2410) || \
  +   defined(CONFIG_LH7A40X) || defined(CONFIG_S3C6400)
 Is it possible to have a better and simpler ifdef?

It is possible and desirable to remove these declarations

   void   s3c2410_irq(void);
   #define ARM920_IRQ_CALLBACK s3c2410_irq
   ulong  get_FCLK (void);

from this header completely. Don't understand what they are doing in 
include/common.h. However, this is outside of the scope of this patchset. 
Please, if you will be fixing this, do this after this patchset.

  +#define NFADDR (ELFIN_NAND_BASE+NFADDR_OFFSET)
  ^^^
 please remove whitesapce

ok

 btw on all macro please add space beetwen operator like
  +#define NFCONF_REG __REG(ELFIN_NAND_BASE+NFCONF_OFFSET)
 to
 #define NFCONF_REG__REG(ELFIN_NAND_BASE + NFCONF_OFFSET)

ok

  +#define Startup_AMDIV  400
 for macro I'll prefer upercase
  +#define Startup_MDIV   400
  +#define Startup_PDIV   6
  +#define Startup_SDIV   1

ok

  +typedef vu_charS3C64XX_REG8;
  +typedef vu_short   S3C64XX_REG16;
  +typedef vu_longS3C64XX_REG32;
 I'll prefer you use the type directly

ok

  +} /*__attribute__((__packed__))*/ s3c64xx_uart;
 why do you remove the packed attribute?

put it back. Makes no _practical_ difference in this case.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-09 Thread Jean-Christophe PLAGNIOL-VILLARD
 +
 +void dcache_disable (void)
 +{
 + ulong reg;
 +
 + reg = read_p15_c1 ();
 + cp_delay ();
 + reg = ~C1_DC;
 + write_p15_c1 (reg);
why not  as the other implementation?
 + write_p15_c1 (reg  ~C1_DC);
 +}
 +
 +int dcache_status (void)
 +{
 + return (read_p15_c1 ()  C1_DC) != 0;
 +}
 +
 +/* flush I/D-cache */
 +static void cache_flush (void)
 +{
 + /* invalidate both caches and flush btb */
 + asm (mcr p15, 0, %0, c7, c7, 0: :r (0));
 + /* mem barrier to sync things */
 + asm (mcr p15, 0, %0, c7, c10, 4: :r (0));
 +}
 +  * The timer is set to wrap after 100s, at 66MHz this obviously
 +  * happens after 10,000,000 ticks. A long variable can thus
 +  * keep values up to 40,000s, i.e., 11 hours. This should be
 +  * enough for most uses:-) Possible optimizations: select a
 +  * binary-friendly frequency, e.g., 1ms / 128. Also calculate
 +  * the prescaler automatically for other PCLK frequencies.
 +  */
 + /* Set timer frequency to 500KHz, at 66MHz we get prescaler=132  255 */
 + timers-TCFG0 = PRESCALER  8;
 + if (timer_load_val == 0) {
 + /*
 +  * for 10 ms clock period @ PCLK with 4 bit divider = 1/2 and
 +  * prescaler = 16. Should be 10390 @33.25MHz and 15625 @ 50 MHz
 +  */
 + timer_load_val = get_PCLK() / PRESCALER * (100 / 4); /* 100s */
 + /*printf(Calculated %lu timer_load_val\n, timer_load_val);*/
please remove if not need
 + timers-TCFG1 = (timers-TCFG1  ~0xf) | 0x2;
 + }
 +
please add some empty line to be more readable
 + /* load value for 10 ms timeout */
 + lastdec = timers-TCNTB4 = timer_load_val;
 + /* auto load, manual update of Timer 4 */
 + timers-TCON = (timers-TCON  ~0x0070) | TCON_4_AUTO |
 + TCON_4_UPDATE;
 + /* auto load, start Timer 4 */
 + timers-TCON = (timers-TCON  ~0x0070) | TCON_4_AUTO | COUNT_4_ON;
 + timestamp = 0;
 +
 + return 0;
 +}
 +
 +/*
 + * timer without interrupts
 + */
 +
 +/*
 + * This function is derived from PowerPC code (read timebase as long long).
 + * On ARM it just returns the timer value.
 + */
 +unsigned long long get_ticks(void)
 +{
 + ulong now = read_timer();
 +
 + if (lastdec = now) {
 + /* normal mode */
 +#define MPLL 1
 +#define EPLL 2
 +
 +/* - 
 */
 +/*
 + * NOTE: This describes the proper use of this file.
 + *
 + * CONFIG_SYS_CLK_FREQ should be defined as the input frequency of the PLL.
 + *
 + * get_FCLK(), get_HCLK(), get_PCLK() and get_UCLK() return the clock of
 + * the specified bus in HZ.
 + */
 +/* - 
 */
 +
 +static ulong get_PLLCLK(int pllreg)
please not uppercase
 +{
 + ulong r, m, p, s;
 +
 + if (pllreg == APLL)
 + r = APLL_CON_REG;
 + else if (pllreg == MPLL)
 + r = MPLL_CON_REG;
 + else if (pllreg == EPLL)
 + r = EPLL_CON0_REG;
 + else
 + hang();
please move to switch implementation
 +
 + m = (r  16)  0x3ff;
 + p = (r  8)  0x3f;
 + s = r  0x7;
 +
 + return m * (CONFIG_SYS_CLK_FREQ / (p * (1  s)));
 +}
 +
 +/* return ARMCORE frequency */
 +ulong get_ARMCLK(void)
please not uppercase
 +{
 + ulong div;
 +
 + div = CLK_DIV0_REG;
 +
 + return get_PLLCLK(APLL) / ((div  0x7) + 1);
 +}
 +
 +/* return FCLK frequency */
 +ulong get_FCLK(void)
please not uppercase
 +{
 + return get_PLLCLK(APLL);
 +}
 +
 +/* return HCLK frequency */
 +ulong get_HCLK(void)
please not uppercase
 +{
 + ulong fclk;
 +
 + uint hclkx2_div = ((CLK_DIV0_REG  9)  0x7) + 1;
 + uint hclk_div = ((CLK_DIV0_REG  8)  0x1) + 1;
 +
 + /*
 +  * Bit 7 exists on s3c6410, and not on s3c6400, it is reserved on
 +  * s3c6400 and is always 0, and it is indeed running in ASYNC mode
 +  */
 + if (OTHERS_REG  0x80)
 + fclk = get_FCLK();  /* SYNC Mode*/
 + else
 + fclk = get_PLLCLK(MPLL);/* ASYNC Mode   */
 +
 + return fclk / (hclk_div * hclkx2_div);
 +}
 +
 +/* return PCLK frequency */
 +ulong get_PCLK(void)
please not uppercase
 +{
 + ulong fclk;
 + uint hclkx2_div = ((CLK_DIV0_REG  9)  0x7) + 1;
 + uint pre_div = ((CLK_DIV0_REG  12)  0xf) + 1;
 +
 + if (OTHERS_REG  0x80)
 + fclk = get_FCLK();  /* SYNC Mode*/
 + else
 + fclk = get_PLLCLK(MPLL);/* ASYNC Mode   */
 +
 + return fclk / (hclkx2_div * pre_div);
 +}
 +
 +/* return UCLK frequency */
 +ulong get_UCLK(void)
please not uppercase
 +{
 + return get_PLLCLK(EPLL);
 +}
 +
 +int print_cpuinfo(void)
 +{
 + printf(\nCPU: [EMAIL PROTECTED], get_ARMCLK() / 100);
 + printf( Fclk = %luMHz, Hclk = %luMHz, Pclk = %luMHz ,
 +get_FCLK() / 100, get_HCLK() / 

Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Andreas Engel
 diff --git a/cpu/arm1176/s3c64xx/interrupts.c 
 b/cpu/arm1176/s3c64xx/interrupts.c
 new file mode 100644
 index 000..4233e8c
 --- /dev/null
 +++ b/cpu/arm1176/s3c64xx/interrupts.c

You can remove anything from enable_interrupts() to do_irq() here. It's
already in lib_arm/interrupts.c.

Andreas

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Guennadi Liakhovetski
On Thu, 7 Aug 2008, Andreas Engel wrote:

  diff --git a/cpu/arm1176/s3c64xx/interrupts.c 
  b/cpu/arm1176/s3c64xx/interrupts.c
  new file mode 100644
  index 000..4233e8c
  --- /dev/null
  +++ b/cpu/arm1176/s3c64xx/interrupts.c
 
 You can remove anything from enable_interrupts() to do_irq() here. It's
 already in lib_arm/interrupts.c.

It must be the library-linking procedure, that prevented the linker from 
complaining about duplicate symbols... Yes, will remove them, thanks. Just 
let's wait a bit if there are more comments.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Jens Gehrlein
Guennadi Liakhovetski schrieb:
 Based on the original S3C64XX port by Samsung for U-Boot 1.1.6.
 
 Signed-off-by: Guennadi Liakhovetski [EMAIL PROTECTED]
 ---
  cpu/arm1176/Makefile|   50 ++
  cpu/arm1176/config.mk   |   35 ++
  cpu/arm1176/cpu.c   |  189 +++
  cpu/arm1176/s3c64xx/Makefile|   48 ++
  cpu/arm1176/s3c64xx/config.mk   |   34 ++
  cpu/arm1176/s3c64xx/cpu_init.S  |  142 +
  cpu/arm1176/s3c64xx/interrupts.c|  280 ++
  cpu/arm1176/s3c64xx/speed.c |  140 +
  cpu/arm1176/start.S |  469 
  include/asm-arm/arch-s3c64xx/hardware.h |   63 +++
  include/common.h|3 +-
  include/s3c6400.h   |  884 
 +++
  include/s3c64x0.h   |   92 

Is it intended to put the CPU specific header files directly into the 
include directory (s3c6400.h and s3c64x0.h)?

Kind regards,
Jens

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Wolfgang Denk
In message [EMAIL PROTECTED] you wrote:

 Is it intended to put the CPU specific header files directly into the 
 include directory (s3c6400.h and s3c64x0.h)?

That's what we've been doing so far:

- ls -l include/s3c*
-rw-rw-r-- 1 wd wd 21763 Dec  9  2007 include/s3c2400.h
-rw-rw-r-- 1 wd wd  7629 Dec  9  2007 include/s3c2410.h
-rw-rw-r-- 1 wd wd 38129 Oct 13  2007 include/s3c24x0.h


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
We are all agreed that your  theory  is  crazy.  The  question  which
divides  us  is  whether it is crazy enough to have a chance of being
correct. My own feeling is that it is not crazy enough.  - Niels Bohr

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Jens Gehrlein
Hi Guennadi,

Guennadi Liakhovetski schrieb:

 diff --git a/cpu/arm1176/s3c64xx/interrupts.c 
 b/cpu/arm1176/s3c64xx/interrupts.c
[snip]
 +void udelay(unsigned long usec)
 +{
 + unsigned long long tmp;
 + ulong tmo;
 +
 + tmo = (usec + 9) / 10;
 + tmp = get_ticks() + tmo;/* get current timestamp */
 +
 + while (get_ticks()  tmp)/* loop till event */
 +  /*NOP*/;
 +}

I tried to follow the interrupt init function, but it's difficult.
What is the least possible delay with the udelay function?
I remember that i.mx31 udelay cannot currently be below 30 microsseconds 
due to the low input clock. If someone uses udelay(1) in polling loops 
with timeout, the actual duration is much more longer than assumed.

Kind regards,
Jens

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Jens Gehrlein
Wolfgang Denk schrieb:
 In message [EMAIL PROTECTED] you wrote:
 Is it intended to put the CPU specific header files directly into the 
 include directory (s3c6400.h and s3c64x0.h)?
 
 That's what we've been doing so far:
 
   - ls -l include/s3c*
   -rw-rw-r-- 1 wd wd 21763 Dec  9  2007 include/s3c2400.h
   -rw-rw-r-- 1 wd wd  7629 Dec  9  2007 include/s3c2410.h
   -rw-rw-r-- 1 wd wd 38129 Oct 13  2007 include/s3c24x0.h

Sorry, don't understand. So is it okay, that these files reside in the 
include directory or not?

-- 
Kind regards,
Jens

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Guennadi Liakhovetski
On Thu, 7 Aug 2008, Jens Gehrlein wrote:

 Hi Guennadi,
 
 Guennadi Liakhovetski schrieb:
 
  diff --git a/cpu/arm1176/s3c64xx/interrupts.c
  b/cpu/arm1176/s3c64xx/interrupts.c
 [snip]
  +void udelay(unsigned long usec)
  +{
  +   unsigned long long tmp;
  +   ulong tmo;
  +
  +   tmo = (usec + 9) / 10;
  +   tmp = get_ticks() + tmo;/* get current timestamp */
  +
  +   while (get_ticks()  tmp)/* loop till event */
  +/*NOP*/;
  +}
 
 I tried to follow the interrupt init function, but it's difficult.
 What is the least possible delay with the udelay function?
 I remember that i.mx31 udelay cannot currently be below 30 microsseconds due
 to the low input clock. If someone uses udelay(1) in polling loops with
 timeout, the actual duration is much more longer than assumed.

Actually, the / 10 and this comment

/*
 * We use the following scheme for the timer:
 * Prescaler is hard fixed at 167, divider at 1/4.
 * This gives at PCLK frequency 66MHz approx. 10us ticks
 * The timer is set to wrap after 100s, at 66MHz this obviously
 * happens after 10,000,000 ticks. A long variable can thus
 * keep values up to 40,000s, i.e., 11 hours. This should be
 * enough for most uses:-) Possible optimizations: select a
 * binary-friendly frequency, e.g., 1ms / 128. Also calculate
 * the prescaler automatically for other PCLK frequencies.
 */

shall make it clear, that the timer resolution is configured to 10us, 
which is also the minimum udelay. The timer could also do better, but then 
we get other disadvantages, e.g., shorter wrap-around time.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: [EMAIL PROTECTED]

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Wolfgang Denk
In message [EMAIL PROTECTED] you wrote:

  That's what we've been doing so far:
  
  - ls -l include/s3c*
  -rw-rw-r-- 1 wd wd 21763 Dec  9  2007 include/s3c2400.h
  -rw-rw-r-- 1 wd wd  7629 Dec  9  2007 include/s3c2410.h
  -rw-rw-r-- 1 wd wd 38129 Oct 13  2007 include/s3c24x0.h
 
 Sorry, don't understand. So is it okay, that these files reside in the 
 include directory or not?

Unless you want to submit a clenaup patch for many existing
processors, yes.

What is your suggestion instead?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Data is a lot like humans: It is  born.  Matures.  Gets  married  to
other  data, divorced. Gets old. One thing that it doesn't do is die.
It has to be killed. - Arthur Miller

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Jens Gehrlein
Wolfgang Denk schrieb:
 In message [EMAIL PROTECTED] you wrote:
 That's what we've been doing so far:

 - ls -l include/s3c*
 -rw-rw-r-- 1 wd wd 21763 Dec  9  2007 include/s3c2400.h
 -rw-rw-r-- 1 wd wd  7629 Dec  9  2007 include/s3c2410.h
 -rw-rw-r-- 1 wd wd 38129 Oct 13  2007 include/s3c24x0.h
 Sorry, don't understand. So is it okay, that these files reside in the 
 include directory or not?
 
 Unless you want to submit a clenaup patch for many existing
 processors, yes.
 
 What is your suggestion instead?

It was just a question to read your opinion. Personally, I can live with 
it. I thought, CPU specific header files had to go to the 
include/asm-arch/arch-cpu directory.

Sorry for the noise.

Kind regards,
Jens

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Jens Gehrlein
Hi Guennadi,

Guennadi Liakhovetski schrieb:
 On Thu, 7 Aug 2008, Jens Gehrlein wrote:
 
 Hi Guennadi,

 Guennadi Liakhovetski schrieb:

 diff --git a/cpu/arm1176/s3c64xx/interrupts.c
 b/cpu/arm1176/s3c64xx/interrupts.c
 [snip]
 +void udelay(unsigned long usec)
 +{
 +   unsigned long long tmp;
 +   ulong tmo;
 +
 +   tmo = (usec + 9) / 10;
 +   tmp = get_ticks() + tmo;/* get current timestamp */
 +
 +   while (get_ticks()  tmp)/* loop till event */
 +/*NOP*/;
 +}
 I tried to follow the interrupt init function, but it's difficult.
 What is the least possible delay with the udelay function?
 I remember that i.mx31 udelay cannot currently be below 30 microsseconds due
 to the low input clock. If someone uses udelay(1) in polling loops with
 timeout, the actual duration is much more longer than assumed.
 
 Actually, the / 10 and this comment
 
   /*
* We use the following scheme for the timer:
* Prescaler is hard fixed at 167, divider at 1/4.
* This gives at PCLK frequency 66MHz approx. 10us ticks
* The timer is set to wrap after 100s, at 66MHz this obviously
* happens after 10,000,000 ticks. A long variable can thus
* keep values up to 40,000s, i.e., 11 hours. This should be
* enough for most uses:-) Possible optimizations: select a
* binary-friendly frequency, e.g., 1ms / 128. Also calculate
* the prescaler automatically for other PCLK frequencies.
*/
 
 shall make it clear, that the timer resolution is configured to 10us, 
 which is also the minimum udelay. The timer could also do better, but then 
 we get other disadvantages, e.g., shorter wrap-around time.

Okay. Thank you.
I think, it's very useful for a developer to know the limits of high 
resolution timers and to see it immediately, so he can consider it in 
his code.

Kind regards,
Jens

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


Re: [U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

2008-08-07 Thread Jean-Christophe PLAGNIOL-VILLARD
On 13:03 Thu 07 Aug , Jens Gehrlein wrote:
 Wolfgang Denk schrieb:
  In message [EMAIL PROTECTED] you wrote:
  That's what we've been doing so far:
 
- ls -l include/s3c*
-rw-rw-r-- 1 wd wd 21763 Dec  9  2007 include/s3c2400.h
-rw-rw-r-- 1 wd wd  7629 Dec  9  2007 include/s3c2410.h
-rw-rw-r-- 1 wd wd 38129 Oct 13  2007 include/s3c24x0.h
  Sorry, don't understand. So is it okay, that these files reside in the 
  include directory or not?
  
  Unless you want to submit a clenaup patch for many existing
  processors, yes.
  
  What is your suggestion instead?
 
 It was just a question to read your opinion. Personally, I can live with 
 it. I thought, CPU specific header files had to go to the 
 include/asm-arch/arch-cpu directory.

Currently the kernel start move to move it to
include/arch/asm

I'll prefer to use this

Best Regards,
J.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users