* [PATCH RESEND v2] bus: ARM CCN PMU driver
From: Arnd Bergmann @ 2014-07-23 21:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407232223.39341.arnd@arndb.de>
On Wednesday 23 July 2014 22:23:38 Arnd Bergmann wrote:
> On Tuesday 22 July 2014, Pawel Moll wrote:
> > Driver providing perf backend for ARM Cache Coherent Network
> > interconnect. Supports counting all hardware events and crosspoint
> > watchpoints.
> >
> > Currently works with CCN-504 only, although there should be
> > no changes required for CCN-508 (just impossible to test it now).
> >
> > Signed-off-by: Pawel Moll <pawel.moll@arm.com>
>
> Applied to next/drivers, thanks!
I'm getting build errors with CONFIG_PERF_EVENTS disabled.
Is the patch below the right answer, or should we still load
the driver and #ifdef the perf-events code?
It seems to me that the driver doesn't do anything besides
perf events, but I could be missing something.
Arnd
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 5c0c2764839f..603eb1be4f6a 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -53,6 +53,7 @@ config ARM_CCI
config ARM_CCN
bool "ARM CCN driver support"
depends on ARM || ARM64
+ depends on PERF_EVENTS
help
PMU (perf) driver supporting the ARM CCN (Cache Coherent Network)
interconnect.
^ permalink raw reply related
* iMX6Q - PCIe
From: John Tobias @ 2014-07-23 21:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
I am trying to use the PCIe on iMX6Q and I am using kernel 3.15.2 and
AEH-AR9462-LC WFI-BT module.
The said module were able to detect by the kernel, able to bring up
the wifi and bluetooth interface and able to scan bluetooth devices as
as scan wifi.
When, I run /usr/sbin/wpa_supplicant -Dnl80211 -iwlp1s0
-c/tmp/wpa_supplicant.conf, I got the following logs (please see
below). The wpa supplicant keeps trying to connect but for unknown
reason, it keeps disconnecting.
Any idea?.
Regards,
john
[ 572.744649] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
wlp1s0: CTRL-EVENT-SCAN-STARTED
wlp1s0: SME: Trying to authentica[ 576.314045] wlp1s0: authenticate
with d8:c7:c8:3b:e0:72
te with d8:c7:c8:3b:e0:72 (SSID='MySSID' freq=5580 MHz)
[ 576.334915] wlp1s0: direct probe to d8:c7:c8:3b:e0:72 (try 1/3)
[ 576.541579] wlp1s0: direct probe to d8:c7:c8:3b:e0:72 (try 2/3)
[ 576.748576] wlp1s0: direct probe to d8:c7:c8:3b:e0:72 (try 3/3)
[ 576.955575] wlp1s0: authentication with d8:c7:c8:3b:e0:72 timed out
wlp1s0: CTRL-EVENT-SCAN-STARTED
wlp1s0: SME: Trying to authentica[ 577.469346] wlp1s0: authenticate
with d8:c7:c8:3b:e0:62
te with d8:c7:c8:3b:e0:62 (SSID='MySSID' freq=2462 MHz)
[ 577.489959] wlp1s0: direct probe to d8:c7:c8:3b:e0:62 (try 1/3)
[ 577.696656] wlp1s0: direct probe to d8:c7:c8:3b:e0:62 (try 2/3)
[ 577.903586] wlp1s0: direct probe to d8:c7:c8:3b:e0:62 (try 3/3)
[ 578.110586] wlp1s0: authentication with d8:c7:c8:3b:e0:62 timed out
wlp1s0: CTRL-EVENT-SCAN-STARTED
wlp1s0: SME: Trying to authentica[ 578.565037] wlp1s0: authenticate
with 6c:f3:7f:1a:22:2a
te with 6c:f3:7f:1a:22:2a (SSID='MySSID' freq=5240 MHz)
[ 578.586309] wlp1s0: direct probe to 6c:f3:7f:1a:22:2a (try 1/3)
[ 578.792580] wlp1s0: direct probe to 6c:f3:7f:1a:22:2a (try 2/3)
[ 578.999627] wlp1s0: direct probe to 6c:f3:7f:1a:22:2a (try 3/3)
[ 579.206576] wlp1s0: authentication with 6c:f3:7f:1a:22:2a timed out
wlp1s0: CTRL-EVENT-SCAN-STARTED
wlp1s0: SME: Trying to authentica[ 579.594670] wlp1s0: authenticate
with 24:de:c6:18:36:52
te with 24:de:c6:18:36:52 (SSID='MySSID' freq=5660 MHz)
[ 579.615907] wlp1s0: direct probe to 24:de:c6:18:36:52 (try 1/3)
[ 579.822587] wlp1s0: direct probe to 24:de:c6:18:36:52 (try 2/3)
[ 580.029587] wlp1s0: direct probe to 24:de:c6:18:36:52 (try 3/3)
[ 580.236582] wlp1s0: authentication with 24:de:c6:18:36:52 timed out
wlp1s0: CTRL-EVENT-SCAN-STARTED
wlp1s0: SME: Trying to authentica[ 580.510611] wlp1s0: authenticate
with 6c:f3:7f:1a:2a:6a
te with 6c:f3:7f:1a:2a:6a (SSID='MySSID' freq=5200 MHz)
[ 580.532053] wlp1s0: direct probe to 6c:f3:7f:1a:2a:6a (try 1/3)
\x03[ 580.539067] wlp1s0: aborting authentication with 6c:f3:7f:1a:2a:6a
by local choice (Reason: 3=DEAUTH_LEAVING)
wlp1s0: CTRL-EVENT-DISCONNECTED bssid=6c:f3:7f:1a:2a:6a reason=3
locally_generated=1
^ permalink raw reply
* [PATCHv4 3/5] common: dma-mapping: Introduce common remapping functions
From: Laura Abbott @ 2014-07-23 21:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723104554.GB1366@localhost>
On 7/23/2014 3:45 AM, Catalin Marinas wrote:
> On Wed, Jul 23, 2014 at 02:35:06AM +0100, Laura Abbott wrote:
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -298,37 +298,19 @@ static void *
>> __dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
>> const void *caller)
>> {
>> - struct vm_struct *area;
>> - unsigned long addr;
>> -
>> /*
>> * DMA allocation can be mapped to user space, so lets
>> * set VM_USERMAP flags too.
>> */
>> - area = get_vm_area_caller(size, VM_ARM_DMA_CONSISTENT | VM_USERMAP,
>> - caller);
>> - if (!area)
>> - return NULL;
>> - addr = (unsigned long)area->addr;
>> - area->phys_addr = __pfn_to_phys(page_to_pfn(page));
>> -
>> - if (ioremap_page_range(addr, addr + size, area->phys_addr, prot)) {
>> - vunmap((void *)addr);
>> - return NULL;
>> - }
>> - return (void *)addr;
>> + return dma_common_contiguous_remap(page, size,
>> + VM_ARM_DMA_CONSISTENT | VM_USERMAP,
>> + prot, caller);
>
> I think we still need at least a comment in the commit log since the arm
> code is moving from ioremap_page_range() to map_vm_area(). There is a
> slight performance penalty with the addition of a kmalloc() on this
> path.
>
> Or even better (IMO), see below.
>
>> --- a/drivers/base/dma-mapping.c
>> +++ b/drivers/base/dma-mapping.c
> [...]
>> +void *dma_common_contiguous_remap(struct page *page, size_t size,
>> + unsigned long vm_flags,
>> + pgprot_t prot, const void *caller)
>> +{
>> + int i;
>> + struct page **pages;
>> + void *ptr;
>> +
>> + pages = kmalloc(sizeof(struct page *) << get_order(size), GFP_KERNEL);
>> + if (!pages)
>> + return NULL;
>> +
>> + for (i = 0; i < (size >> PAGE_SHIFT); i++)
>> + pages[i] = page + i;
>> +
>> + ptr = dma_common_pages_remap(pages, size, vm_flags, prot, caller);
>> +
>> + kfree(pages);
>> +
>> + return ptr;
>> +}
>
> You could avoid the dma_common_page_remap() here (and kmalloc) and
> simply use ioremap_page_range(). We know that
> dma_common_contiguous_remap() is only called with contiguous physical
> range, so ioremap_page_range() is suitable. It also makes it a
> non-functional change for arch/arm.
>
My original thought with using map_vm_area vs. ioremap_page_range was
that ioremap_page_range is really intended for mapping io devices and
the like into the kernel virtual address space. map_vm_area is designed
to handle pages of kernel managed memory. Perhaps it's too nit-picky
a distinction though.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 00/14] arm64: eBPF JIT compiler
From: David Miller @ 2014-07-23 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABg9mcsPUwQe_7KrG=-8UJi1cA3+xbaDo1u+niFQ+JQRt37w7Q@mail.gmail.com>
From: Z Lim <zlim.lnx@gmail.com>
Date: Tue, 22 Jul 2014 22:24:13 -0700
> David, any chance of pulling this series into net-next for 3.17?
I'm more than happy to pull this into net-next as long as the ARM
folks are OK with it.
And if so, please repost this series with the Acks added.
Thanks.
^ permalink raw reply
* [PATCH 4/4] (RFC) X86: add IPI tracepoints
From: Nicolas Pitre @ 2014-07-23 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721185459.54c81bd5@gandalf.local.home>
On Mon, 21 Jul 2014, Steven Rostedt wrote:
> On Fri, 18 Jul 2014 16:59:50 -0400 (EDT)
> Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
> > On Fri, 18 Jul 2014, Steven Rostedt wrote:
> >
> > > On Fri, 18 Jul 2014 01:18:55 -0400
> > > Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > >
> > >
> > > > diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
> > > > index be8e1bde07..e154d176cf 100644
> > > > --- a/arch/x86/kernel/smp.c
> > > > +++ b/arch/x86/kernel/smp.c
> > > > @@ -31,6 +31,12 @@
> > > > #include <asm/apic.h>
> > > > #include <asm/nmi.h>
> > > > #include <asm/trace/irq_vectors.h>
> > > > +
> > > > +#define CREATE_TRACE_POINTS
> > > > +#undef TRACE_INCLUDE_PATH
> > > > +#undef TRACE_INCLUDE_FILE
> > >
> > > I'm curious to why you added the #undefs. I wouldn't think they were
> > > needed.
> >
> > They are needed because asm/trace/irq_vectors.h included prior that
> > point defines them for itself and that makes the inclusion of
> > trace/events/ipi.h fail.
> >
>
> Bah, I tried to get rid of the need for those, but it seems that the
> macro magic is getting a bit out of hand. I need a new macro magic
> hat :-p
>
> What you got here will have to do.
OK.
Now the real question: should I submit it for mainline? I'm a little
bothered by the fact that all exception vectors already have tracepoints
of their own, albeit deeply tied to X86 nomenclature. But nothing that
relates to IPI sources. This patch fixes that by adding some
tracepoints alongside existing ones which may go a long way in making
their instrumentation with generic (arch independent) tools.
What do people think?
Nicolas
^ permalink raw reply
* iMX6Q - PCIe
From: Eric Bénard @ 2014-07-23 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYP9w+qUUtp2LRKgD-Dz+2pubFeX82dGQ6tiv2Ji6VgVig@mail.gmail.com>
Hi John,
Le Wed, 23 Jul 2014 14:49:15 -0700,
John Tobias <john.tobias.ph@gmail.com> a ?crit :
> I am trying to use the PCIe on iMX6Q and I am using kernel 3.15.2 and
> AEH-AR9462-LC WFI-BT module.
>
> The said module were able to detect by the kernel, able to bring up
> the wifi and bluetooth interface and able to scan bluetooth devices as
> as scan wifi.
>
> When, I run /usr/sbin/wpa_supplicant -Dnl80211 -iwlp1s0
> -c/tmp/wpa_supplicant.conf, I got the following logs (please see
> below). The wpa supplicant keeps trying to connect but for unknown
> reason, it keeps disconnecting.
>
>
> Any idea?.
>
you can try to disable MSI (at least that's how I got ath9k working in
FSL's kernel)
Eric
^ permalink raw reply
* [PATCH 2/4] ARM: add IPI tracepoints
From: Nicolas Pitre @ 2014-07-23 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405660735-13408-3-git-send-email-nicolas.pitre@linaro.org>
@Russell: Can I have your ACK on this patch before I send the series
upstream? Here's the revised version accounting for the changes the
discussion in this thread brought about
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Fri Jul 18 00:07:05 2014 -0400
ARM: add IPI tracepoints
The strings used to list IPIs in /proc/interrupts are reused for tracing
purposes.
While at it, prevent a negative ipinr from escaping the range check
in handle_IPI().
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 7c4fada440..9388a3d479 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -47,6 +47,9 @@
#include <asm/mach/arch.h>
#include <asm/mpu.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/ipi.h>
+
/*
* as from 2.5, kernels no longer have an init_tasks structure
* so we need some other way of telling a new secondary core
@@ -430,38 +433,15 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
}
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void (*__smp_cross_call)(const struct cpumask *, unsigned int);
void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
{
- if (!smp_cross_call)
- smp_cross_call = fn;
-}
-
-void arch_send_call_function_ipi_mask(const struct cpumask *mask)
-{
- smp_cross_call(mask, IPI_CALL_FUNC);
-}
-
-void arch_send_wakeup_ipi_mask(const struct cpumask *mask)
-{
- smp_cross_call(mask, IPI_WAKEUP);
-}
-
-void arch_send_call_function_single_ipi(int cpu)
-{
- smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+ if (!__smp_cross_call)
+ __smp_cross_call = fn;
}
-#ifdef CONFIG_IRQ_WORK
-void arch_irq_work_raise(void)
-{
- if (is_smp())
- smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
-}
-#endif
-
-static const char *ipi_types[NR_IPI] = {
+static const char *ipi_types[NR_IPI] __tracepoint_string = {
#define S(x,s) [x] = s
S(IPI_WAKEUP, "CPU wakeup interrupts"),
S(IPI_TIMER, "Timer broadcast interrupts"),
@@ -473,6 +453,12 @@ static const char *ipi_types[NR_IPI] = {
S(IPI_COMPLETION, "completion interrupts"),
};
+static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
+{
+ trace_ipi_raise(target, ipi_types[ipinr]);
+ __smp_cross_call(target, ipinr);
+}
+
void show_ipi_list(struct seq_file *p, int prec)
{
unsigned int cpu, i;
@@ -499,6 +485,29 @@ u64 smp_irq_stat_cpu(unsigned int cpu)
return sum;
}
+void arch_send_call_function_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_CALL_FUNC);
+}
+
+void arch_send_wakeup_ipi_mask(const struct cpumask *mask)
+{
+ smp_cross_call(mask, IPI_WAKEUP);
+}
+
+void arch_send_call_function_single_ipi(int cpu)
+{
+ smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
+}
+
+#ifdef CONFIG_IRQ_WORK
+void arch_irq_work_raise(void)
+{
+ if (is_smp())
+ smp_cross_call(cpumask_of(smp_processor_id()), IPI_IRQ_WORK);
+}
+#endif
+
#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
void tick_broadcast(const struct cpumask *mask)
{
@@ -556,8 +565,10 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
unsigned int cpu = smp_processor_id();
struct pt_regs *old_regs = set_irq_regs(regs);
- if (ipinr < NR_IPI)
+ if ((unsigned)ipinr < NR_IPI) {
+ trace_ipi_entry(ipi_types[ipinr]);
__inc_irq_stat(cpu, ipi_irqs[ipinr]);
+ }
switch (ipinr) {
case IPI_WAKEUP:
@@ -612,6 +623,9 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
cpu, ipinr);
break;
}
+
+ if ((unsigned)ipinr < NR_IPI)
+ trace_ipi_exit(ipi_types[ipinr]);
set_irq_regs(old_regs);
}
^ permalink raw reply related
* [PATCH 1/2] Added dts defintion for Lenovo ix4-300d nas
From: Andrew Lunn @ 2014-07-23 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9AE6F1AD-9296-47E9-91E2-9E34AA48EBB4@perenite.com>
> Both phy are :
> marvell,88e1318
I don't have the datasheet for this specific phy model, but i do have
the datasheet for another similar phy.
> example of a minimal reg write that lead MPP24 to shutdown instead
> of rebooting on original BSP driver
> XXXXX BasicInit
I'm assuming regOffs is decimal, and data is hex?
> phyAdr 0: regOffs: 16 data: 3
Copper Specific control register. 3 means Polarity Reversal Disable &
Jabber function disable.
> phyAdr 0: regOffs: 10 data: 830
Reg 10 is the 1000BASE-T Status register, which is read only!
So this is not making much sense. Are we missing some changes to the
page register? Register 16 of page 3 is the LED control register.
Andrew
^ permalink raw reply
* [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list.
From: Andrew Lunn @ 2014-07-23 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406154923-13612-1-git-send-email-yahoo@perenite.com>
On Wed, Jul 23, 2014 at 03:35:22PM -0700, Benoit Masson wrote:
> Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational computer technology company with headquarters in Beijing, China, and Morrisville, North Carolina, United States.
>
> http://www.lenovo.com/
> Signed-off-by: Benoit Masson <yahoo@perenite.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Andrew
> ---
> 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 46a311e..ae09892 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -71,6 +71,7 @@ karo Ka-Ro electronics GmbH
> keymile Keymile GmbH
> lacie LaCie
> lantiq Lantiq Semiconductor
> +lenovo Lenovo Group Ltd.
> lg LG Corporation
> linux Linux-specific binding
> lsi LSI Corp. (LSI Logic)
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list.
From: Benoit Masson @ 2014-07-23 22:35 UTC (permalink / raw)
To: linux-arm-kernel
Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational computer technology company with headquarters in Beijing, China, and Morrisville, North Carolina, United States.
http://www.lenovo.com/
Signed-off-by: Benoit Masson <yahoo@perenite.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 46a311e..ae09892 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -71,6 +71,7 @@ karo Ka-Ro electronics GmbH
keymile Keymile GmbH
lacie LaCie
lantiq Lantiq Semiconductor
+lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
lsi LSI Corp. (LSI Logic)
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Benoit Masson @ 2014-07-23 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406154923-13612-1-git-send-email-yahoo@perenite.com>
The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
http://shop.lenovo.com/fr/fr/servers/network-storage/lenovoemc/ix4-300d/
Signed-off-by: Benoit Masson <yahoo@perenite.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 284 ++++++++++++++++++++++++
2 files changed, 286 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index adb5ed9..4429495 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -437,8 +437,9 @@ dtb-$(CONFIG_MACH_ARMADA_XP) += \
armada-xp-axpwifiap.dtb \
armada-xp-db.dtb \
armada-xp-gp.dtb \
- armada-xp-netgear-rn2120.dtb \
+ armada-xp-lenovo-ix4-300d.dtb \
armada-xp-matrix.dtb \
+ armada-xp-netgear-rn2120.dtb \
armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
dove-cubox.dtb \
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
new file mode 100644
index 0000000..aedc9dc
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -0,0 +1,284 @@
+/*
+ * Device Tree file for Lenovo Iomega ix4-300d
+ *
+ * Copyright (C) 2014, Benoit Masson <yahoo@perenite.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "armada-xp-mv78230.dtsi"
+
+/ {
+ model = "Lenovo Iomega ix4-300d";
+ compatible = "lenovo,ix4-300d", "marvell,armadaxp-mv78230",
+ "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ stdout-path = "/soc/internal-regs/serial at 12000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x00000000 0 0x20000000>; /* 512MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+
+ pcie-controller {
+ status = "okay";
+
+ /* Quad port sata: Marvell 88SX7042 */
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ /* USB 3.0 xHCI controller: NEC D720200F1 */
+ pcie at 5,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+ };
+
+ internal-regs {
+ pinctrl {
+ poweroff_pin: poweroff-pin {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+
+ power_button_pin: power-button-pin {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+
+ reset_button_pin: reset-button-pin {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+ select_button_pin: select-button-pin {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+
+ scroll_button_pin: scroll-button-pin {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+
+ hdd_led_pin: hdd-led-pin {
+ marvell,pins = "mpp26";
+ marvell,function = "gpio";
+ };
+ };
+
+ serial at 12000 {
+ status = "okay";
+ };
+
+ mdio {
+ phy0: ethernet-phy at 0 { /* Marvell 88E1318 */
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy at 1 { /* Marvell 88E1318 */
+ reg = <1>;
+ };
+ };
+
+ ethernet at 70000 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+
+ ethernet at 74000 {
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
+
+ usb at 50000 {
+ status = "okay";
+ };
+
+ usb at 51000 {
+ status = "okay";
+ };
+
+ i2c at 11000 {
+ compatible = "marvell,mv78230-a0-i2c",
+ "marvell,mv64xxx-i2c";
+ clock-frequency = <400000>;
+ status = "okay";
+
+ adt7473 at 2e {
+ compatible = "adi,adt7473";
+ reg = <0x2e>;
+ };
+
+ pcf8563 at 51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ };
+
+ nand at d0000 {
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0x0000000 0xe0000>;
+ read-only;
+ };
+
+ partition at e0000 {
+ label = "u-boot-env";
+ reg = <0xe0000 0x20000>;
+ read-only;
+ };
+
+ partition at 100000 {
+ label = "u-boot-env2";
+ reg = <0x100000 0x20000>;
+ read-only;
+ };
+
+ partition at 120000 {
+ label = "zImage";
+ reg = <0x120000 0x400000>;
+ };
+
+ partition at 520000 {
+ label = "initrd";
+ reg = <0x520000 0x400000>;
+ };
+
+ partition at xE00000 {
+ label = "boot";
+ reg = <0xE00000 0x3F200000>;
+ };
+
+ partition at flash {
+ label = "flash";
+ reg = <0x0 0x40000000>;
+ };
+ };
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&power_button_pin &reset_button_pin
+ &select_button_pin &scroll_button_pin>;
+ pinctrl-names = "default";
+
+ power-button {
+ label = "Power Button";
+ linux,code = <KEY_POWER>;
+ gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ reset-button {
+ label = "Reset Button";
+ linux,code = <KEY_RESTART>;
+ gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
+ };
+
+ select-button {
+ label = "Select Button";
+ linux,code = <BTN_SELECT>;
+ gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ };
+
+ scroll-button {
+ label = "Scroll Button";
+ linux,code = <KEY_SCROLLDOWN>;
+ gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ spi3 {
+ compatible = "spi-gpio";
+ status = "okay";
+ gpio-sck = <&gpio0 25 0>;
+ gpio-mosi = <&gpio1 15 0>; /*gpio 47*/
+ cs-gpios = <&gpio0 27 0 >;
+ num-chipselects = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio2: gpio2 at 0 {
+ compatible = "fairchild,74hc595";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ registers-number = <2>;
+ spi-max-frequency = <100000>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&hdd_led_pin>;
+ pinctrl-names = "default";
+
+ hdd-led {
+ label = "ix4-300d:blue:hdd";
+ gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ power-led {
+ label = "ix4-300d:power";
+ gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+ /* init blinking while booting */
+ linux,default-trigger = "timer";
+ default-state = "on";
+ };
+
+ sysfail-led {
+ label = "ix4-300d:sysfail:red";
+ gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ sys-led {
+ label = "ix4-300d:sys:blue";
+ gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ hddfail-led {
+ label = "ix4-300d:hddfail:red";
+ gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ };
+
+ /* Warning: you need both eth1 & 0 PHY initialized
+ (i.e having them up does the tweak)
+ for poweroff to shutdown otherwise it reboots */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ pinctrl-0 = <&poweroff_pin>;
+ pinctrl-names = "default";
+ gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Andrew Lunn @ 2014-07-23 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406154923-13612-2-git-send-email-yahoo@perenite.com>
> + i2c at 11000 {
> + compatible = "marvell,mv78230-a0-i2c",
> + "marvell,mv64xxx-i2c";
Ah sorry, i missed this first time. Do you really need
"marvell,mv78230-a0-i2c"?
Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt says:
- "marvell,mv78230-a0-i2c"
* Note: Only use "marvell,mv78230-a0-i2c" for a
very rare, initial version of the SoC which
had broken offload support. Linux
auto-detects this and sets it appropriately.
So i don't think you should have this hear.
Gregory, please could you comment.
> + power-led {
> + label = "ix4-300d:power";
It is normal to include the colour, and you did for all the other
LEDs.
Andrew
^ permalink raw reply
* [PATCH 0/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
From: Suman Anna @ 2014-07-23 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CF34B8.6000602@ti.com>
Hi Lokesh,
On 07/22/2014 11:06 PM, Vutla, Lokesh wrote:
> Hi Nishanth,
> On Tuesday 22 July 2014 10:15 PM, Nishanth Menon wrote:
>> On 07/16/2014 03:36 AM, Lokesh Vutla wrote:
>>> This series add seperate ocp interface lists that are specific to dra74x
>>> and dra72x, and moving USB OTG SS4 to dra74x only since its not present
>>> in dra72x. Without this USB OTG SS4 hwmod gives an abort on dra72x.
>>>
>>> Adding support for soc_is_dra74x() and soc_is_dra72x() in order to differentiate
>>> between dra74x and dra72x and pass the respective ocp interface lists.
>>>
>>> Verified on dra74x evm and dra72x evm using 3.16-rc5 based mainline kernel.
Thanks for the series. I also need this for the differences in DSPs
present on both SoCs.
>>>
>>> Before:
>>> dra74x : http://paste.ubuntu.com/7802364/
>>> dra72x : http://paste.ubuntu.com/7802334/ (Kernel panic)
>>>
>>> After-
>>> dra74x : http://paste.ubuntu.com/7802340/
>>> dra72x : http://paste.ubuntu.com/7802338/ (booted)
>>>
>>> Rajendra Nayak (2):
>>> ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x()
>>> varients
>>> ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
>>>
>>> arch/arm/mach-omap2/omap_hwmod.c | 3 +++
>>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 ++++++++++++++++++++--
>>> arch/arm/mach-omap2/soc.h | 7 +++++++
>>> 3 files changed, 30 insertions(+), 2 deletions(-)
>>>
>> Tested-by: Nishanth Menon <nm@ti.com>
> Thanks..
>>
>> BUT, I suggest a follow up series to do exactly the same (moving stuff
>> that are not common from dra7.dtsi to dra72x.dtsi and 74x.dtsi) as
>> well to ensure that dts indicates exactly the same information (only
>> the applicable IPs are present in dts).
We also need a similar split for clockdomains, and possibly powerdomains
(I haven't compared all of them myself).
regards
Suman
> The separation of dra72x.dtsi and dra74x.dtsi is already happened and the patch is
> already present in mainline[1].
> Looks like usb_otg_ss4 is still present in dra7.dtsi, but this should go into dra74x.dtsi.
> I ll take it up.
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=38b248db60e32734417534b57f9ab687c445113a
>
> Thanks and regards,
> Lokesh
>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* iMX6Q - PCIe
From: John Tobias @ 2014-07-23 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724001622.2b475138@e6520eb>
Hi Eric,
I have a few questions:
1. May I know what FSL's kernel version you are using?.
2. Did you make changes in your device tree for PCIe?.
3. Can I have the model/part # of your ath9k?.
Regards,
john
On Wed, Jul 23, 2014 at 3:16 PM, Eric B?nard <eric@eukrea.com> wrote:
> Hi John,
>
> Le Wed, 23 Jul 2014 14:49:15 -0700,
> John Tobias <john.tobias.ph@gmail.com> a ?crit :
>> I am trying to use the PCIe on iMX6Q and I am using kernel 3.15.2 and
>> AEH-AR9462-LC WFI-BT module.
>>
>> The said module were able to detect by the kernel, able to bring up
>> the wifi and bluetooth interface and able to scan bluetooth devices as
>> as scan wifi.
>>
>> When, I run /usr/sbin/wpa_supplicant -Dnl80211 -iwlp1s0
>> -c/tmp/wpa_supplicant.conf, I got the following logs (please see
>> below). The wpa supplicant keeps trying to connect but for unknown
>> reason, it keeps disconnecting.
>>
>>
>> Any idea?.
>>
> you can try to disable MSI (at least that's how I got ath9k working in
> FSL's kernel)
>
> Eric
^ permalink raw reply
* [PATCH 1/2] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
From: Suman Anna @ 2014-07-23 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405499774-19770-2-git-send-email-lokeshvutla@ti.com>
On 07/16/2014 03:36 AM, Vutla, Lokesh wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> Use the corresponding compatibles to identify the devices.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/mach-omap2/soc.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index 01ca808..5e1be94 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -245,6 +245,8 @@ IS_AM_SUBCLASS(437x, 0x437)
> #define soc_is_omap54xx() 0
> #define soc_is_omap543x() 0
> #define soc_is_dra7xx() 0
> +#define soc_is_dra74x() 0
> +#define soc_is_dra72x() 0
>
> #if defined(MULTI_OMAP2)
> # if defined(CONFIG_ARCH_OMAP2)
> @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>
> #if defined(CONFIG_SOC_DRA7XX)
> #undef soc_is_dra7xx
> +#undef soc_is_dra74x
> +#undef soc_is_dra72x
> #define soc_is_dra7xx() (of_machine_is_compatible("ti,dra7"))
> +#define soc_is_dra74x() (of_machine_is_compatible("ti,dra74"))
> +#define soc_is_dra72x() (of_machine_is_compatible("ti,dra72"))
> +
nit, can you remove this extra blank line when you repost.
regards
Suman
> #endif
>
> /* Various silicon revisions for omap2 */
>
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Benoit Masson @ 2014-07-23 22:52 UTC (permalink / raw)
To: linux-arm-kernel
The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
http://shop.lenovo.com/fr/fr/servers/network-storage/lenovoemc/ix4-300d/
Signed-off-by: Benoit Masson <yahoo@perenite.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 284 ++++++++++++++++++++++++
2 files changed, 286 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index adb5ed9..4429495 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -437,8 +437,9 @@ dtb-$(CONFIG_MACH_ARMADA_XP) += \
armada-xp-axpwifiap.dtb \
armada-xp-db.dtb \
armada-xp-gp.dtb \
- armada-xp-netgear-rn2120.dtb \
+ armada-xp-lenovo-ix4-300d.dtb \
armada-xp-matrix.dtb \
+ armada-xp-netgear-rn2120.dtb \
armada-xp-openblocks-ax3-4.dtb
dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
dove-cubox.dtb \
diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
new file mode 100644
index 0000000..1f33cbc
--- /dev/null
+++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
@@ -0,0 +1,284 @@
+/*
+ * Device Tree file for Lenovo Iomega ix4-300d
+ *
+ * Copyright (C) 2014, Benoit Masson <yahoo@perenite.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "armada-xp-mv78230.dtsi"
+
+/ {
+ model = "Lenovo Iomega ix4-300d";
+ compatible = "lenovo,ix4-300d", "marvell,armadaxp-mv78230",
+ "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ stdout-path = "/soc/internal-regs/serial at 12000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x00000000 0 0x20000000>; /* 512MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000>;
+
+ pcie-controller {
+ status = "okay";
+
+ /* Quad port sata: Marvell 88SX7042 */
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ /* USB 3.0 xHCI controller: NEC D720200F1 */
+ pcie at 5,0 {
+ /* Port 1, Lane 0 */
+ status = "okay";
+ };
+ };
+
+ internal-regs {
+ pinctrl {
+ poweroff_pin: poweroff-pin {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+
+ power_button_pin: power-button-pin {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+
+ reset_button_pin: reset-button-pin {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+ select_button_pin: select-button-pin {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+
+ scroll_button_pin: scroll-button-pin {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+
+ hdd_led_pin: hdd-led-pin {
+ marvell,pins = "mpp26";
+ marvell,function = "gpio";
+ };
+ };
+
+ serial at 12000 {
+ status = "okay";
+ };
+
+ mdio {
+ phy0: ethernet-phy at 0 { /* Marvell 88E1318 */
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy at 1 { /* Marvell 88E1318 */
+ reg = <1>;
+ };
+ };
+
+ ethernet at 70000 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "rgmii-id";
+ };
+
+ ethernet at 74000 {
+ status = "okay";
+ phy = <&phy1>;
+ phy-mode = "rgmii-id";
+ };
+
+ usb at 50000 {
+ status = "okay";
+ };
+
+ usb at 51000 {
+ status = "okay";
+ };
+
+ i2c at 11000 {
+ compatible = "marvell,mv78230-a0-i2c",
+ "marvell,mv64xxx-i2c";
+ clock-frequency = <400000>;
+ status = "okay";
+
+ adt7473 at 2e {
+ compatible = "adi,adt7473";
+ reg = <0x2e>;
+ };
+
+ pcf8563 at 51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ };
+
+ nand at d0000 {
+ status = "okay";
+ num-cs = <1>;
+ marvell,nand-keep-config;
+ marvell,nand-enable-arbiter;
+ nand-on-flash-bbt;
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0x0000000 0xe0000>;
+ read-only;
+ };
+
+ partition at e0000 {
+ label = "u-boot-env";
+ reg = <0xe0000 0x20000>;
+ read-only;
+ };
+
+ partition at 100000 {
+ label = "u-boot-env2";
+ reg = <0x100000 0x20000>;
+ read-only;
+ };
+
+ partition at 120000 {
+ label = "zImage";
+ reg = <0x120000 0x400000>;
+ };
+
+ partition at 520000 {
+ label = "initrd";
+ reg = <0x520000 0x400000>;
+ };
+
+ partition at xE00000 {
+ label = "boot";
+ reg = <0xE00000 0x3F200000>;
+ };
+
+ partition at flash {
+ label = "flash";
+ reg = <0x0 0x40000000>;
+ };
+ };
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&power_button_pin &reset_button_pin
+ &select_button_pin &scroll_button_pin>;
+ pinctrl-names = "default";
+
+ power-button {
+ label = "Power Button";
+ linux,code = <KEY_POWER>;
+ gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ reset-button {
+ label = "Reset Button";
+ linux,code = <KEY_RESTART>;
+ gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
+ };
+
+ select-button {
+ label = "Select Button";
+ linux,code = <BTN_SELECT>;
+ gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ };
+
+ scroll-button {
+ label = "Scroll Button";
+ linux,code = <KEY_SCROLLDOWN>;
+ gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ spi3 {
+ compatible = "spi-gpio";
+ status = "okay";
+ gpio-sck = <&gpio0 25 0>;
+ gpio-mosi = <&gpio1 15 0>; /*gpio 47*/
+ cs-gpios = <&gpio0 27 0 >;
+ num-chipselects = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio2: gpio2 at 0 {
+ compatible = "fairchild,74hc595";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ registers-number = <2>;
+ spi-max-frequency = <100000>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&hdd_led_pin>;
+ pinctrl-names = "default";
+
+ hdd-led {
+ label = "ix4-300d:hdd:blue";
+ gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ power-led {
+ label = "ix4-300d:power:white";
+ gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+ /* init blinking while booting */
+ linux,default-trigger = "timer";
+ default-state = "on";
+ };
+
+ sysfail-led {
+ label = "ix4-300d:sysfail:red";
+ gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ sys-led {
+ label = "ix4-300d:sys:blue";
+ gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ hddfail-led {
+ label = "ix4-300d:hddfail:red";
+ gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ };
+
+ /* Warning: you need both eth1 & 0 PHY initialized
+ (i.e having them up does the tweak)
+ for poweroff to shutdown otherwise it reboots */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ pinctrl-0 = <&poweroff_pin>;
+ pinctrl-names = "default";
+ gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Benoit Masson @ 2014-07-23 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723224236.GC28485@lunn.ch>
No worries, sorry it makes more email for you guys, I've added the colors for power and revert order hdd:blue instead of blue:hdd for the hdd led.
For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours trying to understand this but it only works with this on the ix4-300d :(. There was multiple patch around this and maybe one broke the auto-detect part of this, I've tried compiling with some 3.10 or lower kernel but no luck here I still have to put this a0 option.
Benoit
Le 24 juil. 2014 ? 00:42, Andrew Lunn <andrew@lunn.ch> a ?crit :
>> + i2c at 11000 {
>> + compatible = "marvell,mv78230-a0-i2c",
>> + "marvell,mv64xxx-i2c";
>
> Ah sorry, i missed this first time. Do you really need
> "marvell,mv78230-a0-i2c"?
>
> Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt says:
>
> - "marvell,mv78230-a0-i2c"
> * Note: Only use "marvell,mv78230-a0-i2c" for a
> very rare, initial version of the SoC which
> had broken offload support. Linux
> auto-detects this and sets it appropriately.
>
> So i don't think you should have this hear.
>
> Gregory, please could you comment.
>
>> + power-led {
>> + label = "ix4-300d:power";
>
> It is normal to include the colour, and you did for all the other
> LEDs.
>
> Andrew
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Andrew Lunn @ 2014-07-23 22:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <94F87063-D717-435B-B7C5-EDAC9B26742C@perenite.com>
> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours
> trying to understand this but it only works with this on the
> ix4-300d :(. There was multiple patch around this and maybe one
> broke the auto-detect part of this, I've tried compiling with some
> 3.10 or lower kernel but no luck here I still have to put this a0
> option.
Lets first confirm you have an a0 SoC.
At boot time, it should print:
pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev);
What revision do you have?
If the auto detect code really is broken, Gregory will likely take a
look.
Andrew
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Jason Cooper @ 2014-07-23 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10A7C530-7CD2-4ED0-889A-7FAC1922320F@perenite.com>
On Thu, Jul 24, 2014 at 01:11:12AM +0200, Benoit Masson wrote:
> Le 24 juil. 2014 ? 00:58, Andrew Lunn <andrew@lunn.ch> a ?crit :
>
> >> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours
> >> trying to understand this but it only works with this on the
> >> ix4-300d :(. There was multiple patch around this and maybe one
> >> broke the auto-detect part of this, I've tried compiling with some
> >> 3.10 or lower kernel but no luck here I still have to put this a0
> >> option.
> >
> > Lets first confirm you have an a0 SoC.
> >
> > At boot time, it should print:
> >
> > pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev);
> >
> > What revision do you have?
> >
> > If the auto detect code really is broken, Gregory will likely take a
> > look.
>
> I sure do,
>
> confirmed by u-boot output below:
>
> U-Boot 2009.08 (Mar 04 2013 - 11:13:04) Marvell version: 2.3.2 PQ
> U-Boot Addressing:
> Code:..00600000:006BFFF0
> BSS:..00708EC0
> Stack:..0x5fff70
> PageTable:.0x8e0000
> Heap address:.0x900000:0xe00000
> Board: DB-78230-BP rev 2.0 Wistron
> SoC: MV78230 A0
>
> From kernel I get:
>
> mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1
Well, isn't that a peach? :) Gregory?
thx,
Jason.
^ permalink raw reply
* [PATCH 1/2] Added dts defintion for Lenovo ix4-300d nas
From: Benoit Masson @ 2014-07-23 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723222640.GA28485@lunn.ch>
Well I'm glad you spend time on this. So I'll explain more in detail where I am on this one.
I have the vendor 3.0.29 kernel patched with LSP drivers from Marvell (which includes the PHY & Net drivers).
With this version (called LSPkernel now on) pulling MPP24 GPIO output up shutdown the power of the device.
At first I though it could be watchdog or wol related so I deep dive into both drivers and start uncommenting register write by register write, in the end the LSPKernel start rebooting instead of poweroff when no phy register were written at all... which is when I start thinking about that its was maybe not really which reg were written but that both phy were to be writtent to at least on reg for the MPP24 to poweroff the device and that worked out.
So as soon as both phy get "m88e1318_config_aneg" fucntion called from "drivers/net/phy/marvell.c" it works fine.
Also maybe you can help me there although the marvell.c has m88e1318_get_wol & m88e1318_set_wol setup as part of the MARVELL_PHY_ID_88E1318S calling "ethtool -s eth0 wol g" from debian return a non-supported error .. any though ?
Benoit
Le 24 juil. 2014 ? 00:26, Andrew Lunn <andrew@lunn.ch> a ?crit :
>> Both phy are :
>> marvell,88e1318
>
> I don't have the datasheet for this specific phy model, but i do have
> the datasheet for another similar phy.
>
>> example of a minimal reg write that lead MPP24 to shutdown instead
>> of rebooting on original BSP driver
>
>> XXXXX BasicInit
>
> I'm assuming regOffs is decimal, and data is hex?
>
>> phyAdr 0: regOffs: 16 data: 3
>
> Copper Specific control register. 3 means Polarity Reversal Disable &
> Jabber function disable.
>
>> phyAdr 0: regOffs: 10 data: 830
>
> Reg 10 is the 1000BASE-T Status register, which is read only!
>
> So this is not making much sense. Are we missing some changes to the
> page register? Register 16 of page 3 is the LED control register.
>
> Andrew
>
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Jason Cooper @ 2014-07-23 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406155973-13657-1-git-send-email-yahoo@perenite.com>
Benoit,
This looks a lot better, thanks for turning it around so quickly!
My only general comment is just for the future. When submitting new
versions of patches, please add a 'V2' inside the brackets on the
Subject line. Or v3, or v4, or v14 in rare cases ;-)
It really helps us patch wranglers keep track of which version to apply.
One small comment below.
On Wed, Jul 23, 2014 at 03:52:53PM -0700, Benoit Masson wrote:
> The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
> USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
>
> http://shop.lenovo.com/fr/fr/servers/network-storage/lenovoemc/ix4-300d/
> Signed-off-by: Benoit Masson <yahoo@perenite.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 284 ++++++++++++++++++++++++
> 2 files changed, 286 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
...
> diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> new file mode 100644
> index 0000000..1f33cbc
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
...
> + /* Warning: you need both eth1 & 0 PHY initialized
> + (i.e having them up does the tweak)
> + for poweroff to shutdown otherwise it reboots */
nit: multi-line comments are like this:
/*
* Warning: you need both eth1 & 0 PHY initialized (i.e having
* them up does the tweak) for poweroff to shutdown otherwise it
* reboots
*/
If that's the only thing left, I'll fix it up when I pull it in. No
need to respin just for this.
thx,
Jason.
^ permalink raw reply
* next build: 629 warnings 1 failures (next/next-20140723)
From: Olof Johansson @ 2014-07-23 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53cf8323.e4b6440a.7d37.4f75@mx.google.com>
Catalin, Will,
On Wed, Jul 23, 2014 at 2:40 AM, Olof's autobuilder <build@lixom.net> wrote:
> arm64.defconfig:
> arch/arm64/kernel/head.S:298: Error: unknown or missing system register name at operand 2 -- `mrs x0,S3_4_C12_C9_5'
> arch/arm64/kernel/head.S:301: Error: unknown or missing system register name at operand 1 -- `msr S3_4_C12_C9_5,x0'
> arch/arm64/kernel/head.S:303: Error: unknown or missing system register name at operand 1 -- `msr S3_4_C12_C11_0,xzr'
> arch/arm64/kernel/ptrace.c:1119:3: error: too many arguments to function 'audit_syscall_entry'
> /tmp/ccq7ZztI.s:21: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C12_C12_1,x0'
> /tmp/ccq7ZztI.s:162: Error: unknown or missing system register name at operand 2 -- `mrs x19,S3_0_C12_C12_0'
> /tmp/ccq7ZztI.s:186: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C12_C12_1,x19'
> /tmp/ccq7ZztI.s:220: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C12_C12_1,x19'
> /tmp/ccq7ZztI.s:1110: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C12_C11_5,x27'
> /tmp/ccq7ZztI.s:1530: Error: unknown or missing system register name at operand 2 -- `mrs x0,S3_0_C12_C12_5'
> /tmp/ccq7ZztI.s:1540: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C12_C12_5,x0'
> /tmp/ccq7ZztI.s:1548: Error: unknown or missing system register name at operand 2 -- `mrs x0,S3_0_C12_C12_5'
> /tmp/ccq7ZztI.s:1564: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C4_C6_0,x0'
> /tmp/ccq7ZztI.s:1576: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C12_C12_4,x0'
> /tmp/ccq7ZztI.s:1592: Error: unknown or missing system register name at operand 1 -- `msr S3_0_C12_C12_7,x0'
I'm building with a vanilla gcc 4.8.2 / binutils 2.23.2. That
shouldn't be broken like this, so those changes should be fixed (or
minimal toolchain expecations need to be documented -- but there
really is no good reason to require 4.9.0/2.24).
-Olof
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Andrew Lunn @ 2014-07-23 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723232715.GL23220@titan.lakedaemon.net>
> On Wed, Jul 23, 2014 at 03:52:53PM -0700, Benoit Masson wrote:
> > The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
> > USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
> >
> > http://shop.lenovo.com/fr/fr/servers/network-storage/lenovoemc/ix4-300d/
> > Signed-off-by: Benoit Masson <yahoo@perenite.com>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +-
> > arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 284 ++++++++++++++++++++++++
> > 2 files changed, 286 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> ...
> > diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> > new file mode 100644
> > index 0000000..1f33cbc
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> ...
> > + /* Warning: you need both eth1 & 0 PHY initialized
> > + (i.e having them up does the tweak)
> > + for poweroff to shutdown otherwise it reboots */
>
> nit: multi-line comments are like this:
>
> /*
> * Warning: you need both eth1 & 0 PHY initialized (i.e having
> * them up does the tweak) for poweroff to shutdown otherwise it
> * reboots
> */
>
> If that's the only thing left, I'll fix it up when I pull it in. No
> need to respin just for this.
Hi Jason
We should not really leave the i2c compatibility string as it is.
Hopefully the OEM moved onto B1 stepping at some point. Although B1
devices will work with the workaround, you get better performance
without it.
We should wait for Gregory to look at the quirk and soc-id code.
Andrew
^ permalink raw reply
* [GIT PULL] ARM: mvebu: SoC changes for v3.17 (round 3)
From: Jason Cooper @ 2014-07-23 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201407232231.41787.arnd@arndb.de>
On Wed, Jul 23, 2014 at 10:31:41PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014, Jason Cooper wrote:
> > All,
> >
> > Here's the cpufreq changes I mentioned over the weekend. It's been in
> > -next for a while. Once I get the new version of cpuidle from ThomasP,
> > I'll push that as quickly as possible.
>
> Just for my information, is this coordinated with the cpufreq maintainers?
> I remember being asked to ensure all cpufreq/cpuidle stuff has an Ack
> from them, even stuff that doesn't touch drivers/cpufreq at all.
Good to know.
> The contents look good to me. I can merge them if there are no objections
> from Viresh, feel free to send the next batch already without waiting
> for me to pull.
We've been coordinating with Viresh. He has an unsettled issue on his
side he hopes to have resolved soon. Worst case scenario, he doesn't
get the change in for v3.17, we'll have to do a minor DT fix on top of
-rc1.
> > As usual (do I need to type this each time any more? :) ), this is an
> > incremental pull request from tags/mvebu-soc-3.17-2 up to
> > tags/mvebu-soc-3.17-3 on the mvebu/soc branch.
>
> It certainly helps me to have this information, but you can write it
> more briefly, e.g. "based on tags/mvebu-soc-3.17-2".
Ahhhh.... Much more succinct. Thank you. On a side note, I wonder
what it would take to get 'git request-pull' smart enough to add that
information when handed a tag?
> > The following changes since commit ba364fc752daeded072a5ef31e43b84cb1f9e5fd:
> >
> > ARM: Kirkwood: Remove mach-kirkwood (2014-07-13 22:13:39 +0000)
eg:
ARM: Kirkwood: Remove mach-kirkwood (tags/mvebu-soc-3.17-2)
> >
> > are available in the git repository at:
> >
> > git://git.infradead.org/linux-mvebu.git tags/mvebu-soc-3.17-3
> >
> > for you to fetch changes up to ba3ec5780bba27819bbc4f669e6c77418a00f14b:
> >
> > Merge branch 'mvebu/soc-cpufreq' into mvebu/soc (2014-07-22 20:46:48 +0000)
> >
> > ----------------------------------------------------------------
Is the date of the base commit useful in any way in the pull request?
thx,
Jason.
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Jason Cooper @ 2014-07-23 23:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723232909.GE28485@lunn.ch>
On Thu, Jul 24, 2014 at 01:29:09AM +0200, Andrew Lunn wrote:
> > On Wed, Jul 23, 2014 at 03:52:53PM -0700, Benoit Masson wrote:
> > > The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb,
> > > USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU.
> > >
> > > http://shop.lenovo.com/fr/fr/servers/network-storage/lenovoemc/ix4-300d/
> > > Signed-off-by: Benoit Masson <yahoo@perenite.com>
> > > ---
> > > arch/arm/boot/dts/Makefile | 3 +-
> > > arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts | 284 ++++++++++++++++++++++++
> > > 2 files changed, 286 insertions(+), 1 deletion(-)
> > > create mode 100644 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> > ...
> > > diff --git a/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> > > new file mode 100644
> > > index 0000000..1f33cbc
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
> > ...
> > > + /* Warning: you need both eth1 & 0 PHY initialized
> > > + (i.e having them up does the tweak)
> > > + for poweroff to shutdown otherwise it reboots */
> >
> > nit: multi-line comments are like this:
> >
> > /*
> > * Warning: you need both eth1 & 0 PHY initialized (i.e having
> > * them up does the tweak) for poweroff to shutdown otherwise it
> > * reboots
> > */
> >
> > If that's the only thing left, I'll fix it up when I pull it in. No
> > need to respin just for this.
>
> Hi Jason
>
> We should not really leave the i2c compatibility string as it is.
Agreed.
> Hopefully the OEM moved onto B1 stepping at some point. Although B1
> devices will work with the workaround, you get better performance
> without it.
>
> We should wait for Gregory to look at the quirk and soc-id code.
Yep.
thx,
Jason.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox