Microblaze fixes for revision

Microblaze fixes for revision

[monstr]

Hi All,

here are some patches which fixed some minor things.

There are some categories of patches:
1. Enable some driver for Microblaze - 0011
2. Clean code - 0001, 0003
3. Fix real issue - 0002
4. Do minor changes for future MMU merge - 0004, 0005, 0009
5. Fix sparse errors - 0006, 0007
6. Optional changes - 0008, 0010

All changes are simple and easy to review.

Thanks,
Michal

[PATCH 01/11] microblaze: Remove unneded per cpu SYSCALL_SAVE variable

[monstr]

From: Michal Simek <monstr@monstr.eu>

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/include/asm/entry.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/microblaze/include/asm/entry.h b/arch/microblaze/include/asm/entry.h
index 7f57e42..1019d88 100644
--- a/arch/microblaze/include/asm/entry.h
+++ b/arch/microblaze/include/asm/entry.h
@@ -29,7 +29,6 @@ DECLARE_PER_CPU(unsigned int, KM); /* Kernel/user mode */
 DECLARE_PER_CPU(unsigned int, ENTRY_SP); /* Saved SP on kernel entry */
 DECLARE_PER_CPU(unsigned int, R11_SAVE); /* Temp variable for entry */
 DECLARE_PER_CPU(unsigned int, CURRENT_SAVE); /* Saved current pointer */
-DECLARE_PER_CPU(unsigned int, SYSCALL_SAVE); /* Saved syscall number */
 # endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_MICROBLAZE_ENTRY_H */
-- 
1.5.5.1

[PATCH 02/11] microblaze: Remove while(1) loop from show_regs function

[monstr]

From: Michal Simek <monstr@monstr.eu>

I removed it because of show_regs can't break die function.
If process/kernel failed, die (do_exit) function resolve it.

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/kernel/process.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index 436f26c..bdc8b2c 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -37,8 +37,6 @@ void show_regs(struct pt_regs *regs)
 				regs->r29, regs->r30, regs->r31, regs->pc);
 	printk(KERN_INFO " msr=%08lX, ear=%08lX, esr=%08lX, fsr=%08lX\n",
 				regs->msr, regs->ear, regs->esr, regs->fsr);
-	while (1)
-		;
 }
 
 void (*pm_idle)(void);
-- 
1.5.5.1

Re: [microblaze-uclinux] [PATCH 02/11] microblaze: Remove while(1) loop from show_regs function

[John Williams]

On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> I removed it because of show_regs can't break die function.
> If process/kernel failed, die (do_exit) function resolve it.

ACK

-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

[PATCH 03/11] microblaze: Remove uncache shadow condition

[monstr]

From: Michal Simek <monstr@monstr.eu>

Uncached shadow feature is not supported in current
kernel code that's why I removed it.

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/include/asm/cache.h |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/arch/microblaze/include/asm/cache.h b/arch/microblaze/include/asm/cache.h
index c4c64b4..c209c47 100644
--- a/arch/microblaze/include/asm/cache.h
+++ b/arch/microblaze/include/asm/cache.h
@@ -37,9 +37,4 @@ void _invalidate_dcache(unsigned int addr);
 #define __disable_dcache()		_disable_dcache()
 #define __invalidate_dcache(addr)	_invalidate_dcache(addr)
 
-/* FIXME - I don't think this is right */
-#ifdef CONFIG_XILINX_UNCACHED_SHADOW
-#define UNCACHED_SHADOW_MASK (CONFIG_XILINX_ERAM_SIZE)
-#endif
-
 #endif /* _ASM_MICROBLAZE_CACHE_H */
-- 
1.5.5.1

[PATCH 04/11] microblaze: Rename kernel_mode to pt_mode in pt_regs

[monstr]

From: Michal Simek <monstr@monstr.eu>

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/include/asm/processor.h |    2 +-
 arch/microblaze/include/asm/ptrace.h    |    4 ++--
 arch/microblaze/kernel/asm-offsets.c    |    2 +-
 arch/microblaze/kernel/process.c        |    4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/microblaze/include/asm/processor.h b/arch/microblaze/include/asm/processor.h
