nds32: Use getenv_ulong() in place of getenv(), strtoul

Add ARCH_DMA_MINALIGN definition to asm/cache.h

Signed-off-by Macpaul Lin <[email protected]>

---
?arch/nds32/include/asm/cache.h | ? 11 +++++++++++ ?1 files changed, 11 insertions(+), 0 deletions(-)

arch/nds32/include/asm/cache.h +0 -0

index d769196..fc22c7b 100644
@@ -51,4 +51,15 @@ DEFINE_GET_SYS_REG(DCM_CFG);

?#define DCM_CFG_OFF_DSZ ? ? ? ?6 ? ? ? /* D-cache line size */ ?#define DCM_CFG_MSK_DSZ ? ? ? ?(0x7UL << DCM_CFG_OFF_DSZ)

arch/nds32/include/asm/cache.h +11 -0

+/*
+ * The current upper bound for NDS32 L1 data cache line sizes is 32 bytes.
+ * We use that value for aligning DMA buffers unless the board config has
+ * specified an alternate cache line size.
+ */
+#ifdef CONFIG_SYS_CACHELINE_SIZE
+#define ARCH_DMA_MINALIGN ? ? ?CONFIG_SYS_CACHELINE_SIZE
+#else
+#define ARCH_DMA_MINALIGN ? ? ?32
+#endif
+

?#endif /* _ASM_CACHE_H */
--
1.7.3.5

Quoted 3 lines

Add ARCH_DMA_MINALIGN definition to asm/cache.h

Signed-off-by Macpaul Lin <[email protected]>

Acked-by Anton Staaf <[email protected]>

Since the NDS32 has been come into mainline.
Could I pick up this kind of simple changes of reviewed patches which are related to NDS32 only by myself,
and then send pull-request to you?
Hope this could reducing your loading and gain some benefits

you've got a maintainer tree now:

       http://git.denx.de/?p=u-boot/u-boot-nds32.git

so you should be gathering all the NDS32 patches and pushing to wolfgang. please see the documentation here for the process:
http://www.denx.de/wiki/U-Boot/DevelopmentProcess

short answer:
- fixes should get pushed at any time
- everything else should get pushed during merge window
-mike

Quoted 3 lines

Add ARCH_DMA_MINALIGN definition to asm/cache.h

Signed-off-by Macpaul Lin <[email protected]>

Acked-by Anton Staaf <[email protected]>

This patch add required __iormb and __iowmb to io.h. This also fix some misbehavior to periphal drivers.

This io.h has been fixed with referencing arm/include/asm/io.h.

Signed-off-by Macpaul Lin <[email protected]>

Hi,

can you possibly implement those as inline functions ? It'd be also great if you
could convert the other macros to inline functions.

Thanks!

2011/10/24 Marek Vasut <[email protected]>

Quoted 7 lines

Hi,

can you possibly implement those as inline functions ? It'd be also great if you could convert the other macros to inline functions.

Thanks!

Hi Marek,

Quoted 8 lines

2011/10/24 Marek Vasut <[email protected]>

Quoted 6 lines

Hi,

can you possibly implement those as inline functions ? It'd be also great if you could convert the other macros to inline functions.

Thanks!

I've found there are some different data type warning occur when I'm translating inline function
since all the driver originately call write and read marco.

Most of them is easy to deal with sicne the address is usually a 32-bit address "unsigned int *".
However, the driver/serial/ns16550.c used readb/writeb but the "address" passed in ns16550.c is
byte-wised (unsigned char *).

And there are also address casted in (ulong) in ns16550.c. serial_out(UART_LCR_BKSE | UART_LCRVAL, (ulong)&com_port->lcr); I'm not sure to fix this way would affect ns16550 in other architecutre?.
#define serial_out(x, y) writeb(x, (unsigned int *)y)

And there are also problems when translating readb from macro to inline function.

Some driver cannot be compiled with a return value inside the readb. I think I can post the fix of writeb for NDS32 architecture and see if you give some comments
then I do for other architecture later.

Hi Wolfgang,
Could you please pickup these 2 patches since it was independent to r/w inline functions?
I'm not sure if the merge windows has been closed.
Or should I pick these 2 patches into nds32 repo?

nds32: Use getenv_ulong() in place of getenv(), strtoul
http://patchwork.ozlabs.org/patch/121312/

nds32: cache: define ARCH_DMA_MINALIGN for DMA buffer alignment
http://patchwork.ozlabs.org/patch/121313/

Thanks!

Quoted 6 lines

Hi Marek,

And there are also address casted in (ulong) in ns16550.c. serial_out(UART_LCR_BKSE | UART_LCRVAL, (ulong)&com_port->lcr); I'm not sure to fix this way would affect ns16550 in other architecutre?. #define serial_out(x, y) ? ? ? writeb(x, (unsigned int *)y)

This is definitelly wrong. I'd like to see others comment on this one.

Quoted 3 lines

And there are also problems when translating readb from macro to inline function.

Why?

Hi Marek,

2011/10/25 Marek Vasut <[email protected]>:

[snip]

Please check ns16550.c, current code has another such kind of casting #ifdef CONFIG_SYS_NS16550_PORT_MAPPED
#define serial_out(x, y) outb(x, (ulong)y)
#define serial_in(y) inb((ulong)y)
[...]
#else
#define serial_out(x, y) writeb(x, y)
#define serial_in(y) readb(y)
#endif

Hi Graeme,

2011/10/25 ??? <[email protected]>:

Quoted 6 lines

Hi Marek,

2011/10/25 Marek Vasut <[email protected]>:

[snip]

Quoted 10 lines

