Re: Adding VIRTIO to the multi_v7_defconfig
On Sun, Nov 29, 2015 at 2:31 PM, Arnd Bergmann wrote: > On Sunday 29 November 2015 14:18:24 Peter Crosthwaite wrote: >> >> I started a small project to test as many QEMU emulated ARM boards >> using the multi_v7 defconfig: >> >> https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg00755.html >> >> One thing that came up was we cannot use the virt board as it relies >> on virtio hotplug and drivers to get block and network support. The >> defconfig is missing the drivers. Should we add the VIRTIO drivers to >> the defconfig to bring this into play? > > Yes, please send a patch, this is definitely useful. We normally ask > everyone to use loadable modules for newly enabled device drivers > in multi_v7_defconfig, but we might actually use built-in drivers > here if that would otherwise be the only module needed for booting. > So minimally I am looking for: CONFIG_VIRTIO_PCI=y" CONFIG_VIRTIO_BLK=y" CONFIG_VIRTIO_NET=y" As that gets you booted with network without needing initrd. I guess the rest of VIRTIO makes more sense as modules as follow up work? Regards, Peter > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Adding VIRTIO to the multi_v7_defconfig
Hi, I started a small project to test as many QEMU emulated ARM boards using the multi_v7 defconfig: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg00755.html One thing that came up was we cannot use the virt board as it relies on virtio hotplug and drivers to get block and network support. The defconfig is missing the drivers. Should we add the VIRTIO drivers to the defconfig to bring this into play? Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Adding VIRTIO to the multi_v7_defconfig
Hi, I started a small project to test as many QEMU emulated ARM boards using the multi_v7 defconfig: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg00755.html One thing that came up was we cannot use the virt board as it relies on virtio hotplug and drivers to get block and network support. The defconfig is missing the drivers. Should we add the VIRTIO drivers to the defconfig to bring this into play? Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Adding VIRTIO to the multi_v7_defconfig
On Sun, Nov 29, 2015 at 2:31 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Sunday 29 November 2015 14:18:24 Peter Crosthwaite wrote: >> >> I started a small project to test as many QEMU emulated ARM boards >> using the multi_v7 defconfig: >> >> https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg00755.html >> >> One thing that came up was we cannot use the virt board as it relies >> on virtio hotplug and drivers to get block and network support. The >> defconfig is missing the drivers. Should we add the VIRTIO drivers to >> the defconfig to bring this into play? > > Yes, please send a patch, this is definitely useful. We normally ask > everyone to use loadable modules for newly enabled device drivers > in multi_v7_defconfig, but we might actually use built-in drivers > here if that would otherwise be the only module needed for booting. > So minimally I am looking for: CONFIG_VIRTIO_PCI=y" CONFIG_VIRTIO_BLK=y" CONFIG_VIRTIO_NET=y" As that gets you booted with network without needing initrd. I guess the rest of VIRTIO makes more sense as modules as follow up work? Regards, Peter > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: Implement cpu_relax as yield
Ping!
Anything I need to do or send to to get a merge on this?
Regards,
Peter
On Tue, Mar 3, 2015 at 12:49 AM, Peter Crosthwaite
wrote:
> ARM64 has the yield nop hint which has the intended semantics of
> cpu_relax. Implement.
>
> The immediate application is ARM CPU emulators. An emulator can take
> advantage of the yield hint to de-prioritise an emulated CPU in favor
> of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
> and sees a significant boot time performance increase with this change.
>
> Signed-off-by: Peter Crosthwaite
> Acked-by: Will Deacon
> ---
> arch/arm64/include/asm/processor.h | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/processor.h
> b/arch/arm64/include/asm/processor.h
> index f9be30e..ac2381d 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -126,7 +126,11 @@ extern void release_thread(struct task_struct *);
>
> unsigned long get_wchan(struct task_struct *p);
>
> -#define cpu_relax()barrier()
> +static inline void cpu_relax(void)
> +{
> + asm volatile("yield" ::: "memory");
> +}
> +
> #define cpu_relax_lowlatency()cpu_relax()
>
> /* Thread switching */
> --
> 2.3.0.1.g27a12f1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: Implement cpu_relax as yield
Ping!
Anything I need to do or send to to get a merge on this?
Regards,
Peter
On Tue, Mar 3, 2015 at 12:49 AM, Peter Crosthwaite
peter.crosthwa...@xilinx.com wrote:
ARM64 has the yield nop hint which has the intended semantics of
cpu_relax. Implement.
The immediate application is ARM CPU emulators. An emulator can take
advantage of the yield hint to de-prioritise an emulated CPU in favor
of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
and sees a significant boot time performance increase with this change.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Acked-by: Will Deacon will.dea...@arm.com
---
arch/arm64/include/asm/processor.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index f9be30e..ac2381d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -126,7 +126,11 @@ extern void release_thread(struct task_struct *);
unsigned long get_wchan(struct task_struct *p);
-#define cpu_relax()barrier()
+static inline void cpu_relax(void)
+{
+ asm volatile(yield ::: memory);
+}
+
#define cpu_relax_lowlatency()cpu_relax()
/* Thread switching */
--
2.3.0.1.g27a12f1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: Implement cpu_relax as yield
ARM64 has the yield nop hint which has the intended semantics of
cpu_relax. Implement.
The immediate application is ARM CPU emulators. An emulator can take
advantage of the yield hint to de-prioritise an emulated CPU in favor
of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
and sees a significant boot time performance increase with this change.
Signed-off-by: Peter Crosthwaite
Acked-by: Will Deacon
---
arch/arm64/include/asm/processor.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index f9be30e..ac2381d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -126,7 +126,11 @@ extern void release_thread(struct task_struct *);
unsigned long get_wchan(struct task_struct *p);
-#define cpu_relax()barrier()
+static inline void cpu_relax(void)
+{
+ asm volatile("yield" ::: "memory");
+}
+
#define cpu_relax_lowlatency()cpu_relax()
/* Thread switching */
--
2.3.0.1.g27a12f1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: Implement cpu_relax as yield
ARM64 has the yield nop hint which has the intended semantics of
cpu_relax. Implement.
The immediate application is ARM CPU emulators. An emulator can take
advantage of the yield hint to de-prioritise an emulated CPU in favor
of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
and sees a significant boot time performance increase with this change.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Acked-by: Will Deacon will.dea...@arm.com
---
arch/arm64/include/asm/processor.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index f9be30e..ac2381d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -126,7 +126,11 @@ extern void release_thread(struct task_struct *);
unsigned long get_wchan(struct task_struct *p);
-#define cpu_relax()barrier()
+static inline void cpu_relax(void)
+{
+ asm volatile(yield ::: memory);
+}
+
#define cpu_relax_lowlatency()cpu_relax()
/* Thread switching */
--
2.3.0.1.g27a12f1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm64: Implement cpu_relax as yield
On Wed, Feb 25, 2015 at 5:24 AM, Will Deacon wrote:
> On Tue, Feb 24, 2015 at 11:07:37PM +0000, Peter Crosthwaite wrote:
>> ARM64 has the yield nop hint which has the intended semantics of
>> cpu_relax. Implement.
>>
>> The immediate application is ARM CPU emulators. An emulator can take
>> advantage of the yield hint to de-prioritise an emulated CPU in favor
>> of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
>> and sees a significant boot time performance increase with this change.
>
> Could you elaborate on the QEMU SMP boot case please? Usually SMP pens
> for booting make use of wfe/sev to minimise the spinning overhead.
>
So I did some follow up experiments. With my patch applied I started
trapping instances of cpu_relax (now yielding) in gdb. I then
commented out the cpu_relax's one by one.
This one seems to be the key:
diff --git a/kernel/smp.c b/kernel/smp.c
index f38a1e6..1c692be 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -108,7 +108,8 @@ void __init call_function_init(void)
static void csd_lock_wait(struct call_single_data *csd)
{
while (csd->flags & CSD_FLAG_LOCK)
- cpu_relax();
+ ;
+ //cpu_relax();
}
Hack above causes boot time delay even with my patch applied, so this
is causing my issue it seems.
I found three cpu_relax calls that each seems to do some spinning in
the boot. There probably will be more, but I stopped after finding to
above issue. Full gdb traces below:
Breakpoint 1, multi_cpu_stop (data=0x0) at kernel/stop_machine.c:191
191 cpu_relax();
(gdb) bt
#0 multi_cpu_stop (data=0x0) at kernel/stop_machine.c:191
#1 0xffc00011e750 in cpu_stopper_thread (cpu=) at
kernel/stop_machine.c:473
#2 0xffcce118 in smpboot_thread_fn (data=0xffc00581b980)
at kernel/smpboot.c:161
#3 0xffccae1c in kthread (_create=0xffc00581bb00) at
kernel/kthread.c:207
#4 0xffc85bf0 in ret_from_fork () at arch/arm64/kernel/entry.S:635
#5 0xffc85bf0 in ret_from_fork () at arch/arm64/kernel/entry.S:635
Breakpoint 1, ktime_get_update_offsets_tick
(offs_real=0xffc005987b70, offs_boot=0xffc005987b68,
offs_tai=0xffc005987b60) at kernel/time/timekeeping.c:1785
1785 seq = read_seqcount_begin(_core.seq);
(gdb) bt
#0 ktime_get_update_offsets_tick (offs_real=0xffc005987b70,
offs_boot=0xffc005987b68, offs_tai=0xffc005987b60)
at kernel/time/timekeeping.c:1785
#1 0xffcfbe0c in hrtimer_get_softirq_time (base=) at kernel/time/hrtimer.c:122
#2 hrtimer_run_queues () at kernel/time/hrtimer.c:1448
#3 0xffcfaaac in run_local_timers () at kernel/time/timer.c:1411
#4 update_process_times (user_tick=0) at kernel/time/timer.c:1383
#5 0xffc000106dfc in tick_periodic (cpu=) at
kernel/time/tick-common.c:91
#6 0xffc000107048 in tick_handle_periodic
(dev=0xffc006fcff40) at kernel/time/tick-common.c:103
#7 0xffc000469e30 in timer_handler (evt=,
access=)
at drivers/clocksource/arm_arch_timer.c:148
#8 arch_timer_handler_virt (irq=, dev_id=) at drivers/clocksource/arm_arch_timer.c:159
#9 0xffceef7c in handle_percpu_devid_irq (irq=3,
desc=0xffc005804800) at kernel/irq/chip.c:714
#10 0xffceb0d4 in generic_handle_irq_desc (desc=, irq=) at include/linux/irqdesc.h:128
#11 generic_handle_irq (irq=3) at kernel/irq/irqdesc.c:351
#12 0xffceb3e4 in __handle_domain_irq (domain=,
hwirq=, lookup=true,
regs=) at kernel/irq/irqdesc.c:388
#13 0xffc8241c in handle_domain_irq (regs=,
hwirq=, domain=)
at include/linux/irqdesc.h:146
#14 gic_handle_irq (regs=0xffc005987cc0) at drivers/irqchip/irq-gic.c:276
which I think is this:
106 static inline unsigned __read_seqcount_begin(const seqcount_t *s)
107 {
108 >~~~unsigned ret;
109
110 repeat:
111 >~~~ret = READ_ONCE(s->sequence);
112 >~~~if (unlikely(ret & 1)) {
113 >~~~>~~~cpu_relax();
114 >~~~>~~~goto repeat;
115 >~~~}
116 >~~~return ret;
117 }
Breakpoint 1, csd_lock_wait (csd=) at kernel/smp.c:111
111 cpu_relax();
(gdb) bt
#0 csd_lock_wait (csd=) at kernel/smp.c:111
#1 smp_call_function_many (mask=,
func=0xffc83800 , info=0x0, wait=true)
at kernel/smp.c:449
#2 0xffc00010ddc0 in smp_call_function (func=,
info=, wait=)
at kernel/smp.c:473
#3 0xffc00010de20 in on_each_cpu (func=0xffc83800
, info=0x0, wait=)
at kernel/smp.c:579
#4 0xffc8385c in debug_monitors_init () at
arch/arm64/kernel/debug-monitors.c:151
#5 0xffc828c8 in do_one_initcall (fn=0xffc8383c
) at init/main.c:785
#6 0xffc00073baf0 in do_initcall_level (level=) at
init/main.c:850
#7 do_initcalls () at init/main.c:858
#8 do_basic_setup () at init/main.c:877
#9 kernel_init_freeable () at init/main.c:998
#10 0xffc00054be04 in kernel_init (unused=) at
init/main.c:928
#11 0xffc85bf0 in re
Re: [RFC PATCH] arm64: Implement cpu_relax as yield
On Wed, Feb 25, 2015 at 5:24 AM, Will Deacon will.dea...@arm.com wrote:
On Tue, Feb 24, 2015 at 11:07:37PM +, Peter Crosthwaite wrote:
ARM64 has the yield nop hint which has the intended semantics of
cpu_relax. Implement.
The immediate application is ARM CPU emulators. An emulator can take
advantage of the yield hint to de-prioritise an emulated CPU in favor
of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
and sees a significant boot time performance increase with this change.
Could you elaborate on the QEMU SMP boot case please? Usually SMP pens
for booting make use of wfe/sev to minimise the spinning overhead.
So I did some follow up experiments. With my patch applied I started
trapping instances of cpu_relax (now yielding) in gdb. I then
commented out the cpu_relax's one by one.
This one seems to be the key:
diff --git a/kernel/smp.c b/kernel/smp.c
index f38a1e6..1c692be 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -108,7 +108,8 @@ void __init call_function_init(void)
static void csd_lock_wait(struct call_single_data *csd)
{
while (csd-flags CSD_FLAG_LOCK)
- cpu_relax();
+ ;
+ //cpu_relax();
}
Hack above causes boot time delay even with my patch applied, so this
is causing my issue it seems.
I found three cpu_relax calls that each seems to do some spinning in
the boot. There probably will be more, but I stopped after finding to
above issue. Full gdb traces below:
Breakpoint 1, multi_cpu_stop (data=0x0) at kernel/stop_machine.c:191
191 cpu_relax();
(gdb) bt
#0 multi_cpu_stop (data=0x0) at kernel/stop_machine.c:191
#1 0xffc00011e750 in cpu_stopper_thread (cpu=optimized out) at
kernel/stop_machine.c:473
#2 0xffcce118 in smpboot_thread_fn (data=0xffc00581b980)
at kernel/smpboot.c:161
#3 0xffccae1c in kthread (_create=0xffc00581bb00) at
kernel/kthread.c:207
#4 0xffc85bf0 in ret_from_fork () at arch/arm64/kernel/entry.S:635
#5 0xffc85bf0 in ret_from_fork () at arch/arm64/kernel/entry.S:635
Breakpoint 1, ktime_get_update_offsets_tick
(offs_real=0xffc005987b70, offs_boot=0xffc005987b68,
offs_tai=0xffc005987b60) at kernel/time/timekeeping.c:1785
1785 seq = read_seqcount_begin(tk_core.seq);
(gdb) bt
#0 ktime_get_update_offsets_tick (offs_real=0xffc005987b70,
offs_boot=0xffc005987b68, offs_tai=0xffc005987b60)
at kernel/time/timekeeping.c:1785
#1 0xffcfbe0c in hrtimer_get_softirq_time (base=optimized
out) at kernel/time/hrtimer.c:122
#2 hrtimer_run_queues () at kernel/time/hrtimer.c:1448
#3 0xffcfaaac in run_local_timers () at kernel/time/timer.c:1411
#4 update_process_times (user_tick=0) at kernel/time/timer.c:1383
#5 0xffc000106dfc in tick_periodic (cpu=optimized out) at
kernel/time/tick-common.c:91
#6 0xffc000107048 in tick_handle_periodic
(dev=0xffc006fcff40) at kernel/time/tick-common.c:103
#7 0xffc000469e30 in timer_handler (evt=optimized out,
access=optimized out)
at drivers/clocksource/arm_arch_timer.c:148
#8 arch_timer_handler_virt (irq=optimized out, dev_id=optimized
out) at drivers/clocksource/arm_arch_timer.c:159
#9 0xffceef7c in handle_percpu_devid_irq (irq=3,
desc=0xffc005804800) at kernel/irq/chip.c:714
#10 0xffceb0d4 in generic_handle_irq_desc (desc=optimized
out, irq=optimized out) at include/linux/irqdesc.h:128
#11 generic_handle_irq (irq=3) at kernel/irq/irqdesc.c:351
#12 0xffceb3e4 in __handle_domain_irq (domain=optimized out,
hwirq=optimized out, lookup=true,
regs=optimized out) at kernel/irq/irqdesc.c:388
#13 0xffc8241c in handle_domain_irq (regs=optimized out,
hwirq=optimized out, domain=optimized out)
at include/linux/irqdesc.h:146
#14 gic_handle_irq (regs=0xffc005987cc0) at drivers/irqchip/irq-gic.c:276
which I think is this:
106 static inline unsigned __read_seqcount_begin(const seqcount_t *s)
107 {
108 ~~~unsigned ret;
109
110 repeat:
111 ~~~ret = READ_ONCE(s-sequence);
112 ~~~if (unlikely(ret 1)) {
113 ~~cpu_relax();
114 ~~goto repeat;
115 ~~~}
116 ~~~return ret;
117 }
Breakpoint 1, csd_lock_wait (csd=optimized out) at kernel/smp.c:111
111 cpu_relax();
(gdb) bt
#0 csd_lock_wait (csd=optimized out) at kernel/smp.c:111
#1 smp_call_function_many (mask=optimized out,
func=0xffc83800 clear_os_lock, info=0x0, wait=true)
at kernel/smp.c:449
#2 0xffc00010ddc0 in smp_call_function (func=optimized out,
info=optimized out, wait=optimized out)
at kernel/smp.c:473
#3 0xffc00010de20 in on_each_cpu (func=0xffc83800
clear_os_lock, info=0x0, wait=optimized out)
at kernel/smp.c:579
#4 0xffc8385c in debug_monitors_init () at
arch/arm64/kernel/debug-monitors.c:151
#5 0xffc828c8 in do_one_initcall (fn=0xffc8383c
debug_monitors_init) at init/main.c:785
#6 0xffc00073baf0 in do_initcall_level (level=optimized out) at
init
[PATCH] tty: serial: xilinx_uartps: Use Macro for ttyPS0
All instances of "ttyPS" use this macro except for this one. Convert
it.
Signed-off-by: Peter Crosthwaite
Acked-by: Michal Simek
---
drivers/tty/serial/xilinx_uartps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index cff531a..8f9c543 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1154,7 +1154,8 @@ static int __init cdns_uart_console_setup(struct console
*co, char *options)
return -EINVAL;
if (!port->mapbase) {
- pr_debug("console on ttyPS%i not present\n", co->index);
+ pr_debug("console on " CDNS_UART_TTY_NAME "%i not present\n",
+co->index);
return -ENODEV;
}
--
2.3.0.1.g27a12f1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] arm64: Implement cpu_relax as yield
ARM64 has the yield nop hint which has the intended semantics of
cpu_relax. Implement.
The immediate application is ARM CPU emulators. An emulator can take
advantage of the yield hint to de-prioritise an emulated CPU in favor
of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
and sees a significant boot time performance increase with this change.
Signed-off-by: Peter Crosthwaite
---
arch/arm64/include/asm/processor.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index f9be30e..ac2381d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -126,7 +126,11 @@ extern void release_thread(struct task_struct *);
unsigned long get_wchan(struct task_struct *p);
-#define cpu_relax()barrier()
+static inline void cpu_relax(void)
+{
+ asm volatile("yield" ::: "memory");
+}
+
#define cpu_relax_lowlatency()cpu_relax()
/* Thread switching */
--
2.3.0.1.g27a12f1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: serial: xilinx_uartps: Use Macro for ttyPS0
All instances of ttyPS use this macro except for this one. Convert
it.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Acked-by: Michal Simek michal.si...@xilinx.com
---
drivers/tty/serial/xilinx_uartps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index cff531a..8f9c543 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1154,7 +1154,8 @@ static int __init cdns_uart_console_setup(struct console
*co, char *options)
return -EINVAL;
if (!port-mapbase) {
- pr_debug(console on ttyPS%i not present\n, co-index);
+ pr_debug(console on CDNS_UART_TTY_NAME %i not present\n,
+co-index);
return -ENODEV;
}
--
2.3.0.1.g27a12f1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] arm64: Implement cpu_relax as yield
ARM64 has the yield nop hint which has the intended semantics of
cpu_relax. Implement.
The immediate application is ARM CPU emulators. An emulator can take
advantage of the yield hint to de-prioritise an emulated CPU in favor
of other emulation tasks. QEMU A64 SMP emulation has yield awareness,
and sees a significant boot time performance increase with this change.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
---
arch/arm64/include/asm/processor.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index f9be30e..ac2381d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -126,7 +126,11 @@ extern void release_thread(struct task_struct *);
unsigned long get_wchan(struct task_struct *p);
-#define cpu_relax()barrier()
+static inline void cpu_relax(void)
+{
+ asm volatile(yield ::: memory);
+}
+
#define cpu_relax_lowlatency()cpu_relax()
/* Thread switching */
--
2.3.0.1.g27a12f1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] arm: dts: zynq: Add Digilent ZYBO board
On Sat, Nov 29, 2014 at 1:34 PM, Sören Brinkmann wrote: > Hi Peter, > > The patches look all good to me. But you may want to check your CC > lists. I think at least the DT list should be included. > Resent > For the whole series: > Acked-by: Soren Brinkmann > Thanks, Regards, Peter > Thanks, > Sören > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] arm: dts: zynq: Add Digilent ZYBO board
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.
Acked-by: Soren Brinkmann
Signed-off-by: Peter Crosthwaite
---
Changed since v1:
Change compat vendor prefix from xlnx to digilent (Soren review)
Alphabetise nodes
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/zynq-zybo.dts | 52 +
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/zynq-zybo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7cd36a7..be2e8ce 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -513,7 +513,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-parallella.dtb \
zynq-zc702.dtb \
zynq-zc706.dtb \
- zynq-zed.dtb
+ zynq-zed.dtb \
+ zynq-zybo.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
armada-370-db.dtb \
armada-370-mirabox.dtb \
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
new file mode 100644
index 000..a9a12ce
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2012 National Instruments Corp.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+/include/ "zynq-7000.dtsi"
+
+/ {
+ model = "Zynq ZYBO Development Board";
+ compatible = "digilent,zynq-zybo", "xlnx,zynq-7000";
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyPS0,115200 earlyprintk";
+ };
+
+};
+
+ {
+ ps-clk-frequency = <5000>;
+};
+
+ {
+ status = "okay";
+ phy-mode = "rgmii-id";
+ phy-handle = <_phy>;
+
+ ethernet_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] arm: dts: zynq: Move crystal freq. to board level
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Acked-by: Soren Brinkmann
Signed-off-by: Peter Crosthwaite
---
Changed since v1:
Alphabetize node ordering (Soren review)
Im guessing long term this should be converted to a fixed clock. But
I think this at least steps in that direction.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 -
arch/arm/boot/dts/zynq-parallella.dts | 1 +
arch/arm/boot/dts/zynq-zc702.dts | 4
arch/arm/boot/dts/zynq-zc706.dts | 4
arch/arm/boot/dts/zynq-zed.dts| 4
5 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5b..ee3e5d6 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -243,7 +243,6 @@
clkc: clkc@100 {
#clock-cells = <1>;
compatible = "xlnx,ps7-clkc";
- ps-clk-frequency = <>;
fclk-enable = <0>;
clock-output-names = "armpll", "ddrpll",
"iopll", "cpu_6or4x",
"cpu_3or2x", "cpu_2x",
"cpu_1x", "ddr2x", "ddr3x",
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index 0429bbd..b5792cab 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -35,6 +35,7 @@
};
{
+ ps-clk-frequency = <>;
fclk-enable = <0xf>;
};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda..280f02d 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -42,6 +42,10 @@
status = "okay";
};
+ {
+ ps-clk-frequency = <>;
+};
+
{
status = "okay";
phy-mode = "rgmii-id";
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index a8bbdfb..34f7812 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -29,6 +29,10 @@
};
+ {
+ ps-clk-frequency = <>;
+};
+
{
status = "okay";
phy-mode = "rgmii-id";
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 697779a..1c7cc99 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -29,6 +29,10 @@
};
+ {
+ ps-clk-frequency = <>;
+};
+
{
status = "okay";
phy-mode = "rgmii-id";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] doc: dt: vendor-prefixes: Add Digilent Inc
Digilent is a board designer, making various Linux capabable FPGA and processor boards. Add to the vendor list. Acked-by: Soren Brinkmann Signed-off-by: Peter Crosthwaite --- http://www.digilentinc.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index c177cd7..b1df0ad 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -41,6 +41,7 @@ dallasMaxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. denx Denx Software Engineering digi Digi International Inc. +digilent Diglent, Inc. dlgDialog Semiconductor dlink D-Link Corporation dmoData Modul AG -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] arm: dts: zynq: Add Digilent ZYBO board
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.
Acked-by: Soren Brinkmann soren.brinkm...@xilinx.com
Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com
---
Changed since v1:
Change compat vendor prefix from xlnx to digilent (Soren review)
Alphabetise nodes
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/zynq-zybo.dts | 52 +
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/zynq-zybo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7cd36a7..be2e8ce 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -513,7 +513,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-parallella.dtb \
zynq-zc702.dtb \
zynq-zc706.dtb \
- zynq-zed.dtb
+ zynq-zed.dtb \
+ zynq-zybo.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
armada-370-db.dtb \
armada-370-mirabox.dtb \
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
new file mode 100644
index 000..a9a12ce
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2012 National Instruments Corp.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+/include/ zynq-7000.dtsi
+
+/ {
+ model = Zynq ZYBO Development Board;
+ compatible = digilent,zynq-zybo, xlnx,zynq-7000;
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x2000;
+ };
+
+ chosen {
+ bootargs = console=ttyPS0,115200 earlyprintk;
+ };
+
+};
+
+clkc {
+ ps-clk-frequency = 5000;
+};
+
+gem0 {
+ status = okay;
+ phy-mode = rgmii-id;
+ phy-handle = ethernet_phy;
+
+ ethernet_phy: ethernet-phy@0 {
+ reg = 0;
+ };
+};
+
+sdhci0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] arm: dts: zynq: Move crystal freq. to board level
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Acked-by: Soren Brinkmann soren.brinkm...@xilinx.com
Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com
---
Changed since v1:
Alphabetize node ordering (Soren review)
Im guessing long term this should be converted to a fixed clock. But
I think this at least steps in that direction.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 -
arch/arm/boot/dts/zynq-parallella.dts | 1 +
arch/arm/boot/dts/zynq-zc702.dts | 4
arch/arm/boot/dts/zynq-zc706.dts | 4
arch/arm/boot/dts/zynq-zed.dts| 4
5 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5b..ee3e5d6 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -243,7 +243,6 @@
clkc: clkc@100 {
#clock-cells = 1;
compatible = xlnx,ps7-clkc;
- ps-clk-frequency = ;
fclk-enable = 0;
clock-output-names = armpll, ddrpll,
iopll, cpu_6or4x,
cpu_3or2x, cpu_2x,
cpu_1x, ddr2x, ddr3x,
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index 0429bbd..b5792cab 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -35,6 +35,7 @@
};
clkc {
+ ps-clk-frequency = ;
fclk-enable = 0xf;
};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda..280f02d 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -42,6 +42,10 @@
status = okay;
};
+clkc {
+ ps-clk-frequency = ;
+};
+
gem0 {
status = okay;
phy-mode = rgmii-id;
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index a8bbdfb..34f7812 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -29,6 +29,10 @@
};
+clkc {
+ ps-clk-frequency = ;
+};
+
gem0 {
status = okay;
phy-mode = rgmii-id;
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 697779a..1c7cc99 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -29,6 +29,10 @@
};
+clkc {
+ ps-clk-frequency = ;
+};
+
gem0 {
status = okay;
phy-mode = rgmii-id;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] doc: dt: vendor-prefixes: Add Digilent Inc
Digilent is a board designer, making various Linux capabable FPGA and processor boards. Add to the vendor list. Acked-by: Soren Brinkmann soren.brinkm...@xilinx.com Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com --- http://www.digilentinc.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index c177cd7..b1df0ad 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -41,6 +41,7 @@ dallasMaxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. denx Denx Software Engineering digi Digi International Inc. +digilent Diglent, Inc. dlgDialog Semiconductor dlink D-Link Corporation dmoData Modul AG -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 3/3] arm: dts: zynq: Add Digilent ZYBO board
On Sat, Nov 29, 2014 at 1:34 PM, Sören Brinkmann soren.brinkm...@xilinx.com wrote: Hi Peter, The patches look all good to me. But you may want to check your CC lists. I think at least the DT list should be included. Resent For the whole series: Acked-by: Soren Brinkmann soren.brinkm...@xilinx.com Thanks, Regards, Peter Thanks, Sören -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
Hi Steve,
On Tue, Nov 11, 2014 at 12:10 PM, Steve Wang
wrote:
> Hi, Peter,
>
> According to naming convention, I think "dglnt" is good enough ^.^
>
> By the way, I think there is a need to address another issue that needs to
> be addressed for ZYBO as well (maybe in a separate thread):
> MAC address pre-load from on-board EEPROM.
So i'm not doing any networking work so I don't have visibility of
this feature. My understanding though is its an extra feature and
default networking behaviour provided by the SoC should still be
functional making this follow up work?
The alternative would be to disable gem in the dts on first commit.
> I think ZYBO might still be the only Zynq-based board that has an on-board
> EEPROM for MAC address as well.
>
Is that just software policy though? Should there be DTS level
awareness of MAC address via EEPROM contents or should the dts just
describe the EEPROM?
Regards,
Peter
> Regards,
> Steve
>
> -Peter Crosthwaite wrote: -
> To: Sören Brinkmann , Steve Wang
>
> From: Peter Crosthwaite
> Date: 11/10/2014 02:56PM
> Cc: linux-kernel@vger.kernel.org, mich...@xilinx.com, sor...@xilinx.com
> Subject: Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
>
>
> On Tue, Nov 11, 2014 at 8:42 AM, Sören Brinkmann
> wrote:
>> On Tue, 2014-11-11 at 08:39AM +1000, Peter Crosthwaite wrote:
>>> On Mon, Nov 10, 2014 at 7:47 AM, Sören Brinkmann
>>> wrote:
>>> > Hi Peter,
>>> >
>>> > On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
>>> >> Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
>>> >
>>> > "Digilent ZYBO" here...
>>> >
>>> > [...]
>>> >> +/ {
>>> >> + model = "Zynq ZYBO Development Board";
>>> >> + compatible = "xlnx,zynq-zybo", "xlnx,zynq-7000";
>>> >
>>> > ... "xlnx,zynq-zybo" here. Seems inconsistent. IMHO, there should
>>> > rather be
>>> > a digilent vendor prefix.
>>> >
>>>
>>> Was going for consistency with ZED which also makes this mistake:
>>>
>>> model = "Zynq Zed Development Board";
>>> compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
>>>
>>> We have to choose between consistency and correctness. If we do fix it
>>> though, what is Diglent's four-letter vendor prefix?
>>
>> Since Digilent is the board vendor, I'm for using the appropriate
>> prefix. Vendor prefixes are found in
>> Documentation/devicetree/bindings/vendor-prefixes.txt.
>>
>
> It's not there,
>
> Steven, does Digilent have a preferred dts vendor prefix?
>
> Regards,
> Peter
>
>> Soren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/3] arm: dts: zynq: Add Digilent ZYBO board
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.
Signed-off-by: Peter Crosthwaite
---
Changed since v1:
Change compat vendor prefix from xlnx to digilent (Soren review)
Alphabetise nodes
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/zynq-zybo.dts | 52 +
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/zynq-zybo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7cd36a7..be2e8ce 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -513,7 +513,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-parallella.dtb \
zynq-zc702.dtb \
zynq-zc706.dtb \
- zynq-zed.dtb
+ zynq-zed.dtb \
+ zynq-zybo.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
armada-370-db.dtb \
armada-370-mirabox.dtb \
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
new file mode 100644
index 000..a9a12ce
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2012 National Instruments Corp.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+/include/ "zynq-7000.dtsi"
+
+/ {
+ model = "Zynq ZYBO Development Board";
+ compatible = "digilent,zynq-zybo", "xlnx,zynq-7000";
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyPS0,115200 earlyprintk";
+ };
+
+};
+
+ {
+ ps-clk-frequency = <5000>;
+};
+
+ {
+ status = "okay";
+ phy-mode = "rgmii-id";
+ phy-handle = <_phy>;
+
+ ethernet_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/3] doc: dt: vendor-prefixes: Add Digilent Inc
Digilent is a board designer, making various Linux capabable FPGA and processor boards. Add to the vendor list. Signed-off-by: Peter Crosthwaite --- http://www.digilentinc.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index c177cd7..b1df0ad 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -41,6 +41,7 @@ dallasMaxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. denx Denx Software Engineering digi Digi International Inc. +digilent Diglent, Inc. dlgDialog Semiconductor dlink D-Link Corporation dmoData Modul AG -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/3] arm: dts: zynq: Move crystal freq. to board level
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Signed-off-by: Peter Crosthwaite
---
Changed since v1:
Alphabetize node ordering (Soren review)
Im guessing long term this should be converted to a fixed clock. But
I think this at least steps in that direction.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 -
arch/arm/boot/dts/zynq-parallella.dts | 1 +
arch/arm/boot/dts/zynq-zc702.dts | 4
arch/arm/boot/dts/zynq-zc706.dts | 4
arch/arm/boot/dts/zynq-zed.dts| 4
5 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5b..ee3e5d6 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -243,7 +243,6 @@
clkc: clkc@100 {
#clock-cells = <1>;
compatible = "xlnx,ps7-clkc";
- ps-clk-frequency = <>;
fclk-enable = <0>;
clock-output-names = "armpll", "ddrpll",
"iopll", "cpu_6or4x",
"cpu_3or2x", "cpu_2x",
"cpu_1x", "ddr2x", "ddr3x",
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index 0429bbd..b5792cab 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -35,6 +35,7 @@
};
{
+ ps-clk-frequency = <>;
fclk-enable = <0xf>;
};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda..280f02d 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -42,6 +42,10 @@
status = "okay";
};
+ {
+ ps-clk-frequency = <>;
+};
+
{
status = "okay";
phy-mode = "rgmii-id";
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index a8bbdfb..34f7812 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -29,6 +29,10 @@
};
+ {
+ ps-clk-frequency = <>;
+};
+
{
status = "okay";
phy-mode = "rgmii-id";
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 697779a..1c7cc99 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -29,6 +29,10 @@
};
+ {
+ ps-clk-frequency = <>;
+};
+
{
status = "okay";
phy-mode = "rgmii-id";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/3] doc: dt: vendor-prefixes: Add Digilent Inc
Digilent is a board designer, making various Linux capabable FPGA and processor boards. Add to the vendor list. Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com --- http://www.digilentinc.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index c177cd7..b1df0ad 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -41,6 +41,7 @@ dallasMaxim Integrated Products (formerly Dallas Semiconductor) davicomDAVICOM Semiconductor, Inc. denx Denx Software Engineering digi Digi International Inc. +digilent Diglent, Inc. dlgDialog Semiconductor dlink D-Link Corporation dmoData Modul AG -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/3] arm: dts: zynq: Move crystal freq. to board level
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com
---
Changed since v1:
Alphabetize node ordering (Soren review)
Im guessing long term this should be converted to a fixed clock. But
I think this at least steps in that direction.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 -
arch/arm/boot/dts/zynq-parallella.dts | 1 +
arch/arm/boot/dts/zynq-zc702.dts | 4
arch/arm/boot/dts/zynq-zc706.dts | 4
arch/arm/boot/dts/zynq-zed.dts| 4
5 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5b..ee3e5d6 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -243,7 +243,6 @@
clkc: clkc@100 {
#clock-cells = 1;
compatible = xlnx,ps7-clkc;
- ps-clk-frequency = ;
fclk-enable = 0;
clock-output-names = armpll, ddrpll,
iopll, cpu_6or4x,
cpu_3or2x, cpu_2x,
cpu_1x, ddr2x, ddr3x,
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index 0429bbd..b5792cab 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -35,6 +35,7 @@
};
clkc {
+ ps-clk-frequency = ;
fclk-enable = 0xf;
};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda..280f02d 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -42,6 +42,10 @@
status = okay;
};
+clkc {
+ ps-clk-frequency = ;
+};
+
gem0 {
status = okay;
phy-mode = rgmii-id;
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index a8bbdfb..34f7812 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -29,6 +29,10 @@
};
+clkc {
+ ps-clk-frequency = ;
+};
+
gem0 {
status = okay;
phy-mode = rgmii-id;
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 697779a..1c7cc99 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -29,6 +29,10 @@
};
+clkc {
+ ps-clk-frequency = ;
+};
+
gem0 {
status = okay;
phy-mode = rgmii-id;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/3] arm: dts: zynq: Add Digilent ZYBO board
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.
Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com
---
Changed since v1:
Change compat vendor prefix from xlnx to digilent (Soren review)
Alphabetise nodes
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/zynq-zybo.dts | 52 +
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/zynq-zybo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7cd36a7..be2e8ce 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -513,7 +513,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-parallella.dtb \
zynq-zc702.dtb \
zynq-zc706.dtb \
- zynq-zed.dtb
+ zynq-zed.dtb \
+ zynq-zybo.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
armada-370-db.dtb \
armada-370-mirabox.dtb \
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
new file mode 100644
index 000..a9a12ce
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2012 National Instruments Corp.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+/include/ zynq-7000.dtsi
+
+/ {
+ model = Zynq ZYBO Development Board;
+ compatible = digilent,zynq-zybo, xlnx,zynq-7000;
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x2000;
+ };
+
+ chosen {
+ bootargs = console=ttyPS0,115200 earlyprintk;
+ };
+
+};
+
+clkc {
+ ps-clk-frequency = 5000;
+};
+
+gem0 {
+ status = okay;
+ phy-mode = rgmii-id;
+ phy-handle = ethernet_phy;
+
+ ethernet_phy: ethernet-phy@0 {
+ reg = 0;
+ };
+};
+
+sdhci0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
Hi Steve,
On Tue, Nov 11, 2014 at 12:10 PM, Steve Wang
steven.w...@digilentinc.com wrote:
Hi, Peter,
According to naming convention, I think dglnt is good enough ^.^
By the way, I think there is a need to address another issue that needs to
be addressed for ZYBO as well (maybe in a separate thread):
MAC address pre-load from on-board EEPROM.
So i'm not doing any networking work so I don't have visibility of
this feature. My understanding though is its an extra feature and
default networking behaviour provided by the SoC should still be
functional making this follow up work?
The alternative would be to disable gem in the dts on first commit.
I think ZYBO might still be the only Zynq-based board that has an on-board
EEPROM for MAC address as well.
Is that just software policy though? Should there be DTS level
awareness of MAC address via EEPROM contents or should the dts just
describe the EEPROM?
Regards,
Peter
Regards,
Steve
-Peter Crosthwaite crosthwaitepe...@gmail.com wrote: -
To: Sören Brinkmann soren.brinkm...@xilinx.com, Steve Wang
steven.w...@digilentinc.com
From: Peter Crosthwaite crosthwaitepe...@gmail.com
Date: 11/10/2014 02:56PM
Cc: linux-kernel@vger.kernel.org, mich...@xilinx.com, sor...@xilinx.com
Subject: Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
On Tue, Nov 11, 2014 at 8:42 AM, Sören Brinkmann
soren.brinkm...@xilinx.com wrote:
On Tue, 2014-11-11 at 08:39AM +1000, Peter Crosthwaite wrote:
On Mon, Nov 10, 2014 at 7:47 AM, Sören Brinkmann
soren.brinkm...@xilinx.com wrote:
Hi Peter,
On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
Digilent ZYBO here...
[...]
+/ {
+ model = Zynq ZYBO Development Board;
+ compatible = xlnx,zynq-zybo, xlnx,zynq-7000;
... xlnx,zynq-zybo here. Seems inconsistent. IMHO, there should
rather be
a digilent vendor prefix.
Was going for consistency with ZED which also makes this mistake:
model = Zynq Zed Development Board;
compatible = xlnx,zynq-zed, xlnx,zynq-7000;
We have to choose between consistency and correctness. If we do fix it
though, what is Diglent's four-letter vendor prefix?
Since Digilent is the board vendor, I'm for using the appropriate
prefix. Vendor prefixes are found in
Documentation/devicetree/bindings/vendor-prefixes.txt.
It's not there,
Steven, does Digilent have a preferred dts vendor prefix?
Regards,
Peter
Soren
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node
On Mon, Nov 17, 2014 at 5:32 AM, Sören Brinkmann
wrote:
> On Sun, 2014-11-16 at 11:51AM +0100, Andreas Färber wrote:
>> Hi Michal,
>>
>> Am 14.11.2014 um 11:52 schrieb Michal Simek:
>> > diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
>> > b/arch/arm/boot/dts/zynq-7000.dtsi
>> > index ce2ef5bec4f2..e217fb1c1169 100644
>> > --- a/arch/arm/boot/dts/zynq-7000.dtsi
>> > +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>> > @@ -150,6 +150,13 @@
>> > reg = <0xf8006000 0x1000>;
>> > };
>> >
>> > + ocmc: memory-controller@f800c000 {
>> > + compatible = "xlnx,zynq-ocmc-1.0";
>> > + interrupt-parent = <>;
>> > + interrupts = <0 3 4>;
>> > + reg = <0xf800c000 0x1000>;
>> > + };
>> > +
>> > uart0: serial@e000 {
>> > compatible = "xlnx,xuartps", "cdns,uart-r1p8";
>> > status = "disabled";
>>
>> Not directly related to this patch: As one can see here, the node order
>> is quite a mess... According to Olof, nodes should be ordered by unit
>> address, whereas here some but not all seem ordered by node name. Would
>> you welcome a cleanup patch, or can you fix that yourself?
>
> I wouldn't say it's a mess, just a different property to sort the nodes
> by. For humans reading the DT, searching for nodes, alphabetical order
> helps finding the right node, IMHO.
I do generally find myself asking "whats that thing at that address"
more than I find myself asking the "wheres that piece of hardware" so
Andreas' sorting scheme makes more sense to me. Vertically scanning a
DT to give yourself an overview of the system level address map is
good too. Wheras alphabetic sorting doesn't mean to much.
Regards,
Peter
What advantage would sorting by
> address have?
>
> Thanks,
> Sören
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 6/6] ARM: zynq: DT: Add OCM controller node
On Mon, Nov 17, 2014 at 5:32 AM, Sören Brinkmann
soren.brinkm...@xilinx.com wrote:
On Sun, 2014-11-16 at 11:51AM +0100, Andreas Färber wrote:
Hi Michal,
Am 14.11.2014 um 11:52 schrieb Michal Simek:
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5bec4f2..e217fb1c1169 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -150,6 +150,13 @@
reg = 0xf8006000 0x1000;
};
+ ocmc: memory-controller@f800c000 {
+ compatible = xlnx,zynq-ocmc-1.0;
+ interrupt-parent = intc;
+ interrupts = 0 3 4;
+ reg = 0xf800c000 0x1000;
+ };
+
uart0: serial@e000 {
compatible = xlnx,xuartps, cdns,uart-r1p8;
status = disabled;
Not directly related to this patch: As one can see here, the node order
is quite a mess... According to Olof, nodes should be ordered by unit
address, whereas here some but not all seem ordered by node name. Would
you welcome a cleanup patch, or can you fix that yourself?
I wouldn't say it's a mess, just a different property to sort the nodes
by. For humans reading the DT, searching for nodes, alphabetical order
helps finding the right node, IMHO.
I do generally find myself asking whats that thing at that address
more than I find myself asking the wheres that piece of hardware so
Andreas' sorting scheme makes more sense to me. Vertically scanning a
DT to give yourself an overview of the system level address map is
good too. Wheras alphabetic sorting doesn't mean to much.
Regards,
Peter
What advantage would sorting by
address have?
Thanks,
Sören
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
On Tue, Nov 11, 2014 at 8:42 AM, Sören Brinkmann
wrote:
> On Tue, 2014-11-11 at 08:39AM +1000, Peter Crosthwaite wrote:
>> On Mon, Nov 10, 2014 at 7:47 AM, Sören Brinkmann
>> wrote:
>> > Hi Peter,
>> >
>> > On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
>> >> Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
>> >
>> > "Digilent ZYBO" here...
>> >
>> > [...]
>> >> +/ {
>> >> + model = "Zynq ZYBO Development Board";
>> >> + compatible = "xlnx,zynq-zybo", "xlnx,zynq-7000";
>> >
>> > ... "xlnx,zynq-zybo" here. Seems inconsistent. IMHO, there should rather be
>> > a digilent vendor prefix.
>> >
>>
>> Was going for consistency with ZED which also makes this mistake:
>>
>> model = "Zynq Zed Development Board";
>> compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
>>
>> We have to choose between consistency and correctness. If we do fix it
>> though, what is Diglent's four-letter vendor prefix?
>
> Since Digilent is the board vendor, I'm for using the appropriate
> prefix. Vendor prefixes are found in
> Documentation/devicetree/bindings/vendor-prefixes.txt.
>
It's not there,
Steven, does Digilent have a preferred dts vendor prefix?
Regards,
Peter
> Soren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
On Mon, Nov 10, 2014 at 7:47 AM, Sören Brinkmann
wrote:
> Hi Peter,
>
> On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
>> Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
>
> "Digilent ZYBO" here...
>
> [...]
>> +/ {
>> + model = "Zynq ZYBO Development Board";
>> + compatible = "xlnx,zynq-zybo", "xlnx,zynq-7000";
>
> ... "xlnx,zynq-zybo" here. Seems inconsistent. IMHO, there should rather be
> a digilent vendor prefix.
>
Was going for consistency with ZED which also makes this mistake:
model = "Zynq Zed Development Board";
compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
We have to choose between consistency and correctness. If we do fix it
though, what is Diglent's four-letter vendor prefix?
Regards,
Peter
> Everything else looks pretty straight forward and good.
>
> Soren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: dts: zynq: Move crystal freq. to board level
On Mon, Nov 10, 2014 at 7:34 AM, Sören Brinkmann
wrote:
> On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
>> The fact that all supported boards use the same 33MHz crystal is a
>> co-incidence. The Zynq PS support a range of crystal freqs so the
>> hardcoded setting should be removed from the dtsi. Re-implement it
>> on the board level.
>>
>> This prepares support for Zynq boards with different crystal
>> frequencies (e.g. the Digilent ZYBO).
>
> Even with the 33MHz in the dtsi you can override it on the board-level.
> Just like the 'status' property is overriden in board dts files.
>
Do you want the deletion undone? Even with override capability I think
it should be removed as the number is board level specific and the
dtsi should be limited to SoC level information.
My understanding is the driver will default to 33MHz as well as a
catch-all, so anyone rolling their own top level OOT DTS is going to
be ok too.
>>
>> Signed-off-by: Peter Crosthwaite
>>
>> ---
>> Im guessing long term this should be converted to a fixed clock. But
>> I think this at least steps in that direction.
>
> I was against that since it makes juggling with clock names more
> difficult. The problem is that the CCF uses a global name space of clock
> names.
I thought it was just a
clocks = < >
Where's the namespacing issue?
Btw I think the clocks=phandle would be populated the the dts as well.
So the DTSI would have no clocks = node, and the dts must populate it.
This allows support for an on-board off-soc clock controller
controlling the PS clock (which is in theory supported by the SoC).
Not having the oscillator as fixed-clock in DT removed that
> additional complexity. But it would be possible, I guess.
>
>> ---
>> arch/arm/boot/dts/zynq-7000.dtsi | 1 -
>> arch/arm/boot/dts/zynq-parallella.dts | 4
>> arch/arm/boot/dts/zynq-zc702.dts | 4
>> arch/arm/boot/dts/zynq-zc706.dts | 4
>> arch/arm/boot/dts/zynq-zed.dts| 4
>> 5 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
>> b/arch/arm/boot/dts/zynq-7000.dtsi
>> index ce2ef5b..ee3e5d6 100644
>> --- a/arch/arm/boot/dts/zynq-7000.dtsi
>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>> @@ -243,7 +243,6 @@
>> clkc: clkc@100 {
>> #clock-cells = <1>;
>> compatible = "xlnx,ps7-clkc";
>> - ps-clk-frequency = <>;
>> fclk-enable = <0>;
>> clock-output-names = "armpll", "ddrpll",
>> "iopll", "cpu_6or4x",
>> "cpu_3or2x", "cpu_2x",
>> "cpu_1x", "ddr2x", "ddr3x",
>> diff --git a/arch/arm/boot/dts/zynq-parallella.dts
>> b/arch/arm/boot/dts/zynq-parallella.dts
>> index e1f51ca..cd84d45 100644
>> --- a/arch/arm/boot/dts/zynq-parallella.dts
>> +++ b/arch/arm/boot/dts/zynq-parallella.dts
>> @@ -83,3 +83,7 @@
>> {
>> status = "okay";
>> };
>> +
>> + {
>> + ps-clk-frequency = <>;
>> +};
>> diff --git a/arch/arm/boot/dts/zynq-zc702.dts
>> b/arch/arm/boot/dts/zynq-zc702.dts
>> index 94e2cda..24dcece 100644
>> --- a/arch/arm/boot/dts/zynq-zc702.dts
>> +++ b/arch/arm/boot/dts/zynq-zc702.dts
>> @@ -135,3 +135,7 @@
>> {
>> status = "okay";
>> };
>> +
>> + {
>> + ps-clk-frequency = <>;
>> +};
>> diff --git a/arch/arm/boot/dts/zynq-zc706.dts
>> b/arch/arm/boot/dts/zynq-zc706.dts
>> index a8bbdfb..7b88399 100644
>> --- a/arch/arm/boot/dts/zynq-zc706.dts
>> +++ b/arch/arm/boot/dts/zynq-zc706.dts
>> @@ -114,3 +114,7 @@
>> {
>> status = "okay";
>> };
>> +
>> + {
>> + ps-clk-frequency = <>;
>> +};
>> diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
>> index 697779a..4662da2 100644
>> --- a/arch/arm/boot/dts/zynq-zed.dts
>> +++ b/arch/arm/boot/dts/zynq-zed.dts
>> @@ -46,3 +46,7 @@
>> {
>> status = "okay";
>> };
>> +
>> + {
>> + ps-clk-frequency = <>;
>> +};
>
> I think we currently have the nodes more or less in alphabetical order.
> I'd prefer if we maintained that.
>
Will fix.
Regards,
Peter
> Other than that:
> Acked-by: Soren Brinkmann
>
> Soren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: dts: zynq: Move crystal freq. to board level
On Mon, Nov 10, 2014 at 7:34 AM, Sören Brinkmann
soren.brinkm...@xilinx.com wrote:
On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Even with the 33MHz in the dtsi you can override it on the board-level.
Just like the 'status' property is overriden in board dts files.
Do you want the deletion undone? Even with override capability I think
it should be removed as the number is board level specific and the
dtsi should be limited to SoC level information.
My understanding is the driver will default to 33MHz as well as a
catch-all, so anyone rolling their own top level OOT DTS is going to
be ok too.
Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com
---
Im guessing long term this should be converted to a fixed clock. But
I think this at least steps in that direction.
I was against that since it makes juggling with clock names more
difficult. The problem is that the CCF uses a global name space of clock
names.
I thought it was just a
clocks = phandle
Where's the namespacing issue?
Btw I think the clocks=phandle would be populated the the dts as well.
So the DTSI would have no clocks = node, and the dts must populate it.
This allows support for an on-board off-soc clock controller
controlling the PS clock (which is in theory supported by the SoC).
Not having the oscillator as fixed-clock in DT removed that
additional complexity. But it would be possible, I guess.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 -
arch/arm/boot/dts/zynq-parallella.dts | 4
arch/arm/boot/dts/zynq-zc702.dts | 4
arch/arm/boot/dts/zynq-zc706.dts | 4
arch/arm/boot/dts/zynq-zed.dts| 4
5 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5b..ee3e5d6 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -243,7 +243,6 @@
clkc: clkc@100 {
#clock-cells = 1;
compatible = xlnx,ps7-clkc;
- ps-clk-frequency = ;
fclk-enable = 0;
clock-output-names = armpll, ddrpll,
iopll, cpu_6or4x,
cpu_3or2x, cpu_2x,
cpu_1x, ddr2x, ddr3x,
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index e1f51ca..cd84d45 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -83,3 +83,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts
b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda..24dcece 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -135,3 +135,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts
b/arch/arm/boot/dts/zynq-zc706.dts
index a8bbdfb..7b88399 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -114,3 +114,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 697779a..4662da2 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -46,3 +46,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
I think we currently have the nodes more or less in alphabetical order.
I'd prefer if we maintained that.
Will fix.
Regards,
Peter
Other than that:
Acked-by: Soren Brinkmann soren.brinkm...@xilinx.com
Soren
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
On Mon, Nov 10, 2014 at 7:47 AM, Sören Brinkmann
soren.brinkm...@xilinx.com wrote:
Hi Peter,
On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
Digilent ZYBO here...
[...]
+/ {
+ model = Zynq ZYBO Development Board;
+ compatible = xlnx,zynq-zybo, xlnx,zynq-7000;
... xlnx,zynq-zybo here. Seems inconsistent. IMHO, there should rather be
a digilent vendor prefix.
Was going for consistency with ZED which also makes this mistake:
model = Zynq Zed Development Board;
compatible = xlnx,zynq-zed, xlnx,zynq-7000;
We have to choose between consistency and correctness. If we do fix it
though, what is Diglent's four-letter vendor prefix?
Regards,
Peter
Everything else looks pretty straight forward and good.
Soren
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
On Tue, Nov 11, 2014 at 8:42 AM, Sören Brinkmann
soren.brinkm...@xilinx.com wrote:
On Tue, 2014-11-11 at 08:39AM +1000, Peter Crosthwaite wrote:
On Mon, Nov 10, 2014 at 7:47 AM, Sören Brinkmann
soren.brinkm...@xilinx.com wrote:
Hi Peter,
On Sun, 2014-11-09 at 01:38PM +1000, Peter Crosthwaite wrote:
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
Digilent ZYBO here...
[...]
+/ {
+ model = Zynq ZYBO Development Board;
+ compatible = xlnx,zynq-zybo, xlnx,zynq-7000;
... xlnx,zynq-zybo here. Seems inconsistent. IMHO, there should rather be
a digilent vendor prefix.
Was going for consistency with ZED which also makes this mistake:
model = Zynq Zed Development Board;
compatible = xlnx,zynq-zed, xlnx,zynq-7000;
We have to choose between consistency and correctness. If we do fix it
though, what is Diglent's four-letter vendor prefix?
Since Digilent is the board vendor, I'm for using the appropriate
prefix. Vendor prefixes are found in
Documentation/devicetree/bindings/vendor-prefixes.txt.
It's not there,
Steven, does Digilent have a preferred dts vendor prefix?
Regards,
Peter
Soren
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] arm: dts: zynq: Move crystal freq. to board level
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Signed-off-by: Peter Crosthwaite
---
Im guessing long term this should be converted to a fixed clock. But
I think this at least steps in that direction.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 -
arch/arm/boot/dts/zynq-parallella.dts | 4
arch/arm/boot/dts/zynq-zc702.dts | 4
arch/arm/boot/dts/zynq-zc706.dts | 4
arch/arm/boot/dts/zynq-zed.dts| 4
5 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5b..ee3e5d6 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -243,7 +243,6 @@
clkc: clkc@100 {
#clock-cells = <1>;
compatible = "xlnx,ps7-clkc";
- ps-clk-frequency = <>;
fclk-enable = <0>;
clock-output-names = "armpll", "ddrpll",
"iopll", "cpu_6or4x",
"cpu_3or2x", "cpu_2x",
"cpu_1x", "ddr2x", "ddr3x",
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index e1f51ca..cd84d45 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -83,3 +83,7 @@
{
status = "okay";
};
+
+ {
+ ps-clk-frequency = <>;
+};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda..24dcece 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -135,3 +135,7 @@
{
status = "okay";
};
+
+ {
+ ps-clk-frequency = <>;
+};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index a8bbdfb..7b88399 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -114,3 +114,7 @@
{
status = "okay";
};
+
+ {
+ ps-clk-frequency = <>;
+};
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 697779a..4662da2 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -46,3 +46,7 @@
{
status = "okay";
};
+
+ {
+ ps-clk-frequency = <>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.
Signed-off-by: Peter Crosthwaite
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/zynq-zybo.dts | 52 +
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/zynq-zybo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d872062..e5e77f3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -500,7 +500,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-parallella.dtb \
zynq-zc702.dtb \
zynq-zc706.dtb \
- zynq-zed.dtb
+ zynq-zed.dtb \
+ zynq-zybo.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
armada-370-db.dtb \
armada-370-mirabox.dtb \
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
new file mode 100644
index 000..b02d9d3
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2012 National Instruments Corp.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+/include/ "zynq-7000.dtsi"
+
+/ {
+ model = "Zynq ZYBO Development Board";
+ compatible = "xlnx,zynq-zybo", "xlnx,zynq-7000";
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyPS0,115200 earlyprintk";
+ };
+
+};
+
+ {
+ status = "okay";
+ phy-mode = "rgmii-id";
+ phy-handle = <_phy>;
+
+ ethernet_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ ps-clk-frequency = <5000>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] arm: dts: zynq: Add Digilent ZYBO board
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with
a 50MHz crystal instead of 33MHz.
Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/zynq-zybo.dts | 52 +
2 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/zynq-zybo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d872062..e5e77f3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -500,7 +500,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-parallella.dtb \
zynq-zc702.dtb \
zynq-zc706.dtb \
- zynq-zed.dtb
+ zynq-zed.dtb \
+ zynq-zybo.dtb
dtb-$(CONFIG_MACH_ARMADA_370) += \
armada-370-db.dtb \
armada-370-mirabox.dtb \
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
new file mode 100644
index 000..b02d9d3
--- /dev/null
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2011 - 2014 Xilinx
+ * Copyright (C) 2012 National Instruments Corp.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+/include/ zynq-7000.dtsi
+
+/ {
+ model = Zynq ZYBO Development Board;
+ compatible = xlnx,zynq-zybo, xlnx,zynq-7000;
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x2000;
+ };
+
+ chosen {
+ bootargs = console=ttyPS0,115200 earlyprintk;
+ };
+
+};
+
+gem0 {
+ status = okay;
+ phy-mode = rgmii-id;
+ phy-handle = ethernet_phy;
+
+ ethernet_phy: ethernet-phy@0 {
+ reg = 0;
+ };
+};
+
+sdhci0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
+
+clkc {
+ ps-clk-frequency = 5000;
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] arm: dts: zynq: Move crystal freq. to board level
The fact that all supported boards use the same 33MHz crystal is a
co-incidence. The Zynq PS support a range of crystal freqs so the
hardcoded setting should be removed from the dtsi. Re-implement it
on the board level.
This prepares support for Zynq boards with different crystal
frequencies (e.g. the Digilent ZYBO).
Signed-off-by: Peter Crosthwaite crosthwaite.pe...@gmail.com
---
Im guessing long term this should be converted to a fixed clock. But
I think this at least steps in that direction.
---
arch/arm/boot/dts/zynq-7000.dtsi | 1 -
arch/arm/boot/dts/zynq-parallella.dts | 4
arch/arm/boot/dts/zynq-zc702.dts | 4
arch/arm/boot/dts/zynq-zc706.dts | 4
arch/arm/boot/dts/zynq-zed.dts| 4
5 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index ce2ef5b..ee3e5d6 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -243,7 +243,6 @@
clkc: clkc@100 {
#clock-cells = 1;
compatible = xlnx,ps7-clkc;
- ps-clk-frequency = ;
fclk-enable = 0;
clock-output-names = armpll, ddrpll,
iopll, cpu_6or4x,
cpu_3or2x, cpu_2x,
cpu_1x, ddr2x, ddr3x,
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index e1f51ca..cd84d45 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -83,3 +83,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda..24dcece 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -135,3 +135,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index a8bbdfb..7b88399 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -114,3 +114,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 697779a..4662da2 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -46,3 +46,7 @@
uart1 {
status = okay;
};
+
+clkc {
+ ps-clk-frequency = ;
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
On Sat, Apr 5, 2014 at 4:05 PM, Harini Katakam wrote: > Hi Peter, > > On Sat, Apr 5, 2014 at 4:44 AM, Peter Crosthwaite > wrote: >> On Sat, Apr 5, 2014 at 12:30 AM, Harini Katakam >> wrote: >>> Hi, >>> >>> On Fri, Apr 4, 2014 at 7:38 PM, Harini Katakam >>> wrote: >>>> Hi Mark, >>>> >>>> On Fri, Apr 4, 2014 at 6:16 PM, Mark Brown wrote: >>>>> On Fri, Apr 04, 2014 at 05:44:23PM +0530, Harini Katakam wrote: >>>>>> On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown wrote: >>>>>> > On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote: >>>>> >>>>>> >> This IP can drive 4 slaves. >>>>>> >> The sCS line to be driven is selected in spi device structure and >>>>>> >> that is driven by the software. >>>>> >>>>>> > So why specify this in the binding at all? If the device always has >>>>>> > the >>>>>> > same number of chip selects it's redundant. >>>>> >>>>>> I'm sorry, I should have explained that better. >>>>>> The IP can support upto 4 chip selects. >>>>>> The num-cs value here is the number of chip selects actually used on the >>>>>> board. >> >> Shouldnt it be a property of the controller not the board? How for >> example do we differentiate between different implementations of >> cadence SPI controller that only supports up to two CS lines? My >> thinking is that this property should always be present and = 4 in the >> Zynq case as the controller always has 4 physical CS lines coming out >> (before any decoders, pin muxes or slaves etc.). >> >>>>> >>>>> Why does that need to be configured? Surely the presence of slaves is >>>>> enough information. >> >> And presence of slaves / board info is inferable from subnodes. >> >>>> >>>> OK. I understand. >>>> Can you comment on the case where a decoder is used? >>>> >>>> There is support for adding a decoder where extended slaves can be selected >>>> through the IP's control register. >>>> (This is not currently implemented in the driver but will be in the >>>> future.) >>>> >> >> I think thats seperate information. is-decoded-cs property of something. >> >>>> How should the driver know whether it is 4 or 16 select lines for example? >>>> This has to be written to master->num_chipselect. >>>> >> >> If you only have one property (== 4) how do you tell the difference >> between 4 un-decoded CS lines vs 2 decoded CS lines? >> > > If an SoC implements 2 CS and sets "decoder" property, > then we'd configure the register with "select decode" bit and write > 0b0011 to the slave select field to select 4th slave. > > If decoder property is not set, then we'd write 0b1000 to select 4th slave. > What are your proposed dt bindings for these differing options - what is num-cs in each case? > But yes, if the SoC only implements 2 CS, doesn't use decoder but > if there is an erroneous input to set_cs for 4th slave, it would be a problem. > Sure, that's an error condition though that should be caught by SPI because master->num_chipselect would only be 2 right? Regards, Peter >> >> I think num-cs has validity as the number of CS lines implemented in >> the controller. For any given SoC, it's constant but could differ >> between SoCs. >> > > I dint consider that this property will be useful to SoC's implementing <4 CS; > master->num_chipselect (when set to this property's value) > will be used to check error conditions. > > Regards, > Harini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
On Sat, Apr 5, 2014 at 4:05 PM, Harini Katakam harinikatakamli...@gmail.com wrote: Hi Peter, On Sat, Apr 5, 2014 at 4:44 AM, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: On Sat, Apr 5, 2014 at 12:30 AM, Harini Katakam harinikatakamli...@gmail.com wrote: Hi, On Fri, Apr 4, 2014 at 7:38 PM, Harini Katakam harinikatakamli...@gmail.com wrote: Hi Mark, On Fri, Apr 4, 2014 at 6:16 PM, Mark Brown broo...@kernel.org wrote: On Fri, Apr 04, 2014 at 05:44:23PM +0530, Harini Katakam wrote: On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown broo...@kernel.org wrote: On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote: This IP can drive 4 slaves. The sCS line to be driven is selected in spi device structure and that is driven by the software. So why specify this in the binding at all? If the device always has the same number of chip selects it's redundant. I'm sorry, I should have explained that better. The IP can support upto 4 chip selects. The num-cs value here is the number of chip selects actually used on the board. Shouldnt it be a property of the controller not the board? How for example do we differentiate between different implementations of cadence SPI controller that only supports up to two CS lines? My thinking is that this property should always be present and = 4 in the Zynq case as the controller always has 4 physical CS lines coming out (before any decoders, pin muxes or slaves etc.). Why does that need to be configured? Surely the presence of slaves is enough information. And presence of slaves / board info is inferable from subnodes. OK. I understand. Can you comment on the case where a decoder is used? There is support for adding a decoder where extended slaves can be selected through the IP's control register. (This is not currently implemented in the driver but will be in the future.) I think thats seperate information. is-decoded-cs property of something. How should the driver know whether it is 4 or 16 select lines for example? This has to be written to master-num_chipselect. If you only have one property (== 4) how do you tell the difference between 4 un-decoded CS lines vs 2 decoded CS lines? If an SoC implements 2 CS and sets decoder property, then we'd configure the register with select decode bit and write 0b0011 to the slave select field to select 4th slave. If decoder property is not set, then we'd write 0b1000 to select 4th slave. What are your proposed dt bindings for these differing options - what is num-cs in each case? But yes, if the SoC only implements 2 CS, doesn't use decoder but if there is an erroneous input to set_cs for 4th slave, it would be a problem. Sure, that's an error condition though that should be caught by SPI because master-num_chipselect would only be 2 right? Regards, Peter I think num-cs has validity as the number of CS lines implemented in the controller. For any given SoC, it's constant but could differ between SoCs. I dint consider that this property will be useful to SoC's implementing 4 CS; master-num_chipselect (when set to this property's value) will be used to check error conditions. Regards, Harini -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
On Sat, Apr 5, 2014 at 12:30 AM, Harini Katakam wrote: > Hi, > > On Fri, Apr 4, 2014 at 7:38 PM, Harini Katakam > wrote: >> Hi Mark, >> >> On Fri, Apr 4, 2014 at 6:16 PM, Mark Brown wrote: >>> On Fri, Apr 04, 2014 at 05:44:23PM +0530, Harini Katakam wrote: On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown wrote: > On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote: >>> >> This IP can drive 4 slaves. >> The CS line to be driven is selected in spi device structure and >> that is driven by the software. >>> > So why specify this in the binding at all? If the device always has the > same number of chip selects it's redundant. >>> I'm sorry, I should have explained that better. The IP can support upto 4 chip selects. The num-cs value here is the number of chip selects actually used on the board. Shouldnt it be a property of the controller not the board? How for example do we differentiate between different implementations of cadence SPI controller that only supports up to two CS lines? My thinking is that this property should always be present and = 4 in the Zynq case as the controller always has 4 physical CS lines coming out (before any decoders, pin muxes or slaves etc.). >>> >>> Why does that need to be configured? Surely the presence of slaves is >>> enough information. And presence of slaves / board info is inferable from subnodes. >> >> OK. I understand. >> Can you comment on the case where a decoder is used? >> >> There is support for adding a decoder where extended slaves can be selected >> through the IP's control register. >> (This is not currently implemented in the driver but will be in the future.) >> I think thats seperate information. is-decoded-cs property of something. >> How should the driver know whether it is 4 or 16 select lines for example? >> This has to be written to master->num_chipselect. >> If you only have one property (== 4) how do you tell the difference between 4 un-decoded CS lines vs 2 decoded CS lines? >> Regards, >> Harini > > Just adding to my above comment. > Alternately, I could not use the "num-cs" property and add another > optional property to be used only when required. I think num-cs has validity as the number of CS lines implemented in the controller. For any given SoC, it's constant but could differ between SoCs. Regards, Peter > The driver sets a default value already. > > Regards, > Harini > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] SPI: Add driver for Cadence SPI controller
On Thu, Apr 3, 2014 at 9:10 PM, Harini Katakam wrote: > Add driver for Cadence SPI controller. This is used in Xilinx Zynq. > > Signed-off-by: Harini Katakam > --- > > v2 changes: > - Use xilinx compatible string too. > - Changes read register and write register functions to static inline. > - Removed unecessary dev_info and dev_dbg prints. > - Return IRQ_HANDLED only when interrupt is handled. > - Use a default num-cs value. > - Do init_hardware before requesting irq. > - Remove unecessary master_put() > - Set master->max_speed_hz > - Check for busy in cdns_setup(). > Retained this function with this check as opposed to removing. > The reason for this is clock configuration needs to be done for > the first time before enable is done in prepare_hardware; > prepare_hardware however, doesn't receive spi_device structure. > - Implememnt transfer_one instead of transfer_one_message. > Remove wait_for_completion as this is done by core. > - Implement set_cs. > - Clock enable/disable in prepare/unprepare respectively. > - In suspend, remove reset of hardware; simply call unprepare_hardware. > - In suspend/resume call master_suspend/resume respectively. > - Check for irq<=0 in probe. > - Remove MODULE_ALIAS. > > --- > drivers/spi/Kconfig |7 + > drivers/spi/Makefile |1 + > drivers/spi/spi-cadence.c | 677 > + > 3 files changed, 685 insertions(+) > create mode 100644 drivers/spi/spi-cadence.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 581ee2a..aeae44a 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -148,6 +148,13 @@ config SPI_BUTTERFLY > inexpensive battery powered microcontroller evaluation board. > This same cable can be used to flash new firmware. > > +config SPI_CADENCE > + tristate "Cadence SPI controller" > + depends on SPI_MASTER > + help > + This selects the Cadence SPI controller master driver > + used by Xilinx Zynq. > + > config SPI_CLPS711X > tristate "CLPS711X host SPI controller" > depends on ARCH_CLPS711X > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 95af48d..1be2ed7 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -22,6 +22,7 @@ obj-$(CONFIG_SPI_BFIN_V3) += spi-bfin-v3.o > obj-$(CONFIG_SPI_BFIN_SPORT) += spi-bfin-sport.o > obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o > obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o > +obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o > obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o > obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o > obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o > diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c > new file mode 100644 > index 000..071642d > --- /dev/null > +++ b/drivers/spi/spi-cadence.c > @@ -0,0 +1,677 @@ > +/* > + * Cadence SPI controller driver (master mode only) > + * > + * Copyright (C) 2008 - 2014 Xilinx, Inc. > + * > + * based on Blackfin On-Chip SPI Driver (spi_bfin5xx.c) > + * > + * This program is free software; you can redistribute it and/or modify it > under > + * the terms of the GNU General Public License version 2 as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Name of this driver */ > +#define CDNS_SPI_NAME "cdns-spi" > + > +/* Register offset definitions */ > +#define CDNS_SPI_CR_OFFSET 0x00 /* Configuration Register, RW */ > +#define CDNS_SPI_ISR_OFFSET0x04 /* Interrupt Status Register, RO */ > +#define CDNS_SPI_IER_OFFSET0x08 /* Interrupt Enable Register, WO */ > +#define CDNS_SPI_IDR_OFFSET0x0c /* Interrupt Disable Register, WO */ > +#define CDNS_SPI_IMR_OFFSET0x10 /* Interrupt Enabled Mask Register, RO */ > +#define CDNS_SPI_ER_OFFSET 0x14 /* Enable/Disable Register, RW */ > +#define CDNS_SPI_DR_OFFSET 0x18 /* Delay Register, RW */ > +#define CDNS_SPI_TXD_OFFSET0x1C /* Data Transmit Register, WO */ > +#define CDNS_SPI_RXD_OFFSET0x20 /* Data Receive Register, RO */ > +#define CDNS_SPI_SICR_OFFSET 0x24 /* Slave Idle Count Register, RW */ > +#define CDNS_SPI_THLD_OFFSET 0x28 /* Transmit FIFO Watermark Register,RW */ > + > +/* > + * SPI Configuration Register bit Masks > + * > + * This register contains various control bits that affect the operation > + * of the SPI controller > + */ > +#define CDNS_SPI_CR_MANSTRT_MASK 0x0001 /* Manual TX Start */ > +#define CDNS_SPI_CR_CPHA_MASK 0x0004 /* Clock Phase Control */ > +#define CDNS_SPI_CR_CPOL_MASK 0x0002 /* Clock Polarity Control > */ > +#define CDNS_SPI_CR_SSCTRL_MASK0x3C00 /* Slave Select
Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
On Fri, Apr 4, 2014 at 10:14 PM, Harini Katakam wrote: > Hi Mark, > > On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown wrote: >> On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote: >>> On Fri, Apr 4, 2014 at 3:04 AM, Mark Brown wrote: >>> > On Thu, Apr 03, 2014 at 04:40:31PM +0530, Harini Katakam wrote: >> >>> >> +Optional properties: >>> >> +- num-cs : Number of chip selects used. >> >>> > How does this translate to the hardware? >> >>> This IP can drive 4 slaves. >>> The CS line to be driven is selected in spi device structure and >>> that is driven by the software. >> >> So why specify this in the binding at all? If the device always has the >> same number of chip selects it's redundant. > > I'm sorry, I should have explained that better. > The IP can support upto 4 chip selects. > The num-cs value here is the number of chip selects actually used on the > board. > Just to clarify - do you mean SoC or board level? Regards, Peter >> >>> >> + num-cs = /bits/ 16 <4>; >> >>> > What's going on with the /bits/ - is this something that's required for >>> > the property? >> >>> The master->num-chipselect property is 16 bit but writing <4> here directly >>> leads to 0 being read in of_property_read (because it's big endian). >>> Instead using of property read u32 and then copying, we decided to do this. >>> This was discussed on v2 between Michal and Rob: >> >> No, don't do that. You're contorting the binding to serve Linux's >> implementation needs and you've not documented this requirement either. >> If there *was* a need to have the number be 16 bits you'd need to >> document that reqirement in the binding, though like I say I don't think >> the number needs to be there at all. > > OK. I'll remove the /bits/ 16 and handle it in the driver. > > Regards, > Harini > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
On Fri, Apr 4, 2014 at 10:14 PM, Harini Katakam harinikatakamli...@gmail.com wrote: Hi Mark, On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown broo...@kernel.org wrote: On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote: On Fri, Apr 4, 2014 at 3:04 AM, Mark Brown broo...@kernel.org wrote: On Thu, Apr 03, 2014 at 04:40:31PM +0530, Harini Katakam wrote: +Optional properties: +- num-cs : Number of chip selects used. How does this translate to the hardware? This IP can drive 4 slaves. The CS line to be driven is selected in spi device structure and that is driven by the software. So why specify this in the binding at all? If the device always has the same number of chip selects it's redundant. I'm sorry, I should have explained that better. The IP can support upto 4 chip selects. The num-cs value here is the number of chip selects actually used on the board. Just to clarify - do you mean SoC or board level? Regards, Peter + num-cs = /bits/ 16 4; What's going on with the /bits/ - is this something that's required for the property? The master-num-chipselect property is 16 bit but writing 4 here directly leads to 0 being read in of_property_read (because it's big endian). Instead using of property read u32 and then copying, we decided to do this. This was discussed on v2 between Michal and Rob: No, don't do that. You're contorting the binding to serve Linux's implementation needs and you've not documented this requirement either. If there *was* a need to have the number be 16 bits you'd need to document that reqirement in the binding, though like I say I don't think the number needs to be there at all. OK. I'll remove the /bits/ 16 and handle it in the driver. Regards, Harini -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] SPI: Add driver for Cadence SPI controller
On Thu, Apr 3, 2014 at 9:10 PM, Harini Katakam hari...@xilinx.com wrote: Add driver for Cadence SPI controller. This is used in Xilinx Zynq. Signed-off-by: Harini Katakam hari...@xilinx.com --- v2 changes: - Use xilinx compatible string too. - Changes read register and write register functions to static inline. - Removed unecessary dev_info and dev_dbg prints. - Return IRQ_HANDLED only when interrupt is handled. - Use a default num-cs value. - Do init_hardware before requesting irq. - Remove unecessary master_put() - Set master-max_speed_hz - Check for busy in cdns_setup(). Retained this function with this check as opposed to removing. The reason for this is clock configuration needs to be done for the first time before enable is done in prepare_hardware; prepare_hardware however, doesn't receive spi_device structure. - Implememnt transfer_one instead of transfer_one_message. Remove wait_for_completion as this is done by core. - Implement set_cs. - Clock enable/disable in prepare/unprepare respectively. - In suspend, remove reset of hardware; simply call unprepare_hardware. - In suspend/resume call master_suspend/resume respectively. - Check for irq=0 in probe. - Remove MODULE_ALIAS. --- drivers/spi/Kconfig |7 + drivers/spi/Makefile |1 + drivers/spi/spi-cadence.c | 677 + 3 files changed, 685 insertions(+) create mode 100644 drivers/spi/spi-cadence.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 581ee2a..aeae44a 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -148,6 +148,13 @@ config SPI_BUTTERFLY inexpensive battery powered microcontroller evaluation board. This same cable can be used to flash new firmware. +config SPI_CADENCE + tristate Cadence SPI controller + depends on SPI_MASTER + help + This selects the Cadence SPI controller master driver + used by Xilinx Zynq. + config SPI_CLPS711X tristate CLPS711X host SPI controller depends on ARCH_CLPS711X diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 95af48d..1be2ed7 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_SPI_BFIN_V3) += spi-bfin-v3.o obj-$(CONFIG_SPI_BFIN_SPORT) += spi-bfin-sport.o obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o +obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c new file mode 100644 index 000..071642d --- /dev/null +++ b/drivers/spi/spi-cadence.c @@ -0,0 +1,677 @@ +/* + * Cadence SPI controller driver (master mode only) + * + * Copyright (C) 2008 - 2014 Xilinx, Inc. + * + * based on Blackfin On-Chip SPI Driver (spi_bfin5xx.c) + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/interrupt.h +#include linux/io.h +#include linux/module.h +#include linux/of_irq.h +#include linux/of_address.h +#include linux/platform_device.h +#include linux/spi/spi.h + +/* Name of this driver */ +#define CDNS_SPI_NAME cdns-spi + +/* Register offset definitions */ +#define CDNS_SPI_CR_OFFSET 0x00 /* Configuration Register, RW */ +#define CDNS_SPI_ISR_OFFSET0x04 /* Interrupt Status Register, RO */ +#define CDNS_SPI_IER_OFFSET0x08 /* Interrupt Enable Register, WO */ +#define CDNS_SPI_IDR_OFFSET0x0c /* Interrupt Disable Register, WO */ +#define CDNS_SPI_IMR_OFFSET0x10 /* Interrupt Enabled Mask Register, RO */ +#define CDNS_SPI_ER_OFFSET 0x14 /* Enable/Disable Register, RW */ +#define CDNS_SPI_DR_OFFSET 0x18 /* Delay Register, RW */ +#define CDNS_SPI_TXD_OFFSET0x1C /* Data Transmit Register, WO */ +#define CDNS_SPI_RXD_OFFSET0x20 /* Data Receive Register, RO */ +#define CDNS_SPI_SICR_OFFSET 0x24 /* Slave Idle Count Register, RW */ +#define CDNS_SPI_THLD_OFFSET 0x28 /* Transmit FIFO Watermark Register,RW */ + +/* + * SPI Configuration Register bit Masks + * + * This register contains various control bits that affect the operation + * of the SPI controller + */ +#define CDNS_SPI_CR_MANSTRT_MASK 0x0001 /* Manual TX Start */ +#define CDNS_SPI_CR_CPHA_MASK 0x0004 /* Clock Phase Control */ +#define CDNS_SPI_CR_CPOL_MASK 0x0002 /* Clock Polarity Control */ +#define CDNS_SPI_CR_SSCTRL_MASK
Re: [PATCH v2 2/2] devicetree: Add devicetree bindings documentation for Cadence SPI
On Sat, Apr 5, 2014 at 12:30 AM, Harini Katakam harinikatakamli...@gmail.com wrote: Hi, On Fri, Apr 4, 2014 at 7:38 PM, Harini Katakam harinikatakamli...@gmail.com wrote: Hi Mark, On Fri, Apr 4, 2014 at 6:16 PM, Mark Brown broo...@kernel.org wrote: On Fri, Apr 04, 2014 at 05:44:23PM +0530, Harini Katakam wrote: On Fri, Apr 4, 2014 at 3:39 PM, Mark Brown broo...@kernel.org wrote: On Fri, Apr 04, 2014 at 08:30:38AM +0530, Harini Katakam wrote: This IP can drive 4 slaves. The CS line to be driven is selected in spi device structure and that is driven by the software. So why specify this in the binding at all? If the device always has the same number of chip selects it's redundant. I'm sorry, I should have explained that better. The IP can support upto 4 chip selects. The num-cs value here is the number of chip selects actually used on the board. Shouldnt it be a property of the controller not the board? How for example do we differentiate between different implementations of cadence SPI controller that only supports up to two CS lines? My thinking is that this property should always be present and = 4 in the Zynq case as the controller always has 4 physical CS lines coming out (before any decoders, pin muxes or slaves etc.). Why does that need to be configured? Surely the presence of slaves is enough information. And presence of slaves / board info is inferable from subnodes. OK. I understand. Can you comment on the case where a decoder is used? There is support for adding a decoder where extended slaves can be selected through the IP's control register. (This is not currently implemented in the driver but will be in the future.) I think thats seperate information. is-decoded-cs property of something. How should the driver know whether it is 4 or 16 select lines for example? This has to be written to master-num_chipselect. If you only have one property (== 4) how do you tell the difference between 4 un-decoded CS lines vs 2 decoded CS lines? Regards, Harini Just adding to my above comment. Alternately, I could not use the num-cs property and add another optional property to be used only when required. I think num-cs has validity as the number of CS lines implemented in the controller. For any given SoC, it's constant but could differ between SoCs. Regards, Peter The driver sets a default value already. Regards, Harini -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
On Thu, Dec 19, 2013 at 8:47 PM, Jonas Jensen wrote:
> Add a generic (dtsi) include file for MOXA ART SoCs.
>
> Also add a file for UC-7112-LX.
>
> Signed-off-by: Jonas Jensen
Reviewed-by: Peter Crosthwaite
P.S. you could have added this already, small changes don't require a
RB droppage.
Regards,
Peter
> ---
> Documentation/devicetree/bindings/arm/moxart.txt | 12 ++
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/moxart-uc7112lx.dts| 117 ++
> arch/arm/boot/dts/moxart.dtsi| 148
> +++
> 4 files changed, 278 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt
> create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts
> create mode 100644 arch/arm/boot/dts/moxart.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/moxart.txt
> b/Documentation/devicetree/bindings/arm/moxart.txt
> new file mode 100644
> index 000..11087ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/moxart.txt
> @@ -0,0 +1,12 @@
> +MOXA ART device tree bindings
> +
> +Boards with the MOXA ART SoC shall have the following properties:
> +
> +Required root node property:
> +
> +compatible = "moxa,moxart";
> +
> +Boards:
> +
> +- UC-7112-LX: embedded computer
> + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 40e13e3..99a730f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -111,6 +111,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
> kirkwood-ts219-6281.dtb \
> kirkwood-ts219-6282.dtb
> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
> +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
> dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \
> qcom-msm8960-cdp.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts
> b/arch/arm/boot/dts/moxart-uc7112lx.dts
> new file mode 100644
> index 000..10d088d
> --- /dev/null
> +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts
> @@ -0,0 +1,117 @@
> +/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Licensed under GPLv2 or later.
> + */
> +
> +/dts-v1/;
> +/include/ "moxart.dtsi"
> +
> +/ {
> + model = "MOXA UC-7112-LX";
> + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x200>;
> + };
> +
> + clocks {
> + ref12: ref12M {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <1200>;
> + };
> + };
> +
> + flash@8000,0 {
> + compatible = "numonyx,js28f128", "cfi-flash";
> + reg = <0x8000 0x100>;
> + bank-width = <2>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "bootloader";
> + reg = <0x0 0x4>;
> + };
> + partition@4 {
> + label = "linux kernel";
> + reg = <0x4 0x1C>;
> + };
> + partition@20 {
> + label = "root filesystem";
> + reg = <0x20 0x80>;
> + };
> + partition@a0 {
> + label = "user filesystem";
> + reg = <0xa0 0x60>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + user-led {
> + label = "ready-led";
> + gpios = < 27 0x1>;
> + default-state = "on";
> + linux,default-trigger = "default-on";
> + };
> + };
> +
> + gpio_keys_polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <500>;
> + button@25 {
> + label = "G
Re: [PATCH v7 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
On Thu, Dec 19, 2013 at 8:47 PM, Jonas Jensen jonas.jen...@gmail.com wrote:
Add a generic (dtsi) include file for MOXA ART SoCs.
Also add a file for UC-7112-LX.
Signed-off-by: Jonas Jensen jonas.jen...@gmail.com
Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
P.S. you could have added this already, small changes don't require a
RB droppage.
Regards,
Peter
---
Documentation/devicetree/bindings/arm/moxart.txt | 12 ++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/moxart-uc7112lx.dts| 117 ++
arch/arm/boot/dts/moxart.dtsi| 148
+++
4 files changed, 278 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt
create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts
create mode 100644 arch/arm/boot/dts/moxart.dtsi
diff --git a/Documentation/devicetree/bindings/arm/moxart.txt
b/Documentation/devicetree/bindings/arm/moxart.txt
new file mode 100644
index 000..11087ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/moxart.txt
@@ -0,0 +1,12 @@
+MOXA ART device tree bindings
+
+Boards with the MOXA ART SoC shall have the following properties:
+
+Required root node property:
+
+compatible = moxa,moxart;
+
+Boards:
+
+- UC-7112-LX: embedded computer
+ compatible = moxa,moxart-uc-7112-lx, moxa,moxart
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 40e13e3..99a730f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -111,6 +111,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
+dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
dtb-$(CONFIG_ARCH_MSM) += qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts
b/arch/arm/boot/dts/moxart-uc7112lx.dts
new file mode 100644
index 000..10d088d
--- /dev/null
+++ b/arch/arm/boot/dts/moxart-uc7112lx.dts
@@ -0,0 +1,117 @@
+/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX
+ *
+ * Copyright (C) 2013 Jonas Jensen jonas.jen...@gmail.com
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/dts-v1/;
+/include/ moxart.dtsi
+
+/ {
+ model = MOXA UC-7112-LX;
+ compatible = moxa,moxart-uc-7112-lx, moxa,moxart;
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x200;
+ };
+
+ clocks {
+ ref12: ref12M {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 1200;
+ };
+ };
+
+ flash@8000,0 {
+ compatible = numonyx,js28f128, cfi-flash;
+ reg = 0x8000 0x100;
+ bank-width = 2;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ label = bootloader;
+ reg = 0x0 0x4;
+ };
+ partition@4 {
+ label = linux kernel;
+ reg = 0x4 0x1C;
+ };
+ partition@20 {
+ label = root filesystem;
+ reg = 0x20 0x80;
+ };
+ partition@a0 {
+ label = user filesystem;
+ reg = 0xa0 0x60;
+ };
+ };
+
+ leds {
+ compatible = gpio-leds;
+ user-led {
+ label = ready-led;
+ gpios = gpio 27 0x1;
+ default-state = on;
+ linux,default-trigger = default-on;
+ };
+ };
+
+ gpio_keys_polled {
+ compatible = gpio-keys-polled;
+ #address-cells = 1;
+ #size-cells = 0;
+ poll-interval = 500;
+ button@25 {
+ label = GPIO Reset;
+ linux,code = 116;
+ gpios = gpio 25 1;
+ };
+ };
+
+ chosen {
+ bootargs = console=ttyS0,115200n8 earlyprintk
root=/dev/mmcblk0p1 rw rootwait;
+ };
+};
+
+clk_pll {
+ clocks = ref12;
+};
+
+sdhci {
+ status = okay;
+};
+
+mdio0 {
+ status = okay;
+
+ ethphy0: ethernet-phy@1 {
+ device_type = ethernet-phy;
+ compatible = moxa,moxart-rtl8201cp,
ethernet-phy-ieee802.3-c22;
+ reg = 1;
+ };
+};
+
+mdio1 {
+ status = okay;
+
+ ethphy1: ethernet-phy@1 {
+ device_type = ethernet-phy;
+ compatible = moxa
Re: [PATCH v6 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
+ {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + ethphy0: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp",
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + ethphy1: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp",
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
You phy stuff looks good to me, thanks for the changes.
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/moxart.dtsi b/arch/arm/boot/dts/moxart.dtsi
> new file mode 100644
> index 000..da1d8ef
> --- /dev/null
> +++ b/arch/arm/boot/dts/moxart.dtsi
> @@ -0,0 +1,154 @@
> +/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Licensed under GPLv2 or later.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + compatible = "moxa,moxart";
> + model = "MOXART";
> + interrupt-parent = <>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "faraday,fa526";
> + reg = <0>;
> + };
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ref12: ref12M {
> + compatible = "fixed-clock";
Is the correct split to perhaps have the fixed-clock node in dtsi as
you have here but ...
> + #clock-cells = <0>;
> + clock-frequency = <1200>;
The board is responsible for the frequency?
I guess in this schema,
1. the "fixed-clock" node corresponds to the existence of clock input
pins on the SoC level - hence the node is DTSI.
2. setting the clock-frequency corresponds to populatation of those
input pins with a soldered crystal - hence done in DTS
Then again, I'm not entirely sure, and I think I might be splitting
hairs here, So.
Reviewed-by: Peter Crosthwaite
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x9000 0x1000>;
> + ranges;
> +
> + intc: interrupt-controller@9880 {
> + compatible = "moxa,moxart-ic";
> + reg = <0x9880 0x38>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupt-mask = <0x0008>;
> + };
> +
> + clk_pll: clk_pll@9810 {
> + compatible = "moxa,moxart-pll-clock";
> + #clock-cells = <0>;
> + reg = <0x9810 0x34>;
> + };
> +
> + clk_apb: clk_apb@9810 {
> + compatible = "moxa,moxart-apb-clock";
> + #clock-cells = <0>;
> + reg = <0x9810 0x34>;
> + clocks = <_pll>;
> + };
> +
> + timer: timer@9840 {
> + compatible = "moxa,moxart-timer";
> + reg = <0x9840 0x42>;
> + interrupts = <19 1>;
> + clocks = <_apb>;
> + };
> +
> + gpio: gpio@9870 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + compatible = "moxa,moxart-gpio";
> + reg = <0x9870 0xC>;
> + };
> +
> + rtc: rtc {
> + compatible = "moxa,moxart-rtc";
> + gpio-rtc-sclk = < 5 0>;
> + gpio-rtc-data = < 6 0>;
> +
Re: [PATCH v6 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
--- /dev/null
+++ b/arch/arm/boot/dts/moxart.dtsi
@@ -0,0 +1,154 @@
+/* moxart.dtsi - Device Tree Include file for MOXA ART family SoC
+ *
+ * Copyright (C) 2013 Jonas Jensen jonas.jen...@gmail.com
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = moxa,moxart;
+ model = MOXART;
+ interrupt-parent = intc;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = faraday,fa526;
+ reg = 0;
+ };
+ };
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ref12: ref12M {
+ compatible = fixed-clock;
Is the correct split to perhaps have the fixed-clock node in dtsi as
you have here but ...
+ #clock-cells = 0;
+ clock-frequency = 1200;
The board is responsible for the frequency?
I guess in this schema,
1. the fixed-clock node corresponds to the existence of clock input
pins on the SoC level - hence the node is DTSI.
2. setting the clock-frequency corresponds to populatation of those
input pins with a soldered crystal - hence done in DTS
Then again, I'm not entirely sure, and I think I might be splitting
hairs here, So.
Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
+ };
+ };
+
+ soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x9000 0x1000;
+ ranges;
+
+ intc: interrupt-controller@9880 {
+ compatible = moxa,moxart-ic;
+ reg = 0x9880 0x38;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ interrupt-mask = 0x0008;
+ };
+
+ clk_pll: clk_pll@9810 {
+ compatible = moxa,moxart-pll-clock;
+ #clock-cells = 0;
+ reg = 0x9810 0x34;
+ };
+
+ clk_apb: clk_apb@9810 {
+ compatible = moxa,moxart-apb-clock;
+ #clock-cells = 0;
+ reg = 0x9810 0x34;
+ clocks = clk_pll;
+ };
+
+ timer: timer@9840 {
+ compatible = moxa,moxart-timer;
+ reg = 0x9840 0x42;
+ interrupts = 19 1;
+ clocks = clk_apb;
+ };
+
+ gpio: gpio@9870 {
+ gpio-controller;
+ #gpio-cells = 2;
+ compatible = moxa,moxart-gpio;
+ reg = 0x9870 0xC;
+ };
+
+ rtc: rtc {
+ compatible = moxa,moxart-rtc;
+ gpio-rtc-sclk = gpio 5 0;
+ gpio-rtc-data = gpio 6 0;
+ gpio-rtc-reset = gpio 7 0;
+ };
+
+ dma: dma@9050 {
+ compatible = moxa,moxart-dma;
+ reg = 0x90500080 0x40;
+ interrupts = 24 0;
+ #dma-cells = 1;
+ };
+
+ watchdog: watchdog@9850 {
+ compatible = moxa,moxart-watchdog;
+ reg = 0x9850 0x10;
+ clocks = clk_apb;
+ };
+
+ sdhci: sdhci@98e0 {
+ compatible = moxa,moxart-sdhci;
+ reg = 0x98e0 0x5C;
+ interrupts = 5 0;
+ clocks = clk_apb;
+ dmas = dma 5,
+ dma 5;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mdio0: mdio@90900090 {
+ compatible = moxa,moxart-mdio;
+ reg = 0x90900090 0x8;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ mdio1: mdio@9290 {
+ compatible = moxa,moxart-mdio;
+ reg = 0x9290 0x8;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ mac0: mac@9090 {
+ compatible = moxa,moxart-mac;
+ reg = 0x9090 0x90;
+ interrupts = 25 0;
+ phy
Re: [PATCH v5 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
+ compatible = "moxa,moxart-mdio";
> + reg = <0x90900090 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> +
> + ethphy0: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp",
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> + };
> +
> + mdio1: mdio@9290 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x9290 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> +
> + ethphy1: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp",
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
Are the phys board or SoC level?
> + };
> +
> + mac0: mac@9090 {
> + compatible = "moxa,moxart-mac";
> + reg = <0x9090 0x90>;
> + interrupts = <25 0>;
> + phy-handle = <>;
> + phy-mode = "mii";
If the IP supports multiple PHYs of different external connection
schemes then the phy connectivity should got back to board level. If
not:
Reviewed-by: Peter Crosthwaite
I don't know much about arm/mach- and Kconfig, so I'll sit out the
review of P1.
Regards,
Peter
> + status = "disabled";
> + };
> +
> + mac1: mac@9200 {
> + compatible = "moxa,moxart-mac";
> + reg = <0x9200 0x90>;
> + interrupts = <27 0>;
> + phy-handle = <>;
> + phy-mode = "mii";
> + status = "disabled";
> + };
> +
> + uart0: uart@9820 {
> + compatible = "ns16550a";
> + reg = <0x9820 0x20>;
> + interrupts = <31 8>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clock-frequency = <14745600>;
> + status = "disabled";
> + };
> + };
> +};
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
;
+ };
+ };
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ref12: ref12M {
+ compatible = fixed-clock;
+ #clock-cells = 0;
+ clock-frequency = 1200;
Crystal board level?
+ };
+ };
+
+ soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x9000 0x1000;
+ ranges;
+
+ intc: interrupt-controller@9880 {
+ compatible = moxa,moxart-ic;
+ reg = 0x9880 0x38;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ interrupt-mask = 0x0008;
+ };
+
+ clk_pll: clk_pll@9810 {
+ compatible = moxa,moxart-pll-clock;
+ #clock-cells = 0;
+ reg = 0x9810 0x34;
+ clocks = ref12;
+ };
+
+ clk_apb: clk_apb@9810 {
+ compatible = moxa,moxart-apb-clock;
+ #clock-cells = 0;
+ reg = 0x9810 0x34;
+ clocks = clk_pll;
+ };
+
+ timer: timer@9840 {
+ compatible = moxa,moxart-timer;
+ reg = 0x9840 0x42;
+ interrupts = 19 1;
+ clocks = clk_apb;
+ };
+
+ gpio: gpio@9870 {
+ gpio-controller;
+ #gpio-cells = 2;
+ compatible = moxa,moxart-gpio;
+ reg = 0x9870 0xC;
+ };
+
+ rtc: rtc {
+ compatible = moxa,moxart-rtc;
+ gpio-rtc-sclk = gpio 5 0;
+ gpio-rtc-data = gpio 6 0;
+ gpio-rtc-reset = gpio 7 0;
+ };
+
+ dma: dma@9050 {
+ compatible = moxa,moxart-dma;
+ reg = 0x90500080 0x40;
+ interrupts = 24 0;
+ #dma-cells = 1;
+ };
+
+ watchdog: watchdog@9850 {
+ compatible = moxa,moxart-watchdog;
+ reg = 0x9850 0x10;
+ clocks = clk_apb;
+ };
+
+ sdhci: sdhci@98e0 {
+ compatible = moxa,moxart-sdhci;
+ reg = 0x98e0 0x5C;
+ interrupts = 5 0;
+ clocks = clk_apb;
+ dmas = dma 5,
+ dma 5;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mdio0: mdio@90900090 {
+ compatible = moxa,moxart-mdio;
+ reg = 0x90900090 0x8;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+
+ ethphy0: ethernet-phy@1 {
+ device_type = ethernet-phy;
+ compatible = moxa,moxart-rtl8201cp,
ethernet-phy-ieee802.3-c22;
+ reg = 1;
+ };
+ };
+
+ mdio1: mdio@9290 {
+ compatible = moxa,moxart-mdio;
+ reg = 0x9290 0x8;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+
+ ethphy1: ethernet-phy@1 {
+ device_type = ethernet-phy;
+ compatible = moxa,moxart-rtl8201cp,
ethernet-phy-ieee802.3-c22;
+ reg = 1;
+ };
Are the phys board or SoC level?
+ };
+
+ mac0: mac@9090 {
+ compatible = moxa,moxart-mac;
+ reg = 0x9090 0x90;
+ interrupts = 25 0;
+ phy-handle = ethphy0;
+ phy-mode = mii;
If the IP supports multiple PHYs of different external connection
schemes then the phy connectivity should got back to board level. If
not:
Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
I don't know much about arm/mach- and Kconfig, so I'll sit out the
review of P1.
Regards,
Peter
+ status = disabled;
+ };
+
+ mac1: mac@9200 {
+ compatible = moxa,moxart
Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen wrote:
> On 15 December 2013 05:27, Peter Crosthwaite
> wrote:
>>> + sdhci: sdhci@98e0 {
>>> + compatible = "moxa,moxart-sdhci";
>>> + reg = <0x98e0 0x5C>;
>>> + interrupts = <5 0>;
>>> + clocks = <_apb>;
>>> + dmas = < 5>,
>>> + < 5>;
>>> + dma-names = "tx", "rx";
>>> + };
>>
>> Is your SDHCI really implemented on the board level? The fact that its
>> reg property is within the same as the SoC range (for your dtsi)
>> suggests the SDHCI is part of the SoC and should perhaps be in the
>> dtsi?
>
>>> + mac1: mac@9200 {
>>> + compatible = "moxa,moxart-mac";
>>> + reg = <0x9200 0x90>;
>>> + interrupts = <27 0>;
>>> + phy-handle = <>;
>>> + phy-mode = "mii";
>>> + };
>>
>> Same for MACs.
>
>>> +
>>> + uart0: uart@9820 {
>>> + compatible = "ns16550a";
>>> + reg = <0x9820 0x20>;
>>> + interrupts = <31 8>;
>>> + reg-shift = <2>;
>>> + reg-io-width = <4>;
>>> + clock-frequency = <14745600>;
>>> + status = "okay";
>>> + };
>>> +
>>
>> And UARTs.
>>
>> Let me know if i'm misunderstanding dts/dtsi split but looking at some
>> of the other SoCs this seems inconsistent to me.
>
>
> It is likely to be true, that technically these are all part of the
> SoC. By examining the hardware, there are no external chips (on either
> base or main board) that looks capable of handling such functions:
>
> https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953
>
> I made the split with some consideration to other MOXA ART machines,
> that they can be added as a separate file including the same dtsi:
>
> MOXA ART hardware examples:
>
> UC-7112/UC-7110: "SD slot (UC-7112, and UC-7112 Plus only)":
> http://www.moxa.com/product/UC-7112_UC-7110.htm
>
> IA241: "64 MB RAM":
> http://www.moxa.com/product/IA241_IA240.htm
>
> UC-7101-LX: "One 10/100 Mbps Ethernet port":
> http://www.moxa.com/product/UC-7101-LX.htm
>
>
> UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think
> MAC is good as is, RAM should move out from SoC?
>
> I don't know if they all have a debug UART (I only have access to
> UC-7112-LX), and it's not obvious in specifications. UART can possibly
> be moved into SoC as you say.
>
I think its going to all be in the SoC. Having it board level would
mean you have a system bus as copper which is not very SoC like (at
least for UART anyway).
> In cases where SD slot is missing but the register remains in the SoC,
> how is that normally handled?
>
Soren Brinkmann's recent addition of ethernet to the Zynq SoC
illustrates the concept for a MAC. The two MACs are added to the
shared dtsi but disabled. The board level dts then enables it for the
one which is board populated:
https://lkml.org/lkml/2013/12/11/434
I think its generally applicable to your SD MAC and UART cases. The
tegra20 dtsi illustrates the status = "disabled" concept specifically
for SDHCI.
Regards,
Peter
>
> Regards,
> Jonas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
On Tue, Dec 17, 2013 at 6:05 AM, Jonas Jensen jonas.jen...@gmail.com wrote:
On 15 December 2013 05:27, Peter Crosthwaite
peter.crosthwa...@xilinx.com wrote:
+ sdhci: sdhci@98e0 {
+ compatible = moxa,moxart-sdhci;
+ reg = 0x98e0 0x5C;
+ interrupts = 5 0;
+ clocks = clk_apb;
+ dmas = dma 5,
+ dma 5;
+ dma-names = tx, rx;
+ };
Is your SDHCI really implemented on the board level? The fact that its
reg property is within the same as the SoC range (for your dtsi)
suggests the SDHCI is part of the SoC and should perhaps be in the
dtsi?
+ mac1: mac@9200 {
+ compatible = moxa,moxart-mac;
+ reg = 0x9200 0x90;
+ interrupts = 27 0;
+ phy-handle = ethphy1;
+ phy-mode = mii;
+ };
Same for MACs.
+
+ uart0: uart@9820 {
+ compatible = ns16550a;
+ reg = 0x9820 0x20;
+ interrupts = 31 8;
+ reg-shift = 2;
+ reg-io-width = 4;
+ clock-frequency = 14745600;
+ status = okay;
+ };
+
And UARTs.
Let me know if i'm misunderstanding dts/dtsi split but looking at some
of the other SoCs this seems inconsistent to me.
It is likely to be true, that technically these are all part of the
SoC. By examining the hardware, there are no external chips (on either
base or main board) that looks capable of handling such functions:
https://plus.google.com/photos/103371465418643926605/albums/5820634595801767953
I made the split with some consideration to other MOXA ART machines,
that they can be added as a separate file including the same dtsi:
MOXA ART hardware examples:
UC-7112/UC-7110: SD slot (UC-7112, and UC-7112 Plus only):
http://www.moxa.com/product/UC-7112_UC-7110.htm
IA241: 64 MB RAM:
http://www.moxa.com/product/IA241_IA240.htm
UC-7101-LX: One 10/100 Mbps Ethernet port:
http://www.moxa.com/product/UC-7101-LX.htm
UC-7112-LX has 32 MB RAM and two ethernet ports. This is why I think
MAC is good as is, RAM should move out from SoC?
I don't know if they all have a debug UART (I only have access to
UC-7112-LX), and it's not obvious in specifications. UART can possibly
be moved into SoC as you say.
I think its going to all be in the SoC. Having it board level would
mean you have a system bus as copper which is not very SoC like (at
least for UART anyway).
In cases where SD slot is missing but the register remains in the SoC,
how is that normally handled?
Soren Brinkmann's recent addition of ethernet to the Zynq SoC
illustrates the concept for a MAC. The two MACs are added to the
shared dtsi but disabled. The board level dts then enables it for the
one which is board populated:
https://lkml.org/lkml/2013/12/11/434
I think its generally applicable to your SD MAC and UART cases. The
tegra20 dtsi illustrates the status = disabled concept specifically
for SDHCI.
Regards,
Peter
Regards,
Jonas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
On Sat, Dec 14, 2013 at 12:33 AM, Jonas Jensen wrote:
> Add a generic (dtsi) include file for MOXA ART SoCs.
>
> Also add a file for UC-7112-LX.
>
> Signed-off-by: Jonas Jensen
> ---
> Documentation/devicetree/bindings/arm/moxart.txt | 12 +++
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/moxart-uc7112lx.dts| 131
> +++
> arch/arm/boot/dts/moxart.dtsi| 100 +
> 4 files changed, 244 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt
> create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts
> create mode 100644 arch/arm/boot/dts/moxart.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/moxart.txt
> b/Documentation/devicetree/bindings/arm/moxart.txt
> new file mode 100644
> index 000..11087ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/moxart.txt
> @@ -0,0 +1,12 @@
> +MOXA ART device tree bindings
> +
> +Boards with the MOXA ART SoC shall have the following properties:
> +
> +Required root node property:
> +
> +compatible = "moxa,moxart";
> +
> +Boards:
> +
> +- UC-7112-LX: embedded computer
> + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9fe33e7..f331b22 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -318,6 +318,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
> dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
> zynq-zc706.dtb \
> zynq-zed.dtb
> +dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
>
> targets += dtbs
> targets += $(dtb-y)
> diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts
> b/arch/arm/boot/dts/moxart-uc7112lx.dts
> new file mode 100644
> index 000..c63d013
> --- /dev/null
> +++ b/arch/arm/boot/dts/moxart-uc7112lx.dts
> @@ -0,0 +1,131 @@
> +/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Licensed under GPLv2 or later.
> + */
> +
> +/dts-v1/;
> +/include/ "moxart.dtsi"
> +
> +/ {
> + model = "MOXA UC-7112-LX";
> + compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x200>;
> + };
> +
> + flash@8000,0 {
> + compatible = "numonyx,js28f128", "cfi-flash";
> + reg = <0x8000 0x100>;
> + bank-width = <2>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "bootloader";
> + reg = <0x0 0x4>;
> + };
> + partition@4 {
> + label = "linux kernel";
> + reg = <0x4 0x1C>;
> + };
> + partition@20 {
> + label = "root filesystem";
> + reg = <0x20 0x80>;
> + };
> + partition@a0 {
> + label = "user filesystem";
> + reg = <0xa0 0x60>;
> + };
> + };
> +
> + sdhci: sdhci@98e0 {
> + compatible = "moxa,moxart-sdhci";
> + reg = <0x98e0 0x5C>;
> + interrupts = <5 0>;
> + clocks = <_apb>;
> + dmas = < 5>,
> + < 5>;
> + dma-names = "tx", "rx";
> + };
Is your SDHCI really implemented on the board level? The fact that its
reg property is within the same as the SoC range (for your dtsi)
suggests the SDHCI is part of the SoC and should perhaps be in the
dtsi?
> +
> + mdio0: mdio@90900090 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x90900090 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp",
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> + };
> +
> + mdio1: mdio@9290 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x9290 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy1: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp",
> "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> + };
> +
> + mac0: mac@9090 {
> + compatible = "moxa,moxart-mac";
> + reg = <0x9090 0x90>;
> + interrupts = <25 0>;
> + phy-handle = <>;
> + phy-mode = "mii";
> + };
> +
> +
Re: [PATCH v4 2/2] ARM: mach-moxart: add MOXA ART SoC device tree files
On Sat, Dec 14, 2013 at 12:33 AM, Jonas Jensen jonas.jen...@gmail.com wrote:
Add a generic (dtsi) include file for MOXA ART SoCs.
Also add a file for UC-7112-LX.
Signed-off-by: Jonas Jensen jonas.jen...@gmail.com
---
Documentation/devicetree/bindings/arm/moxart.txt | 12 +++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/moxart-uc7112lx.dts| 131
+++
arch/arm/boot/dts/moxart.dtsi| 100 +
4 files changed, 244 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/moxart.txt
create mode 100644 arch/arm/boot/dts/moxart-uc7112lx.dts
create mode 100644 arch/arm/boot/dts/moxart.dtsi
diff --git a/Documentation/devicetree/bindings/arm/moxart.txt
b/Documentation/devicetree/bindings/arm/moxart.txt
new file mode 100644
index 000..11087ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/moxart.txt
@@ -0,0 +1,12 @@
+MOXA ART device tree bindings
+
+Boards with the MOXA ART SoC shall have the following properties:
+
+Required root node property:
+
+compatible = moxa,moxart;
+
+Boards:
+
+- UC-7112-LX: embedded computer
+ compatible = moxa,moxart-uc-7112-lx, moxa,moxart
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9fe33e7..f331b22 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -318,6 +318,7 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
zynq-zc706.dtb \
zynq-zed.dtb
+dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
targets += dtbs
targets += $(dtb-y)
diff --git a/arch/arm/boot/dts/moxart-uc7112lx.dts
b/arch/arm/boot/dts/moxart-uc7112lx.dts
new file mode 100644
index 000..c63d013
--- /dev/null
+++ b/arch/arm/boot/dts/moxart-uc7112lx.dts
@@ -0,0 +1,131 @@
+/* moxart-uc7112lx.dts - Device Tree file for MOXA UC-7112-LX
+ *
+ * Copyright (C) 2013 Jonas Jensen jonas.jen...@gmail.com
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/dts-v1/;
+/include/ moxart.dtsi
+
+/ {
+ model = MOXA UC-7112-LX;
+ compatible = moxa,moxart-uc-7112-lx, moxa,moxart;
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x200;
+ };
+
+ flash@8000,0 {
+ compatible = numonyx,js28f128, cfi-flash;
+ reg = 0x8000 0x100;
+ bank-width = 2;
+ #address-cells = 1;
+ #size-cells = 1;
+ partition@0 {
+ label = bootloader;
+ reg = 0x0 0x4;
+ };
+ partition@4 {
+ label = linux kernel;
+ reg = 0x4 0x1C;
+ };
+ partition@20 {
+ label = root filesystem;
+ reg = 0x20 0x80;
+ };
+ partition@a0 {
+ label = user filesystem;
+ reg = 0xa0 0x60;
+ };
+ };
+
+ sdhci: sdhci@98e0 {
+ compatible = moxa,moxart-sdhci;
+ reg = 0x98e0 0x5C;
+ interrupts = 5 0;
+ clocks = clk_apb;
+ dmas = dma 5,
+ dma 5;
+ dma-names = tx, rx;
+ };
Is your SDHCI really implemented on the board level? The fact that its
reg property is within the same as the SoC range (for your dtsi)
suggests the SDHCI is part of the SoC and should perhaps be in the
dtsi?
+
+ mdio0: mdio@90900090 {
+ compatible = moxa,moxart-mdio;
+ reg = 0x90900090 0x8;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ethphy0: ethernet-phy@1 {
+ device_type = ethernet-phy;
+ compatible = moxa,moxart-rtl8201cp,
ethernet-phy-ieee802.3-c22;
+ reg = 1;
+ };
+ };
+
+ mdio1: mdio@9290 {
+ compatible = moxa,moxart-mdio;
+ reg = 0x9290 0x8;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ethphy1: ethernet-phy@1 {
+ device_type = ethernet-phy;
+ compatible = moxa,moxart-rtl8201cp,
ethernet-phy-ieee802.3-c22;
+ reg = 1;
+ };
+ };
+
+ mac0: mac@9090 {
+ compatible = moxa,moxart-mac;
+ reg = 0x9090 0x90;
+ interrupts = 25 0;
+ phy-handle = ethphy0;
+ phy-mode = mii;
+ };
+
+ mac1: mac@9200 {
+ compatible = moxa,moxart-mac;
+ reg = 0x9200 0x90;
+ interrupts = 27 0;
+
Re: [PATCH v1 1/2] of: irq: Ignore disabled intc's when searching map
Ping! On Thu, Nov 28, 2013 at 5:26 PM, Peter Crosthwaite wrote: > When searching the interrupt map, if a matched parent is disabled, just > ignore it and move on with the search. > > This allows for specifying connection of a single device IRQ to > multiple interrupt controllers via the interrupt map schema. This change > allows for selection of the active interrupt controller via the already > existing status = "disabled" mechanism. > > Signed-off-by: Peter Crosthwaite > Acked-by: Michal Simek > --- > drivers/of/irq.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 786b0b4..22e414b 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -217,6 +217,9 @@ int of_irq_parse_raw(const __be32 *addr, struct > of_phandle_args *out_irq) > goto fail; > } > > + if (!of_device_is_available(newpar)) > + match = 0; > + > /* Get #interrupt-cells and #address-cells of new > * parent > */ > -- > 1.8.4.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/2] of: irq: Ignore disabled intc's when searching map
Ping! On Thu, Nov 28, 2013 at 5:26 PM, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: When searching the interrupt map, if a matched parent is disabled, just ignore it and move on with the search. This allows for specifying connection of a single device IRQ to multiple interrupt controllers via the interrupt map schema. This change allows for selection of the active interrupt controller via the already existing status = disabled mechanism. Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com Acked-by: Michal Simek michal.si...@xilinx.com --- drivers/of/irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 786b0b4..22e414b 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -217,6 +217,9 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq) goto fail; } + if (!of_device_is_available(newpar)) + match = 0; + /* Get #interrupt-cells and #address-cells of new * parent */ -- 1.8.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Thu, Nov 28, 2013 at 12:17 AM, Grant Likely wrote: > On Wed, 27 Nov 2013 19:06:35 +1000, Peter Crosthwaite > wrote: >> On Mon, Nov 25, 2013 at 7:32 AM, Grant Likely >> wrote: >> > On Sun, 24 Nov 2013 17:04:52 +1000, Peter Crosthwaite >> > wrote: >> >> On Wed, Nov 13, 2013 at 4:14 PM, Grant Likely >> >> wrote: >> >> > On Wed, 13 Nov 2013 09:17:01 +1000, Peter Crosthwaite >> >> > wrote: >> >> >> It's going to get a little verbose once you start making multiple >> >> >> connections as you need one mux per wire. Perhaps it could be cleaned >> >> >> up by making the foo_irq_mux node(s) a child of foo? >> >> > >> >> > It could, but then you need some way of attaching a driver to that node, >> >> > and that would require building knowledge into the driver again. >> >> > >> >> > Can you boil it down to a couple of concrete examples? What is a >> >> > specific example of how the platform should decide which interrupt line >> >> > to use? >> >> > >> >> >> >> So i've spent some time playing with this. I now have a booting kernel >> >> with multiple root interrupt controllers and peripheral devices >> >> multiply-connected to both root controllers. But only one on of the >> >> controllers is used by Linux (as linux being able to use multiple >> >> intcs is a non-trivial problem). So the scheme I am using is to have >> >> one of these root intc's marked as disabled via >> > >> > Multiple intc's should be a solved problem. What issue are you seeing? >> > Or is this a microblaze specific problem? >> > >> >> It's multiple root (i.e. have no explicit parent) interrupt >> controllers. And linux >> doesnt respect status = "disabled" for interrupt controllers at all it seems. > > That can be fixed. :-) > Patches on list. Regards, Peter > g. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 1/2] of: irq: Ignore disabled intc's when searching map
When searching the interrupt map, if a matched parent is disabled, just ignore it and move on with the search. This allows for specifying connection of a single device IRQ to multiple interrupt controllers via the interrupt map schema. This change allows for selection of the active interrupt controller via the already existing status = "disabled" mechanism. Signed-off-by: Peter Crosthwaite Acked-by: Michal Simek --- drivers/of/irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 786b0b4..22e414b 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -217,6 +217,9 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq) goto fail; } + if (!of_device_is_available(newpar)) + match = 0; + /* Get #interrupt-cells and #address-cells of new * parent */ -- 1.8.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 2/2] of: irq: Ignore disabled interrupt controllers
When searching the system for interrupt controllers, skip over any
that are explicitly disabled.
This makes interrupt controllers consistent with regular devices,
which can be marked as do-not-probe via the status = "disabled" dts
property.
Signed-off-by: Peter Crosthwaite
Acked-by: Michal Simek
---
drivers/of/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 22e414b..bf80268 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -441,7 +441,8 @@ void __init of_irq_init(const struct of_device_id *matches)
INIT_LIST_HEAD(_parent_list);
for_each_matching_node(np, matches) {
- if (!of_find_property(np, "interrupt-controller", NULL))
+ if (!of_find_property(np, "interrupt-controller", NULL) ||
+ !of_device_is_available(np))
continue;
/*
* Here, we allocate and populate an intc_desc with the node
--
1.8.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 0/2] of: irq: Ignore disabled interrupt controllers
Hi All, These two patches support the case where an interrupt controller is marked as disabled. Patch 1 fixed the dts interrupt-map search logic to ignore disabled interrupt controllers. Patch 2 stops disabled interrupt controllers getting probed. Peter Crosthwaite (2): of: irq: Ignore disabled intc's when searching map of: irq: Ignore disabled interrupt controllers drivers/of/irq.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 1.8.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Mon, Nov 25, 2013 at 7:32 AM, Grant Likely wrote: > On Sun, 24 Nov 2013 17:04:52 +1000, Peter Crosthwaite > wrote: >> On Wed, Nov 13, 2013 at 4:14 PM, Grant Likely >> wrote: >> > On Wed, 13 Nov 2013 09:17:01 +1000, Peter Crosthwaite >> > wrote: >> >> It's going to get a little verbose once you start making multiple >> >> connections as you need one mux per wire. Perhaps it could be cleaned >> >> up by making the foo_irq_mux node(s) a child of foo? >> > >> > It could, but then you need some way of attaching a driver to that node, >> > and that would require building knowledge into the driver again. >> > >> > Can you boil it down to a couple of concrete examples? What is a >> > specific example of how the platform should decide which interrupt line >> > to use? >> > >> >> So i've spent some time playing with this. I now have a booting kernel >> with multiple root interrupt controllers and peripheral devices >> multiply-connected to both root controllers. But only one on of the >> controllers is used by Linux (as linux being able to use multiple >> intcs is a non-trivial problem). So the scheme I am using is to have >> one of these root intc's marked as disabled via > > Multiple intc's should be a solved problem. What issue are you seeing? > Or is this a microblaze specific problem? > It's multiple root (i.e. have no explicit parent) interrupt controllers. And linux doesnt respect status = "disabled" for interrupt controllers at all it seems. I'll send the patches tmrw. Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Mon, Nov 25, 2013 at 7:32 AM, Grant Likely grant.lik...@linaro.org wrote: On Sun, 24 Nov 2013 17:04:52 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: On Wed, Nov 13, 2013 at 4:14 PM, Grant Likely grant.lik...@linaro.org wrote: On Wed, 13 Nov 2013 09:17:01 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: It's going to get a little verbose once you start making multiple connections as you need one mux per wire. Perhaps it could be cleaned up by making the foo_irq_mux node(s) a child of foo? It could, but then you need some way of attaching a driver to that node, and that would require building knowledge into the driver again. Can you boil it down to a couple of concrete examples? What is a specific example of how the platform should decide which interrupt line to use? So i've spent some time playing with this. I now have a booting kernel with multiple root interrupt controllers and peripheral devices multiply-connected to both root controllers. But only one on of the controllers is used by Linux (as linux being able to use multiple intcs is a non-trivial problem). So the scheme I am using is to have one of these root intc's marked as disabled via Multiple intc's should be a solved problem. What issue are you seeing? Or is this a microblaze specific problem? It's multiple root (i.e. have no explicit parent) interrupt controllers. And linux doesnt respect status = disabled for interrupt controllers at all it seems. I'll send the patches tmrw. Regards, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 0/2] of: irq: Ignore disabled interrupt controllers
Hi All, These two patches support the case where an interrupt controller is marked as disabled. Patch 1 fixed the dts interrupt-map search logic to ignore disabled interrupt controllers. Patch 2 stops disabled interrupt controllers getting probed. Peter Crosthwaite (2): of: irq: Ignore disabled intc's when searching map of: irq: Ignore disabled interrupt controllers drivers/of/irq.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 1.8.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 2/2] of: irq: Ignore disabled interrupt controllers
When searching the system for interrupt controllers, skip over any
that are explicitly disabled.
This makes interrupt controllers consistent with regular devices,
which can be marked as do-not-probe via the status = disabled dts
property.
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Acked-by: Michal Simek michal.si...@xilinx.com
---
drivers/of/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 22e414b..bf80268 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -441,7 +441,8 @@ void __init of_irq_init(const struct of_device_id *matches)
INIT_LIST_HEAD(intc_parent_list);
for_each_matching_node(np, matches) {
- if (!of_find_property(np, interrupt-controller, NULL))
+ if (!of_find_property(np, interrupt-controller, NULL) ||
+ !of_device_is_available(np))
continue;
/*
* Here, we allocate and populate an intc_desc with the node
--
1.8.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 1/2] of: irq: Ignore disabled intc's when searching map
When searching the interrupt map, if a matched parent is disabled, just ignore it and move on with the search. This allows for specifying connection of a single device IRQ to multiple interrupt controllers via the interrupt map schema. This change allows for selection of the active interrupt controller via the already existing status = disabled mechanism. Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com Acked-by: Michal Simek michal.si...@xilinx.com --- drivers/of/irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 786b0b4..22e414b 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -217,6 +217,9 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq) goto fail; } + if (!of_device_is_available(newpar)) + match = 0; + /* Get #interrupt-cells and #address-cells of new * parent */ -- 1.8.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Thu, Nov 28, 2013 at 12:17 AM, Grant Likely grant.lik...@linaro.org wrote: On Wed, 27 Nov 2013 19:06:35 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: On Mon, Nov 25, 2013 at 7:32 AM, Grant Likely grant.lik...@linaro.org wrote: On Sun, 24 Nov 2013 17:04:52 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: On Wed, Nov 13, 2013 at 4:14 PM, Grant Likely grant.lik...@linaro.org wrote: On Wed, 13 Nov 2013 09:17:01 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: It's going to get a little verbose once you start making multiple connections as you need one mux per wire. Perhaps it could be cleaned up by making the foo_irq_mux node(s) a child of foo? It could, but then you need some way of attaching a driver to that node, and that would require building knowledge into the driver again. Can you boil it down to a couple of concrete examples? What is a specific example of how the platform should decide which interrupt line to use? So i've spent some time playing with this. I now have a booting kernel with multiple root interrupt controllers and peripheral devices multiply-connected to both root controllers. But only one on of the controllers is used by Linux (as linux being able to use multiple intcs is a non-trivial problem). So the scheme I am using is to have one of these root intc's marked as disabled via Multiple intc's should be a solved problem. What issue are you seeing? Or is this a microblaze specific problem? It's multiple root (i.e. have no explicit parent) interrupt controllers. And linux doesnt respect status = disabled for interrupt controllers at all it seems. That can be fixed. :-) Patches on list. Regards, Peter g. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Wed, Nov 13, 2013 at 4:14 PM, Grant Likely wrote: > On Wed, 13 Nov 2013 09:17:01 +1000, Peter Crosthwaite > wrote: >> On Tue, Nov 12, 2013 at 6:50 PM, Grant Likely >> wrote: >> > On Tue, 12 Nov 2013 17:49:37 +1000, Peter Crosthwaite >> > wrote: >> >> Hi Grant, >> >> >> >> On Tue, Nov 12, 2013 at 4:54 PM, Grant Likely >> >> wrote: >> >> > On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite >> >> > wrote: >> >> >> Hi Grant, >> >> >> >> >> >> On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely >> >> >> wrote: >> >> >> > The standard interrupts property in device tree can only handle >> >> >> > interrupts coming from a single interrupt parent. If a device is >> >> >> > wired >> >> >> > to multiple interrupt controllers, then it needs to be attached to a >> >> >> > node with an interrupt-map property to demux the interrupt specifiers >> >> >> > which is confusing. It would be a lot easier if there was a form of >> >> >> > the >> >> >> > interrupts property that allows for a separate interrupt phandle for >> >> >> > each interrupt specifier. >> >> >> > >> >> >> > This patch does exactly that by creating a new interrupts-extended >> >> >> > property which reuses the phandle+arguments pattern used by GPIOs and >> >> >> > other core bindings. >> >> >> > >> >> >> > Signed-off-by: Grant Likely >> >> >> > Cc: Rob Herring >> >> >> > --- >> >> >> > .../bindings/interrupt-controller/interrupts.txt | 29 +++-- >> >> >> > arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + >> >> >> > arch/arm/boot/dts/versatile-ab.dts | 2 +- >> >> >> > arch/arm/boot/dts/versatile-pb.dts | 2 +- >> >> >> > drivers/of/irq.c | 16 +++-- >> >> >> > drivers/of/selftest.c | 70 >> >> >> > ++ >> >> >> > 6 files changed, 122 insertions(+), 13 deletions(-) >> >> >> > >> >> >> > diff --git >> >> >> > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> >> > >> >> >> > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> >> > index 72a06c0..1486497 100644 >> >> >> > --- >> >> >> > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> >> > +++ >> >> >> > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> >> > @@ -4,16 +4,33 @@ Specifying interrupt information for devices >> >> >> > 1) Interrupt client nodes >> >> >> > - >> >> >> > >> >> >> > -Nodes that describe devices which generate interrupts must contain >> >> >> > an >> >> >> > -"interrupts" property. This property must contain a list of >> >> >> > interrupt >> >> >> > -specifiers, one per output interrupt. The format of the interrupt >> >> >> > specifier is >> >> >> > -determined by the interrupt controller to which the interrupts are >> >> >> > routed; see >> >> >> > -section 2 below for details. >> >> >> > +Nodes that describe devices which generate interrupts must contain >> >> >> > an either an >> >> >> > +"interrupts" property or an "interrupts-extended" property. These >> >> >> > properties >> >> >> > +contain a list of interrupt specifiers, one per output interrupt. >> >> >> > The format of >> >> >> > +the interrupt specifier is determined by the interrupt controller >> >> >> > to which the >> >> >> > +interrupts are routed; see section 2 below for details. >> >> >> > + >> >> >> > + Example: >> >> >> > + interrupt-parent = <>; >&g
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Wed, Nov 13, 2013 at 4:14 PM, Grant Likely grant.lik...@linaro.org wrote: On Wed, 13 Nov 2013 09:17:01 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: On Tue, Nov 12, 2013 at 6:50 PM, Grant Likely grant.lik...@linaro.org wrote: On Tue, 12 Nov 2013 17:49:37 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Hi Grant, On Tue, Nov 12, 2013 at 4:54 PM, Grant Likely grant.lik...@linaro.org wrote: On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Hi Grant, On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely grant.lik...@linaro.org wrote: The standard interrupts property in device tree can only handle interrupts coming from a single interrupt parent. If a device is wired to multiple interrupt controllers, then it needs to be attached to a node with an interrupt-map property to demux the interrupt specifiers which is confusing. It would be a lot easier if there was a form of the interrupts property that allows for a separate interrupt phandle for each interrupt specifier. This patch does exactly that by creating a new interrupts-extended property which reuses the phandle+arguments pattern used by GPIOs and other core bindings. Signed-off-by: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com --- .../bindings/interrupt-controller/interrupts.txt | 29 +++-- arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + arch/arm/boot/dts/versatile-ab.dts | 2 +- arch/arm/boot/dts/versatile-pb.dts | 2 +- drivers/of/irq.c | 16 +++-- drivers/of/selftest.c | 70 ++ 6 files changed, 122 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 72a06c0..1486497 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -4,16 +4,33 @@ Specifying interrupt information for devices 1) Interrupt client nodes - -Nodes that describe devices which generate interrupts must contain an -interrupts property. This property must contain a list of interrupt -specifiers, one per output interrupt. The format of the interrupt specifier is -determined by the interrupt controller to which the interrupts are routed; see -section 2 below for details. +Nodes that describe devices which generate interrupts must contain an either an +interrupts property or an interrupts-extended property. These properties +contain a list of interrupt specifiers, one per output interrupt. The format of +the interrupt specifier is determined by the interrupt controller to which the +interrupts are routed; see section 2 below for details. + + Example: + interrupt-parent = intc1; + interrupts = 5 0, 6 0; The interrupt-parent property is used to specify the controller to which interrupts are routed and contains a single phandle referring to the interrupt controller node. This property is inherited, so it may be specified in an -interrupt client node or in any of its parent nodes. +interrupt client node or in any of its parent nodes. Interrupts listed in the +interrupts property are always in reference to the node's interrupt parent. + +The interrupts-extended property is a special form for use when a node needs +to reference multiple interrupt parents. Each entry in this property contains +both the parent phandle and the interrupt specifier. interrupts-extended +should only be used when a device has multiple interrupt parents. + + Example: + interrupts-extended = intc1 5 1, intc2 1 0; + A slightly different but related problem I am trying to solve with interrupt bindings, is to describe connection of a single device interrupt line to multiple interrupts controller, whereas this binding seems to be describing connection of different interrupt lines to different controllers. Can this syntax accommodate my case is any way? Bascially I think I'm asking for multiple interrupt specifiers for a single IRQ output if that's possible. Should I just be using the interrupt map syntax instead? interrupt-map-mask = 0 0 63; interrupt-map = 0 0 25 intc0 ... , 0 0 25 intc1 ... , Interrupt map doesn't actually help you here either since the core code doesn't know what to do with it. It will probably only match and return one of the options
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Tue, Nov 12, 2013 at 6:50 PM, Grant Likely wrote: > On Tue, 12 Nov 2013 17:49:37 +1000, Peter Crosthwaite > wrote: >> Hi Grant, >> >> On Tue, Nov 12, 2013 at 4:54 PM, Grant Likely >> wrote: >> > On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite >> > wrote: >> >> Hi Grant, >> >> >> >> On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely >> >> wrote: >> >> > The standard interrupts property in device tree can only handle >> >> > interrupts coming from a single interrupt parent. If a device is wired >> >> > to multiple interrupt controllers, then it needs to be attached to a >> >> > node with an interrupt-map property to demux the interrupt specifiers >> >> > which is confusing. It would be a lot easier if there was a form of the >> >> > interrupts property that allows for a separate interrupt phandle for >> >> > each interrupt specifier. >> >> > >> >> > This patch does exactly that by creating a new interrupts-extended >> >> > property which reuses the phandle+arguments pattern used by GPIOs and >> >> > other core bindings. >> >> > >> >> > Signed-off-by: Grant Likely >> >> > Cc: Rob Herring >> >> > --- >> >> > .../bindings/interrupt-controller/interrupts.txt | 29 +++-- >> >> > arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + >> >> > arch/arm/boot/dts/versatile-ab.dts | 2 +- >> >> > arch/arm/boot/dts/versatile-pb.dts | 2 +- >> >> > drivers/of/irq.c | 16 +++-- >> >> > drivers/of/selftest.c | 70 >> >> > ++ >> >> > 6 files changed, 122 insertions(+), 13 deletions(-) >> >> > >> >> > diff --git >> >> > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> > index 72a06c0..1486497 100644 >> >> > --- >> >> > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> > +++ >> >> > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> >> > @@ -4,16 +4,33 @@ Specifying interrupt information for devices >> >> > 1) Interrupt client nodes >> >> > - >> >> > >> >> > -Nodes that describe devices which generate interrupts must contain an >> >> > -"interrupts" property. This property must contain a list of interrupt >> >> > -specifiers, one per output interrupt. The format of the interrupt >> >> > specifier is >> >> > -determined by the interrupt controller to which the interrupts are >> >> > routed; see >> >> > -section 2 below for details. >> >> > +Nodes that describe devices which generate interrupts must contain an >> >> > either an >> >> > +"interrupts" property or an "interrupts-extended" property. These >> >> > properties >> >> > +contain a list of interrupt specifiers, one per output interrupt. The >> >> > format of >> >> > +the interrupt specifier is determined by the interrupt controller to >> >> > which the >> >> > +interrupts are routed; see section 2 below for details. >> >> > + >> >> > + Example: >> >> > + interrupt-parent = <>; >> >> > + interrupts = <5 0>, <6 0>; >> >> > >> >> > The "interrupt-parent" property is used to specify the controller to >> >> > which >> >> > interrupts are routed and contains a single phandle referring to the >> >> > interrupt >> >> > controller node. This property is inherited, so it may be specified in >> >> > an >> >> > -interrupt client node or in any of its parent nodes. >> >> > +interrupt client node or in any of its parent nodes. Interrupts listed >> >> > in the >> >> > +"interrupts" property are always in reference to the node's interrupt >> >> > parent. >> >> > + >> >> > +The "interrupts-extended" property is a special fo
Re: [RFC 9/9] of/irq: create interrupts-extended property
On Tue, Nov 12, 2013 at 6:50 PM, Grant Likely grant.lik...@linaro.org wrote: On Tue, 12 Nov 2013 17:49:37 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Hi Grant, On Tue, Nov 12, 2013 at 4:54 PM, Grant Likely grant.lik...@linaro.org wrote: On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Hi Grant, On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely grant.lik...@linaro.org wrote: The standard interrupts property in device tree can only handle interrupts coming from a single interrupt parent. If a device is wired to multiple interrupt controllers, then it needs to be attached to a node with an interrupt-map property to demux the interrupt specifiers which is confusing. It would be a lot easier if there was a form of the interrupts property that allows for a separate interrupt phandle for each interrupt specifier. This patch does exactly that by creating a new interrupts-extended property which reuses the phandle+arguments pattern used by GPIOs and other core bindings. Signed-off-by: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com --- .../bindings/interrupt-controller/interrupts.txt | 29 +++-- arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + arch/arm/boot/dts/versatile-ab.dts | 2 +- arch/arm/boot/dts/versatile-pb.dts | 2 +- drivers/of/irq.c | 16 +++-- drivers/of/selftest.c | 70 ++ 6 files changed, 122 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 72a06c0..1486497 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -4,16 +4,33 @@ Specifying interrupt information for devices 1) Interrupt client nodes - -Nodes that describe devices which generate interrupts must contain an -interrupts property. This property must contain a list of interrupt -specifiers, one per output interrupt. The format of the interrupt specifier is -determined by the interrupt controller to which the interrupts are routed; see -section 2 below for details. +Nodes that describe devices which generate interrupts must contain an either an +interrupts property or an interrupts-extended property. These properties +contain a list of interrupt specifiers, one per output interrupt. The format of +the interrupt specifier is determined by the interrupt controller to which the +interrupts are routed; see section 2 below for details. + + Example: + interrupt-parent = intc1; + interrupts = 5 0, 6 0; The interrupt-parent property is used to specify the controller to which interrupts are routed and contains a single phandle referring to the interrupt controller node. This property is inherited, so it may be specified in an -interrupt client node or in any of its parent nodes. +interrupt client node or in any of its parent nodes. Interrupts listed in the +interrupts property are always in reference to the node's interrupt parent. + +The interrupts-extended property is a special form for use when a node needs +to reference multiple interrupt parents. Each entry in this property contains +both the parent phandle and the interrupt specifier. interrupts-extended +should only be used when a device has multiple interrupt parents. + + Example: + interrupts-extended = intc1 5 1, intc2 1 0; + A slightly different but related problem I am trying to solve with interrupt bindings, is to describe connection of a single device interrupt line to multiple interrupts controller, whereas this binding seems to be describing connection of different interrupt lines to different controllers. Can this syntax accommodate my case is any way? Bascially I think I'm asking for multiple interrupt specifiers for a single IRQ output if that's possible. Should I just be using the interrupt map syntax instead? interrupt-map-mask = 0 0 63; interrupt-map = 0 0 25 intc0 ... , 0 0 25 intc1 ... , Interrupt map doesn't actually help you here either since the core code doesn't know what to do with it. It will probably only match and return one of the options. Yes I noticed that. Although we are a fair way off Linux patches for this just yet and all I want to solve near-term is the hardware description problem (what core Linux IRQ code is actually supposed to do when given such a wiring setup is probably an open question). What I would do is describe both
Re: [RFC 9/9] of/irq: create interrupts-extended property
Hi Grant, On Tue, Nov 12, 2013 at 4:54 PM, Grant Likely wrote: > On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite > wrote: >> Hi Grant, >> >> On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely >> wrote: >> > The standard interrupts property in device tree can only handle >> > interrupts coming from a single interrupt parent. If a device is wired >> > to multiple interrupt controllers, then it needs to be attached to a >> > node with an interrupt-map property to demux the interrupt specifiers >> > which is confusing. It would be a lot easier if there was a form of the >> > interrupts property that allows for a separate interrupt phandle for >> > each interrupt specifier. >> > >> > This patch does exactly that by creating a new interrupts-extended >> > property which reuses the phandle+arguments pattern used by GPIOs and >> > other core bindings. >> > >> > Signed-off-by: Grant Likely >> > Cc: Rob Herring >> > --- >> > .../bindings/interrupt-controller/interrupts.txt | 29 +++-- >> > arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + >> > arch/arm/boot/dts/versatile-ab.dts | 2 +- >> > arch/arm/boot/dts/versatile-pb.dts | 2 +- >> > drivers/of/irq.c | 16 +++-- >> > drivers/of/selftest.c | 70 >> > ++ >> > 6 files changed, 122 insertions(+), 13 deletions(-) >> > >> > diff --git >> > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > index 72a06c0..1486497 100644 >> > --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt >> > @@ -4,16 +4,33 @@ Specifying interrupt information for devices >> > 1) Interrupt client nodes >> > - >> > >> > -Nodes that describe devices which generate interrupts must contain an >> > -"interrupts" property. This property must contain a list of interrupt >> > -specifiers, one per output interrupt. The format of the interrupt >> > specifier is >> > -determined by the interrupt controller to which the interrupts are >> > routed; see >> > -section 2 below for details. >> > +Nodes that describe devices which generate interrupts must contain an >> > either an >> > +"interrupts" property or an "interrupts-extended" property. These >> > properties >> > +contain a list of interrupt specifiers, one per output interrupt. The >> > format of >> > +the interrupt specifier is determined by the interrupt controller to >> > which the >> > +interrupts are routed; see section 2 below for details. >> > + >> > + Example: >> > + interrupt-parent = <>; >> > + interrupts = <5 0>, <6 0>; >> > >> > The "interrupt-parent" property is used to specify the controller to which >> > interrupts are routed and contains a single phandle referring to the >> > interrupt >> > controller node. This property is inherited, so it may be specified in an >> > -interrupt client node or in any of its parent nodes. >> > +interrupt client node or in any of its parent nodes. Interrupts listed in >> > the >> > +"interrupts" property are always in reference to the node's interrupt >> > parent. >> > + >> > +The "interrupts-extended" property is a special form for use when a node >> > needs >> > +to reference multiple interrupt parents. Each entry in this property >> > contains >> > +both the parent phandle and the interrupt specifier. "interrupts-extended" >> > +should only be used when a device has multiple interrupt parents. >> > + >> > + Example: >> > + interrupts-extended = < 5 1>, < 1 0>; >> > + >> >> A slightly different but related problem I am trying to solve with >> interrupt bindings, is to describe connection of a single device >> interrupt line to multiple interrupts controller, whereas this binding >> seems to be describing connection of different interrupt lines to >> different controllers. Can this syntax accommodate my case is any way? >> >> Bascially I think I'm
Re: [RFC 9/9] of/irq: create interrupts-extended property
Hi Grant, On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely wrote: > The standard interrupts property in device tree can only handle > interrupts coming from a single interrupt parent. If a device is wired > to multiple interrupt controllers, then it needs to be attached to a > node with an interrupt-map property to demux the interrupt specifiers > which is confusing. It would be a lot easier if there was a form of the > interrupts property that allows for a separate interrupt phandle for > each interrupt specifier. > > This patch does exactly that by creating a new interrupts-extended > property which reuses the phandle+arguments pattern used by GPIOs and > other core bindings. > > Signed-off-by: Grant Likely > Cc: Rob Herring > --- > .../bindings/interrupt-controller/interrupts.txt | 29 +++-- > arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + > arch/arm/boot/dts/versatile-ab.dts | 2 +- > arch/arm/boot/dts/versatile-pb.dts | 2 +- > drivers/of/irq.c | 16 +++-- > drivers/of/selftest.c | 70 > ++ > 6 files changed, 122 insertions(+), 13 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > index 72a06c0..1486497 100644 > --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > @@ -4,16 +4,33 @@ Specifying interrupt information for devices > 1) Interrupt client nodes > - > > -Nodes that describe devices which generate interrupts must contain an > -"interrupts" property. This property must contain a list of interrupt > -specifiers, one per output interrupt. The format of the interrupt specifier > is > -determined by the interrupt controller to which the interrupts are routed; > see > -section 2 below for details. > +Nodes that describe devices which generate interrupts must contain an either > an > +"interrupts" property or an "interrupts-extended" property. These properties > +contain a list of interrupt specifiers, one per output interrupt. The format > of > +the interrupt specifier is determined by the interrupt controller to which > the > +interrupts are routed; see section 2 below for details. > + > + Example: > + interrupt-parent = <>; > + interrupts = <5 0>, <6 0>; > > The "interrupt-parent" property is used to specify the controller to which > interrupts are routed and contains a single phandle referring to the > interrupt > controller node. This property is inherited, so it may be specified in an > -interrupt client node or in any of its parent nodes. > +interrupt client node or in any of its parent nodes. Interrupts listed in the > +"interrupts" property are always in reference to the node's interrupt parent. > + > +The "interrupts-extended" property is a special form for use when a node > needs > +to reference multiple interrupt parents. Each entry in this property contains > +both the parent phandle and the interrupt specifier. "interrupts-extended" > +should only be used when a device has multiple interrupt parents. > + > + Example: > + interrupts-extended = < 5 1>, < 1 0>; > + A slightly different but related problem I am trying to solve with interrupt bindings, is to describe connection of a single device interrupt line to multiple interrupts controller, whereas this binding seems to be describing connection of different interrupt lines to different controllers. Can this syntax accommodate my case is any way? Bascially I think I'm asking for multiple interrupt specifiers for a single IRQ output if that's possible. Should I just be using the interrupt map syntax instead? interrupt-map-mask = < 0 0 63>; interrupt-map = < 0 0 25 ... >, < 0 0 25 ... >, Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
Hi Grant, On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely grant.lik...@linaro.org wrote: The standard interrupts property in device tree can only handle interrupts coming from a single interrupt parent. If a device is wired to multiple interrupt controllers, then it needs to be attached to a node with an interrupt-map property to demux the interrupt specifiers which is confusing. It would be a lot easier if there was a form of the interrupts property that allows for a separate interrupt phandle for each interrupt specifier. This patch does exactly that by creating a new interrupts-extended property which reuses the phandle+arguments pattern used by GPIOs and other core bindings. Signed-off-by: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com --- .../bindings/interrupt-controller/interrupts.txt | 29 +++-- arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + arch/arm/boot/dts/versatile-ab.dts | 2 +- arch/arm/boot/dts/versatile-pb.dts | 2 +- drivers/of/irq.c | 16 +++-- drivers/of/selftest.c | 70 ++ 6 files changed, 122 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 72a06c0..1486497 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -4,16 +4,33 @@ Specifying interrupt information for devices 1) Interrupt client nodes - -Nodes that describe devices which generate interrupts must contain an -interrupts property. This property must contain a list of interrupt -specifiers, one per output interrupt. The format of the interrupt specifier is -determined by the interrupt controller to which the interrupts are routed; see -section 2 below for details. +Nodes that describe devices which generate interrupts must contain an either an +interrupts property or an interrupts-extended property. These properties +contain a list of interrupt specifiers, one per output interrupt. The format of +the interrupt specifier is determined by the interrupt controller to which the +interrupts are routed; see section 2 below for details. + + Example: + interrupt-parent = intc1; + interrupts = 5 0, 6 0; The interrupt-parent property is used to specify the controller to which interrupts are routed and contains a single phandle referring to the interrupt controller node. This property is inherited, so it may be specified in an -interrupt client node or in any of its parent nodes. +interrupt client node or in any of its parent nodes. Interrupts listed in the +interrupts property are always in reference to the node's interrupt parent. + +The interrupts-extended property is a special form for use when a node needs +to reference multiple interrupt parents. Each entry in this property contains +both the parent phandle and the interrupt specifier. interrupts-extended +should only be used when a device has multiple interrupt parents. + + Example: + interrupts-extended = intc1 5 1, intc2 1 0; + A slightly different but related problem I am trying to solve with interrupt bindings, is to describe connection of a single device interrupt line to multiple interrupts controller, whereas this binding seems to be describing connection of different interrupt lines to different controllers. Can this syntax accommodate my case is any way? Bascially I think I'm asking for multiple interrupt specifiers for a single IRQ output if that's possible. Should I just be using the interrupt map syntax instead? interrupt-map-mask = 0 0 63; interrupt-map = 0 0 25 intc0 ... , 0 0 25 intc1 ... , Regards, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 9/9] of/irq: create interrupts-extended property
Hi Grant, On Tue, Nov 12, 2013 at 4:54 PM, Grant Likely grant.lik...@linaro.org wrote: On Tue, 12 Nov 2013 08:58:15 +1000, Peter Crosthwaite peter.crosthwa...@xilinx.com wrote: Hi Grant, On Wed, Oct 16, 2013 at 6:39 AM, Grant Likely grant.lik...@linaro.org wrote: The standard interrupts property in device tree can only handle interrupts coming from a single interrupt parent. If a device is wired to multiple interrupt controllers, then it needs to be attached to a node with an interrupt-map property to demux the interrupt specifiers which is confusing. It would be a lot easier if there was a form of the interrupts property that allows for a separate interrupt phandle for each interrupt specifier. This patch does exactly that by creating a new interrupts-extended property which reuses the phandle+arguments pattern used by GPIOs and other core bindings. Signed-off-by: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com --- .../bindings/interrupt-controller/interrupts.txt | 29 +++-- arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 16 + arch/arm/boot/dts/versatile-ab.dts | 2 +- arch/arm/boot/dts/versatile-pb.dts | 2 +- drivers/of/irq.c | 16 +++-- drivers/of/selftest.c | 70 ++ 6 files changed, 122 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 72a06c0..1486497 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -4,16 +4,33 @@ Specifying interrupt information for devices 1) Interrupt client nodes - -Nodes that describe devices which generate interrupts must contain an -interrupts property. This property must contain a list of interrupt -specifiers, one per output interrupt. The format of the interrupt specifier is -determined by the interrupt controller to which the interrupts are routed; see -section 2 below for details. +Nodes that describe devices which generate interrupts must contain an either an +interrupts property or an interrupts-extended property. These properties +contain a list of interrupt specifiers, one per output interrupt. The format of +the interrupt specifier is determined by the interrupt controller to which the +interrupts are routed; see section 2 below for details. + + Example: + interrupt-parent = intc1; + interrupts = 5 0, 6 0; The interrupt-parent property is used to specify the controller to which interrupts are routed and contains a single phandle referring to the interrupt controller node. This property is inherited, so it may be specified in an -interrupt client node or in any of its parent nodes. +interrupt client node or in any of its parent nodes. Interrupts listed in the +interrupts property are always in reference to the node's interrupt parent. + +The interrupts-extended property is a special form for use when a node needs +to reference multiple interrupt parents. Each entry in this property contains +both the parent phandle and the interrupt specifier. interrupts-extended +should only be used when a device has multiple interrupt parents. + + Example: + interrupts-extended = intc1 5 1, intc2 1 0; + A slightly different but related problem I am trying to solve with interrupt bindings, is to describe connection of a single device interrupt line to multiple interrupts controller, whereas this binding seems to be describing connection of different interrupt lines to different controllers. Can this syntax accommodate my case is any way? Bascially I think I'm asking for multiple interrupt specifiers for a single IRQ output if that's possible. Should I just be using the interrupt map syntax instead? interrupt-map-mask = 0 0 63; interrupt-map = 0 0 25 intc0 ... , 0 0 25 intc1 ... , Interrupt map doesn't actually help you here either since the core code doesn't know what to do with it. It will probably only match and return one of the options. Yes I noticed that. Although we are a fair way off Linux patches for this just yet and all I want to solve near-term is the hardware description problem (what core Linux IRQ code is actually supposed to do when given such a wiring setup is probably an open question). What I would do is describe both in your interrupts property and make the driver know that the extra interrupt specifier is for the same interrupt output. So this is a little annoying, as ideally device drivers should not be aware of their external connections. I'm trying to describe board (or SoC) level wiring in hopefully
[RFC] Micron M25P80 Part name variants
Hi All,
For micron M25P80 parts there is a mix of naming conventions in the
device table:
/* Micron */
{ "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
{ "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, 0) },
{ "n25q128a13", INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
{ "n25q256a", INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
n25q128 has a11 and a13 variants, while 256 does not. Should this be
consistent across parts? If so should we adopt Liming Wangs "axx"
precedent universally? Here is a hunk from Ed Maste that applies the
relevant change to QEMU (currently on list) that would be nice to
merge. Can we fix this Linux side in similar fashion?
/* Micron */
-{ INFO("n25q032a",0x20bb16, 0, 64 << 10, 64, ER_4K) },
-{ INFO("n25q128a11", 0x20bb18, 0, 64 << 10, 256, 0) },
-{ INFO("n25q128a13", 0x20ba18, 0, 64 << 10, 256, 0) },
-{ INFO("n25q256a",0x20ba19, 0, 64 << 10, 512, ER_4K) },
+{ INFO("n25q032a11", 0x20bb16, 0, 64 << 10, 64, ER_4K) },
+{ INFO("n25q032a13", 0x20ba16, 0, 64 << 10, 64, ER_4K) },
+{ INFO("n25q064a11", 0x20bb17, 0, 64 << 10, 128, ER_4K) },
+{ INFO("n25q064a13", 0x20ba17, 0, 64 << 10, 128, ER_4K) },
+{ INFO("n25q128a11", 0x20bb18, 0, 64 << 10, 256, ER_4K) },
+{ INFO("n25q128a13", 0x20ba18, 0, 64 << 10, 256, ER_4K) },
+{ INFO("n25q256a11", 0x20bb19, 0, 64 << 10, 512, ER_4K) },
+{ INFO("n25q256a13", 0x20ba19, 0, 64 << 10, 512, ER_4K) },
Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] Micron M25P80 Part name variants
Hi All,
For micron M25P80 parts there is a mix of naming conventions in the
device table:
/* Micron */
{ n25q064, INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
{ n25q128a11, INFO(0x20bb18, 0, 64 * 1024, 256, 0) },
{ n25q128a13, INFO(0x20ba18, 0, 64 * 1024, 256, 0) },
{ n25q256a, INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
n25q128 has a11 and a13 variants, while 256 does not. Should this be
consistent across parts? If so should we adopt Liming Wangs axx
precedent universally? Here is a hunk from Ed Maste that applies the
relevant change to QEMU (currently on list) that would be nice to
merge. Can we fix this Linux side in similar fashion?
/* Micron */
-{ INFO(n25q032a,0x20bb16, 0, 64 10, 64, ER_4K) },
-{ INFO(n25q128a11, 0x20bb18, 0, 64 10, 256, 0) },
-{ INFO(n25q128a13, 0x20ba18, 0, 64 10, 256, 0) },
-{ INFO(n25q256a,0x20ba19, 0, 64 10, 512, ER_4K) },
+{ INFO(n25q032a11, 0x20bb16, 0, 64 10, 64, ER_4K) },
+{ INFO(n25q032a13, 0x20ba16, 0, 64 10, 64, ER_4K) },
+{ INFO(n25q064a11, 0x20bb17, 0, 64 10, 128, ER_4K) },
+{ INFO(n25q064a13, 0x20ba17, 0, 64 10, 128, ER_4K) },
+{ INFO(n25q128a11, 0x20bb18, 0, 64 10, 256, ER_4K) },
+{ INFO(n25q128a13, 0x20ba18, 0, 64 10, 256, ER_4K) },
+{ INFO(n25q256a11, 0x20bb19, 0, 64 10, 512, ER_4K) },
+{ INFO(n25q256a13, 0x20ba19, 0, 64 10, 512, ER_4K) },
Regards,
Peter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] microblaze: improve failure handling for GPIO reset
On Thu, Aug 9, 2012 at 4:43 AM, Stephan Linz wrote:
> Early exit from of_platform_reset_gpio_probe() if there
> was no GPIO reset line configured.
>
> Avoid kernel oops in gpio_system_reset():
>
> [ 96.603690] Restarting system.
> [ 96.606094] Machine restart...
> [ 96.608810] Oops: kernel access of bad area, sig: 11
> [ 96.613662] Registers dump: mode=824C1D1C
> [ 96.617858] r1=C000BB0C, r2=, r3=FEF8, r4=15B4
> [ 96.623736] r5=C0276270, r6=0001, r7=, r8=15B4
> [ 96.629597] r9=15B3, r10=15B4, r11=, r12=
> [ 96.635733] r13=, r14=000F, r15=C0002B04, r16=
> [ 96.641973] r17=C011E1A0, r18=8115, r19=0010, r20=48184ED8
> [ 96.648184] r21=, r22=FFEA, r23=0001, r24=FEE1DEAD
> [ 96.654396] r25=0054, r26=1000B1C8, r27=, r28=
> [ 96.660622] r29=, r30=, r31=C24A97E0, rPC=C011E1A0
> [ 96.666849] msr=42A2, ear=004C, esr=0872, fsr=362E3639
>
> Signed-off-by: Stephan Linz
Tested-by: Peter Crosthwaite
> ---
> v2 Remove additional printk message from machine_restart()
> ---
> arch/microblaze/kernel/reset.c |6 +-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
> index 8d663d9..c021123 100644
> --- a/arch/microblaze/kernel/reset.c
> +++ b/arch/microblaze/kernel/reset.c
> @@ -28,6 +28,7 @@ void of_platform_reset_gpio_probe(void)
> if (!gpio_is_valid(handle)) {
> printk(KERN_INFO "Skipping unavailable RESET gpio %d (%s)\n",
> handle, "reset");
> + return;
> }
>
> ret = gpio_request(handle, "reset");
> @@ -60,7 +61,10 @@ err:
>
> static void gpio_system_reset(void)
> {
> - gpio_set_value(handle, 1 - reset_val);
> + if (gpio_is_valid(handle))
> + gpio_set_value(handle, 1 - reset_val);
> + else
> + printk(KERN_NOTICE "Reset GPIO unavailable - halting!\n");
> }
> #else
> static void gpio_system_reset(void)
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] microblaze: improve failure handling for GPIO reset
On Thu, Aug 9, 2012 at 4:43 AM, Stephan Linz l...@li-pro.net wrote:
Early exit from of_platform_reset_gpio_probe() if there
was no GPIO reset line configured.
Avoid kernel oops in gpio_system_reset():
[ 96.603690] Restarting system.
[ 96.606094] Machine restart...
[ 96.608810] Oops: kernel access of bad area, sig: 11
[ 96.613662] Registers dump: mode=824C1D1C
[ 96.617858] r1=C000BB0C, r2=, r3=FEF8, r4=15B4
[ 96.623736] r5=C0276270, r6=0001, r7=, r8=15B4
[ 96.629597] r9=15B3, r10=15B4, r11=, r12=
[ 96.635733] r13=, r14=000F, r15=C0002B04, r16=
[ 96.641973] r17=C011E1A0, r18=8115, r19=0010, r20=48184ED8
[ 96.648184] r21=, r22=FFEA, r23=0001, r24=FEE1DEAD
[ 96.654396] r25=0054, r26=1000B1C8, r27=, r28=
[ 96.660622] r29=, r30=, r31=C24A97E0, rPC=C011E1A0
[ 96.666849] msr=42A2, ear=004C, esr=0872, fsr=362E3639
Signed-off-by: Stephan Linz l...@li-pro.net
Tested-by: Peter Crosthwaite peter.crosthwa...@petalogix.com
---
v2 Remove additional printk message from machine_restart()
---
arch/microblaze/kernel/reset.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index 8d663d9..c021123 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -28,6 +28,7 @@ void of_platform_reset_gpio_probe(void)
if (!gpio_is_valid(handle)) {
printk(KERN_INFO Skipping unavailable RESET gpio %d (%s)\n,
handle, reset);
+ return;
}
ret = gpio_request(handle, reset);
@@ -60,7 +61,10 @@ err:
static void gpio_system_reset(void)
{
- gpio_set_value(handle, 1 - reset_val);
+ if (gpio_is_valid(handle))
+ gpio_set_value(handle, 1 - reset_val);
+ else
+ printk(KERN_NOTICE Reset GPIO unavailable - halting!\n);
}
#else
static void gpio_system_reset(void)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] microblaze: uartlite: avoid NULL pointer exception
On Thu, Aug 9, 2012 at 4:44 AM, Stephan Linz wrote:
> 'prop' is an pointer and can only be unset (NULL) after
> prop = of_get_property() when it goes wrong.
>
> Kernel oops in ulite_probe():
>
> [1.016645] uartlite 8fff.debug: failed to get alias id, errno -19
> [1.024246] Oops: kernel access of bad area, sig: 11
> [1.029733] Registers dump: mode=27827D60
> [1.034362] r1=C79113E0, r2=, r3=, r4=
> [1.040918] r5=C02E1E49, r6=C02D5918, r7=0070, r8=14C9
> [1.047475] r9=14C8, r10=14C9, r11=0006, r12=FFFC
> [1.054318] r13=, r14=C79114A0, r15=C0293BDC, r16=
> [1.061261] r17=C0293BE4, r18=FFFE, r19=C788BDC8, r20=
> [1.068207] r21=, r22=FFED, r23=C788BDC0, r24=C033E840
> [1.075145] r25=C033EEA4, r26=, r27=, r28=
> [1.082086] r29=, r30=, r31=C7824AC0, rPC=C0293BE4
> [1.089024] msr=46A2, ear=, esr=0872, fsr=C7827E08
> [1.096281] Kernel panic - not syncing: Attempted to kill init!
>
> Now it is:
>
> [1.014924] uartlite 8fff.debug: failed to get alias id, errno -19
> [1.022543] uartlite 8fff.debug: failed to get port-number
>
> Signed-off-by: Stephan Linz
Reviewed-by: Peter Crosthwaite
Tested-by: Peter Crosthwaite
> ---
> drivers/tty/serial/uartlite.c |5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
> index a276282..3cba732 100644
> --- a/drivers/tty/serial/uartlite.c
> +++ b/drivers/tty/serial/uartlite.c
> @@ -589,9 +589,8 @@ static int __devinit ulite_probe(struct platform_device
> *pdev)
> dev_warn(>dev, "failed to get alias id, errno %d\n",
> id);
> /* Fall back to old port-number property */
> prop = of_get_property(pdev->dev.of_node, "port-number",
> NULL);
> - if (prop < 0) {
> - dev_warn(>dev,
> - "failed to get port-number, errno %d\n",
> prop);
> + if (!prop) {
> + dev_warn(>dev, "failed to get port-number\n");
> id = -1;
> } else
> id = be32_to_cpup(prop);
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] microblaze: uartlite: avoid NULL pointer exception
On Thu, Aug 9, 2012 at 4:44 AM, Stephan Linz l...@li-pro.net wrote:
'prop' is an pointer and can only be unset (NULL) after
prop = of_get_property() when it goes wrong.
Kernel oops in ulite_probe():
[1.016645] uartlite 8fff.debug: failed to get alias id, errno -19
[1.024246] Oops: kernel access of bad area, sig: 11
[1.029733] Registers dump: mode=27827D60
[1.034362] r1=C79113E0, r2=, r3=, r4=
[1.040918] r5=C02E1E49, r6=C02D5918, r7=0070, r8=14C9
[1.047475] r9=14C8, r10=14C9, r11=0006, r12=FFFC
[1.054318] r13=, r14=C79114A0, r15=C0293BDC, r16=
[1.061261] r17=C0293BE4, r18=FFFE, r19=C788BDC8, r20=
[1.068207] r21=, r22=FFED, r23=C788BDC0, r24=C033E840
[1.075145] r25=C033EEA4, r26=, r27=, r28=
[1.082086] r29=, r30=, r31=C7824AC0, rPC=C0293BE4
[1.089024] msr=46A2, ear=, esr=0872, fsr=C7827E08
[1.096281] Kernel panic - not syncing: Attempted to kill init!
Now it is:
[1.014924] uartlite 8fff.debug: failed to get alias id, errno -19
[1.022543] uartlite 8fff.debug: failed to get port-number
Signed-off-by: Stephan Linz l...@li-pro.net
Reviewed-by: Peter Crosthwaite peter.crosthwa...@petalogix.com
Tested-by: Peter Crosthwaite peter.crosthwa...@petalogix.com
---
drivers/tty/serial/uartlite.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
index a276282..3cba732 100644
--- a/drivers/tty/serial/uartlite.c
+++ b/drivers/tty/serial/uartlite.c
@@ -589,9 +589,8 @@ static int __devinit ulite_probe(struct platform_device
*pdev)
dev_warn(pdev-dev, failed to get alias id, errno %d\n,
id);
/* Fall back to old port-number property */
prop = of_get_property(pdev-dev.of_node, port-number,
NULL);
- if (prop 0) {
- dev_warn(pdev-dev,
- failed to get port-number, errno %d\n,
prop);
+ if (!prop) {
+ dev_warn(pdev-dev, failed to get port-number\n);
id = -1;
} else
id = be32_to_cpup(prop);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