index d8e1543..4bed76d 100644
--- a/arch/microblaze/include/asm/processor.h
+++ b/arch/microblaze/include/asm/processor.h
@@ -62,7 +62,7 @@ static inline void start_thread(struct pt_regs *regs,
 {
 	regs->pc = pc;
 	regs->r1 = usp;
-	regs->kernel_mode = 0;
+	regs->pt_mode = 0;
 }
 
 /* Free all resources held by a thread. */
diff --git a/arch/microblaze/include/asm/ptrace.h b/arch/microblaze/include/asm/ptrace.h
index f1f0348..55015bc 100644
--- a/arch/microblaze/include/asm/ptrace.h
+++ b/arch/microblaze/include/asm/ptrace.h
@@ -52,10 +52,10 @@ struct pt_regs {
 	microblaze_reg_t ear;
 	microblaze_reg_t esr;
 	microblaze_reg_t fsr;
-	int kernel_mode;
+	int pt_mode;
 };
 
-#define kernel_mode(regs)		((regs)->kernel_mode)
+#define kernel_mode(regs)		((regs)->pt_mode)
 #define user_mode(regs)			(!kernel_mode(regs))
 
 #define instruction_pointer(regs)	((regs)->pc)
diff --git a/arch/microblaze/kernel/asm-offsets.c b/arch/microblaze/kernel/asm-offsets.c
index 38e1a2e..aabd9e9 100644
--- a/arch/microblaze/kernel/asm-offsets.c
+++ b/arch/microblaze/kernel/asm-offsets.c
@@ -57,7 +57,7 @@ int main(int argc, char *argv[])
 	DEFINE(PT_R29, offsetof(struct pt_regs, r29));
 	DEFINE(PT_R30, offsetof(struct pt_regs, r30));
 	DEFINE(PT_R31, offsetof(struct pt_regs, r31));
-	DEFINE(PT_MODE, offsetof(struct pt_regs, kernel_mode));
+	DEFINE(PT_MODE, offsetof(struct pt_regs, pt_mode));
 	BLANK();
 
 	/* Magic offsets for PTRACE PEEK/POKE etc */
diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index bdc8b2c..40cc148 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -18,7 +18,7 @@
 
 void show_regs(struct pt_regs *regs)
 {
-	printk(KERN_INFO " Registers dump: mode=%X\r\n", regs->kernel_mode);
+	printk(KERN_INFO " Registers dump: mode=%X\r\n", regs->pt_mode);
 	printk(KERN_INFO " r1=%08lX, r2=%08lX, r3=%08lX, r4=%08lX\n",
 				regs->r1, regs->r2, regs->r3, regs->r4);
 	printk(KERN_INFO " r5=%08lX, r6=%08lX, r7=%08lX, r8=%08lX\n",
@@ -169,7 +169,7 @@ int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 	regs.r6 = (unsigned long)arg;
 	local_save_flags(regs.msr);
 	regs.pc = (unsigned long)kernel_thread_helper;
-	regs.kernel_mode = 1;
+	regs.pt_mode = 1;
 
 	ret = do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0,
 			&regs, 0, NULL, NULL);
-- 
1.5.5.1

[PATCH 05/11] microblaze: Move task_pt_regs up

[monstr]

From: Michal Simek <monstr@monstr.eu>

This change is important for easier merge with Microblaze MMU code.

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/include/asm/processor.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/microblaze/include/asm/processor.h b/arch/microblaze/include/asm/processor.h
index 4bed76d..cea42a3 100644
--- a/arch/microblaze/include/asm/processor.h
+++ b/arch/microblaze/include/asm/processor.h
@@ -26,6 +26,9 @@ extern const struct seq_operations cpuinfo_op;
 
 # endif /* __ASSEMBLY__ */
 
+#define task_pt_regs(tsk) \
+		(((struct pt_regs *)(THREAD_SIZE + task_stack_page(tsk))) - 1)
+
 /*
  * User space process size: memory size
  *
@@ -84,9 +87,6 @@ extern unsigned long get_wchan(struct task_struct *p);
  */
 extern int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags);
 
-# define task_pt_regs(tsk) \
-		(((struct pt_regs *)(THREAD_SIZE + task_stack_page(tsk))) - 1)
-
 # define KSTK_EIP(tsk)	(0)
 # define KSTK_ESP(tsk)	(0)
 
-- 
1.5.5.1

[PATCH 06/11] microblaze: Remove sparse error in traps.c

[monstr]

From: Michal Simek <monstr@monstr.eu>

CHECK   arch/microblaze/kernel/traps.c
arch/microblaze/kernel/traps.c:37:47: warning: Using plain integer as NULL pointer
CC      arch/microblaze/kernel/traps.o

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/kernel/traps.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
index fbdc533..293ef48 100644
--- a/arch/microblaze/kernel/traps.c
+++ b/arch/microblaze/kernel/traps.c
@@ -34,7 +34,7 @@ static int kstack_depth_to_print = 24;
 
 static int __init kstack_setup(char *s)
 {
-	kstack_depth_to_print = strict_strtoul(s, 0, 0);
+	kstack_depth_to_print = strict_strtoul(s, 0, NULL);
 
 	return 1;
 }
-- 
1.5.5.1

Re: [microblaze-uclinux] [PATCH 06/11] microblaze: Remove sparse error in traps.c

[John Williams]

On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> CHECK   arch/microblaze/kernel/traps.c
> arch/microblaze/kernel/traps.c:37:47: warning: Using plain integer as NULL pointer
> CC      arch/microblaze/kernel/traps.o
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>

ACK

[PATCH 07/11] microblaze: Add missing declaration for die and _exception func

[monstr]

From: Michal Simek <monstr@monstr.eu>

This change remove sparse errors.

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/include/asm/exceptions.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/microblaze/include/asm/exceptions.h b/arch/microblaze/include/asm/exceptions.h
index 4cdd215..24ca540 100644
--- a/arch/microblaze/include/asm/exceptions.h
+++ b/arch/microblaze/include/asm/exceptions.h
@@ -61,6 +61,9 @@
 asmlinkage void full_exception(struct pt_regs *regs, unsigned int type,
 							int fsr, int addr);
 
+void die(const char *str, struct pt_regs *fp, long err);
+void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr);
+
 #if defined(CONFIG_XMON)
 extern void xmon(struct pt_regs *regs);
 extern int xmon_bpt(struct pt_regs *regs);
-- 
1.5.5.1

Re: [microblaze-uclinux] [PATCH 07/11] microblaze: Add missing declaration for die and _exception func

[John Williams]

On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:

> This change remove sparse errors.
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>

ACK

[PATCH 08/11] microblaze: Add missing preadv and pwritev syscalls

[monstr]

From: Michal Simek <monstr@monstr.eu>

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/include/asm/unistd.h   |    4 +++-
 arch/microblaze/kernel/syscall_table.S |    2 ++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/microblaze/include/asm/unistd.h b/arch/microblaze/include/asm/unistd.h
index d9d3903..b5e2f5f 100644
--- a/arch/microblaze/include/asm/unistd.h
+++ b/arch/microblaze/include/asm/unistd.h
@@ -378,8 +378,10 @@
 #define __NR_sendmsg		360 /* new */
 #define __NR_recvmsg		361 /* new */
 #define __NR_accept04		362 /* new */
+#define __NR_preadv		363 /* new */
+#define __NR_pwritev		364 /* new */
 
-#define __NR_syscalls		363
+#define __NR_syscalls		365
 
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
diff --git a/arch/microblaze/kernel/syscall_table.S b/arch/microblaze/kernel/syscall_table.S
index 529b0db..3bb42ec 100644
--- a/arch/microblaze/kernel/syscall_table.S
+++ b/arch/microblaze/kernel/syscall_table.S
@@ -363,3 +363,5 @@ ENTRY(sys_call_table)
 	.long sys_sendmsg		/* 360 */
 	.long sys_recvmsg
 	.long sys_ni_syscall
+	.long sys_ni_syscall
+	.long sys_ni_syscall
-- 
1.5.5.1

Re: [microblaze-uclinux] [PATCH 08/11] microblaze: Add missing preadv and pwritev syscalls

[John Williams]

On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>

ACK

[PATCH 09/11] microblaze: Move start_thread to process.c

[monstr]

From: Michal Simek <monstr@monstr.eu>

This change is due to upcomming MMU merge

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/include/asm/processor.h |   13 +++----------
 arch/microblaze/kernel/process.c        |    9 +++++++++
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/microblaze/include/asm/processor.h b/arch/microblaze/include/asm/processor.h
index cea42a3..89aa395 100644
--- a/arch/microblaze/include/asm/processor.h
+++ b/arch/microblaze/include/asm/processor.h
@@ -29,6 +29,9 @@ extern const struct seq_operations cpuinfo_op;
 #define task_pt_regs(tsk) \
 		(((struct pt_regs *)(THREAD_SIZE + task_stack_page(tsk))) - 1)
 
+/* Do necessary setup to start up a newly executed thread. */
+void start_thread(struct pt_regs *regs, unsigned long pc, unsigned long usp);
+
 /*
  * User space process size: memory size
  *
@@ -58,16 +61,6 @@ struct task_struct;
 struct thread_struct { };
 # define INIT_THREAD	{ }
 
-/* Do necessary setup to start up a newly executed thread. */
-static inline void start_thread(struct pt_regs *regs,
-				unsigned long pc,
-				unsigned long usp)
-{
-	regs->pc = pc;
-	regs->r1 = usp;
-	regs->pt_mode = 0;
-}
-
 /* Free all resources held by a thread. */
 static inline void release_thread(struct task_struct *dead_task)
 {
diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index 40cc148..dd15de9 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -182,3 +182,12 @@ unsigned long get_wchan(struct task_struct *p)
 /* TBD (used by procfs) */
 	return 0;
 }
+
+/* Set up a thread for executing a new program */
+void start_thread(struct pt_regs *regs, unsigned long pc, unsigned long usp)
+{
+	set_fs(USER_DS);
+	regs->pc = pc;
+	regs->r1 = usp;
+	regs->pt_mode = 0;
+}
-- 
1.5.5.1

