* [PATCH 2/8] ARM: at91: at91sam9g10: fix SOC type detection
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
From: Ivan Shugov <ivan.shugov@gmail.com>
Newer at91sam9g10 SoC revision can't be detected, so the kernel can't boot with
this kind of kernel panic:
"AT91: Impossible to detect the SOC type"
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G10-EK
Ignoring tag cmdline (using the default kernel command line)
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
Kernel panic - not syncing: AT91: Impossible to detect the SOC type
[<c00133d4>] (unwind_backtrace+0x0/0xe0) from [<c02366dc>] (panic+0x78/0x1cc)
[<c02366dc>] (panic+0x78/0x1cc) from [<c02fa35c>] (at91_map_io+0x90/0xc8)
[<c02fa35c>] (at91_map_io+0x90/0xc8) from [<c02f9860>] (paging_init+0x564/0x6d0)
[<c02f9860>] (paging_init+0x564/0x6d0) from [<c02f7914>] (setup_arch+0x464/0x704)
[<c02f7914>] (setup_arch+0x464/0x704) from [<c02f44f8>] (start_kernel+0x6c/0x2d4)
[<c02f44f8>] (start_kernel+0x6c/0x2d4) from [<20008040>] (0x20008040)
The reason for this is that the Debug Unit Chip ID Register has changed between
Engineering Sample and definitive revision of the SoC. Changing the check of
cidr to socid will address the problem. We do not integrate this check to the
list just above because we also have to make sure that the extended id is
disregarded.
Signed-off-by: Ivan Shugov <ivan.shugov@gmail.com>
[nicolas.ferre at atmel.com: change commit message]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [v3.1] # since commit 8c3583b6
---
arch/arm/mach-at91/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index da9881b..6a3d4bb 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -151,7 +151,7 @@ static void __init soc_detect(u32 dbgu_base)
}
/* at91sam9g10 */
- if ((cidr & ~AT91_CIDR_EXT) == ARCH_ID_AT91SAM9G10) {
+ if ((socid & ~AT91_CIDR_EXT) == ARCH_ID_AT91SAM9G10) {
at91_soc_initdata.type = AT91_SOC_SAM9G10;
at91_boot_soc = at91sam9261_soc;
}
--
1.7.11.3
^ permalink raw reply related
* [PATCH 1/8] ARM: at91/tc: fix typo in the DT document
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351092432.git.nicolas.ferre@atmel.com>
From: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> [v3.4]
---
Documentation/devicetree/bindings/arm/atmel-at91.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index ecc81e3..d187e9f 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -8,7 +8,7 @@ PIT Timer required properties:
shared across all System Controller members.
TC/TCLIB Timer required properties:
-- compatible: Should be "atmel,<chip>-pit".
+- compatible: Should be "atmel,<chip>-tcb".
<chip> can be "at91rm9200" or "at91sam9x5"
- reg: Should contain registers location and length
- interrupts: Should contain all interrupts for the TC block
--
1.7.11.3
^ permalink raw reply related
* [PATCH 0/8] at91: 3.7 fixes patch series
From: Nicolas Ferre @ 2012-10-24 15:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I am posting this patch series just before sending a pull-request to Arnd and
Olof.
There are 2 new patches that I have just cooked today about external IRQ
handling: please review.
I would like you to double check that I have not made any mistake while
collecting the other patches...
Thanks, best regards,
Bo Shen (2):
ARM: at91/i2c: change id to let i2c-gpio work
ARM: at91/i2c: change id to let i2c-at91 work
Ivan Shugov (1):
ARM: at91: at91sam9g10: fix SOC type detection
Jean-Christophe PLAGNIOL-VILLARD (1):
ARM: at91: drop duplicated config SOC_AT91SAM9 entry
Josh Wu (1):
ARM: at91/tc: fix typo in the DT document
Marek Belisko (1):
ARM: at91/dts: at91sam9g20ek_common: Fix typos in buttons labels.
Nicolas Ferre (2):
ARM: at91: fix external interrupts in non-DT case
ARM: at91: fix external interrupt specification in board code
Documentation/devicetree/bindings/arm/atmel-at91.txt | 2 +-
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 4 ++--
arch/arm/mach-at91/Kconfig | 10 ++--------
arch/arm/mach-at91/at91rm9200.c | 2 +-
arch/arm/mach-at91/at91rm9200_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9260.c | 4 ++--
arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9261.c | 4 ++--
arch/arm/mach-at91/at91sam9261_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9263.c | 2 +-
arch/arm/mach-at91/at91sam9263_devices.c | 4 ++--
arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++--
arch/arm/mach-at91/board-neocore926.c | 2 +-
arch/arm/mach-at91/board-sam9261ek.c | 2 +-
arch/arm/mach-at91/board-sam9263ek.c | 2 +-
arch/arm/mach-at91/generic.h | 3 ++-
arch/arm/mach-at91/irq.c | 9 +++++++--
arch/arm/mach-at91/setup.c | 4 ++--
18 files changed, 35 insertions(+), 35 deletions(-)
--
1.7.11.3
^ permalink raw reply
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Andrew Lunn @ 2012-10-24 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024172050.412ff1bf@skate>
On Wed, Oct 24, 2012 at 05:20:50PM +0200, Thomas Petazzoni wrote:
> Andrew,
>
> On Wed, 24 Oct 2012 17:06:14 +0200, Andrew Lunn wrote:
>
> > There are two variants of this box, ax3/2 and ax3/4. The ax3/4 can
> > have more RAM and has a mini pci express slot. Do you expect both
> > boards to be supported with one dts file?
>
> I have the ax3/4 version apparently.
>
> So, we can have the following possible schemes:
>
> + openblocks-ax3.dtsi
> + openblocks-ax3-2.dts
> + openblocks-ax3-4.dts
>
> But I am not sure if using a .dtsi to factorize things common between
> multiple boards is OK. Or we can do:
>
> + openblocks-ax3-2.dts
> + openblocks-ax3-4.dts
>
> With openblocks-ax3-4.dts being the simple addition of PCIe slot + more
> RAM. That said, I don't have the ax3/2 board anyway, so should we plan
> for something that nobody can test at the moment, or wait for someone
> to get a ax3/2 board, and therefore be able to do the testing? I think
> I prefer to submit dts files that are know to work and have been tested
> on hardware that we have.
Hi Thomas
I agree with the last point. So maybe have a openblocks-ax3-4.dts and
set the compatibility string to plathome,openblocks-ax3-4.
When somebody gets a ax3/2, they can refactor the common DT into a
dtsi file without causing any compatibility issues.
Andrew
^ permalink raw reply
* [PATCH] ARM: dts: OMAP: Rename pandaES and var_som for consistency
From: Benoit Cousson @ 2012-10-24 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Rename the files to have consistent names across OMAP boards.
Update the Makefile to use the new names.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Uri Yosef <uri.y@variscite.com>
---
arch/arm/boot/dts/Makefile | 4 ++--
.../dts/{omap4-pandaES.dts => omap4-panda-es.dts} | 0
.../dts/{omap4-var_som.dts => omap4-var-som.dts} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{omap4-pandaES.dts => omap4-panda-es.dts} (100%)
rename arch/arm/boot/dts/{omap4-var_som.dts => omap4-var-som.dts} (100%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e69c921..634bd42 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -68,8 +68,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap4-panda.dtb \
- omap4-pandaES.dtb \
- omap4-var_som.dtb \
+ omap4-panda-es.dtb \
+ omap4-var-som.dtb \
omap4-sdp.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts b/arch/arm/boot/dts/omap4-panda-es.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-pandaES.dts
rename to arch/arm/boot/dts/omap4-panda-es.dts
diff --git a/arch/arm/boot/dts/omap4-var_som.dts b/arch/arm/boot/dts/omap4-var-som.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-var_som.dts
rename to arch/arm/boot/dts/omap4-var-som.dts
--
1.7.0.4
^ permalink raw reply related
* [PATCH 10/10] ARM: imx6q: implement WAIT mode with coupled cpuidle
From: Lorenzo Pieralisi @ 2012-10-24 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024135725.GA2464@S2101-09.ap.freescale.net>
On Wed, Oct 24, 2012 at 02:57:31PM +0100, Shawn Guo wrote:
> On Tue, Oct 23, 2012 at 06:35:43PM +0100, Lorenzo Pieralisi wrote:
> > On Tue, Oct 23, 2012 at 04:22:59PM +0100, Shawn Guo wrote:
> >
> > [...]
> >
> > > +/*
> > > + * For each cpu, setup the broadcast timer because local timer
> > > + * stops for the states other than WFI.
> > > + */
> > > +static void imx6q_setup_broadcast_timer(void *arg)
> > > +{
> > > + int cpu = smp_processor_id();
> > > +
> > > + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
> > > +}
> >
> > Can anyone explain to me please why this is needed ?
> >
> It basically does nothing if either NO_HZ or HIGH_RES_TIMERS is
> enabled, in which case tick_broadcast_setup_oneshot is already called
> on init_timers path to set up bc->event_handler. This is the general
> case since nowadays we have both options enabled by default for most
> systems.
>
> However if neither option is enabled, CLOCK_EVT_NOTIFY_BROADCAST_ON
> notifying will help route to call tick_broadcast_setup_oneshot to have
> bc->event_handler set up.
>
> So in short, it's needed to have broadcast timer work as expected when
> neither NO_HZ or HIGH_RES_TIMERS is enabled.
Ok, point taken, it was just to check I was not missing anything on the
expected usage on systems where those options are enabled.
Thanks a lot,
Lorenzo
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Josh Coombs @ 2012-10-24 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351090434-30499-1-git-send-email-andrew@lunn.ch>
Andrew, are there any required kernel config changes to go along with
this? I didn't see any updates to the default configs in the patches
so I want to make sure I'm testing with the right options enabled.
Josh C
On Wed, Oct 24, 2012 at 10:53 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> This patchset converts all DT kirkwood boards to using pinctrl.
>
> This patchset depends on an earlier patchset to allow the mvebu
> pinctrl driver and gpio driver to be built for kirkwood.
>
> Only the TS219 conversion has been tested on hardware. The remaining
> are compile tested. Before merging upstream, it would be good if the
> others could be tested on hardware.
>
> This series along with the dependents can be found in:
>
> git://github.com/lunn/linux.git v3.7-rc2-pinctrl
>
> Andrew Lunn (9):
> ARM: Kirkwood: Convert TS219 to pinctrl.
> ARM: Kirkwood: Convert iConnect to pinctrl.
> ARM: Kirkwood: Convert dnskw to pinctrl
> ARM: Kirkwood: Convert dockstar to pinctrl.
> ARM: Kirkwood: Convert dreamplug to pinctrl.
> ARM: Kirkwood: Convert GoFlex Net to pinctrl.
> ARM: Kirkwood: Convert ib62x0 to pinctrl.
> ARM: Kirkwood: Convert lsxl boards to pinctrl.
> ARM: Kirkwood: Convert IX2-200 to pinctrl.
>
> arch/arm/boot/dts/kirkwood-dnskw.dtsi | 136 +++++++++++++++++++++++++
> arch/arm/boot/dts/kirkwood-dockstar.dts | 21 ++++
> arch/arm/boot/dts/kirkwood-dreamplug.dts | 26 +++++
> arch/arm/boot/dts/kirkwood-goflexnet.dts | 57 +++++++++++
> arch/arm/boot/dts/kirkwood-ib62x0.dts | 41 ++++++++
> arch/arm/boot/dts/kirkwood-iconnect.dts | 52 ++++++++++
> arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 90 ++++++++++++++++
> arch/arm/boot/dts/kirkwood-lsxl.dtsi | 67 ++++++++++++
> arch/arm/boot/dts/kirkwood-ts219-6281.dts | 56 ++++++++++
> arch/arm/boot/dts/kirkwood-ts219-6282.dts | 56 ++++++++++
> arch/arm/mach-kirkwood/board-dnskw.c | 37 -------
> arch/arm/mach-kirkwood/board-dockstar.c | 10 --
> arch/arm/mach-kirkwood/board-dreamplug.c | 14 ---
> arch/arm/mach-kirkwood/board-goflexnet.c | 18 ----
> arch/arm/mach-kirkwood/board-ib62x0.c | 21 ----
> arch/arm/mach-kirkwood/board-iconnect.c | 17 ----
> arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 24 -----
> arch/arm/mach-kirkwood/board-lsxl.c | 19 ----
> arch/arm/mach-kirkwood/board-ts219.c | 25 -----
> 19 files changed, 602 insertions(+), 185 deletions(-)
>
> --
> 1.7.10.4
>
^ permalink raw reply
* Possible regression in arm/io.h
From: Will Deacon @ 2012-10-24 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABYn4sxnwzj8KFfELzCLzQMcAjiqS3_Vr2kStkm-na8G1noPHA@mail.gmail.com>
On Wed, Oct 24, 2012 at 04:04:46PM +0100, Bastian Hecht wrote:
> >> > Ok, I'll have a look at the impact of moving exclusively to "Q" when I get a
> >> > chance. Which toolchain are you using?
> >>
> >> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> >> For a more verbose info take a look at the bug report link.
> >
> > Ok, thanks. One other thing you could try while I try to find a copy of that
> > toolchain is changing the "+" modifier to an "=", like I proposed in this
> > version of the patch:
>
> So if alter it to fit to your patch scheme the result is:
Sorry, the change wasn't as trivial as I thought -- you have to reorder the
constraints because an output becomes an input for the load accessors. I
tried it myself and it doesn't fix the issue (I can reproduce it now).
Will
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Sebastian Andrzej Siewior @ 2012-10-24 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210241013310.1481-100000@iolanthe.rowland.org>
On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
> Under the circumstances, do we really need a new binding document for
> the ehci-platform driver? We should be able to use the existing
> usb-ehci binding, perhaps with some new properties added:
>
> has-synopsys-hc-bug
> no-io-watchdog
> has-tt
On the PCI side we have VID, PID which is used for quirks. Sometimes we have a
revision ID which can be used to figure out if "this quirk" is still required.
The PCI driver probes by class so the ehci driver does not have a large table
of VID/PID for each controller out there. And the USB controller in two
different Intel boards has a different PID so a quirk, if required, could be
applied only to the specific mainboard.
Based on this we need atleast two compatible entries one "HW-Specific"
followed by a generic one (similar to PCI class).
Doing it the PCI way we would have to have table and figure out which
HW-specific compatible entry sets the TT flag and which one does the
no-io-watchdog. Having has-tt in compatible isn't right.
I'm all with Alan here, to make a shortcut and allow Linux specific properties
which describe a specific quirk in less code lines. Other OS can just ignore
those and build their table based on the compatible entry if they want to.
So usb-ehci should be fine. It is a generic USB-EHCI controller after all.
Quirks or no quirks, the register layout is the same, the functionality is the
same. If you can't map memory >4GiB then you need a quirk for this but you may
discover it way too late.
If your platform driver requires extra code for the PHY then it is still an
EHCI controller. The PHY wasn't setup by the bootloader / bios so Linux has to
deal with it.
> We probably can omit has-synopsys-hc-bug, as that is specific to one
> type of MIPS ATH79 controller. The driver can check for it explicitly,
> if necessary.
>
> In fact, it's not clear that these new properties need to be added now.
> They can be added over time as needed, as existing drivers are
> converted over to DT. Or is it preferable to document these things
> now, preemptively as it were?
I would add it only if required / has users.
> Alan Stern
Sebastian
^ permalink raw reply
* [PATCH RESEND] xen/arm: use the __HVC macro
From: Stefano Stabellini @ 2012-10-24 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
Use the new __HVC macro in hypercall.S.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
arch/arm/xen/hypercall.S | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 074f5ed..71f7239 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -48,20 +48,16 @@
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/opcodes-virt.h>
#include <xen/interface/xen.h>
-/* HVC 0xEA1 */
-#ifdef CONFIG_THUMB2_KERNEL
-#define xen_hvc .word 0xf7e08ea1
-#else
-#define xen_hvc .word 0xe140ea71
-#endif
+#define XEN_IMM 0xEA1
#define HYPERCALL_SIMPLE(hypercall) \
ENTRY(HYPERVISOR_##hypercall) \
mov r12, #__HYPERVISOR_##hypercall; \
- xen_hvc; \
+ __HVC(XEN_IMM); \
mov pc, lr; \
ENDPROC(HYPERVISOR_##hypercall)
@@ -76,7 +72,7 @@ ENTRY(HYPERVISOR_##hypercall) \
stmdb sp!, {r4} \
ldr r4, [sp, #4] \
mov r12, #__HYPERVISOR_##hypercall; \
- xen_hvc \
+ __HVC(XEN_IMM); \
ldm sp!, {r4} \
mov pc, lr \
ENDPROC(HYPERVISOR_##hypercall)
@@ -100,7 +96,7 @@ ENTRY(privcmd_call)
mov r2, r3
ldr r3, [sp, #8]
ldr r4, [sp, #4]
- xen_hvc
+ __HVC(XEN_IMM)
ldm sp!, {r4}
mov pc, lr
ENDPROC(privcmd_call);
--
1.7.2.5
^ permalink raw reply related
* [RFC 6/6] ARM: sched: clear SD_SHARE_POWERLINE
From: Santosh Shilimkar @ 2012-10-24 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349595838-31274-7-git-send-email-vincent.guittot@linaro.org>
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
> The ARM platforms take advantage of packing small tasks on few cores.
> This is true even when the cores of a cluster can't be powergated
> independently.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> arch/arm/kernel/topology.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index 26c12c6..00511d0 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -226,6 +226,11 @@ static inline void update_cpu_power(unsigned int cpuid, unsigned int mpidr) {}
> */
> struct cputopo_arm cpu_topology[NR_CPUS];
>
> +int arch_sd_share_power_line(void)
> +{
> + return 0*SD_SHARE_POWERLINE;
> +}
Making this selection of policy based on sched domain will better. Just
gives the flexibility to choose a separate scheme for big and little
systems which will be very convenient.
Regards
Santosh
^ permalink raw reply
* [RFC 5/6] sched: pack the idle load balance
From: Santosh Shilimkar @ 2012-10-24 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349595838-31274-6-git-send-email-vincent.guittot@linaro.org>
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
> Look for an idle CPU close the pack buddy CPU whenever possible.
s/close/close to
> The goal is to prevent the wake up of a CPU which doesn't share the power
> line of the pack CPU
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/fair.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 6df53b5..f76acdc 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5158,7 +5158,25 @@ static struct {
>
> static inline int find_new_ilb(int call_cpu)
> {
> + struct sched_domain *sd;
> int ilb = cpumask_first(nohz.idle_cpus_mask);
> + int buddy = per_cpu(sd_pack_buddy, call_cpu);
> +
> + /*
> + * If we have a pack buddy CPU, we try to run load balance on a CPU
> + * that is close to the buddy.
> + */
> + if (buddy != -1)
> + for_each_domain(buddy, sd) {
> + if (sd->flags & SD_SHARE_CPUPOWER)
> + continue;
Do you mean SD_SHARE_POWERLINE here ?
> +
> + ilb = cpumask_first_and(sched_domain_span(sd),
> + nohz.idle_cpus_mask);
> +
> + if (ilb < nr_cpu_ids)
> + break;
> + }
>
> if (ilb < nr_cpu_ids && idle_cpu(ilb))
> return ilb;
>
Can you please expand "idle CPU _close_ the pack buddy CPU" ?
Regards
santosh
^ permalink raw reply
* [RFC 4/6] sched: secure access to other CPU statistics
From: Santosh Shilimkar @ 2012-10-24 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349595838-31274-5-git-send-email-vincent.guittot@linaro.org>
$subject is bit confusing here.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
> The atomic update of runnable_avg_sum and runnable_avg_period are ensured
> by their size and the toolchain. But we must ensure to not read an old value
> for one field and a newly updated value for the other field. As we don't
> want to lock other CPU while reading these fields, we read twice each fields
> and check that no change have occured in the middle.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/fair.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8c9d3ed..6df53b5 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3133,13 +3133,28 @@ static int select_idle_sibling(struct task_struct *p, int target)
> static inline bool is_buddy_busy(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> + volatile u32 *psum = &rq->avg.runnable_avg_sum;
> + volatile u32 *pperiod = &rq->avg.runnable_avg_period;
> + u32 sum, new_sum, period, new_period;
> + int timeout = 10;
So it can be 2 times read or more as well.
> +
> + while (timeout) {
> + sum = *psum;
> + period = *pperiod;
> + new_sum = *psum;
> + new_period = *pperiod;
> +
> + if ((sum == new_sum) && (period == new_period))
> + break;
> +
> + timeout--;
> + }
>
Seems like you did notice incorrect pair getting read
for rq runnable_avg_sum and runnable_avg_period. Seems
like the fix is to update them together under some lock
to avoid such issues.
Regards
Santosh
^ permalink raw reply
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Thomas Petazzoni @ 2012-10-24 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024150614.GD11837@lunn.ch>
Andrew,
On Wed, 24 Oct 2012 17:06:14 +0200, Andrew Lunn wrote:
> There are two variants of this box, ax3/2 and ax3/4. The ax3/4 can
> have more RAM and has a mini pci express slot. Do you expect both
> boards to be supported with one dts file?
I have the ax3/4 version apparently.
So, we can have the following possible schemes:
+ openblocks-ax3.dtsi
+ openblocks-ax3-2.dts
+ openblocks-ax3-4.dts
But I am not sure if using a .dtsi to factorize things common between
multiple boards is OK. Or we can do:
+ openblocks-ax3-2.dts
+ openblocks-ax3-4.dts
With openblocks-ax3-4.dts being the simple addition of PCIe slot + more
RAM. That said, I don't have the ax3/2 board anyway, so should we plan
for something that nobody can test at the moment, or wait for someone
to get a ax3/2 board, and therefore be able to do the testing? I think
I prefer to submit dts files that are know to work and have been tested
on hardware that we have.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC 3/6] sched: pack small tasks
From: Santosh Shilimkar @ 2012-10-24 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349595838-31274-4-git-send-email-vincent.guittot@linaro.org>
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
> During sched_domain creation, we define a pack buddy CPU if available.
>
> On a system that share the powerline at all level, the buddy is set to -1
>
> On a dual clusters / dual cores system which can powergate each core and
> cluster independantly, the buddy configuration will be :
> | CPU0 | CPU1 | CPU2 | CPU3 |
> -----------------------------------
> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
^
Is that a typo ? Should it be CPU2 instead of
CPU0 ?
> Small tasks tend to slip out of the periodic load balance.
> The best place to choose to migrate them is at their wake up.
>
I have tried this series since I was looking at some of these packing
bits. On Mobile workloads like OSIdle with Screen ON, MP3, gallary,
I did see some additional filtering of threads with this series
but its not making much difference in power. More on this below.
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/core.c | 1 +
> kernel/sched/fair.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++
> kernel/sched/sched.h | 1 +
> 3 files changed, 111 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index dab7908..70cadbe 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
> rcu_assign_pointer(rq->sd, sd);
> destroy_sched_domains(tmp, cpu);
>
> + update_packing_domain(cpu);
> update_top_cache_domain(cpu);
> }
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4f4a4f6..8c9d3ed 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -157,6 +157,63 @@ void sched_init_granularity(void)
> update_sysctl();
> }
>
> +
> +/*
> + * Save the id of the optimal CPU that should be used to pack small tasks
> + * The value -1 is used when no buddy has been found
> + */
> +DEFINE_PER_CPU(int, sd_pack_buddy);
> +
> +/* Look for the best buddy CPU that can be used to pack small tasks
> + * We make the assumption that it doesn't wort to pack on CPU that share the
s/wort/worth
> + * same powerline. We looks for the 1st sched_domain without the
> + * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the lowest
> + * power per core based on the assumption that their power efficiency is
> + * better */
Commenting style..
/*
*
*/
Can you please expand the why the assumption is right ?
"it doesn't wort to pack on CPU that share the same powerline"
Think about a scenario where you have quad core, ducal cluster system
|Cluster1| |cluster 2|
| CPU0 | CPU1 | CPU2 | CPU3 | | CPU0 | CPU1 | CPU2 | CPU3 |
Both clusters run from same voltage rail and have same PLL
clocking them. But the cluster have their own power domain
and all CPU's can power gate them-self to low power states.
Clusters also have their own level2 caches.
In this case, you will still save power if you try to pack
load on one cluster. No ?
> +void update_packing_domain(int cpu)
> +{
> + struct sched_domain *sd;
> + int id = -1;
> +
> + sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
> + if (!sd)
> + sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
> + else
> + sd = sd->parent;
> +
> + while (sd) {
> + struct sched_group *sg = sd->groups;
> + struct sched_group *pack = sg;
> + struct sched_group *tmp = sg->next;
> +
> + /* 1st CPU of the sched domain is a good candidate */
> + if (id == -1)
> + id = cpumask_first(sched_domain_span(sd));
> +
> + /* loop the sched groups to find the best one */
> + while (tmp != sg) {
> + if (tmp->sgp->power * sg->group_weight <
> + sg->sgp->power * tmp->group_weight)
> + pack = tmp;
> + tmp = tmp->next;
> + }
> +
> + /* we have found a better group */
> + if (pack != sg)
> + id = cpumask_first(sched_group_cpus(pack));
> +
> + /* Look for another CPU than itself */
> + if ((id != cpu)
> + || ((sd->parent) && !(sd->parent->flags && SD_LOAD_BALANCE)))
Is the condition "!(sd->parent->flags && SD_LOAD_BALANCE)" for
big.LITTLE kind of system where SD_LOAD_BALANCE may not be used ?
> + break;
> +
> + sd = sd->parent;
> + }
> +
> + pr_info(KERN_INFO "CPU%d packing on CPU%d\n", cpu, id);
> + per_cpu(sd_pack_buddy, cpu) = id;
> +}
> +
> #if BITS_PER_LONG == 32
> # define WMULT_CONST (~0UL)
> #else
> @@ -3073,6 +3130,55 @@ static int select_idle_sibling(struct task_struct *p, int target)
> return target;
> }
>
> +static inline bool is_buddy_busy(int cpu)
> +{
> + struct rq *rq = cpu_rq(cpu);
> +
> + /*
> + * A busy buddy is a CPU with a high load or a small load with a lot of
> + * running tasks.
> + */
> + return ((rq->avg.usage_avg_sum << rq->nr_running) >
> + rq->avg.runnable_avg_period);
I agree busy CPU is the one with high load, but many small threads may
not make CPU fully busy, right ? Should we just stick to the load
parameter alone here ?
> +}
> +
> +static inline bool is_light_task(struct task_struct *p)
> +{
> + /* A light task runs less than 25% in average */
> + return ((p->se.avg.usage_avg_sum << 2) < p->se.avg.runnable_avg_period);
> +}
Since the whole packing logic relies on the light threads only, the
overall effectiveness is not significant. Infact with multiple tries on
Dual core system, I didn't see any major improvement in power. I think
we need to be more aggressive here. From the cover letter, I noticed
that, you were concerned about any performance drop due to packing and
may be that is the reason you chose the conservative threshold. But the
fact is, if we want to save meaningful power, there will be slight
performance drop which is expected.
> +static int check_pack_buddy(int cpu, struct task_struct *p)
> +{
> + int buddy = per_cpu(sd_pack_buddy, cpu);
> +
> + /* No pack buddy for this CPU */
> + if (buddy == -1)
> + return false;
> +
> + /*
> + * If a task is waiting for running on the CPU which is its own buddy,
> + * let the default behavior to look for a better CPU if available
> + * The threshold has been set to 37.5%
> + */
> + if ((buddy == cpu)
> + && ((p->se.avg.usage_avg_sum << 3) < (p->se.avg.runnable_avg_sum * 5)))
> + return false;
I lost you here on better CPU , 37.5 % and last two conditions.
Isn't the first condition 'buddy==cpu' enough to return since nothing
really needs to be done in that case. Can you please expand this a bit?
> +
> + /* buddy is not an allowed CPU */
> + if (!cpumask_test_cpu(buddy, tsk_cpus_allowed(p)))
> + return false;
> +
> + /*
> + * If the task is a small one and the buddy is not overloaded,
> + * we use buddy cpu
> + */
> + if (!is_light_task(p) || is_buddy_busy(buddy))
> + return false;
This is right but both the evaluation needs update to be effective.
Regards
Santosh
^ permalink raw reply
* [RFC 2/6] sched: add a new SD SHARE_POWERLINE flag for sched_domain
From: Santosh Shilimkar @ 2012-10-24 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349595838-31274-3-git-send-email-vincent.guittot@linaro.org>
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
> This new flag SD SHARE_POWERLINE reflects the sharing of the power rail
> between the members of a domain. As this is the current assumption of the
> scheduler, the flag is added to all sched_domain
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> arch/ia64/include/asm/topology.h | 1 +
> arch/tile/include/asm/topology.h | 1 +
> include/linux/sched.h | 1 +
> include/linux/topology.h | 3 +++
> kernel/sched/core.c | 5 +++++
> 5 files changed, 11 insertions(+)
>
> diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
> index a2496e4..065c720 100644
> --- a/arch/ia64/include/asm/topology.h
> +++ b/arch/ia64/include/asm/topology.h
> @@ -65,6 +65,7 @@ void build_cpu_to_node_map(void);
> | SD_BALANCE_EXEC \
> | SD_BALANCE_FORK \
> | SD_WAKE_AFFINE, \
> + | arch_sd_share_power_line() \
> .last_balance = jiffies, \
> .balance_interval = 1, \
> .nr_balance_failed = 0, \
> diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
> index 7a7ce39..d39ed0b 100644
> --- a/arch/tile/include/asm/topology.h
> +++ b/arch/tile/include/asm/topology.h
> @@ -72,6 +72,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
> | 0*SD_PREFER_LOCAL \
> | 0*SD_SHARE_CPUPOWER \
> | 0*SD_SHARE_PKG_RESOURCES \
> + | arch_sd_share_power_line() \
> | 0*SD_SERIALIZE \
> , \
> .last_balance = jiffies, \
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 4786b20..74f2daf 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -862,6 +862,7 @@ enum cpu_idle_type {
> #define SD_WAKE_AFFINE 0x0020 /* Wake task to waking CPU */
> #define SD_PREFER_LOCAL 0x0040 /* Prefer to keep tasks local to this domain */
> #define SD_SHARE_CPUPOWER 0x0080 /* Domain members share cpu power */
> +#define SD_SHARE_POWERLINE 0x0100 /* Domain members share power domain */
If you ignore the current use of SD_SHARE_CPUPOWER, isn't the meaning of
CPUPOWER and POWERLINE is same here. Just trying to understand the clear
meaning of this new flag. Have you not considered SD_SHARE_CPUPOWER
because it is being used for cpu_power and needs at least minimum two
domains ? SD_PACKING would have been probably more appropriate based
on the way it is being used in further series.
Regards
Santosh
^ permalink raw reply
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Andrew Lunn @ 2012-10-24 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350980365-6698-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Tue, Oct 23, 2012 at 10:19:25AM +0200, Thomas Petazzoni wrote:
> This platform, available in Japan from PlatHome, has a dual-core
> Armada XP, the MV78260. For now, only the two serial ports and the
> three front LEDs are supported. Support for network, SATA, USB and
> other peripherals will be added as drivers for them become available
> for Armada XP in mainline.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> ---
> This is 3.8 material.
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/openblocks-ax3.dts | 69 ++++++++++++++++++++++++++++++++++
> arch/arm/mach-mvebu/armada-370-xp.c | 1 +
> 3 files changed, 72 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/openblocks-ax3.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f37cf9f..b7814b9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -44,7 +44,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> msm8960-cdp.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> - armada-xp-db.dtb
> + armada-xp-db.dtb \
> + openblocks-ax3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
> imx53-ard.dtb \
> imx53-evk.dtb \
> diff --git a/arch/arm/boot/dts/openblocks-ax3.dts b/arch/arm/boot/dts/openblocks-ax3.dts
> new file mode 100644
> index 0000000..f757116
> --- /dev/null
> +++ b/arch/arm/boot/dts/openblocks-ax3.dts
> @@ -0,0 +1,69 @@
> +/*
> + * Device Tree file for OpenBlocks AX3 board
> + *
> + * Copyright (C) 2012 Marvell
> + *
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +/dts-v1/;
> +/include/ "armada-xp-mv78260.dtsi"
> +
> +/ {
> + model = "PlatHome OpenBlocks AX3 board";
> + compatible = "plathome,openblocks-ax3", "marvell,armadaxp-mv78260", "marvell,armadaxp", "marvell,armada-370-xp";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200 earlyprintk";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x40000000>; /* 1 GB */
> + };
Hi Thomas
There are two variants of this box, ax3/2 and ax3/4. The ax3/4 can
have more RAM and has a mini pci express slot. Do you expect both
boards to be supported with one dts file?
Thanks
Andrew
^ permalink raw reply
* [PATCH] ARM: PMU: fix runtime PM enable
From: Jon Hunter @ 2012-10-24 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024143204.GF7339@mudshark.cambridge.arm.com>
On 10/24/2012 09:32 AM, Will Deacon wrote:
> On Wed, Oct 24, 2012 at 03:16:43PM +0100, Jon Hunter wrote:
>> Hi Will,
>>
>> On 10/24/2012 04:31 AM, Will Deacon wrote:
>>> Can we not just use the presence of the resume/suspend function pointers to
>>> indicate whether we should enable runtime pm or not? i.e. if they're not
>>> NULL, then enable the thing?
>>
>> I wondered if you would ask that :-)
>>
>> Unfortunately, we can't. For example, OMAP3430 and OMAP4460 both require
>> runtime_pm to be enabled to turn on the debug sub-system in OMAP for PMU
>> to work. However, neither of these devices are using the suspend/resume
>> callbacks because the HWMOD framework is doing this for us behind the
>> scenes.
>>
>> So then you ask, why do we need the resume/suspend callbacks, well we
>> will need them for OMAP4430 where in addition to turning on the debug
>> sub-system we need to configure the CTI module. Therefore, I had to add
>> another plat data variable.
>
> Hmmm, now I start to wonder whether your original idea of having separate
> callbacks for enable/disable irq and resume/suspend doesn't make more sense.
> Then the CTI magic can go in the irq management code and be totally separate
> to the PM stuff.
>
> What do you reckon?
The resume/suspend calls really replaced the enable/disable irq
callbacks. That still seems like a good approach given that we need
runtime PM for OMAP and PMU.
The problem is going to be with device-tree. When booting with
device-tree we will not call the current OMAP specific code that is
creating the PMU device and calling pm_runtime_enable(). So calling
pm_runtime_enable() needs to be done somewhere in the PERF driver and
that's the real problem here.
>> By the way, I did add a comment in the above changelog about this. See
>> the last paragraph, not sure if this is 100% clear.
>
> Sorry, I missed that this morning.
>
>> One alternative I had thought about was always calling
>> pm_runtime_enable() on registering the PMU device and avoid having a
>> use_runtime_pm variable. For ARM platforms that don't use runtime PM the
>> pm_runtime_enable() function does nothing. However, I was more concerned
>> about adding unnecessary overhead for ARM platforms that are using
>> runtime PM but don't need runtime PM for PMU. I don't see any side
>> affects on our OMAP2 platform that does not need runtime PM for PMU.
>> However, was not sure what is best here.
>
> Nah, we should be able to fix this in the platdata, I'd just rather have
> function pointers instead of state variables in there.
Well, we could pass a pointer to pm_runtime_enable() function in the
platdata.
Cheers
Jon
^ permalink raw reply
* Possible regression in arm/io.h
From: Bastian Hecht @ 2012-10-24 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024135854.GD7339@mudshark.cambridge.arm.com>
>> > Ok, I'll have a look at the impact of moving exclusively to "Q" when I get a
>> > chance. Which toolchain are you using?
>>
>> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
>> For a more verbose info take a look at the bug report link.
>
> Ok, thanks. One other thing you could try while I try to find a copy of that
> toolchain is changing the "+" modifier to an "=", like I proposed in this
> version of the patch:
So if alter it to fit to your patch scheme the result is:
CC arch/arm/kernel/asm-offsets.s
In file included from include/linux/scatterlist.h:10,
from include/linux/dma-mapping.h:9,
from arch/arm/kernel/asm-offsets.c:15:
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h: In function
'__raw_readb':
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:100: error:
output operand constraint lacks '='
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:98: error:
output operand constraint lacks '='
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:98: error:
invalid lvalue in asm output 0
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h: In function
'__raw_readl':
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:109: error:
output operand constraint lacks '='
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:107: error:
output operand constraint lacks '='
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:107: error:
invalid lvalue in asm output 0
and if I just replace all +Q with =Q it's this:
LD kernel/time/built-in.o
drivers/sh/intc/access.c: In function 'test_8':
drivers/sh/intc/access.c:78: warning: passing argument 1 of
'__raw_readb' makes pointer from integer without a cast
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:95: note:
expected 'const volatile void *' but argument is of type 'long
unsigned int'
drivers/sh/intc/access.c: In function 'test_16':
drivers/sh/intc/access.c:84: warning: passing argument 1 of
'__raw_readw' makes pointer from integer without a cast
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:71: note:
expected 'const volatile void *' but argument is of type 'long
unsigned int'
drivers/sh/intc/access.c: In function 'test_32':
drivers/sh/intc/access.c:90: warning: passing argument 1 of
'__raw_readl' makes pointer from integer without a cast
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:104: note:
expected 'const volatile void *' but argument is of type 'long
unsigned int'
drivers/sh/intc/access.c: In function 'write_8':
drivers/sh/intc/access.c:96: warning: passing argument 2 of
'__raw_writeb' makes pointer from integer without a cast
/home/basti/renesas/flctl_patch/arch/arm/include/asm/io.h:81: note:
expected 'volatile void *' but argument is of type 'long unsigned int'
... and so on
cheers,
Bastian
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-24 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5086F8D6.5050605@gmail.com>
On Tue, 23 Oct 2012, Rob Herring wrote:
> On 10/23/2012 02:33 PM, Alan Stern wrote:
> > On Tue, 23 Oct 2012, Stephen Warren wrote:
> >
> >>> Nothing intrinsically distinguishes this class of hardware. The only
> >>> thing these devices have in common is that they can be managed by
> >>> Linux's ehci-platform driver.
> >>
> >> I don't agree. They're all EHCI USB controllers (or all EHCI USB
> >> controllers that don't require custom drivers due to quirks), which is a
> >> much more general statement than anything related to which driver Linux
> >> uses for them.
> >
> > That's true, but it doesn't distinguish these devices. There are other
> > EHCI controllers with no quirks that nevertheless can't be handled by
> > ehci-platform because they have requirements (_not_ quirks) that
> > ehci-platform is unable to deal with currently -- clocks or power
> > supplies or special register settings or PHYs or etc.
>
> But what if the h/w has quirks you haven't yet discovered? You need the
> compatible property to be specific now, so if there are any future
> driver changes needed the DT does not have to change (as it may be in
> firmware which you can't change).
That argument applies always, doesn't it? There's always a chance that
you might discover a new quirk in a device for which the DT board file
has already been written and committed to firmware. The board file
could declare that the device is compatible with something older, but
the new quirk might ruin that compatibility.
> > Okay, fine. But then what should the binding documentation specify for
> > the compatible value? A list of all the HW models that the driver
> > currently supports?
>
> The binding docs should be independent of the driver. There may be
> fields the driver ignores. So you need to document all defined
> compatible strings. It is fine if the driver only has "usb-ehci", but it
> is not fine for the DT to only have that.
Under the circumstances, do we really need a new binding document for
the ehci-platform driver? We should be able to use the existing
usb-ehci binding, perhaps with some new properties added:
has-synopsys-hc-bug
no-io-watchdog
has-tt
We probably can omit has-synopsys-hc-bug, as that is specific to one
type of MIPS ATH79 controller. The driver can check for it explicitly,
if necessary.
In fact, it's not clear that these new properties need to be added now.
They can be added over time as needed, as existing drivers are
converted over to DT. Or is it preferable to document these things
now, preemptively as it were?
The one that matters most and is most clearly a property of the HW is
"has-tt". IMO it should be added right away, even though there may
already be DT board files that could specify it but don't. Right now,
for example, the ehci-xilinx-of driver checks instead for the
"support-usb-fs" property, as defined in
Documentation/devicetree/bindings/xilinx.txt.
Alan Stern
^ permalink raw reply
* [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
From: Peter Korsgaard @ 2012-10-24 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089624-20794-2-git-send-email-maxime.ripard@free-electrons.com>
>>>>> "MR" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:
Hi,
MR> Allow the i2c-mux-gpio to be used by a device tree enabled device. The
MR> bindings are inspired by the one found in the i2c-mux-pinctrl driver.
MR> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
MR> Reviewed-by: Stephen Warren <swarren@nvidia.com>
MR> ---
MR> .../devicetree/bindings/i2c/i2c-mux-gpio.txt | 81 +++++++++++
MR> drivers/i2c/muxes/i2c-mux-gpio.c | 146 +++++++++++++++-----
MR> 2 files changed, 196 insertions(+), 31 deletions(-)
MR> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
MR> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
MR> new file mode 100644
MR> index 0000000..d61726f
MR> --- /dev/null
MR> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
MR> @@ -0,0 +1,81 @@
MR> +GPIO-based I2C Bus Mux
MR> +
MR> +This binding describes an I2C bus multiplexer that uses GPIOs to
MR> +route the I2C signals.
MR> +
MR> + +-----+ +-----+
MR> + | dev | | dev |
MR> + +------------+ +-----+ +-----+
MR> + | SoC | | |
MR> + | | /--------+--------+
MR> + | +------+ | +------+ child bus A, on GPIO value set to 0
MR> + | | I2C |-|--| Mux |
MR> + | +------+ | +--+---+ child bus B, on GPIO value set to 1
MR> + | | | \----------+--------+--------+
MR> + | +------+ | | | | |
MR> + | | GPIO |-|-----+ +-----+ +-----+ +-----+
MR> + | +------+ | | dev | | dev | | dev |
MR> + +------------+ +-----+ +-----+ +-----+
MR> +
MR> +Required properties:
MR> +- compatible: i2c-mux-gpio
MR> +- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
MR> + port is connected to.
MR> +- mux-gpios: list of gpios used to control the muxer
MR> +* Standard I2C mux properties. See mux.txt in this directory.
MR> +* I2C child bus nodes. See mux.txt in this directory.
MR> +
MR> +Optional properties:
MR> +- idle-state: value to set to the muxer when idle. When no value is
s/to set to the muxer/to set the muxer to/
MR> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
MR> @@ -16,6 +16,8 @@
MR> #include <linux/module.h>
MR> #include <linux/slab.h>
MR> #include <linux/gpio.h>
MR> +#include <linux/of_i2c.h>
MR> +#include <linux/of_gpio.h>
MR> struct gpiomux {
MR> struct i2c_adapter *parent;
MR> @@ -57,29 +59,111 @@ static int __devinit match_gpio_chip_by_label(struct gpio_chip *chip,
MR> return !strcmp(chip->label, data);
MR> }
MR> +#ifdef CONFIG_OF
MR> +static int __devinit i2c_mux_gpio_probe_dt(struct gpiomux *mux,
MR> + struct platform_device *pdev)
MR> +{
MR> + struct device_node *np = pdev->dev.of_node;
MR> + struct device_node *adapter_np, *child;
MR> + struct i2c_adapter *adapter;
MR> + unsigned *values, *gpios;
MR> + int i = 0;
MR> +
MR> + if (!np)
MR> + return 0;
This should be -ENODEV, otherwise we end up using a zeroed out struct
i2c_mux_gpio_platform_data in case i2c_mux_gpio is used with the
platform bus but the platform forgets to pass the pdata.
With those two minor fixes:
Acked-by: Peter Korsgaard <peter.korsgaard@barco.com>
--
Sorry about disclaimer - It's out of my control.
Bye, Peter Korsgaard
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Thomas Petazzoni @ 2012-10-24 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5087FD91.1050803@free-electrons.com>
Dear Gregory CLEMENT,
On Wed, 24 Oct 2012 16:39:13 +0200, Gregory CLEMENT wrote:
> > As others said, the prefix is wrong. Since the file is named coherency,
> > maybe just "coherency_" as the prefix? Not sure, though. Shouldn't the
> > file be named coherency-armada-370-xp.c, as we have done for the irq
> > controller file? In that case, the armada_370_xp prefix would make
> > sense
>
> I would prefer to just use coherency_ everywhere and keep the name of
> the file as is. It made sense to suffix the irq file with
> armada-370-xp because the other mvebu SoCs have their own irq
> controller. Whereas, as far as I know the coherency unit is only
> present in the Armada 370/XP.
Well your argumentation may also be seen as an argument to name it
coherency-armada-370-xp.c :-) I don't have a strong opinion on this
though, and we can always rename it later if needed.
> >> int armada_xp_get_cpu_count(void)
> >> {
> >> int reg, cnt;
> >
> > static?
>
> Which function?
> armada_xp_get_cpu_count and armada_370_xp_set_cpu_coherent are exported
> and moreover are not part of this patch set but the SMP one.
Ok, then maybe this function shouldn't be between the DMA operations
implementation and the bus notifier callback.
> Yes indeed code in headsmp.S and armada_xp_smp_prepare_cpus() are
> redundant we can simplify it. I will change it in the SMP series and
> for this series also.
Great, thanks!
> > Do we have a good reason for having
> > armada_370_xp_coherency_iocache_init() separate from
> > armada_370_xp_coherency_iocache_init() ? I.e, what prevents us from
>
> No good reason because they are the same! ;)
Oops, indeed. but I see that you fixed the problem.
> But more seriously, armada_370_xp_coherency_init() is called as an
> early_init call whereas armada_370_xp_coherency_iocache_init() is called
> later by armada_370_xp_dt_init(). I have to check if we can use
> bus_register_notifier() from an early_init call or if we still need to
> call armada_370_xp_coherency_init() as an early_init call.
The early_initcall() is mandatory, see the comment on top of it:
+/* Coherency initialization have to be done before the SMP
+ * initialization of the CPUs*/
+early_initcall(armada_370_xp_coherency_init);
(BTW, there is a missing space between CPUs and the comment terminator).
So, my point was more: is it possible to register the bus notifier
as early as inside an early_initcall() callback.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 9/9] ARM: Kirkwood: Convert IX2-200 to pinctrl.
From: Andrew Lunn @ 2012-10-24 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351090434-30499-1-git-send-email-andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 90 +++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 24 -------
2 files changed, 90 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
index 865aeec..d8fa8e8 100644
--- a/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
+++ b/arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
@@ -16,6 +16,96 @@
};
ocp at f1000000 {
+ pinctrl: pinctrl at 10000 {
+ compatible = "marvell,88f6281-pinctrl";
+ reg = <0x10000 0x20>;
+
+ pinctrl-0 = < &pmx_button_reset &pmx_button_power
+ &pmx_led_backup &pmx_led_power
+ &pmx_button_otb &pmx_led_rebuild
+ &pmx_led_health
+ &pmx_led_sata_brt_ctrl_1
+ &pmx_led_sata_brt_ctrl_2
+ &pmx_led_backup_brt_ctrl_1
+ &pmx_led_backup_brt_ctrl_2
+ &pmx_led_power_brt_ctrl_1
+ &pmx_led_power_brt_ctrl_2
+ &pmx_led_health_brt_ctrl_1
+ &pmx_led_health_brt_ctrl_2
+ &pmx_led_rebuild_brt_ctrl_1
+ &pmx_led_rebuild_brt_ctrl_2 >;
+ pinctrl-names = "default";
+
+ pmx_button_reset: pmx-button-reset {
+ marvell,pins = "mpp12";
+ marvell,function = "gpio";
+ };
+ pmx_button_power: pmx-button-power {
+ marvell,pins = "mpp14";
+ marvell,function = "gpio";
+ };
+ pmx_led_backup: pmx-led-backup {
+ marvell,pins = "mpp15";
+ marvell,function = "gpio";
+ };
+ pmx_led_power: pmx-led-power {
+ marvell,pins = "mpp16";
+ marvell,function = "gpio";
+ };
+ pmx_button_otb: pmx-button-otb {
+ marvell,pins = "mpp35";
+ marvell,function = "gpio";
+ };
+ pmx_led_rebuild: pmx-led-rebuild {
+ marvell,pins = "mpp36";
+ marvell,function = "gpio";
+ };
+ pmx_led_health: pmx-led_health {
+ marvell,pins = "mpp37";
+ marvell,function = "gpio";
+ };
+ pmx_led_sata_brt_ctrl_1: pmx-led-sata-brt-ctrl-1 {
+ marvell,pins = "mpp38";
+ marvell,function = "gpio";
+ };
+ pmx_led_sata_brt_ctrl_2: pmx-led-sata-brt-ctrl-2 {
+ marvell,pins = "mpp39";
+ marvell,function = "gpio";
+ };
+ pmx_led_backup_brt_ctrl_1: pmx-led-backup-brt-ctrl-1 {
+ marvell,pins = "mpp40";
+ marvell,function = "gpio";
+ };
+ pmx_led_backup_brt_ctrl_2: pmx-led-backup-brt-ctrl-2 {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+ pmx_led_power_brt_ctrl_1: pmx-led-power-brt-ctrl-1 {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+ pmx_led_power_brt_ctrl_2: pmx-led-power-brt-ctrl-2 {
+ marvell,pins = "mpp43";
+ marvell,function = "gpio";
+ };
+ pmx_led_health_brt_ctrl_1: pmx-led-health-brt-ctrl-1 {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+ pmx_led_health_brt_ctrl_2: pmx-led-health-brt-ctrl-2 {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+ pmx_led_rebuild_brt_ctrl_1: pmx-led-rebuild-brt-ctrl-1 {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+ pmx_led_rebuild_brt_ctrl_2: pmx-led-rebuild-brt-ctrl-2 {
+ marvell,pins = "mpp45";
+ marvell,function = "gpio";
+ };
+
+ };
i2c at 11000 {
status = "okay";
diff --git a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c b/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
index 158fb97..c144712 100644
--- a/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
+++ b/arch/arm/mach-kirkwood/board-iomega_ix2_200.c
@@ -15,7 +15,6 @@
#include <linux/ethtool.h>
#include <mach/kirkwood.h>
#include "common.h"
-#include "mpp.h"
static struct mv643xx_eth_platform_data iomega_ix2_200_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_NONE,
@@ -23,34 +22,11 @@ static struct mv643xx_eth_platform_data iomega_ix2_200_ge00_data = {
.duplex = DUPLEX_FULL,
};
-static unsigned int iomega_ix2_200_mpp_config[] __initdata = {
- MPP12_GPIO, /* Reset Button */
- MPP14_GPIO, /* Power Button */
- MPP15_GPIO, /* Backup LED (blue) */
- MPP16_GPIO, /* Power LED (white) */
- MPP35_GPIO, /* OTB Button */
- MPP36_GPIO, /* Rebuild LED (white) */
- MPP37_GPIO, /* Health LED (red) */
- MPP38_GPIO, /* SATA LED brightness control 1 */
- MPP39_GPIO, /* SATA LED brightness control 2 */
- MPP40_GPIO, /* Backup LED brightness control 1 */
- MPP41_GPIO, /* Backup LED brightness control 2 */
- MPP42_GPIO, /* Power LED brightness control 1 */
- MPP43_GPIO, /* Power LED brightness control 2 */
- MPP44_GPIO, /* Health LED brightness control 1 */
- MPP45_GPIO, /* Health LED brightness control 2 */
- MPP46_GPIO, /* Rebuild LED brightness control 1 */
- MPP47_GPIO, /* Rebuild LED brightness control 2 */
- 0
-};
-
void __init iomega_ix2_200_init(void)
{
/*
* Basic setup. Needs to be called early.
*/
- kirkwood_mpp_conf(iomega_ix2_200_mpp_config);
-
kirkwood_ehci_init();
kirkwood_ge01_init(&iomega_ix2_200_ge00_data);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 8/9] ARM: Kirkwood: Convert lsxl boards to pinctrl.
From: Andrew Lunn @ 2012-10-24 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351090434-30499-1-git-send-email-andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 67 ++++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-lsxl.c | 19 ----------
2 files changed, 67 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 8fea375..01d6e3a 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -6,6 +6,73 @@
};
ocp at f1000000 {
+ pinctrl: pinctrl at 10000 {
+ compatible = "marvell,88f6281-pinctrl";
+ reg = <0x10000 0x20>;
+
+ pinctrl-0 = < &pmx_power_hdd &pmx_usb_vbus
+ &pmx_fan_low &pmx_fan_high
+ &pmx_led_function_red &pmx_led_alarm
+ &pmx_led_info &pmx_led_power
+ &pmx_fan_lock &pmx_button_function
+ &pmx_power_switch &pmx_power_auto_switch
+ &pmx_led_function_blue >;
+ pinctrl-names = "default";
+
+ pmx_power_hdd: pmx-power-hdd {
+ marvell,pins = "mpp10";
+ marvell,function = "gpio";
+ };
+ pmx_usb_vbus: pmx-usb-vbus {
+ marvell,pins = "mpp11";
+ marvell,function = "gpio";
+ };
+ pmx_fan_high: pmx-fan-high {
+ marvell,pins = "mpp18";
+ marvell,function = "gpo";
+ };
+ pmx_fan_low: pmx-fan-low {
+ marvell,pins = "mpp19";
+ marvell,function = "gpo";
+ };
+ pmx_led_function_blue: pmx-led-function-blue {
+ marvell,pins = "mpp36";
+ marvell,function = "gpio";
+ };
+ pmx_led_alarm: pmx-led-alarm {
+ marvell,pins = "mpp37";
+ marvell,function = "gpio";
+ };
+ pmx_led_info: pmx-led-info {
+ marvell,pins = "mpp38";
+ marvell,function = "gpio";
+ };
+ pmx_led_power: pmx-led-power {
+ marvell,pins = "mpp39";
+ marvell,function = "gpio";
+ };
+ pmx_fan_lock: pmx-fan-lock {
+ marvell,pins = "mpp40";
+ marvell,function = "gpo";
+ };
+ pmx_button_function: pmx-button-function {
+ marvell,pins = "mpp41";
+ marvell,function = "gpio";
+ };
+ pmx_power_switch: pmx-power-switch {
+ marvell,pins = "mpp42";
+ marvell,function = "gpio";
+ };
+ pmx_power_auto_switch: pmx-power-auto-switch {
+ marvell,pins = "mpp43";
+ marvell,function = "gpio";
+ };
+ pmx_led_function_red: pmx-led-function_red {
+ marvell,pins = "mpp43";
+ marvell,function = "gpio";
+ };
+
+ };
sata at 80000 {
status = "okay";
nr-ports = <1>;
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
index 83d8975..868bdb0 100644
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ b/arch/arm/mach-kirkwood/board-lsxl.c
@@ -26,7 +26,6 @@
#include <asm/mach/arch.h>
#include <mach/kirkwood.h>
#include "common.h"
-#include "mpp.h"
static struct mv643xx_eth_platform_data lsxl_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(0),
@@ -36,23 +35,6 @@ static struct mv643xx_eth_platform_data lsxl_ge01_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static unsigned int lsxl_mpp_config[] __initdata = {
- MPP10_GPO, /* HDD Power Enable */
- MPP11_GPIO, /* USB Vbus Enable */
- MPP18_GPO, /* FAN High Enable# */
- MPP19_GPO, /* FAN Low Enable# */
- MPP36_GPIO, /* Function Blue LED */
- MPP37_GPIO, /* Alarm LED */
- MPP38_GPIO, /* Info LED */
- MPP39_GPIO, /* Power LED */
- MPP40_GPIO, /* Fan Lock */
- MPP41_GPIO, /* Function Button */
- MPP42_GPIO, /* Power Switch */
- MPP43_GPIO, /* Power Auto Switch */
- MPP48_GPIO, /* Function Red LED */
- 0
-};
-
#define LSXL_GPIO_FAN_HIGH 18
#define LSXL_GPIO_FAN_LOW 19
#define LSXL_GPIO_FAN_LOCK 40
@@ -119,7 +101,6 @@ void __init lsxl_init(void)
/*
* Basic setup. Needs to be called early.
*/
- kirkwood_mpp_conf(lsxl_mpp_config);
/* usb and sata power on */
gpio_set_value(LSXL_GPIO_USB_POWER, 1);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/9] ARM: Kirkwood: Convert ib62x0 to pinctrl.
From: Andrew Lunn @ 2012-10-24 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351090434-30499-1-git-send-email-andrew@lunn.ch>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/kirkwood-ib62x0.dts | 41 +++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-ib62x0.c | 21 -----------------
2 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 66794ed..713b39b 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -16,6 +16,47 @@
};
ocp at f1000000 {
+ pinctrl: pinctrl at 10000 {
+ compatible = "marvell,88f6281-pinctrl";
+ reg = <0x10000 0x20>;
+
+ pinctrl-0 = < &pmx_nand
+ &pmx_led_os_red &pmx_power_off
+ &pmx_led_os_green &pmx_led_usb_transfer
+ &pmx_button_reset &pmx_button_usb_copy >;
+ pinctrl-names = "default";
+
+ pmx_nand: pmx-nand {
+ marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3",
+ "mpp04", "mpp5", "mpp18",
+ "mpp19";
+ marvell,function = "nand";
+ };
+ pmx_led_os_red: pmx-led-os-red {
+ marvell,pins = "mpp22";
+ marvell,function = "gpio";
+ };
+ pmx_power_off: pmx-power-off {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+ pmx_led_os_green: pmx-led-os-green {
+ marvell,pins = "mpp25";
+ marvell,function = "gpio";
+ };
+ pmx_led_usb_transfer: pmx-led-usb-transfer {
+ marvell,pins = "mpp27";
+ marvell,function = "gpio";
+ };
+ pmx_button_reset: pmx-button-reset {
+ marvell,pins = "mpp28";
+ marvell,function = "gpio";
+ };
+ pmx_button_usb_copy: pmx-button-usb-copy {
+ marvell,pins = "mpp29";
+ marvell,function = "gpio";
+ };
+ };
serial at 12000 {
clock-frequency = <200000000>;
status = "okay";
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
index cfc47f8..1b2a4a4 100644
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-kirkwood/board-ib62x0.c
@@ -23,7 +23,6 @@
#include <asm/mach/arch.h>
#include <mach/kirkwood.h>
#include "common.h"
-#include "mpp.h"
#define IB62X0_GPIO_POWER_OFF 24
@@ -31,24 +30,6 @@ static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
.phy_addr = MV643XX_ETH_PHY_ADDR(8),
};
-static unsigned int ib62x0_mpp_config[] __initdata = {
- MPP0_NF_IO2,
- MPP1_NF_IO3,
- MPP2_NF_IO4,
- MPP3_NF_IO5,
- MPP4_NF_IO6,
- MPP5_NF_IO7,
- MPP18_NF_IO0,
- MPP19_NF_IO1,
- MPP22_GPIO, /* OS LED red */
- MPP24_GPIO, /* Power off device */
- MPP25_GPIO, /* OS LED green */
- MPP27_GPIO, /* USB transfer LED */
- MPP28_GPIO, /* Reset button */
- MPP29_GPIO, /* USB Copy button */
- 0
-};
-
static void ib62x0_power_off(void)
{
gpio_set_value(IB62X0_GPIO_POWER_OFF, 1);
@@ -59,8 +40,6 @@ void __init ib62x0_init(void)
/*
* Basic setup. Needs to be called early.
*/
- kirkwood_mpp_conf(ib62x0_mpp_config);
-
kirkwood_ehci_init();
kirkwood_ge00_init(&ib62x0_ge00_data);
if (gpio_request(IB62X0_GPIO_POWER_OFF, "ib62x0:power:off") == 0 &&
--
1.7.10.4
^ permalink raw reply related
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