* [PATCH v4 3/5] zynq: remove use of CLKDEV_LOOKUP
From: Josh Cartwright @ 2012-10-24 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024200222.GA6713@beefymiracle.amer.corp.natinst.com>
The Zynq support in mainline does not (yet) make use of any of the
generic clk or clk lookup functionality. Remove what is upstream for
now, until the out-of-tree implementation is in suitable form for
merging.
An important side effect of this patch is that it allows the building of
a Zynq kernel without running into unresolved symbol problems:
drivers/built-in.o: In function `amba_get_enable_pclk':
clkdev.c:(.text+0x444): undefined reference to `clk_enable'
drivers/built-in.o: In function `amba_remove':
clkdev.c:(.text+0x488): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_probe':
clkdev.c:(.text+0x540): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_device_add':
clkdev.c:(.text+0x77c): undefined reference to `clk_disable'
drivers/built-in.o: In function `enable_clock':
clkdev.c:(.text+0x29738): undefined reference to `clk_enable'
drivers/built-in.o: In function `disable_clock':
clkdev.c:(.text+0x29778): undefined reference to `clk_disable'
drivers/built-in.o: In function `__pm_clk_remove':
clkdev.c:(.text+0x297f8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_suspend':
clkdev.c:(.text+0x29bc8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_resume':
clkdev.c:(.text+0x29c28): undefined reference to `clk_enable'
make[2]: *** [vmlinux] Error 1
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
In addition, eliminate Zynq's "use" of the versatile platform, as it is
no longer needed. As Nick Bowler points out:
For the record, I think this was introduced by commit 56a34b03ff427
("ARM: versatile: Make plat-versatile clock optional") which forgot to
select PLAT_VERSATILE_CLOCK on Zynq. This is not all that surprising,
because the fact that Zynq "uses" PLAT_VERSATILE is secretly hidden in
the Makefile.
Nevertheless, the only feature from versatile that Zynq needed was the
clock support, so this patch should *also* delete the secret use of
plat-versatile by removing this line from arch/arm/Makefile:
plat-$(CONFIG_ARCH_ZYNQ) += versatile
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/Kconfig | 1 -
arch/arm/Makefile | 1 -
arch/arm/mach-zynq/common.c | 1 -
arch/arm/mach-zynq/include/mach/clkdev.h | 32 --------------------------------
4 files changed, 35 deletions(-)
delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cce4f8d..de70d99 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -946,7 +946,6 @@ config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform"
select ARM_AMBA
select ARM_GIC
- select CLKDEV_LOOKUP
select CPU_V7
select GENERIC_CLOCKEVENTS
select ICST
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 451757d..8dbab2d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -197,7 +197,6 @@ machine-$(CONFIG_ARCH_ZYNQ) += zynq
# by CONFIG_* macro name.
plat-$(CONFIG_ARCH_OMAP) += omap
plat-$(CONFIG_ARCH_S3C64XX) += samsung
-plat-$(CONFIG_ARCH_ZYNQ) += versatile
plat-$(CONFIG_PLAT_IOP) += iop
plat-$(CONFIG_PLAT_NOMADIK) += nomadik
plat-$(CONFIG_PLAT_ORION) += orion
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 056091a..ba48f06 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -31,7 +31,6 @@
#include <asm/hardware/cache-l2x0.h>
#include <mach/zynq_soc.h>
-#include <mach/clkdev.h>
#include "common.h"
static struct of_device_id zynq_of_bus_ids[] __initdata = {
diff --git a/arch/arm/mach-zynq/include/mach/clkdev.h b/arch/arm/mach-zynq/include/mach/clkdev.h
deleted file mode 100644
index c6e73d8..0000000
--- a/arch/arm/mach-zynq/include/mach/clkdev.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-zynq/include/mach/clkdev.h
- *
- * Copyright (C) 2011 Xilinx, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#ifndef __MACH_CLKDEV_H__
-#define __MACH_CLKDEV_H__
-
-#include <plat/clock.h>
-
-struct clk {
- unsigned long rate;
- const struct clk_ops *ops;
- const struct icst_params *params;
- void __iomem *vcoreg;
-};
-
-#define __clk_get(clk) ({ 1; })
-#define __clk_put(clk) do { } while (0)
-
-#endif
--
1.8.0
^ permalink raw reply related
* [PATCH 1/9] ARM: Kirkwood: Convert TS219 to pinctrl.
From: Andrew Lunn @ 2012-10-24 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024220021.148a88ff@skate>
> I think what Shawn Guo did with i.MX 28 is really neat. In the current
> patches posted by Andrew, for example, the following piece:
>
> + pmx_uart1: pmx-uart1 {
> + marvell,pins = "mpp13", "mpp14";
> + marvell,function = "uart1";
> + };
>
> is needlessly repeated in kirkwood-ts219-6281.dts,
> kirkwood-ts219-6282.dts and kirkwood-dnskw.dtsi. This is clearly a
> pinmux configuration that sets up TXD/RXD of UART1, and it should be in
> kirkwood.dtsi.
I did try that, but was getting errors from dtc.
Andrew
^ permalink raw reply
* [PATCH v4 2/5] zynq: use pl310 device tree bindings
From: Josh Cartwright @ 2012-10-24 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024200222.GA6713@beefymiracle.amer.corp.natinst.com>
The Zynq has a PL310 L2 cache controller. Convert in-tree uses to using
the device tree.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/zynq-ep107.dts | 9 +++++++++
arch/arm/mach-zynq/common.c | 9 +--------
arch/arm/mach-zynq/include/mach/zynq_soc.h | 4 ----
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-ep107.dts b/arch/arm/boot/dts/zynq-ep107.dts
index 7bfff4a..87204d7 100644
--- a/arch/arm/boot/dts/zynq-ep107.dts
+++ b/arch/arm/boot/dts/zynq-ep107.dts
@@ -44,6 +44,15 @@
<0xF8F00100 0x100>;
};
+ L2: cache-controller {
+ compatible = "arm,pl310-cache";
+ reg = <0xF8F02000 0x1000>;
+ arm,data-latency = <2 3 2>;
+ arm,tag-latency = <2 3 2>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
uart0: uart at e0000000 {
compatible = "xlnx,xuartps";
reg = <0xE0000000 0x1000>;
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index d73963b..056091a 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -45,12 +45,10 @@ static struct of_device_id zynq_of_bus_ids[] __initdata = {
*/
static void __init xilinx_init_machine(void)
{
-#ifdef CONFIG_CACHE_L2X0
/*
* 64KB way size, 8-way associativity, parity disabled
*/
- l2x0_init(PL310_L2CC_BASE, 0x02060000, 0xF0F0FFFF);
-#endif
+ l2x0_of_init(0x02060000, 0xF0F0FFFF);
of_platform_bus_probe(NULL, zynq_of_bus_ids, NULL);
}
@@ -83,11 +81,6 @@ static struct map_desc io_desc[] __initdata = {
.pfn = __phys_to_pfn(SCU_PERIPH_PHYS),
.length = SZ_8K,
.type = MT_DEVICE,
- }, {
- .virtual = PL310_L2CC_VIRT,
- .pfn = __phys_to_pfn(PL310_L2CC_PHYS),
- .length = SZ_4K,
- .type = MT_DEVICE,
},
#ifdef CONFIG_DEBUG_LL
diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h b/arch/arm/mach-zynq/include/mach/zynq_soc.h
index 3d1c6a6..218283a 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -25,9 +25,6 @@
#define TTC0_PHYS 0xF8001000
#define TTC0_VIRT TTC0_PHYS
-#define PL310_L2CC_PHYS 0xF8F02000
-#define PL310_L2CC_VIRT PL310_L2CC_PHYS
-
#define SCU_PERIPH_PHYS 0xF8F00000
#define SCU_PERIPH_VIRT SCU_PERIPH_PHYS
@@ -35,7 +32,6 @@
#define TTC0_BASE IOMEM(TTC0_VIRT)
#define SCU_PERIPH_BASE IOMEM(SCU_PERIPH_VIRT)
-#define PL310_L2CC_BASE IOMEM(PL310_L2CC_VIRT)
/*
* Mandatory for CONFIG_LL_DEBUG, UART is mapped virtual = physical
--
1.8.0
^ permalink raw reply related
* [PATCH v4 1/5] zynq: use GIC device tree bindings
From: Josh Cartwright @ 2012-10-24 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024200222.GA6713@beefymiracle.amer.corp.natinst.com>
The Zynq uses the cortex-a9-gic. This eliminates the need to hardcode
register addresses.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/zynq-ep107.dts | 8 +++++---
arch/arm/mach-zynq/common.c | 7 ++++++-
arch/arm/mach-zynq/include/mach/zynq_soc.h | 2 --
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-ep107.dts b/arch/arm/boot/dts/zynq-ep107.dts
index 37ca192..7bfff4a 100644
--- a/arch/arm/boot/dts/zynq-ep107.dts
+++ b/arch/arm/boot/dts/zynq-ep107.dts
@@ -36,10 +36,12 @@
ranges;
intc: interrupt-controller at f8f01000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
interrupt-controller;
- compatible = "arm,gic";
- reg = <0xF8F01000 0x1000>;
- #interrupt-cells = <2>;
+ reg = <0xF8F01000 0x1000>,
+ <0xF8F00100 0x100>;
};
uart0: uart at e0000000 {
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index ab5cfdd..d73963b 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -55,12 +55,17 @@ static void __init xilinx_init_machine(void)
of_platform_bus_probe(NULL, zynq_of_bus_ids, NULL);
}
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ { }
+};
+
/**
* xilinx_irq_init() - Interrupt controller initialization for the GIC.
*/
static void __init xilinx_irq_init(void)
{
- gic_init(0, 29, SCU_GIC_DIST_BASE, SCU_GIC_CPU_BASE);
+ of_irq_init(irq_match);
}
/* The minimum devices needed to be mapped before the VM system is up and
diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h b/arch/arm/mach-zynq/include/mach/zynq_soc.h
index d0d3f8f..3d1c6a6 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -35,8 +35,6 @@
#define TTC0_BASE IOMEM(TTC0_VIRT)
#define SCU_PERIPH_BASE IOMEM(SCU_PERIPH_VIRT)
-#define SCU_GIC_CPU_BASE (SCU_PERIPH_BASE + 0x100)
-#define SCU_GIC_DIST_BASE (SCU_PERIPH_BASE + 0x1000)
#define PL310_L2CC_BASE IOMEM(PL310_L2CC_VIRT)
/*
--
1.8.0
^ permalink raw reply related
* [PATCH v4 0/5] zynq subarch cleanups
From: Josh Cartwright @ 2012-10-24 20:02 UTC (permalink / raw)
To: linux-arm-kernel
Hey all-
I think everything is in a good state to merge now, from here its a
discussion of process.
Thanks to everyone involved.
---
Things have been relatively quiet on the Zynq front lately. This patchset does
a bit of cleanup of the Zynq subarchitecture. It was the necessary set of
things I had to do to get a zynq target booting with the upstream qemu model.
Patches 1 and 2 move zynq to use the GIC and pl310 L2 cache controller device
tree bindings respectively.
Patch 3 removes unused clock infrastructure. The plan is to rework the
out-of-tree Xilinx generic clk support into something suitable for merging.
What's in tree now just isn't used at all, and can be removed.
Patch 4 and 5 move around the static peripheral mappings into the vmalloc area.
---
Changes since v3:
- Patch 3 also removes the zynq "use" of versatile
Changes since v2:
- Reordered patchset to prevent remapping peripherals that were subsequently
removed from the static map
- Use DT bindings for the L2 cache controller
Changes since v1:
- Make sure arm at kernel.org was included
- Rebased on arm-soc/for-next
- Added a cover letter
- Elaborated a bit on why I removed CLKDEV_LOOKUP
---
Josh Cartwright (5):
zynq: use GIC device tree bindings
zynq: use pl310 device tree bindings
zynq: remove use of CLKDEV_LOOKUP
ARM: annotate VMALLOC_END definition with _AC
zynq: move static peripheral mappings
arch/arm/Kconfig | 1 -
arch/arm/Makefile | 1 -
arch/arm/boot/dts/zynq-ep107.dts | 17 +++++++++++++---
arch/arm/include/asm/pgtable.h | 2 +-
arch/arm/mach-zynq/common.c | 23 ++++++++++-----------
arch/arm/mach-zynq/include/mach/clkdev.h | 32 ------------------------------
arch/arm/mach-zynq/include/mach/zynq_soc.h | 29 ++++++++++++---------------
7 files changed, 38 insertions(+), 67 deletions(-)
delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
--
1.8.0
^ permalink raw reply
* [RFC] Energy/power monitoring within the kernel
From: Guenter Roeck @ 2012-10-24 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351096647.23327.64.camel@hornet>
On Wed, Oct 24, 2012 at 05:37:27PM +0100, Pawel Moll wrote:
> On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote:
> > > Traditionally such data should be exposed to the user via hwmon sysfs
> > > interface, and that's exactly what I did for "my" platform - I have
> > > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good
> > > enough to draw pretty graphs in userspace. Everyone was happy...
> > >
> > Only driver supporting "energy" output so far is ibmaem, and the reported energy
> > is supposed to be cumulative, as in energy = power * time. Do you mean power,
> > possibly ?
>
> So the vexpress would be the second one, than :-) as the energy
> "monitor" actually on the latest tiles reports 64-bit value of
> microJoules consumed (or produced) since the power-up.
>
> Some of the older boards were able to report instant power, but this
> metrics is less useful in our case.
>
> > > Now I am getting new requests to do more with this data. In particular
> > > I'm asked how to add such information to ftrace/perf output. The second
> > > most frequent request is about providing it to a "energy aware"
> > > cpufreq governor.
> >
> > Anything energy related would have to be along the line of "do something after a
> > certain amount of work has been performed", which at least at the surface does
> > not make much sense to me, unless you mean something along the line of a
> > process scheduler which schedules a process not based on time slices but based
> > on energy consumed, ie if you want to define a time slice not in milli-seconds
> > but in Joule.
>
> Actually there is some research being done in this direction, but it's
> way too early to draw any conclusions...
>
> > If so, I would argue that a similar behavior could be achieved by varying the
> > duration of time slices with the current CPU speed, or simply by using cycle
> > count instead of time as time slice parameter. Not that I am sure if such an
> > approach would really be of interest for anyone.
> >
> > Or do you really mean power, not energy, such as in "reduce CPU speed if its
> > power consumption is above X Watt" ?
>
> Uh. To be completely honest I must answer: I'm not sure how the "energy
> aware" cpufreq governor is supposed to work. I have been simply asked to
> provide the data in some standard way, if possible.
>
> > I am not sure how this would be expected to work. hwmon is, by its very nature,
> > a passive subsystem: It doesn't do anything unless data is explicitly requested
> > from it. It does not update an attribute unless that attribute is read.
> > That does not seem to fit well with the idea of tracing - which assumes
> > that some activity is happening, ultimately, all by itself, presumably
> > periodically. The idea to have a user space application read hwmon data only
> > for it to trigger trace events does not seem to be very compelling to me.
>
> What I had in mind was similar to what adt7470 driver does. The driver
> would automatically access the device every now and then to update it's
> internal state and generate the trace event on the way. This
> auto-refresh "feature" is particularly appealing for me, as on some of
> "my" platforms can take up to 500 microseconds to actually get the data.
> So doing this in background (and providing users with the last known
> value in the meantime) seems attractive.
>
A bad example doesn't mean it should be used elsewhere.
adt7470 needs up to two seconds for a temperature measurement cycle, and it
can not perform automatic cycles all by itself. In this context, executing
temperature measurement cycles in the background makes a lot of sense,
especially since one does not want to wait for two seconds when reading
a sysfs attribute.
But that only means that the chip is most likely not a good choice when selecting
a temperature sensor, not that the code necessary to get it working should be used
as an example for other drivers.
Guenter
> > An exception is if a monitoring device suppports interrupts, and if its driver
> > actually implements those interrupts. This is, however, not the case for most of
> > the current drivers (if any), mostly because interrupt support for hardware
> > monitoring devices is very platform dependent and thus difficult to implement.
>
> Interestingly enough the newest version of our platform control micro
> (doing the energy monitoring as well) can generate and interrupt when a
> transaction is finished, so I was planning to periodically update the
> all sort of values. And again, generating a trace event on this
> opportunity would be trivial.
>
> > > Of course a particular driver could register its own perf PMU on its
> > > own. It's certainly an option, just very suboptimal in my opinion.
> > > Or maybe not? Maybe the task is so specialized that it makes sense?
> > >
> > We had a couple of attempts to provide an in-kernel API. Unfortunately,
> > the result was, at least so far, more complexity on the driver side.
> > So the difficulty is really to define an API which is really simple, and does
> > not just complicate driver development for a (presumably) rare use case.
>
> Yes, I appreciate this. That's why this option is actually my least
> favourite. Anyway, what I was thinking about was just a thin shin that
> *can* be used by a driver to register some particular value with the
> core (so it can be enumerated and accessed by in-kernel clients) and the
> core could (or not) create a sysfs attribute for this value on behalf of
> the driver. Seems lightweight enough, unless previous experience
> suggests otherwise?
>
> Cheers!
>
> Pawe?
>
>
>
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Andrew Lunn @ 2012-10-24 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210242006.55879.michael@walle.cc>
On Wed, Oct 24, 2012 at 08:06:55PM +0200, Michael Walle wrote:
> Hi Andrew,
>
> Am Mittwoch 24 Oktober 2012, 16:53:45 schrieb Andrew Lunn:
> > 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:
>
> Unfortunately, this doesn't work for me. git bisect tells me its commit
> e01139ec82162f21875d09e820686aede4219695.
>
> I guess it has something to do with the lsxl_init calling gpio_set_value().
Humm.
I guess it is too early to use gpio. I don't think the gpio driver has
not been configured yet.
I need to think about this.
What happens if you comment out these two gpio_set_value calls?
Andrew
^ permalink raw reply
* [PATCH 1/9] ARM: Kirkwood: Convert TS219 to pinctrl.
From: Thomas Petazzoni @ 2012-10-24 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50884659.1020208@gmail.com>
Sebastian,
On Wed, 24 Oct 2012 21:49:45 +0200, Sebastian Hesselbarth wrote:
> Agree, but for now a global pinhog on pinctrl node itself is the correct
> way to go here. As soon as there is pinctrl support in the specific
> device drivers we can move pinmux phandle there.
I agree.
> Here I disagree. Even quite simple interfaces like uart can have dozens
> of possible mpp configurations, e.g. rx/tx on up to three different pins
> each plus rts/cts on various pins plus all possible combinations.
>
> Now consider some more complex interface with more than one mpp pin per
> interface pin. Do you really want to predefine all possible combinations
> even if it is more likely that in fact only one is used on all boards
> because they are all based on the same reference design?
Where did I say that you should define *all* possible configurations?
I said: "The SoC .dtsi file should define all the pinmux groups that are
described in the datasheet and are used by boards". Read again the "and
are used by boards".
So I'm clearly not advocating adding *all* possible configurations,
because there would be gazillions of them. But I'm in favor of moving
the *used* configurations to the .dtsi files.
> > * The board .dts file should define the pinmux groups that are really
> > board-specific (buttons, LEDs, etc.), and then for each device,
> > point to the correct pinmux group (either defined in the .dtsi file
> > or in the board file).
>
> With respect to mpp the actual configuration _is_ board specific. There
> are maybe only some pins that are always used if a specific interface is
> used, e.g. nand pins on dove can only be switched with gpio.
I am not sure to follow you here. There is clearly some MPP pins whose
muxing groups can be defined in the SoC level file, and some other MPP
pins whose muxing should entirely be done at the board level file.
For a UART, the .dtsi file can define a pinmux configuration for
RX/TX/RTS/CTS, and the .dts file only needs to reference this
configuration.
For LEDs, buttons and similar things, the pinmux configuration should
be defined in the .dts file, and of course the .dts file will reference
this configuration.
I think what Shawn Guo did with i.MX 28 is really neat. In the current
patches posted by Andrew, for example, the following piece:
+ pmx_uart1: pmx-uart1 {
+ marvell,pins = "mpp13", "mpp14";
+ marvell,function = "uart1";
+ };
is needlessly repeated in kirkwood-ts219-6281.dts,
kirkwood-ts219-6282.dts and kirkwood-dnskw.dtsi. This is clearly a
pinmux configuration that sets up TXD/RXD of UART1, and it should be in
kirkwood.dtsi.
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] [RFC] pinctrl: mvebu: reset pins to an UNKNOWN state on startup
From: Thomas Petazzoni @ 2012-10-24 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508843AF.7060803@gmail.com>
Sebastian,
On Wed, 24 Oct 2012 21:38:23 +0200, Sebastian Hesselbarth wrote:
> how you make sure something you don't know about? The bootloader sets
> these pinmux settings for a reason and if the DT doesn't tell the kernel
> it should make no assumptions at all.
Apparently, the general feeling of the kernel people is that the kernel
should reduce as much as possible its dependency on the hardware
configuration set up by the bootloader. Therefore, even though your
bootloader does a certain pinmux configuration, your kernel should make
its own pinmux configuration and be fully independent from the one done
by the bootloader. If we want to achieve this, then it seemed like a
good idea to put all pins to an unknown state at boot time.
> IMHO it isn't - but maybe I am missing the point here. What is it that
> you don't like in the bootloaders choice of configuring pinmux?
Just because the kernel should not depend on hardware configuration
done by the bootloader, except for very core things like DRAM timings
and al. At least, that's my understanding of where the ARM kernel
people are trying to go. But I might have misunderstood, in which case
of course, the entire purpose of this patch disappears.
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
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-24 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4612865.mWDXHX689T@dtor-d630.eng.vmware.com>
Hi,
On Wed, Oct 24, 2012 at 12:38:44PM -0700, Dmitry Torokhov wrote:
> On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote:
> > >
> > >
> > > That is a valid concern and we'll need to find a compromise here. As I
> > > said,
> > WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a
> > valid concern ? Tell that to the millions of devices shipped with Linux
> > everyday. Power usage if it's the top concern in any product, is right
> > there as the top five. Likewise for silicon erratas.
>
> I think we should come back to this discussion when you get more coffee
> and start parsing other party e-mails properly.
indeed. I really misparsed it. My bad. comments withdrawn.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/8824c75d/attachment.sig>
^ permalink raw reply
* [PATCH 1/9] ARM: Kirkwood: Convert TS219 to pinctrl.
From: Sebastian Hesselbarth @ 2012-10-24 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024213128.2d4c07dc@skate>
On 10/24/2012 09:31 PM, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Wed, 24 Oct 2012 16:53:46 +0200, Andrew Lunn wrote:
>
>> + pinctrl-0 =< &pmx_uart0&pmx_uart1&pmx_spi
>> + &pmx_twsi0&pmx_sata0&pmx_sata1
>> + &pmx_ram_size&pmx_reset_button
>> + &pmx_USB_copy_button&pmx_board_id>;
>
> It would be really better to have those under each device, rather than
> globally declared here. For some devices such as UARTs, it is not yet
> possible with the 8250 driver to associate pinctrl pins (but I'm
> planning to work on that soon). However for the other drivers (SPI,
> TWSI, SATA, button), it should be possible.
Thomas,
Agree, but for now a global pinhog on pinctrl node itself is the correct
way to go here. As soon as there is pinctrl support in the specific
device drivers we can move pinmux phandle there.
>> + pmx_uart0: pmx-uart0 {
>> + marvell,pins = "mpp10", "mpp11";
>> + marvell,function = "uart0";
>> + };
>> ...
>
> All those definitions are not board specific, they are common to the
> SoC. So they should be in the corresponding .dtsi file.
>
> Basically:
>
> * The SoC .dtsi file should define all the pinmux groups that are
> described in the datasheet and are used by boards. I.e, there may be
> conflicting groups defined, where one group configures pin X with
> function Y, while another group configures pin X with function Z.
Here I disagree. Even quite simple interfaces like uart can have dozens
of possible mpp configurations, e.g. rx/tx on up to three different pins
each plus rts/cts on various pins plus all possible combinations.
Now consider some more complex interface with more than one mpp pin per
interface pin. Do you really want to predefine all possible combinations
even if it is more likely that in fact only one is used on all boards
because they are all based on the same reference design?
> * The board .dts file should define the pinmux groups that are really
> board-specific (buttons, LEDs, etc.), and then for each device,
> point to the correct pinmux group (either defined in the .dtsi file
> or in the board file).
With respect to mpp the actual configuration _is_ board specific. There
are maybe only some pins that are always used if a specific interface is
used, e.g. nand pins on dove can only be switched with gpio.
Sebastian
^ permalink raw reply
* [PATCH 2/2] cpufreq: governors: remove redundant code
From: Rafael J. Wysocki @ 2012-10-24 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpomUD-JQbkyEom+_BaRqJSvw8P_hBUsrjTU3vH6bM1+scQ@mail.gmail.com>
On Wednesday 24 of October 2012 11:37:13 Viresh Kumar wrote:
> On 22 October 2012 14:16, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 20 October 2012 01:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >> Initially ondemand governor was written and then using its code conservative
> >> governor is written. It used a lot of code from ondemand governor, but copy of
> >> code was created instead of using the same routines from both governors. Which
> >> increased code redundancy, which is difficult to manage.
> >>
> >> This patch is an attempt to move common part of both the governors to
> >> cpufreq_governor.c file to come over above mentioned issues.
> >>
> >> This shouldn't change anything from functionality point of view.
> >>
> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> For everybody else, this patch is already pushed by Rafael in his linux-next
> branch.
Well, not yet, although I'm going to do that.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-24 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50882EED.9020200@wwwdotorg.org>
On Wed, 24 Oct 2012, Stephen Warren wrote:
> > What's the reason for listing the generic value if drivers can't key
> > off it? Does it contain any information that's not already present in
> > the specific values?
>
> This may or may not be a mistake.
>
> The idea is that usb-ehci is included in the device node's compatible
> list iff the HW is 100% compatible with a "usb-ehci" HW device, and
But there is no such thing as a "usb-ehci" HW device. That's part of
the reason this whole discussion got started.
> hence a pure usb-ehci driver can handle the hardware without any
> additional knowledge. (That's true in general for any compatible value).
To as great an extent as is reasonable, ehci-platform is supposed to
be that "pure usb-ehci driver".
> It's quite possible that this often gets translated to the subtly
> different "the HW is an EHCI controller, so it gets
> compatible="usb-ehci"" when writing .dts files.
>
> So yes we probably should remove compatible="usb-ehci" from any device
> node for HW which really isn't a pure EHCI device. That would presumably
> require looking at the existing custom drivers and/or HW specs to
> determine what, if anything, is different about the HW.
Of course, removing it from the board files in the new kernel won't
have any effect on old board files embedded in firmware. Those old
firmwares then might not work with newer kernels.
> Related, at least on Tegra, the PHY handling is IIRC pretty tightly
> coupled into the EHCI driver. We probably should have separate nodes
> for, and drivers for, the PHYs instead. I don't know if that would
> remove all the non-standard attributes of the Tegra EHCI HW and hence
> allow Tegra's EHCI to be handled by the generic driver. From memory,
> there are certainly some HW workarounds in the Tegra EHCI driver that
> would need to be ported though.
In fact, ehci-tegra is probably the _most_ non-standard of the EHCI
drivers.
> > It sounds like the ehci-platform driver should simply list all the
> > specific HW device types (or base HW device types) that it handles, and
> > it shouldn't include "usb-ehci" in the list. As more DT board files
> > are created or as ehci-platform becomes capable to taking over from
> > other drivers, its device list would grow.
>
> That's certainly a reasonable way to go too. I think the only downside
> with that approach is that every new device needs a kernel update to add
> it to the table, whereas using a generic compatible="usb-ehci" wouldn't,
> assuming no quirks were required for the new device.
New devices could list an older device they are upwardly compatible
with. Then no kernel update would be needed. Now, I agree that a
generic entry would be more logical, but there's no generic "standard"
hardware for it to describe.
Alan Stern
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Dmitry Torokhov @ 2012-10-24 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024191042.GC772@arwen.pp.htv.fi>
On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote:
> >
> >
> > That is a valid concern and we'll need to find a compromise here. As I
> > said,
> WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a
> valid concern ? Tell that to the millions of devices shipped with Linux
> everyday. Power usage if it's the top concern in any product, is right
> there as the top five. Likewise for silicon erratas.
I think we should come back to this discussion when you get more coffee
and start parsing other party e-mails properly.
--
Dmitry
^ permalink raw reply
* [PATCH] [RFC] pinctrl: mvebu: reset pins to an UNKNOWN state on startup
From: Sebastian Hesselbarth @ 2012-10-24 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351106281-31288-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/24/2012 09:18 PM, Thomas Petazzoni wrote:
> Note: this patch is a *RFC*, it is not intended for merging, only to
> get a discussion started. The code is horrible, makes terrible
> assumptions and so on.
>
> On many platforms, most of the pinmux initialization is done in the
> bootloader, and therefore persists when we boot the Linux kernel. This
> prevents us from making sure that the pinmux configuration in the
> board device trees is correct.
Thomas,
how you make sure something you don't know about? The bootloader sets
these pinmux settings for a reason and if the DT doesn't tell the kernel
it should make no assumptions at all.
> One idea to make sure our device trees are correct in terms of
> pinmuxing is to set the state of each pin to an unavailable function
> during the initialization of the pinctrl driver. This way, only pins
> that are explicitly configured through proper device tree attributes
> will actually be functional.
>
> Remaining questions to solve:
>
> * Is this useful?
IMHO it isn't - but maybe I am missing the point here. What is it that
you don't like in the bootloaders choice of configuring pinmux?
> * Maybe some pins should be excluded for this, especially if the
> console serial port pins are muxed. On Armada XP, it's not the
> case: UART0 RX/UART0 TX pins are not part of MPPs, so we can clear
> all pins. But on other mvebu platforms, it may be the case.
That's why you don't touch pins that you don't know about. The mvebu
pinctrl is written to overwrite pinctrl settings only if someone
requests a special function. Usually this is done by a developer that
knows about the board.
Sebastian
^ permalink raw reply
* [PATCH v2] arm: mvebu: support for the PlatHome OpenBlocks AX3-4 board
From: Thomas Petazzoni @ 2012-10-24 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350980365-6698-1-git-send-email-thomas.petazzoni@free-electrons.com>
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 SMP, 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.
Changes since v1:
* Renamed the board to OpenBlocks AX3-4, since there is a variant
called AX3-2 which has less RAM, and no mini PCIe port. Requested
by Andrew Lunn.
* Fix the amount of memory to 3 GB. In fact, the board has 1 GB
soldered, and 2 GB in a SODIMM slot (which is therefore
removable). But as the board is delivered as is, we'll assume it
has 3 GB of memory by default.
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/openblocks-ax3-4.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-4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..6f2a25d 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-4.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
diff --git a/arch/arm/boot/dts/openblocks-ax3-4.dts b/arch/arm/boot/dts/openblocks-ax3-4.dts
new file mode 100644
index 0000000..7ef8052
--- /dev/null
+++ b/arch/arm/boot/dts/openblocks-ax3-4.dts
@@ -0,0 +1,69 @@
+/*
+ * Device Tree file for OpenBlocks AX3-4 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-4 board";
+ compatible = "plathome,openblocks-ax3-4", "marvell,armadaxp-mv78260", "marvell,armadaxp", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0xC0000000>; /* 3 GB */
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ serial at d0012100 {
+ clock-frequency = <250000000>;
+ status = "okay";
+ };
+ pinctrl {
+ led_pins: led-pins-0 {
+ marvell,pins = "mpp49", "mpp51", "mpp53";
+ marvell,function = "gpio";
+ };
+ };
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ red_led {
+ label = "red_led";
+ gpios = <&gpio1 17 1>;
+ default-state = "off";
+ };
+
+ yellow_led {
+ label = "yellow_led";
+ gpios = <&gpio1 19 1>;
+ default-state = "off";
+ };
+
+ green_led {
+ label = "green_led";
+ gpios = <&gpio1 21 1>;
+ default-state = "off";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..68f1483 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
static const char * const armada_370_xp_dt_board_dt_compat[] = {
"marvell,a370-db",
"marvell,axp-db",
+ "plathome,openblocks-ax3-4",
NULL,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/9] ARM: Kirkwood: Convert TS219 to pinctrl.
From: Thomas Petazzoni @ 2012-10-24 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351090434-30499-2-git-send-email-andrew@lunn.ch>
Dear Andrew Lunn,
On Wed, 24 Oct 2012 16:53:46 +0200, Andrew Lunn wrote:
> + pinctrl-0 = < &pmx_uart0 &pmx_uart1 &pmx_spi
> + &pmx_twsi0 &pmx_sata0 &pmx_sata1
> + &pmx_ram_size &pmx_reset_button
> + &pmx_USB_copy_button &pmx_board_id>;
It would be really better to have those under each device, rather than
globally declared here. For some devices such as UARTs, it is not yet
possible with the 8250 driver to associate pinctrl pins (but I'm
planning to work on that soon). However for the other drivers (SPI,
TWSI, SATA, button), it should be possible.
> + pinctrl-names = "default";
> +
> + pmx_uart0: pmx-uart0 {
> + marvell,pins = "mpp10", "mpp11";
> + marvell,function = "uart0";
> + };
> + pmx_uart1: pmx-uart1 {
> + marvell,pins = "mpp13", "mpp14";
> + marvell,function = "uart1";
> + };
> + pmx_spi: pmx-spi {
> + marvell,pins = "mpp0", "mpp1", "mpp2", "mpp3";
> + marvell,function = "spi";
> + };
> + pmx_twsi0: pmx-twsi0 {
> + marvell,pins = "mpp8", "mpp9";
> + marvell,function = "twsi0";
> + };
> + pmx_sata0: pmx-sata0 {
> + marvell,pins = "mpp5", "mpp21", "mpp23";
> + marvell,function = "sata0";
> + };
> + pmx_sata1: pmx-sata1 {
> + marvell,pins = "mpp4", "mpp20", "mpp22";
> + marvell,function = "sata1";
> + };
All those definitions are not board specific, they are common to the
SoC. So they should be in the corresponding .dtsi file.
Basically:
* The SoC .dtsi file should define all the pinmux groups that are
described in the datasheet and are used by boards. I.e, there may be
conflicting groups defined, where one group configures pin X with
function Y, while another group configures pin X with function Z.
* The board .dts file should define the pinmux groups that are really
board-specific (buttons, LEDs, etc.), and then for each device,
point to the correct pinmux group (either defined in the .dtsi file
or in the board file).
See for example imx28.dtsi, and then the boards such as
imx28-cfa10036.dts, imx28-evk.dts, imx28-m28evk.dts, imx28-tx28.dts.
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 v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-24 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5088399F.2000102@firmworks.com>
On Wed, 24 Oct 2012, Mitch Bradley wrote:
> >> Ah, now I'm starting to get the picture.
> >>
> >> So by listing "usb-ehci" in its device ID table, a driver would
> >> essentially be saying that it can handle _all_ USB EHCI controllers.
>
>
> Actually, it means that the driver can handle at least USB EHCI
> controllers that are 100% compatible with the EHCI spec (requiring
> nothing extra). The driver might be able to handle almost-compatible
> controllers, possibly with the help of additional properties.
Unfortunately that's not saying very much. The EHCI spec describes
only PCI-based controllers. Every other sort does require something
extra.
> If a DT node lists "usb-ehci" as a "fallback", it's not guaranteed that
> a given version of that driver will work, but it's worth a try in the
> event that no more-specific driver is matched.
While I haven't checked in detail, it seems quite likely that this
would not work with some of the devices that have "usb-ehci" listed in
their compatible values.
Alan Stern
^ permalink raw reply
* [PATCH] ARM: boot: Fix usage of kecho
From: Arnd Bergmann @ 2012-10-24 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210241444090.16518@xanadu.home>
On Wednesday 24 October 2012, Nicolas Pitre wrote:
> On Wed, 24 Oct 2012, Fabio Estevam wrote:
>
> > From: Fabio Estevam <fabio.estevam@freescale.com>
> >
> > Since commit edc88ceb0 (ARM: be really quiet when building with 'make -s') the
> > following output is generated when building a kernel for ARM:
> >
> > echo ' Kernel: arch/arm/boot/Image is ready'
> > Kernel: arch/arm/boot/Image is ready
> > Building modules, stage 2.
> > echo ' Kernel: arch/arm/boot/zImage is ready'
> > Kernel: arch/arm/boot/zImage is ready
> >
> > As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
> > '@$(kecho)'.
> >
> > Make this change so no more unwanted 'echo' messages are displayed.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Sorry for this, I really should have tested without '-s'.
Arnd
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Thomas Petazzoni @ 2012-10-24 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024153502.GH11837@lunn.ch>
Andrew,
On Wed, 24 Oct 2012 17:35:02 +0200, Andrew Lunn wrote:
> I've been testing with is:
>
> make kirkwood_defconfig
> make
>
> The _defconfig file now contains all boards and should build most
> common drivers to get the boards booted. If something critical is
> missing for your boards, please let us known and we will add it to
> _defconfig.
Are you sure you don't need to add a
select PINCTRL
in the CONFIG_ARCH_KIRKWOOD symbol?
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] [RFC] pinctrl: mvebu: reset pins to an UNKNOWN state on startup
From: Thomas Petazzoni @ 2012-10-24 19:18 UTC (permalink / raw)
To: linux-arm-kernel
Note: this patch is a *RFC*, it is not intended for merging, only to
get a discussion started. The code is horrible, makes terrible
assumptions and so on.
On many platforms, most of the pinmux initialization is done in the
bootloader, and therefore persists when we boot the Linux kernel. This
prevents us from making sure that the pinmux configuration in the
board device trees is correct.
One idea to make sure our device trees are correct in terms of
pinmuxing is to set the state of each pin to an unavailable function
during the initialization of the pinctrl driver. This way, only pins
that are explicitly configured through proper device tree attributes
will actually be functional.
Remaining questions to solve:
* Is this useful?
* How to figure out what function number is a good function number to
set all pins to at startup? It could be passed by the SoC-specific
pinctrl drivers.
* Maybe some pins should be excluded for this, especially if the
console serial port pins are muxed. On Armada XP, it's not the
case: UART0 RX/UART0 TX pins are not part of MPPs, so we can clear
all pins. But on other mvebu platforms, it may be the case.
* If this sounds like an interesting thing, should we keep it only at
the mvebu driver level, or make it something more generically
available in the pinctrl subsystem?
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/pinctrl/pinctrl-mvebu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-mvebu.c b/drivers/pinctrl/pinctrl-mvebu.c
index 8e6266c..32a9cbe 100644
--- a/drivers/pinctrl/pinctrl-mvebu.c
+++ b/drivers/pinctrl/pinctrl-mvebu.c
@@ -739,6 +739,9 @@ int __devinit mvebu_pinctrl_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "registered pinctrl driver\n");
+ for (n = 0; n < pctl->num_groups; n++)
+ mvebu_pinconf_group_set(pctl->pctldev, n, 7);
+
/* register gpio ranges */
for (n = 0; n < soc->ngpioranges; n++)
pinctrl_add_gpio_range(pctl->pctldev, &soc->gpioranges[n]);
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-24 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <64355430.MNHe7H1cg3@dtor-d630.eng.vmware.com>
Hi,
On Wed, Oct 24, 2012 at 10:58:53AM -0700, Dmitry Torokhov wrote:
> On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> > > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> > > >
> > > > <dmitry.torokhov@gmail.com> wrote:
> > > > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > > > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > > > > receive the same patches for the rest of input drivers shortly.
> > > > > This suggests that the operation is done at the wrong level. Do the
> > > > > pin configuration as you parse DT data, the same way you set up i2c
> > > > > devices registers in of_i2c.c, and leave the individual drivers that
> > > > > do
> > > > > not care about specifics alone.
> > > >
> > > > Exactly this can be done with pinctrl hogs.
> > > >
> > > > The problem with that is that it removes the cross-reference
> > > > between the device and it's pinctrl handle (also from the device
> > > > tree). Instead the pinctrl handle gets referenced to the pin controller
> > > > itself. So from a modelling perpective this looks a bit ugly.
> > > >
> > > > So we have two kinds of ugly:
> > > >
> > > > - Sprinke devm_pinctrl_get_select_default() over all drivers
> > > >
> > > > which makes pinctrl handles properly reference their devices
> > > >
> > > > - Use hogs and loose coupling between pinctrl handles and their
> > > >
> > > > devices
> > > >
> > > > A third alternative as outlined is to use notifiers and some
> > > > resource core in drivers/base/*
> > >
> > > OK, so with drivers/base/, have you considered doing default pinctrl
> > > selection in bus's probe() methods? Yo would select the default
> > > configuration before starting probing the device and maybe select idle
> > > when probe fails or device is unbound? That would still keep the link
> > > between device object and pinctrl and there less busses than device
> > > drivers out there.
> >
> > it starts to become confusing after a while. I mean, there's a reason
> > why all drivers explictly call pm_runtim_enable(), right ?
>
> Right. Because not all of them support runtime PM and quite usually their
> PM methods are not ready to go until initialization is complete. And again,
> the driver here controls its own behavior.
likewise not all devices will need pin muxing, those which do (granted,
an increasing number of them since transistor size continue to shrink,
allowing chip manufacturers to pack more features inside a single die,
while the number of external pins/balls remain the same), will call
pinctrl to setup muxing right.
> > From a first thought, one could think of just yanking that into bus'
> > probe() as you may suggest, but sometimes the device is already enabled,
> > so we need extra tricks:
> >
> > pm_runtime_set_active();
> > pm_runtime_enable();
> > pm_runtime_get();
> >
> > the same could happen with pinctrl eventually. What if a device needs to
> > do something else (an errata fix as an example) before requesting
> > pinctrl's default state ?
>
> That is a valid concern and we'll need to find a compromise here. As I said,
WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a
valid concern ? Tell that to the millions of devices shipped with Linux
everyday. Power usage if it's the top concern in any product, is right
there as the top five. Likewise for silicon erratas.
Let's face it, just like SW, HW has bugs; the difference is that no
company will continue to do several spins of an ASIC just because some
SW engineer doesn't get concerned about a silicon bug. It's just too
expensive to re-spin the ASIC. And even if we get another revision of
the ASIC, we still need to support the older version as there might be
cellphones, laser welding machines, IPTVs and whatever product already
shipped.
> I am not saying that no driver should ever touch pinctrl. I can see, for
> example, input drivers actually disabling pins until they are ->open()ed,
> in addition of doing that at [runtime] suspend/resume. But it would be nice
> if we could have "dumb" drivers not care about pins.
Like I replied on another sub-thread, this will just create exceptions
to the rule which is far more messy than having a couple of extra lines
of code in a few drivers. We can even argue that eventually all drivers
will need to toggle pins in runtime in order to save that extra
microwatt of runtime power consumption, so why bother adding exceptions ?
In fact, we already have the exception: drivers which don't need to
fiddle with pin muxing, just don't use pinctrl. The ones you're
receiving today are the one which, for whatever reason, need to make
sure pin muxing is right. If it's not toggling in runtime, it might just
be because $AUTHOR decided that it would be best to do thing in small
steps (don't we all agree with that ?). Maybe he thought that changing
pins in runtime could cause problems, so let's get bare minimum in
mainline and work towards optimizations in parallel.
All in all, I don't see why you're complaining so much about a couple of
lines of code. Even if it needs to be added to all drivers in tree. So
what ? As long as pinctrl works fine in multiple platforms, what is done
for e.g. OMAP2 should work fine in OMAP3/4/5. An even more complex
example: what works on OMAP, should work on Exynos, Tegra, etc, if the
same driver is used accross those platforms.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/9ba36a47/attachment.sig>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-24 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4099134.xWUIfbbahk@dtor-d630.eng.vmware.com>
Hi,
On Wed, Oct 24, 2012 at 10:28:46AM -0700, Dmitry Torokhov wrote:
> > for more complex pinctrl use cases. These are my dogfood drivers ...
> > Most of these will request more than one state and switch the driver
> > between these different states at runtime, in these examples for power
> > saving there are states named "default", "sleep" and in the I2C driver
> > also "idle".
> >
> > These examples are more typical to how the ux500 platform will
> > look, also the SKE input driver will move the devise to sleep/default
> > states but we need to merge PM code before we can do that.
>
> I do not say that no drivers should ever touch pinctrl, just that most
> of them do not have to if you have other layers to the right thing for
> them.
It will be a much bigger mess. Some drivers don't need to care about
pinctrl because drivers/base handle it for them, while some others will
need a way to tell drivers/base "hey, don't touch pinctrl at all because
I know what I'm doing" and that has to happen before probe() too,
otherwise it's already too late and, according to what you suggest,
drivers/base will already have touched pinctrl. The only way I see would
be to add an extra "dont_touch_my_pins" field to every driver structure
in the kernel. Clearly what you say is nonsense.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/a0916399/attachment.sig>
^ permalink raw reply
* [PATCH] Revert "serial: omap: fix software flow control"
From: Greg KH @ 2012-10-24 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024100254.GG5665@arwen.pp.htv.fi>
On Wed, Oct 24, 2012 at 01:02:55PM +0300, Felipe Balbi wrote:
> Hi Greg,
>
> On Tue, Oct 16, 2012 at 08:13:59AM -0700, Tony Lindgren wrote:
> > * Felipe Balbi <balbi@ti.com> [121016 07:16]:
> > > This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
> > > (serial: omap: fix software flow control).
> > >
> > > As Russell has pointed out, that commit isn't fixing
> > > Software Flow Control at all, and it actually makes
> > > it even more broken.
> > >
> > > It was agreed to revert this commit and use Russell's
> > > latest UART patches instead.
> > >
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> >
> > This seems like the best way to go for the -rc series:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> Any chance you can pick this one up for v3.7-rc3 ?
Now queued up, sorry for the delay.
greg k-h
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Mitch Bradley @ 2012-10-24 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50882EED.9020200@wwwdotorg.org>
On 10/24/2012 8:09 AM, Stephen Warren wrote:
> On 10/24/2012 11:46 AM, Alan Stern wrote:
>> On Wed, 24 Oct 2012, Stephen Warren wrote:
>>
>>>> How do we determine which existing drivers claim to support usb-ehci?
>>>> A quick search under arch/ and drivers/ turns up nothing but
>>>> drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
>>>> match should be easy enough, and then "usb-ehci" would be safe to use
>>>> in ehci-platform.c.
>>>
>>> It's not drivers that claim to support usb-ehci, but device tree files
>>> that contain nodes that include "usb-ehci" in their compatible value,
>>> yet need to be handled by a driver that isn't the generic USB EHCI
>>> driver, and that driver binds to the other more specific compatible value:
>>>
>>>> $ grep -HrnI usb-ehci arch/*/boot/dts
> ...
>>> and then search for all those other compatible values in drivers. The
>>> ARM instances certainly all have this issue (although perhaps it's worth
>>> investigating if a generic could work for them instead). The PPC
>>> instances need more investigation; the values don't show up in of match
>>> tables but rather in code.
>>
>> Ah, now I'm starting to get the picture.
>>
>> So by listing "usb-ehci" in its device ID table, a driver would
>> essentially be saying that it can handle _all_ USB EHCI controllers.
Actually, it means that the driver can handle at least USB EHCI
controllers that are 100% compatible with the EHCI spec (requiring
nothing extra). The driver might be able to handle almost-compatible
controllers, possibly with the help of additional properties.
If a DT node lists "usb-ehci" as a "fallback", it's not guaranteed that
a given version of that driver will work, but it's worth a try in the
event that no more-specific driver is matched.
>
> Yes, exactly.
>
>> (Which means that the entry in ehci-ppc-of.c is questionable; perhaps
>> the intention is that this driver really does handle all EHCI
>> controllers on any PPC-based OpenFirmware platform bus.)
>
> Yes, that seems questionable, although perhaps within the context of
> only enabling the driver on PPC specifically, it may be reasonable.
>
>>> This doesn't continue forever though; you typically only list the
>>> specific HW model, the base specific model it's compatible with, and any
>>> generic value needed. So, a hypothetical Tegra40 EHCI controller would be:
>>>
>>> compatible = "nvidia,tegra40-ehci", "nvidia,tegra20-ehci", "usb-ehci".
>>
>> What's the reason for listing the generic value if drivers can't key
>> off it? Does it contain any information that's not already present in
>> the specific values?
>
> This may or may not be a mistake.
>
> The idea is that usb-ehci is included in the device node's compatible
> list iff the HW is 100% compatible with a "usb-ehci" HW device, and
> hence a pure usb-ehci driver can handle the hardware without any
> additional knowledge. (That's true in general for any compatible value).
>
> It's quite possible that this often gets translated to the subtly
> different "the HW is an EHCI controller, so it gets
> compatible="usb-ehci"" when writing .dts files.
>
> So yes we probably should remove compatible="usb-ehci" from any device
> node for HW which really isn't a pure EHCI device. That would presumably
> require looking at the existing custom drivers and/or HW specs to
> determine what, if anything, is different about the HW.
>
> Related, at least on Tegra, the PHY handling is IIRC pretty tightly
> coupled into the EHCI driver. We probably should have separate nodes
> for, and drivers for, the PHYs instead. I don't know if that would
> remove all the non-standard attributes of the Tegra EHCI HW and hence
> allow Tegra's EHCI to be handled by the generic driver. From memory,
> there are certainly some HW workarounds in the Tegra EHCI driver that
> would need to be ported though.
>
>> It sounds like the ehci-platform driver should simply list all the
>> specific HW device types (or base HW device types) that it handles, and
>> it shouldn't include "usb-ehci" in the list. As more DT board files
>> are created or as ehci-platform becomes capable to taking over from
>> other drivers, its device list would grow.
>
> That's certainly a reasonable way to go too. I think the only downside
> with that approach is that every new device needs a kernel update to add
> it to the table, whereas using a generic compatible="usb-ehci" wouldn't,
> assuming no quirks were required for the new device.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ 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