Please check ns16550.c, current code has another such kind of casting #ifdef CONFIG_SYS_NS16550_PORT_MAPPED
#define serial_out(x, y) outb(x, (ulong)y)
#define serial_in(y) inb((ulong)y)
[...]
#else
#define serial_out(x, y) writeb(x, y)
#define serial_in(y) readb(y)
#endif

I'm going to change writeb/readb series functions from macro into inline functions.

However, I've found data type casting problem in NS16550. Only here the serial_out with CONFIG_SYS_NS16550_PORT_MAPPED is used for board "eNET".
Is this a necessary for this machine to access 8-bytes data?

Since inline functions are type sensitive,
I've suggest to replace the macro for other machines like writeb(x, (uint)y) but Marek think this is not good enough.
Could you give some comments?

Hi Macpaul

Quoted 2 lines

I'm going to change writeb/readb series functions from macro into inline functions.

For all arches? Have you seen /arch/x86/include/asm/io.h?

Quoted 1 line

Is this a necessary for this machine to access 8-bytes data?

outb/inb access 8-bit data in a 16-bit address space and the ns16650 has (for the x86 architecture at least) byte aligned registers

Quoted 4 lines

Since inline functions are type sensitive,
I've suggest to replace the macro for other machines like writeb(x, (uint)y) but Marek think this is not good enough.
Could you give some comments?

Hmm, but eNET (well, all x86 really) would not use writeb/readb - outb/inb would be used instead so if you are only touching the writeb/readb, eNET would never see this. So I don't understand where your type conflicts are occuring

Looking at the ulong cast, I was wondering why it was there, and the commit diff says I wrote it which is a bit of a worry :) x86 only has 65535 ports accessible via outb and inb, so I would have thought the case should have been a ushort, not a ulong.

I'm sorry, but without a patch to see what you are actually doing, I'm having a bit of difficulty picturing what is happening and what could be going wrong...

Hi Graeme,

? 2011?10?26???1:55?Graeme Russ <[email protected]> ???

Quoted 1 line

Hi Macpaul

[snip]

Quoted 4 lines

Quoted 2 lines

I'm going to change writeb/readb series functions from macro into inline functions.

For all arches? Have you seen /arch/x86/include/asm/io.h?

Currently, I have take a looked into arm, mips, and blackfin. Because the most probably common problem lead with the function replacement might be
NS16550, so I check NS16550 at first.

According to your reminding, it seem there is no necessary for x86 to replace the macro.
Is that correct?

However I have no idea is there any other architecture like x86.

Quoted 5 lines

Quoted 1 line

Is this a necessary for this machine to access 8-bytes data?

outb/inb access 8-bit data in a 16-bit address space and the ns16650 has (for the x86 architecture at least) byte aligned registers

Okay, so it's not actually an "ulong" casting.

Quoted 10 lines

Quoted 4 lines

Since inline functions are type sensitive,
I've suggest to replace the macro for other machines like writeb(x, (uint)y) but Marek think this is not good enough.
Could you give some comments?

Hmm, but eNET (well, all x86 really) would not use writeb/readb - outb/inb would be used instead so if you are only touching the writeb/readb, eNET would never see this. So I don't understand where your type conflicts are occuring

Because the the address passed into writeb and readb in ns16550.c will be "unsigned char" if they defined CONFIG_SYS_NS16550_REG_SIZE as "1" or "-4" and then
will lead compile warnings when the address of inline function of writeb/readb is "unsigned int".
(Please refer to include/ns16550.c)

Quoted 5 lines

Looking at the ulong cast, I was wondering why it was there, and the commit diff says I wrote it which is a bit of a worry :) x86 only has 65535 ports accessible via outb and inb, so I would have thought the case should have been a ushort, not a ulong.

Okay, so we can double confirmed it is an ushort not an ulong.

Quoted 4 lines

I'm sorry, but without a patch to see what you are actually doing, I'm having a bit of difficulty picturing what is happening and what could be going wrong...

Sorry not to add you at the beginning when the discussion begin. Because when I sent this patch, I thought it is only related to NDS32 arch at first.

For examples, the origin implementation in macro is this.
#define __arch_getb(a) (*(unsigned char *)(a))
#define __arch_putb(v, a) (*(unsigned char *)(a) = (v))

#define dmb()          __asm__ __volatile__ ("" : : : "memory")
#define __iormb()      dmb()
#define __iowmb()      dmb()

#define writeb(v, c) ({ u8 __v = v; __iowmb(); __arch_putb(__v, c); __v; })
#define readb(a) __arch_getb(a)

The new implementation in inline function will be like this.

static inline void writeb(unsigned char val, unsigned char *addr)

{
      __iowmb();
      __arch_putb(val, addr);
}
static inline unsigned char readb(unsigned char *addr)
{
       u8      val;

       val = __arch_getb(addr);
       __iormb();
       return val;
}

1. This patch add required __iormb and __iowmb to io.h. ? This also fix some misbehavior to periphal drivers.
? This io.h has been fixed with referencing arm/include/asm/io.h.
2. This patch replaced macro writeb and readb into inline function.

Signed-off-by Macpaul Lin <[email protected]>

---
Changes for v2:
?- translate writeb macro into inline function.

?arch/nds32/include/asm/io.h | ? 72 +++++++++++++++++++++++++++++++------------ ?1 files changed, 52 insertions(+), 20 deletions(-)

This changes the board code to use the new getenv_ulong() function.

Signed-off-by Macpaul Lin <[email protected]>

---
?arch/nds32/lib/board.c | ? 12 ++---------- ?1 files changed, 2 insertions(+), 10 deletions(-)