Re: [microblaze-uclinux] [PATCH 09/11] microblaze: Move start_thread to process.c

[John Williams]

On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> This change is due to upcomming MMU merge
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>

ACK

[PATCH 10/11] microblaze: Remove redundant variable

[monstr]

From: Michal Simek <monstr@monstr.eu>

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 arch/microblaze/kernel/process.c |    5 +----
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/microblaze/kernel/process.c b/arch/microblaze/kernel/process.c
index dd15de9..07d4fa3 100644
--- a/arch/microblaze/kernel/process.c
+++ b/arch/microblaze/kernel/process.c
@@ -161,7 +161,6 @@ static void kernel_thread_helper(int (*fn)(void *), void *arg)
 int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 	struct pt_regs regs;
-	int ret;
 
 	memset(&regs, 0, sizeof(regs));
 	/* store them in non-volatile registers */
@@ -171,10 +170,8 @@ int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
 	regs.pc = (unsigned long)kernel_thread_helper;
 	regs.pt_mode = 1;
 
-	ret = do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0,
+	return do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0,
 			&regs, 0, NULL, NULL);
-
-	return ret;
 }
 
 unsigned long get_wchan(struct task_struct *p)
-- 
1.5.5.1

Re: [microblaze-uclinux] [PATCH 10/11] microblaze: Remove redundant variable

[John Williams]

On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>

ACK

[PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[monstr]

From: Michal Simek <monstr@monstr.eu>

Signed-off-by: Michal Simek <monstr@monstr.eu>
---
 drivers/block/Kconfig |    2 +-
 drivers/char/Kconfig  |    2 +-
 drivers/gpio/Kconfig  |    2 +-
 drivers/usb/Kconfig   |    1 +
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index ddea8e4..9f1665f 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
 
 config XILINX_SYSACE
 	tristate "Xilinx SystemACE support"
-	depends on 4xx
+	depends on 4xx || MICROBLAZE
 	help
 	  Include support for the Xilinx SystemACE CompactFlash interface
 
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 735bbe2..bb1a071 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -893,7 +893,7 @@ config DTLK
 
 config XILINX_HWICAP
 	tristate "Xilinx HWICAP Support"
-	depends on XILINX_VIRTEX
+	depends on XILINX_VIRTEX || MICROBLAZE
 	help
 	  This option enables support for Xilinx Internal Configuration
 	  Access Port (ICAP) driver.  The ICAP is used on Xilinx Virtex
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index edb0253..11f3739 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
 
 config GPIO_XILINX
 	bool "Xilinx GPIO support"
-	depends on PPC_OF
+	depends on PPC_OF || MICROBLAZE
 	help
 	  Say yes here to support the Xilinx FPGA GPIO device
 
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index c6c816b..5eee3f8 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
 	default y if PCMCIA && !M32R			# sl811_cs
 	default y if ARM				# SL-811
 	default y if SUPERH				# r8a66597-hcd
+	default y if MICROBLAZE
 	default PCI
 
 # many non-PCI SOC chips embed OHCI
-- 
1.5.5.1

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Williams]

On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>

ACK from a MicroBlaze perspective, but some other comments below:

A note more for the Xilinx PPC folks (ie Grant Likely):

Shouldn't some of these Kconfig depends for PPC be unified?  We have:

>  config XILINX_SYSACE
>        tristate "Xilinx SystemACE support"
> -       depends on 4xx
> +       depends on 4xx || MICROBLAZE

>  config XILINX_HWICAP
>        tristate "Xilinx HWICAP Support"
> -       depends on XILINX_VIRTEX
> +       depends on XILINX_VIRTEX || MICROBLAZE


>  config GPIO_XILINX
>        bool "Xilinx GPIO support"
> -       depends on PPC_OF
> +       depends on PPC_OF || MICROBLAZE
>        help
>          Say yes here to support the Xilinx FPGA GPIO device

Are these all really different options?  PPC_OF?  XILINX_VIRTEX?  4xx?

John

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Grant Likely]

On Thu, Apr 16, 2009 at 11:01 PM, John Williams
<john.williams@petalogix.com> wrote:
> On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
>> From: Michal Simek <monstr@monstr.eu>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>
> ACK from a MicroBlaze perspective, but some other comments below:

Acked-by: Grant Likely <grant.likely@secretlab.ca>

But I'm not sure who should pick this up.

>
> A note more for the Xilinx PPC folks (ie Grant Likely):
>
> Shouldn't some of these Kconfig depends for PPC be unified?  We have:
>
>>  config XILINX_SYSACE
>>        tristate "Xilinx SystemACE support"
>> -       depends on 4xx
>> +       depends on 4xx || MICROBLAZE
>
>>  config XILINX_HWICAP
>>        tristate "Xilinx HWICAP Support"
>> -       depends on XILINX_VIRTEX
>> +       depends on XILINX_VIRTEX || MICROBLAZE
>
>
>>  config GPIO_XILINX
>>        bool "Xilinx GPIO support"
>> -       depends on PPC_OF
>> +       depends on PPC_OF || MICROBLAZE
>>        help
>>          Say yes here to support the Xilinx FPGA GPIO device
>
> Are these all really different options?  PPC_OF?  XILINX_VIRTEX?  4xx?

xsysace should just depend on either PPC or OF.  It is applicable to
more than just virtex/spartan systems (I know of at least one
non-virtex 440 board with a systemace, hence the 4xx usage), and it is
conceivable that it would be used on other architectures.

XILINX_VIRTEX makes some sense for hwicap

PPC_OF doesn't have any real meaning anymore.  PPC would be better.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Stephen Neuendorffer]

> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
> Behalf Of Grant Likely
> Sent: Thursday, April 16, 2009 11:52 PM
> To: John Williams
> Cc: microblaze-uclinux@itee.uq.edu.au; linux-kernel@vger.kernel.org; Michal Simek
> Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
> 
> On Thu, Apr 16, 2009 at 11:01 PM, John Williams
> <john.williams@petalogix.com> wrote:
> > On Thu, Apr 16, 2009 at 7:56 PM,  <monstr@monstr.eu> wrote:
> >> From: Michal Simek <monstr@monstr.eu>
> >>
> >> Signed-off-by: Michal Simek <monstr@monstr.eu>
> >
> > ACK from a MicroBlaze perspective, but some other comments below:
> 
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> 
> But I'm not sure who should pick this up.
> 
> >
> > A note more for the Xilinx PPC folks (ie Grant Likely):
> >
> > Shouldn't some of these Kconfig depends for PPC be unified?  We have:
> >
> >>  config XILINX_SYSACE
> >>        tristate "Xilinx SystemACE support"
> >> -       depends on 4xx
> >> +       depends on 4xx || MICROBLAZE
> >
> >>  config XILINX_HWICAP
> >>        tristate "Xilinx HWICAP Support"
> >> -       depends on XILINX_VIRTEX
> >> +       depends on XILINX_VIRTEX || MICROBLAZE
> >
> >
> >>  config GPIO_XILINX
> >>        bool "Xilinx GPIO support"
> >> -       depends on PPC_OF
> >> +       depends on PPC_OF || MICROBLAZE
> >>        help
> >>          Say yes here to support the Xilinx FPGA GPIO device
> >
> > Are these all really different options?  PPC_OF?  XILINX_VIRTEX?  4xx?
> 
> xsysace should just depend on either PPC or OF.  It is applicable to
> more than just virtex/spartan systems (I know of at least one
> non-virtex 440 board with a systemace, hence the 4xx usage), and it is
> conceivable that it would be used on other architectures.
> 
> XILINX_VIRTEX makes some sense for hwicap
> 
> PPC_OF doesn't have any real meaning anymore.  PPC would be better.

I'd like to see a single configuration option that makes all of these drivers available.  That way, any processor system (x86, soft arm core, etc.) could turn those on.. The only thing these drivers *REALLY* depend on is OF...  I've circulated patches to do this several times, although they're probably hopelessly out of date at this point.

Steve

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Stephen Neuendorffer]

Can we have XILINX_DRIVERS, please?  That way this can also be enabled
on any architecture that has FPGA peripherals.

Steve

> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au
[mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
> Behalf Of monstr@monstr.eu
> Sent: Thursday, April 16, 2009 2:57 AM
> To: linux-kernel@vger.kernel.org
> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
Enable drivers for Microblaze
> 
> From: Michal Simek <monstr@monstr.eu>
> 
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> ---
>  drivers/block/Kconfig |    2 +-
>  drivers/char/Kconfig  |    2 +-
>  drivers/gpio/Kconfig  |    2 +-
>  drivers/usb/Kconfig   |    1 +
>  4 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index ddea8e4..9f1665f 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
> 
>  config XILINX_SYSACE
>  	tristate "Xilinx SystemACE support"
> -	depends on 4xx
> +	depends on 4xx || MICROBLAZE
>  	help
>  	  Include support for the Xilinx SystemACE CompactFlash
interface
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index 735bbe2..bb1a071 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -893,7 +893,7 @@ config DTLK
> 
>  config XILINX_HWICAP
>  	tristate "Xilinx HWICAP Support"
> -	depends on XILINX_VIRTEX
> +	depends on XILINX_VIRTEX || MICROBLAZE
>  	help
>  	  This option enables support for Xilinx Internal Configuration
>  	  Access Port (ICAP) driver.  The ICAP is used on Xilinx Virtex
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index edb0253..11f3739 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
> 
>  config GPIO_XILINX
>  	bool "Xilinx GPIO support"
> -	depends on PPC_OF
> +	depends on PPC_OF || MICROBLAZE
>  	help
>  	  Say yes here to support the Xilinx FPGA GPIO device
> 
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index c6c816b..5eee3f8 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
>  	default y if PCMCIA && !M32R			# sl811_cs
>  	default y if ARM				# SL-811
>  	default y if SUPERH				# r8a66597-hcd
> +	default y if MICROBLAZE
>  	default PCI
> 
>  # many non-PCI SOC chips embed OHCI
> --
> 1.5.5.1
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page :
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Grant Likely]

On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> Can we have XILINX_DRIVERS, please? =A0That way this can also be enabled
> on any architecture that has FPGA peripherals.

I've thought about this more, and I'd really rather not.  The list of
affected drivers is short and is not a large maintenance burden.  I
don't think a list of 2 or 3 architecture selects for each driver is
unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
anyway.  At any given time one of these drivers may be needed on
another platform.  ie. the SystemACE device is present on at least one
non-virtex, non-spartan platform.

g.

>
> Steve
>
>> -----Original Message-----
>> From: owner-microblaze-uclinux@itee.uq.edu.au
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
>> Behalf Of monstr@monstr.eu
>> Sent: Thursday, April 16, 2009 2:57 AM
>> To: linux-kernel@vger.kernel.org
>> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
>> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
> Enable drivers for Microblaze
>>
>> From: Michal Simek <monstr@monstr.eu>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>> =A0drivers/block/Kconfig | =A0 =A02 +-
>> =A0drivers/char/Kconfig =A0| =A0 =A02 +-
>> =A0drivers/gpio/Kconfig =A0| =A0 =A02 +-
>> =A0drivers/usb/Kconfig =A0 | =A0 =A01 +
>> =A04 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>> index ddea8e4..9f1665f 100644
>> --- a/drivers/block/Kconfig
>> +++ b/drivers/block/Kconfig
>> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
>>
>> =A0config XILINX_SYSACE
>> =A0 =A0 =A0 tristate "Xilinx SystemACE support"
>> - =A0 =A0 depends on 4xx
>> + =A0 =A0 depends on 4xx || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 Include support for the Xilinx SystemACE CompactFlash
> interface
>>
>> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
>> index 735bbe2..bb1a071 100644
>> --- a/drivers/char/Kconfig
>> +++ b/drivers/char/Kconfig
>> @@ -893,7 +893,7 @@ config DTLK
>>
>> =A0config XILINX_HWICAP
>> =A0 =A0 =A0 tristate "Xilinx HWICAP Support"
>> - =A0 =A0 depends on XILINX_VIRTEX
>> + =A0 =A0 depends on XILINX_VIRTEX || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 This option enables support for Xilinx Internal Configur=
ation
>> =A0 =A0 =A0 =A0 Access Port (ICAP) driver. =A0The ICAP is used on Xilinx=
 Virtex
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index edb0253..11f3739 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
>>
>> =A0config GPIO_XILINX
>> =A0 =A0 =A0 bool "Xilinx GPIO support"
>> - =A0 =A0 depends on PPC_OF
>> + =A0 =A0 depends on PPC_OF || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 Say yes here to support the Xilinx FPGA GPIO device
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index c6c816b..5eee3f8 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
>> =A0 =A0 =A0 default y if PCMCIA && !M32R =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0# sl811_cs
>> =A0 =A0 =A0 default y if ARM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0# SL-811
>> =A0 =A0 =A0 default y if SUPERH =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 # r8a66597-hcd
>> + =A0 =A0 default y if MICROBLAZE
>> =A0 =A0 =A0 default PCI
>>
>> =A0# many non-PCI SOC chips embed OHCI
>> --
>> 1.5.5.1
>>
>> ___________________________
>> microblaze-uclinux mailing list
>> microblaze-uclinux@itee.uq.edu.au
>> Project Home Page :
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
>> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>>
>
>
> This email and any attachments are intended for the sole use of the named=
 recipient(s) and contain(s) confidential information that may be proprieta=
ry, privileged or copyrighted under applicable law. If you are not the inte=
nded recipient, do not read, copy, or forward this email message or any att=
achments. Delete this email message and any attachments immediately.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Grant Likely]

On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> Can we have XILINX_DRIVERS, please?  That way this can also be enabled
> on any architecture that has FPGA peripherals.

I've thought about this more, and I'd really rather not.  The list of
affected drivers is short and is not a large maintenance burden.  I
don't think a list of 2 or 3 architecture selects for each driver is
unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
anyway.  At any given time one of these drivers may be needed on
another platform.  ie. the SystemACE device is present on at least one
non-virtex, non-spartan platform.

g.

>
> Steve
>
>> -----Original Message-----
>> From: owner-microblaze-uclinux@itee.uq.edu.au
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
>> Behalf Of monstr@monstr.eu
>> Sent: Thursday, April 16, 2009 2:57 AM
>> To: linux-kernel@vger.kernel.org
>> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
>> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
> Enable drivers for Microblaze
>>
>> From: Michal Simek <monstr@monstr.eu>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>>  drivers/block/Kconfig |    2 +-
>>  drivers/char/Kconfig  |    2 +-
>>  drivers/gpio/Kconfig  |    2 +-
>>  drivers/usb/Kconfig   |    1 +
>>  4 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>> index ddea8e4..9f1665f 100644
>> --- a/drivers/block/Kconfig
>> +++ b/drivers/block/Kconfig
>> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
>>
>>  config XILINX_SYSACE
>>       tristate "Xilinx SystemACE support"
>> -     depends on 4xx
>> +     depends on 4xx || MICROBLAZE
>>       help
>>         Include support for the Xilinx SystemACE CompactFlash
> interface
>>
>> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
>> index 735bbe2..bb1a071 100644
>> --- a/drivers/char/Kconfig
>> +++ b/drivers/char/Kconfig
>> @@ -893,7 +893,7 @@ config DTLK
>>
>>  config XILINX_HWICAP
>>       tristate "Xilinx HWICAP Support"
>> -     depends on XILINX_VIRTEX
>> +     depends on XILINX_VIRTEX || MICROBLAZE
>>       help
>>         This option enables support for Xilinx Internal Configuration
>>         Access Port (ICAP) driver.  The ICAP is used on Xilinx Virtex
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index edb0253..11f3739 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
>>
>>  config GPIO_XILINX
>>       bool "Xilinx GPIO support"
>> -     depends on PPC_OF
>> +     depends on PPC_OF || MICROBLAZE
>>       help
>>         Say yes here to support the Xilinx FPGA GPIO device
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index c6c816b..5eee3f8 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
>>       default y if PCMCIA && !M32R                    # sl811_cs
>>       default y if ARM                                # SL-811
>>       default y if SUPERH                             # r8a66597-hcd
>> +     default y if MICROBLAZE
>>       default PCI
>>
>>  # many non-PCI SOC chips embed OHCI
>> --
>> 1.5.5.1
>>
>> ___________________________
>> microblaze-uclinux mailing list
>> microblaze-uclinux@itee.uq.edu.au
>> Project Home Page :
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
>> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Stephen Neuendorffer]

[-- Attachment #1: Type: text/plain, Size: 5165 bytes --]

On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>wrote:

> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > Can we have XILINX_DRIVERS, please?  That way this can also be enabled
> > on any architecture that has FPGA peripherals.
>
> I've thought about this more, and I'd really rather not.  The list of
> affected drivers is short and is not a large maintenance burden.  I
> don't think a list of 2 or 3 architecture selects for each driver is
> unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
> anyway.  At any given time one of these drivers may be needed on
> another platform.  ie. the SystemACE device is present on at least one
> non-virtex, non-spartan platform.


Which is exactly why having it architecture dependent isn't right...  All of
these drivers
could be needed and used on any OF-based platform.  If you have a platform
(for instance, a processor connected to an FPGA which has these peripherals
in the FPGA) then you should be able to enable these drivers.  Just my 2
cents...

Steve


>
> g.
>
> >
> > Steve
> >
> >> -----Original Message-----
> >> From: owner-microblaze-uclinux@itee.uq.edu.au
> > [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
> >> Behalf Of monstr@monstr.eu
> >> Sent: Thursday, April 16, 2009 2:57 AM
> >> To: linux-kernel@vger.kernel.org
> >> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
> >> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
> > Enable drivers for Microblaze
> >>
> >> From: Michal Simek <monstr@monstr.eu>
> >>
> >> Signed-off-by: Michal Simek <monstr@monstr.eu>
> >> ---
> >>  drivers/block/Kconfig |    2 +-
> >>  drivers/char/Kconfig  |    2 +-
> >>  drivers/gpio/Kconfig  |    2 +-
> >>  drivers/usb/Kconfig   |    1 +
> >>  4 files changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> >> index ddea8e4..9f1665f 100644
> >> --- a/drivers/block/Kconfig
> >> +++ b/drivers/block/Kconfig
> >> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
> >>
> >>  config XILINX_SYSACE
> >>       tristate "Xilinx SystemACE support"
> >> -     depends on 4xx
> >> +     depends on 4xx || MICROBLAZE
> >>       help
> >>         Include support for the Xilinx SystemACE CompactFlash
> > interface
> >>
> >> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> >> index 735bbe2..bb1a071 100644
> >> --- a/drivers/char/Kconfig
> >> +++ b/drivers/char/Kconfig
> >> @@ -893,7 +893,7 @@ config DTLK
> >>
> >>  config XILINX_HWICAP
> >>       tristate "Xilinx HWICAP Support"
> >> -     depends on XILINX_VIRTEX
> >> +     depends on XILINX_VIRTEX || MICROBLAZE
> >>       help
> >>         This option enables support for Xilinx Internal Configuration
> >>         Access Port (ICAP) driver.  The ICAP is used on Xilinx Virtex
> >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >> index edb0253..11f3739 100644
> >> --- a/drivers/gpio/Kconfig
> >> +++ b/drivers/gpio/Kconfig
> >> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
> >>
> >>  config GPIO_XILINX
> >>       bool "Xilinx GPIO support"
> >> -     depends on PPC_OF
> >> +     depends on PPC_OF || MICROBLAZE
> >>       help
> >>         Say yes here to support the Xilinx FPGA GPIO device
> >>
> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> >> index c6c816b..5eee3f8 100644
> >> --- a/drivers/usb/Kconfig
> >> +++ b/drivers/usb/Kconfig
> >> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
> >>       default y if PCMCIA && !M32R                    # sl811_cs
> >>       default y if ARM                                # SL-811
> >>       default y if SUPERH                             # r8a66597-hcd
> >> +     default y if MICROBLAZE
> >>       default PCI
> >>
> >>  # many non-PCI SOC chips embed OHCI
> >> --
> >> 1.5.5.1
> >>
> >> ___________________________
> >> microblaze-uclinux mailing list
> >> microblaze-uclinux@itee.uq.edu.au
> >> Project Home Page :
> > http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux<http://www.itee.uq.edu.au/%7Ejwilliams/mblaze-uclinux>
> >> Mailing List Archive :
> > http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/<http://www.itee.uq.edu.au/%7Elistarch/microblaze-uclinux/>
> >>
> >
> >
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are not
> the intended recipient, do not read, copy, or forward this email message or
> any attachments. Delete this email message and any attachments immediately.
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

[-- Attachment #2: Type: text/html, Size: 7341 bytes --]

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Williams]

On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
<stephen.neuendorffer@gmail.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca=
>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> > Can we have XILINX_DRIVERS, please? =A0That way this can also be enabl=
ed
>> > on any architecture that has FPGA peripherals.
>>
>> I've thought about this more, and I'd really rather not. =A0The list of
>> affected drivers is short and is not a large maintenance burden. =A0I
>> don't think a list of 2 or 3 architecture selects for each driver is
>> unreasonable. =A0A "XILINX_DRIVERS" config item doesn't really help much
>> anyway. =A0At any given time one of these drivers may be needed on
>> another platform. =A0ie. the SystemACE device is present on at least one
>> non-virtex, non-spartan platform.
>
> Which is exactly why having it architecture dependent isn't right...=A0 A=
ll of
> these drivers
> could be needed and used on any OF-based platform.=A0 If you have a platf=
orm
> (for instance, a processor connected to an FPGA which has these periphera=
ls
> in the FPGA) then you should be able to enable these drivers.=A0 Just my =
2
> cents...

What about the radical approach of having NO architecture
filters/selectors?  Even if some random i386 user selects one of these
drivers, so what?  It will still compile cleanly (if it doesn't we
have to fix it), but there'll be no platform_device_register() call in
their machine startup to actually cause driver / device binding.

No harm, no foul.  Problem goes away.

Then, as Grant points out, the rare cases where non-Xilinx platforms
do use this stuff, they'll presumably know what they're doing and it's
their responsibility to register the appropriate platform_device
structures and make the magic happen.

John
--=20
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Williams]

On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
<stephen.neuendorffer@gmail.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> > Can we have XILINX_DRIVERS, please?  That way this can also be enabled
>> > on any architecture that has FPGA peripherals.
>>
>> I've thought about this more, and I'd really rather not.  The list of
>> affected drivers is short and is not a large maintenance burden.  I
>> don't think a list of 2 or 3 architecture selects for each driver is
>> unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
>> anyway.  At any given time one of these drivers may be needed on
>> another platform.  ie. the SystemACE device is present on at least one
>> non-virtex, non-spartan platform.
>
> Which is exactly why having it architecture dependent isn't right...  All of
> these drivers
> could be needed and used on any OF-based platform.  If you have a platform
> (for instance, a processor connected to an FPGA which has these peripherals
> in the FPGA) then you should be able to enable these drivers.  Just my 2
> cents...

What about the radical approach of having NO architecture
filters/selectors?  Even if some random i386 user selects one of these
drivers, so what?  It will still compile cleanly (if it doesn't we
have to fix it), but there'll be no platform_device_register() call in
their machine startup to actually cause driver / device binding.

No harm, no foul.  Problem goes away.

Then, as Grant points out, the rare cases where non-Xilinx platforms
do use this stuff, they'll presumably know what they're doing and it's
their responsibility to register the appropriate platform_device
structures and make the magic happen.

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Stephen Neuendorffer]

[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]


My thinking is that these drivers are likely to be used as a group,
hence it would be nice to make it easy to get them all visible/enabled somehow.

Steve

-----Original Message-----
From: John Williams [mailto:john.williams@petalogix.com]
Sent: Sun 4/19/2009 4:03 PM
To: microblaze-uclinux@itee.uq.edu.au
Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-kernel@vger.kernel.org; John Linn
Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
 
On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
<stephen.neuendorffer@gmail.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> > Can we have XILINX_DRIVERS, please?  That way this can also be enabled
>> > on any architecture that has FPGA peripherals.
>>
>> I've thought about this more, and I'd really rather not.  The list of
>> affected drivers is short and is not a large maintenance burden.  I
>> don't think a list of 2 or 3 architecture selects for each driver is
>> unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
>> anyway.  At any given time one of these drivers may be needed on
>> another platform.  ie. the SystemACE device is present on at least one
>> non-virtex, non-spartan platform.
>
> Which is exactly why having it architecture dependent isn't right...  All of
> these drivers
> could be needed and used on any OF-based platform.  If you have a platform
> (for instance, a processor connected to an FPGA which has these peripherals
> in the FPGA) then you should be able to enable these drivers.  Just my 2
> cents...

What about the radical approach of having NO architecture
filters/selectors?  Even if some random i386 user selects one of these
drivers, so what?  It will still compile cleanly (if it doesn't we
have to fix it), but there'll be no platform_device_register() call in
their machine startup to actually cause driver / device binding.

No harm, no foul.  Problem goes away.

Then, as Grant points out, the rare cases where non-Xilinx platforms
do use this stuff, they'll presumably know what they're doing and it's
their responsibility to register the appropriate platform_device
structures and make the magic happen.

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663




This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


[-- Attachment #2: Type: text/html, Size: 3872 bytes --]

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Linn]

> -----Original Message-----
> From: Stephen Neuendorffer
> Sent: Sunday, April 19, 2009 11:52 PM
> To: John Williams; microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.org=
; John Linn
> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enab=
le drivers for Microblaze
> =

> =

> My thinking is that these drivers are likely to be used as a group,
> hence it would be nice to make it easy to get them all visible/enabled so=
mehow.
> 
> Steve


It seems like John's suggestion of no arch filters would satisfy that also.=
 Since FPGAs are used in so many different applications this would seem to =
open the drivers up to everyone regardless of what processor they're using.=
 It's certainly less complex so I like it in that way.

But maybe I'm missing something here and there's a downside?

-- John

> =

> -----Original Message-----
> From: John Williams [mailto:john.williams@petalogix.com]
> Sent: Sun 4/19/2009 4:03 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-=
kernel@vger.kernel.org; John
> Linn
> Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enab=
le drivers for Microblaze
> =

> On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
> <stephen.neuendorffer@gmail.com> wrote:
> >
> >
> > On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.=
ca>
> > wrote:
> >>
> >> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> >> <stephen.neuendorffer@xilinx.com> wrote:
> >> >
> >> > Can we have XILINX_DRIVERS, please? =A0That way this can also be ena=
bled
> >> > on any architecture that has FPGA peripherals.
> >>
> >> I've thought about this more, and I'd really rather not. =A0The list o=
f
> >> affected drivers is short and is not a large maintenance burden. =A0I
> >> don't think a list of 2 or 3 architecture selects for each driver is
> >> unreasonable. =A0A "XILINX_DRIVERS" config item doesn't really help mu=
ch
> >> anyway. =A0At any given time one of these drivers may be needed on
> >> another platform. =A0ie. the SystemACE device is present on at least o=
ne
> >> non-virtex, non-spartan platform.
> >
> > Which is exactly why having it architecture dependent isn't right...=A0=
 All of
> > these drivers
> > could be needed and used on any OF-based platform.=A0 If you have a pla=
tform
> > (for instance, a processor connected to an FPGA which has these periphe=
rals
> > in the FPGA) then you should be able to enable these drivers.=A0 Just m=
y 2
> > cents...
> =

> What about the radical approach of having NO architecture
> filters/selectors?  Even if some random i386 user selects one of these
> drivers, so what?  It will still compile cleanly (if it doesn't we
> have to fix it), but there'll be no platform_device_register() call in
> their machine startup to actually cause driver / device binding.
> =

> No harm, no foul.  Problem goes away.
> =

> Then, as Grant points out, the rare cases where non-Xilinx platforms
> do use this stuff, they'll presumably know what they're doing and it's
> their responsibility to register the appropriate platform_device
> structures and make the magic happen.
> =

> John
> --
> John Williams, PhD, B.Eng, B.IT
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
> =



This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Linn]

> -----Original Message-----
> From: Stephen Neuendorffer
> Sent: Sunday, April 19, 2009 11:52 PM
> To: John Williams; microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.org; John Linn
> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
> 
> 
> My thinking is that these drivers are likely to be used as a group,
> hence it would be nice to make it easy to get them all visible/enabled somehow.
> 
> Steve


It seems like John's suggestion of no arch filters would satisfy that also. Since FPGAs are used in so many different applications this would seem to open the drivers up to everyone regardless of what processor they're using. It's certainly less complex so I like it in that way.

But maybe I'm missing something here and there's a downside?

-- John

> 
> -----Original Message-----
> From: John Williams [mailto:john.williams@petalogix.com]
> Sent: Sun 4/19/2009 4:03 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-kernel@vger.kernel.org; John
> Linn
> Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
> 
> On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
> <stephen.neuendorffer@gmail.com> wrote:
> >
> >
> > On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>
> > wrote:
> >>
> >> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> >> <stephen.neuendorffer@xilinx.com> wrote:
> >> >
> >> > Can we have XILINX_DRIVERS, please?  That way this can also be enabled
> >> > on any architecture that has FPGA peripherals.
> >>
> >> I've thought about this more, and I'd really rather not.  The list of
> >> affected drivers is short and is not a large maintenance burden.  I
> >> don't think a list of 2 or 3 architecture selects for each driver is
> >> unreasonable.  A "XILINX_DRIVERS" config item doesn't really help much
> >> anyway.  At any given time one of these drivers may be needed on
> >> another platform.  ie. the SystemACE device is present on at least one
> >> non-virtex, non-spartan platform.
> >
> > Which is exactly why having it architecture dependent isn't right...  All of
> > these drivers
> > could be needed and used on any OF-based platform.  If you have a platform
> > (for instance, a processor connected to an FPGA which has these peripherals
> > in the FPGA) then you should be able to enable these drivers.  Just my 2
> > cents...
> 
> What about the radical approach of having NO architecture
> filters/selectors?  Even if some random i386 user selects one of these
> drivers, so what?  It will still compile cleanly (if it doesn't we
> have to fix it), but there'll be no platform_device_register() call in
> their machine startup to actually cause driver / device binding.
> 
> No harm, no foul.  Problem goes away.
> 
> Then, as Grant points out, the rare cases where non-Xilinx platforms
> do use this stuff, they'll presumably know what they're doing and it's
> their responsibility to register the appropriate platform_device
> structures and make the magic happen.
> 
> John
> --
> John Williams, PhD, B.Eng, B.IT
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
> 


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Grant Likely]

On Mon, Apr 20, 2009 at 8:36 AM, John Linn <John.Linn@xilinx.com> wrote:
>> -----Original Message-----
>> From: Stephen Neuendorffer
>> Sent: Sunday, April 19, 2009 11:52 PM
>> To: John Williams; microblaze-uclinux@itee.uq.edu.au
>> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.or=
g; John Linn
>> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Ena=
ble drivers for Microblaze
>>
>>
>> My thinking is that these drivers are likely to be used as a group,
>> hence it would be nice to make it easy to get them all visible/enabled s=
omehow.
>>
>> Steve
>
>
> It seems like John's suggestion of no arch filters would satisfy that als=
o. Since FPGAs are used in so many different applications this would seem t=
o open the drivers up to everyone regardless of what processor they're usin=
g. It's certainly less complex so I like it in that way.
>
> But maybe I'm missing something here and there's a downside?

No, I don't think there is.

I think CONFIG_OF is the right thing to do.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Grant Likely]

On Mon, Apr 20, 2009 at 8:36 AM, John Linn <John.Linn@xilinx.com> wrote:
>> -----Original Message-----
>> From: Stephen Neuendorffer
>> Sent: Sunday, April 19, 2009 11:52 PM
>> To: John Williams; microblaze-uclinux@itee.uq.edu.au
>> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.org; John Linn
>> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
>>
>>
>> My thinking is that these drivers are likely to be used as a group,
>> hence it would be nice to make it easy to get them all visible/enabled somehow.
>>
>> Steve
>
>
> It seems like John's suggestion of no arch filters would satisfy that also. Since FPGAs are used in so many different applications this would seem to open the drivers up to everyone regardless of what processor they're using. It's certainly less complex so I like it in that way.
>
> But maybe I'm missing something here and there's a downside?

No, I don't think there is.

I think CONFIG_OF is the right thing to do.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Williams]

On Tue, Apr 21, 2009 at 12:48 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Mon, Apr 20, 2009 at 8:36 AM, John Linn <John.Linn@xilinx.com> wrote:
>>> -----Original Message-----
>>> From: Stephen Neuendorffer
>>> Sent: Sunday, April 19, 2009 11:52 PM
>>> To: John Williams; microblaze-uclinux@itee.uq.edu.au
>>> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.o=
rg; John Linn
>>> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: En=
able drivers for Microblaze
>>>
>>>
>>> My thinking is that these drivers are likely to be used as a group,
>>> hence it would be nice to make it easy to get them all visible/enabled =
somehow.
>>>
>>> Steve
>>
>>
>> It seems like John's suggestion of no arch filters would satisfy that al=
so. Since FPGAs are used in so many different applications this would seem =
to open the drivers up to everyone regardless of what processor they're usi=
ng. It's certainly less complex so I like it in that way.
>>
>> But maybe I'm missing something here and there's a downside?
>
> No, I don't think there is.
>
> I think CONFIG_OF is the right thing to do.

Some (most?) of the Xilinx drivers currently have this construct:

#ifdef CONFIG_OF

// probe using OF

#else

// probe using platform_device

#endif

so unless this is going to change some time soon, maybe even CONFIG_OF
is too restrictive?

John
--=20
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Williams]

On Tue, Apr 21, 2009 at 12:48 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Mon, Apr 20, 2009 at 8:36 AM, John Linn <John.Linn@xilinx.com> wrote:
>>> -----Original Message-----
>>> From: Stephen Neuendorffer
>>> Sent: Sunday, April 19, 2009 11:52 PM
>>> To: John Williams; microblaze-uclinux@itee.uq.edu.au
>>> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.org; John Linn
>>> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
>>>
>>>
>>> My thinking is that these drivers are likely to be used as a group,
>>> hence it would be nice to make it easy to get them all visible/enabled somehow.
>>>
>>> Steve
>>
>>
>> It seems like John's suggestion of no arch filters would satisfy that also. Since FPGAs are used in so many different applications this would seem to open the drivers up to everyone regardless of what processor they're using. It's certainly less complex so I like it in that way.
>>
>> But maybe I'm missing something here and there's a downside?
>
> No, I don't think there is.
>
> I think CONFIG_OF is the right thing to do.

Some (most?) of the Xilinx drivers currently have this construct:

#ifdef CONFIG_OF

// probe using OF

#else

// probe using platform_device

#endif

so unless this is going to change some time soon, maybe even CONFIG_OF
is too restrictive?

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Arnd Bergmann]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Tuesday 21 April 2009, John Williams wrote:
> Some (most?) of the Xilinx drivers currently have this construct:
> 
> #ifdef CONFIG_OF
> 
> // probe using OF
> 
> #else

If there are multiple ways of detecting the device, then
the driver should be compilable on any system that allows
either one.

At the very least, it should be restricted to CONFIG_HAS_IOMEM,
which is probably required for any of these, but not provided
on stuff like UML or s390.

Drivers that use of_* functions unconditionally need to
depend on CONFIG_OF.

Also, some of the xilinx drivers apparantly use DCR, which in turn is
only defined when you have CONFIG_PPC_DCR, and these
have so far only been used on powerpc. If other architectures
start using DCR (I hope that never happens), we will need a
global CONFIG_DCR option.

	Arnd <><

[-- Attachment #2: Type: text/html, Size: 5105 bytes --]

who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board

[derekzheng]

Hi all guys:

The Freescale MPC8536DS board Integrated TestFloat cases, and I do not =
know how to test this feature on this board.
Please tell me how to test it if you known

Thanks very much!

Derek

who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board

[derekzheng]

Hi all guys:

The Freescale MPC8536DS board Integrated TestFloat cases, and I do not know how to test this feature on this board.
Please tell me how to test it if you known

Thanks very much!

Derek

Re: who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board

[Kumar Gala]

On Apr 19, 2009, at 4:25 AM, derekzheng wrote:

> Hi all guys:
>
> The Freescale MPC8536DS board Integrated TestFloat cases, and I do  
> not know how to test this feature on this board.
> Please tell me how to test it if you known

1. why are you CC' the microblaze list on this question?
2. I assume you are talking about the FSL BSP for MPC8536DS
3. testfloat is a set of tests.  Its not clear what your question is.   
You build testfloat and run it and it reports pass/fails.

- k

Re:Re: who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board

[zhengxiang9]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

thanks for you help.
i am sorry,i make a mistake , i can not update my mail list

derek  zheng 








在2009-04-20，"Kumar Gala" <galak@kernel.crashing.org> 写道：
>
>On Apr 19, 2009, at 4:25 AM, derekzheng wrote:
>
>> Hi all guys:
>>
>> The Freescale MPC8536DS board Integrated TestFloat cases, and I do  
>> not know how to test this feature on this board.
>> Please tell me how to test it if you known
>
>1. why are you CC' the microblaze list on this question?
>2. I assume you are talking about the FSL BSP for MPC8536DS
>3. testfloat is a set of tests.  Its not clear what your question is.   
>You build testfloat and run it and it reports pass/fails.
>
>- k

[-- Attachment #2: Type: text/html, Size: 949 bytes --]

RE: who know's what is "TestFloat cases" and how to test this feature onthe Freescale MPC8536DS board

[Liu Yu-B13201]

> -----Original Message-----
> From: linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of derekzheng
> Sent: Sunday, April 19, 2009 5:25 PM
> To: 'linuxppc-dev'; microblaze-uclinux@itee.uq.edu.au;=20
> linux-kernel@vger.kernel.org
> Subject: who know's what is "TestFloat cases" and how to test=20
> this feature onthe Freescale MPC8536DS board
>=20
> Hi all guys:
>=20
> The Freescale MPC8536DS board Integrated TestFloat cases, and=20
> I do not know how to test this feature on this board.
> Please tell me how to test it if you known
>=20

You can find the user manual "E500v2 SPE Floating Point" in BSP iso.

RE: who know's what is "TestFloat cases" and how to test this feature onthe Freescale MPC8536DS board

[Liu Yu-B13201]

> -----Original Message-----
> From: linuxppc-dev-bounces+b13201=freescale.com@ozlabs.org 
> [mailto:linuxppc-dev-bounces+b13201=freescale.com@ozlabs.org] 
> On Behalf Of derekzheng
> Sent: Sunday, April 19, 2009 5:25 PM
> To: 'linuxppc-dev'; microblaze-uclinux@itee.uq.edu.au; 
> linux-kernel@vger.kernel.org
> Subject: who know's what is "TestFloat cases" and how to test 
> this feature onthe Freescale MPC8536DS board
> 
> Hi all guys:
> 
> The Freescale MPC8536DS board Integrated TestFloat cases, and 
> I do not know how to test this feature on this board.
> Please tell me how to test it if you known
> 

You can find the user manual "E500v2 SPE Floating Point" in BSP iso.

Re: Microblaze fixes for revision

[Andrew Morton]

On Thu, 16 Apr 2009 11:56:27 +0200
monstr@monstr.eu wrote:

> here are some patches which fixed some minor things.

How are microblaze patches getting into Linus's tree?

An appropriate route would be for you to ask him to pull the git tree. 
I could send them (as I do with alpha, uml and maybe others), but
that's more a last-resort way of maintaining an architecture.

The microblaze git tree should be included in linux-next.  Please
prepare a branch and send the info over to Stephen Rothwell
<sfr@canb.auug.org.au> and linux-next@vger.kernel.org to get that all
set up.

For these particular patches: officially, 2.6.30-rcN is in bugfix-only
mode.  But as microblaze is newly-added in 2.6.30 I think it's OK to
put non-bugfixes into 2.6.30 as well - we might as well get the
architecture as up-to-date as possible for the 2.6.30 release.

Re: Microblaze fixes for revision

[Michal Simek]

Andrew Morton wrote:
> On Thu, 16 Apr 2009 11:56:27 +0200
> monstr@monstr.eu wrote:
>
>   
>> here are some patches which fixed some minor things.
>>     
>
> How are microblaze patches getting into Linus's tree?
>   
I created two branches in git as Ingo suggested me.
1. for-linus -> this branch stores new features which comes to next
merge open window
2. fixes-for-linus -> this branch stores fixes which come to rc version

I asked Linus for pulling it to his tree. I think rc3 will be soon - the
changes which I sent for
reviewing to LKML are OK (except Kconfig patch 11/11 - which I removed
for now) - they are ready
in fixes-for-linus branch.
I'll write next pull request - some days after rc3.

> An appropriate route would be for you to ask him to pull the git tree. 
> I could send them (as I do with alpha, uml and maybe others), but
> that's more a last-resort way of maintaining an architecture.
>   
I think that my maintaining will be good for you and all.

> The microblaze git tree should be included in linux-next.  Please
> prepare a branch and send the info over to Stephen Rothwell
> <sfr@canb.auug.org.au> and linux-next@vger.kernel.org to get that all
> set up.
>   
OK. I will contact him to sort this things.

> For these particular patches: officially, 2.6.30-rcN is in bugfix-only
> mode.  But as microblaze is newly-added in 2.6.30 I think it's OK to
> put non-bugfixes into 2.6.30 as well - we might as well get the
> architecture as up-to-date as possible for the 2.6.30 release.
>   
Thanks but I don't need to add new feature now.
I am solving some problems with romfs which comes with David's romfs changes

And I am preparing MMU Microblaze patches which I want to send to review
to LKML soon. I have there only some things to solve (like add
__uClinux__ to headers). I tested it with LTP and the results are good.
I would like to have ACKs and add it in next merge open window.

Thanks,
Michal

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>   


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663