* [PATCH] ARM: add get_user() support for 8 byte types
From: Rob Clark @ 2012-11-12 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112192727.GB28341@n2100.arm.linux.org.uk>
On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
>> From: Rob Clark <rob@ti.com>
>>
>> A new atomic modeset/pageflip ioctl being developed in DRM requires
>> get_user() to work for 64bit types (in addition to just put_user()).
>
> NAK.
>
> (I did write a better email explaining all the ins and outs of why this
> won't work and why 64-bit get_user isn't possible, but my editor crapped
> out and lost all that well written message; I don't fancy typing it all
> out again.)
>
> Nevertheless,
> int test_ptr(unsigned int **v, unsigned int **p)
> {
> return get_user(*v, p);
> }
>
> produces a warning, and you can't get away from that if you stick 64-bit
> support into get_user().
Actually, it seems like using 'register typeof(x) __r2 asm("r2");'
does avoid that warning..
I don't know if that was the only argument against 64-bit get_user().
But it will at least be inconvenient that get_user() works for 64bit
on x86 but not arm..
BR,
-R
> Sorry, 64-bit get_user() is a no-no.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* usb clock not found on imx27 when using dt
From: trem @ 2012-11-12 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112075411.GO10369@pengutronix.de>
On 12/11/12 08:54, s.hauer at pengutronix.de wrote:
> On Sun, Nov 11, 2012 at 08:34:34PM +0000, Philippe Reynes wrote:
>> Hi all,
>>
>> I try to add the support of usb on my armadeus apf27,
>> but there is a problem when try to reclaim the clock.
>> imx_usb mxc-ehci.0: Failed to get clock, err=-2
>>
>> To avoid adding too many attachment to this mail,
>> I've put all the information on a website. You can
>> found them here: http://ryu.zarb.org/~trem/armadeus/
>>
>>
>> The initial issue is in the directory : 20121110
>>
>> boot-3.7-rc4.log : boot log with the issue
>> linux-3.7-rc4.config : the configuration file for the kernel
>> investifation.txt : the description of my investigation.
>
> You should really post the relevant bits on the mailing list. Nobody
> visits websites for investigating your issue. Besides, it will not be
> in the mailing list archives so people will not find it later.
You're right, I add an archive with all log as attachment.
>>
>>
>> I've tried to fix the clock issue, but another issue occurs.
>> The information about this "fix" is in : 20121111
>> boot-3.7-rc4.log : boot log with the new issue
>> issue.txt : the description of the change done on the kernel
>>
>> I've got severals questions :
>> - does my dts correct with usb change ?
>> - does someone has already tested usb on imx27 with dt ?
>
> Please investigate in using the chipidea driver. This will be the way
> forward for i.MX.
I use the chipidea driver for the usb.
The main issue is that the chipidea driver don't found the clock :
[ 0.761693] imx_usb mxc-ehci.0: Failed to get clock, err=-2
[ 0.767620] imx_usb: probe of mxc-ehci.0 failed with error -2
The driver ci13xxx_imx request the clock in the probe function
in the following line:
data->clk = devm_clk_get(&pdev->dev, NULL);
calling: clk = clk_get(dev, id);
calling: clk_get_sys(dev_id, con_id);
calling: clk_find(dev_id, con_id);
with dev_id = mxc-ehci.0 and con_id = NULL
This last function fail to found a clock.
In the function mx27_clocks_init, several mxc-ehci.0
clocks are registered, but all with a con_id.
So the function clk_find fails.
As I'm not really sure of the dts, I don't know if the problem
is in the dts or in the driver (maybe both).
Regards,
Philippe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usb_imx27_dt.tar.bz2
Type: application/x-bzip
Size: 24021 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121112/2d224f44/attachment-0001.bin>
^ permalink raw reply
* [PATCH V2 1/5] arm: mvebu: Added support for coherency fabric in mach-mvebu
From: Gregory CLEMENT @ 2012-11-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105140258.GO3351@mudshark.cambridge.arm.com>
Hi Will,
On 11/05/2012 03:02 PM, Will Deacon wrote:
> Hi Gregory,
>
> On Mon, Oct 29, 2012 at 09:11:44PM +0000, Gregory CLEMENT wrote:
>> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
>> new file mode 100644
>> index 0000000..69e130d
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/coherency.c
>> @@ -0,0 +1,89 @@
>> +/*
>> + * Coherency fabric (Aurora) support for Armada 370 and XP platforms.
>> + *
>> + * Copyright (C) 2012 Marvell
>> + *
>> + * Yehuda Yitschak <yehuday@marvell.com>
>> + * Gregory Clement <gregory.clement@free-electrons.com>
>> + * 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.
>> + *
>> + * The Armada 370 and Armada XP SOCs have a coherency fabric which is
>> + * responsible for ensuring hardware coherency between all CPUs and between
>> + * CPUs and I/O masters. This file initializes the coherency fabric and
>> + * supplies basic routines for configuring and controlling hardware coherency
>> + */
>
> [...]
>
>> +int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
>> +{
>> + int reg;
>> +
>> + if (!coherency_base) {
>> + pr_warn("Can't make CPU %d cache coherent.\n", hw_cpu_id);
>> + pr_warn("Coherency fabric is not initialized\n");
>> + return 1;
>> + }
>> +
>> + /* Enable the CPU in coherency fabric */
>> + reg = readl(coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> + reg |= 1 << (24 + hw_cpu_id);
>> + writel(reg, coherency_base + COHERENCY_FABRIC_CTL_OFFSET);
>> +
>> + /* Add CPU to SMP group */
>> + reg = readl(coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> + reg |= 1 << (16 + hw_cpu_id + (smp_group_id == 0 ? 8 : 0));
>> + writel(reg, coherency_base + COHERENCY_FABRIC_CFG_OFFSET);
>> +
>> + return 0;
>> +}
>
> These writels may expand to code containing calls to outer_sync(), which
> will attempt to take a spinlock for the aurora l2. Given that the CPU isn't
> coherent, how does this play out with the exclusive store instruction in the
> lock?
I dug a little this subject: and I am not sure there is problem. In SMP mode,
only the system cache mode of Aurora is used. In this mode, outer_cache.sync
is void then outer_sync() won't call any function, so there will be no
access to any spinlock.
Gregory
^ permalink raw reply
* [PATCH] RFC: pinctrl: grab default handler with bus notifiers
From: Stephen Warren @ 2012-11-12 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352636539-6318-1-git-send-email-linus.walleij@stericsson.com>
On 11/11/2012 05:22 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This makes the pinctrl subsystem auto-grab the pinctrl handle and
> set the "default" (PINCTRL_STATE_DEFAULT) state for every device
> that is present on the platform or AMBA (PrimeCell) bus right
> before probe. This will account for the lion's share of embedded
> silicon devcies. The behaviour is achieved using bus notifiers
> on the platform and AMBA (PrimeCell) busses.
Doing this seems reasonable.
> Notice that the patch disregards deferral as per above:
...
> Another solution that was discussed was whether to move
> the default pinctrl handle and state grab to the device
> core as an optional field in struct device itself, but
> I'd like to first propose this less intrusive mechanism.
I think doing that approach makes a lot more sense; wouldn't it
completely avoid the issues with deferred probe that this notifier-based
method can't solve? It would also be very much in line with e.g.
dev_get_regmap() - if every resource that a driver required were handled
like that, then deferred probe could be significantly isolated into the
driver core rather than in every driver...
> diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
> index da40efb..b6c27b1 100644
> --- a/Documentation/pinctrl.txt
> +++ b/Documentation/pinctrl.txt
> @@ -972,6 +972,19 @@ pinmux core.
> Pin control requests from drivers
> =================================
>
> +When a device driver is about to probe on the platform or AMBA (PrimeCell)
> +bus,
Why not make this apply to every device? I don't think the specific bus
type impacts whether pinctrl would be useful?
> @@ -1097,8 +1110,8 @@ situations that can be electrically unpleasant, you will certainly want to
> -The above can be hidden: using pinctrl hogs, the pin control driver may be
> -setting up the config and muxing for the pins when it is probing,
> +The above can be hidden: using device notifiers, the pinctrl core may be
> +setting up the config and muxing for the pins when the device is probing,
> nevertheless orthogonal to the GPIO subsystem.
Why removing "using pinctrl hogs"; can't "it" (although I didn't check
what "it" is...) be hidden using either pinctrl hogs or device notifiers?
> But there are also situations where it makes sense for the GPIO subsystem
> @@ -1144,6 +1157,13 @@ PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */, "power_func")
>
> This gives the exact same result as the above construction.
>
> +This should not be used for any kind of device which is represented in
> +the device model. For platform and AMBA (PrimeCell) devices, such as found
> +in many SoC:s, the pinctrl core will listen to notifications from these
> +buses and attempt to do pinctrl_get_select_default() for these devices
> +right before their device drivers are probed, so hogging these will just
> +make the model look strange.
(re: the first sentence:) Why not? For the device tree case, that's
forcing DT authors to sprinkle the device tree across all devices
throughout the tree, rather than having a simple single "hog" table in
the pin controller itself. At least where there's no dynamic muxing
required, I don't think it makes any semantic difference whether the
pinctrl configuration is represented as a single "pinmux HW"
configuration, or split up per-device, and writing the single
centralized configuration is easier.
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> @@ -684,9 +687,16 @@ static struct pinctrl *pinctrl_get_locked(struct device *dev)
> if (WARN_ON(!dev))
> return ERR_PTR(-EINVAL);
>
> + /*
> + * See if somebody else (such as the pinctrl core, using the
> + * notifiers) has already obtained a handle to the pinctrl for
> + * this device. In that case, return another pointer to it.
> + */
> p = find_pinctrl(dev);
> - if (p != NULL)
> - return ERR_PTR(-EBUSY);
> + if (p != NULL) {
> + dev_dbg(dev, "obtain a copy of previously claimed pinctrl\n");
> + return p;
You'd want to implement full reference-counting then; IIRC, that's why I
banned pinctrl_get() running twice in the original code.
^ permalink raw reply
* [PATCH v4] Add device tree file for the armadeus apf27
From: Philippe Reynes @ 2012-11-12 20:28 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Philippe Reynes <tremyfr@yahoo.fr>
Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>
---
v4: update model to use the same format as apf28
remove some empty line
v3: set 26M clock to 0 (not used)
v2: avoid enable again the watchdog
arch/arm/boot/dts/imx27-apf27.dts | 89 +++++++++++++++++++++++++++++++++++++
1 files changed, 89 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/imx27-apf27.dts
diff --git a/arch/arm/boot/dts/imx27-apf27.dts b/arch/arm/boot/dts/imx27-apf27.dts
new file mode 100644
index 0000000..c0327c0
--- /dev/null
+++ b/arch/arm/boot/dts/imx27-apf27.dts
@@ -0,0 +1,89 @@
+/*
+ * Copyright 2012 Philippe Reynes <tremyfr@yahoo.fr>
+ * Copyright 2012 Armadeus Systems <support@armadeus.com>
+ *
+ * Based on code which is: Copyright 2012 Sascha Hauer, Pengutronix
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "imx27.dtsi"
+
+/ {
+ model = "Armadeus Systems APF27 module";
+ compatible = "armadeus,imx27-apf27", "fsl,imx27";
+
+ memory {
+ reg = <0xa0000000 0x04000000>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc26m {
+ compatible = "fsl,imx-osc26m", "fixed-clock";
+ clock-frequency = <0>;
+ };
+ };
+
+ soc {
+ aipi at 10000000 {
+ serial at 1000a000 {
+ status = "okay";
+ };
+
+ ethernet at 1002b000 {
+ status = "okay";
+ };
+ };
+
+ nand at d8000000 {
+ status = "okay";
+ nand-bus-width = <16>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0x0 0x100000>;
+ };
+
+ partition at 100000 {
+ label = "env";
+ reg = <0x100000 0x80000>;
+ };
+
+ partition at 180000 {
+ label = "env2";
+ reg = <0x180000 0x80000>;
+ };
+
+ partition at 200000 {
+ label = "firmware";
+ reg = <0x200000 0x80000>;
+ };
+
+ partition at 280000 {
+ label = "dtb";
+ reg = <0x280000 0x80000>;
+ };
+
+ partition at 300000 {
+ label = "kernel";
+ reg = <0x300000 0x500000>;
+ };
+
+ partition at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0xf800000>;
+ };
+ };
+ };
+};
--
1.7.4.4
^ permalink raw reply related
* [PATCH V3 00/13] ARM: OMAP: DMTIMER fixes
From: Tony Lindgren @ 2012-11-12 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121112 10:22]:
> This series includes several fixes for the OMAP DMTIMER driver. This is
> based upon Tony Lindgren's current master branch [1].
You should be able to use omap-for-v3.8/dt as the base now with
the cleanup merged there. The master branch is just a merge of the
various topic branches, and can't be used as a base for pull requests.
Regards,
Tony
> [1] http://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
^ permalink raw reply
* [PATCH v4 5/9] document: devicetree: bind pinconf with pin-single
From: Stephen Warren @ 2012-11-12 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352301582-12244-6-git-send-email-haojian.zhuang@gmail.com>
On 11/07/2012 08:19 AM, Haojian Zhuang wrote:
> Add comments with pinconf & gpio range in the document of
> pinctrl-single.
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
> Required properties:
> -- compatible : "pinctrl-single"
> +- compatible : "pinctrl-single" or "pinconf-single".
> + "pinctrl-single" means that pinconf isn't supported.
> + "pinconf-single" means that generic pinconf is supported.
>
> - reg : offset and length of the register set for the mux registers
>
> @@ -14,9 +16,33 @@ Optional properties:
> - pinctrl-single,function-off : function off mode for disabled state if
> available and same for all registers; if not specified, disabling of
> pin functions is ignored
> +
> - pinctrl-single,bit-per-mux : boolean to indicate that one register controls
> more than one pin
>
> +- pinctrl-single,power-source-mask : mask of setting power source in
> + the pinmux register
> +
> +- pinctrl-single,power-source : value of setting power source field
> + in the pinmux register
Isn't power-source an enumeration? As such, shouldn't the pinctrl state
definition supply the value, rather than the pin controller definition?
The above two properties imply to me that you're saying "these bits
(power-source-mask) in any pin register must be set to this one value
(power-source)". However, I think you want to say "these bits
(power-source-mask) are used to configure the power source", and then
allow the state nodes (what's reference from pinctrl client devices'
pinctrl-n properties) to define the value.
Perhaps that's your intent already, but if so, the properties for the
two different nodes should be documented separately, not all interleaved
in a single list, without any indication of which node they get put into.
> +- pinctrl-single,bias-mask : mask of setting bias value in the pinmux
> + register
> +
> +- pinctrl-single,bias-disable : value of disabling bias in the pinmux
> + register
> +
> +- pinctrl-single,bias-pull-down : value of setting bias pull down in
> + the pinmux register
> +
> +- pinctrl-single,bias-pull-up : value of setting bias pull up in the
> + pinmux register
> +
> +- pinctrl-single,bias : value of setting bias in the pinmux register
If there are bias-disable, bias-pull-down, and bias-pull-up properties,
what is the plain "bias" property for?
> +- pinctrl-single,input-schmitt-mask : mask of setting input schmitt
> + in the pinmux register
And if the "value" properties go into the pinctrl state nodes, why isn't
there a "value" property for schmitt?
> +Optional sub-node: In case some pins could be configured as GPIO in the pinmux
> +register. If both GPIO nubmer and pin base of those pins are in ascending order,
> +those pins could be defined as a GPIO range. The sub-node should be defined in
> +.dtsi files of those silicons.
Pinctrl state definitions are also nodes directly inside the pin
controller node. How does the pin controller driver know whether a child
node is a state definition, or a GPIO range? Is the node required to
have some specific name?
^ permalink raw reply
* [PATCH] ARM: integrator: use BUG_ON where possible
From: Arnd Bergmann @ 2012-11-12 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352406191-14303-6-git-send-email-sasha.levin@oracle.com>
On Thursday 08 November 2012, Sasha Levin wrote:
> Just use BUG_ON() instead of constructions such as:
>
> if (...)
> BUG()
>
> A simplified version of the semantic patch that makes this transformation
> is as follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e;
> @@
> - if (e) BUG();
> + BUG_ON(e);
> // </smpl>
>
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Linus Walleij is doing most of the integrator work these days, maybe he
wants to apply the patch.
Acked-by: Arnd Bergmann <arnd@arndb.de>
> arch/arm/mach-integrator/pci_v3.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
> index bbeca59..85938de 100644
> --- a/arch/arm/mach-integrator/pci_v3.c
> +++ b/arch/arm/mach-integrator/pci_v3.c
> @@ -191,12 +191,9 @@ static void __iomem *v3_open_config_window(struct pci_bus *bus,
> /*
> * Trap out illegal values
> */
> - if (offset > 255)
> - BUG();
> - if (busnr > 255)
> - BUG();
> - if (devfn > 255)
> - BUG();
> + BUG_ON(offset > 255);
> + BUG_ON(busnr > 255);
> + BUG_ON(devfn > 255);
>
> if (busnr == 0) {
> int slot = PCI_SLOT(devfn);
> --
> 1.7.10.4
>
>
^ permalink raw reply
* [GIT PULL v2] Renesas ARM-based SoC for v3.8 #2
From: Arnd Bergmann @ 2012-11-12 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352446165-19298-1-git-send-email-horms@verge.net.au>
On Friday 09 November 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following SoC enhancements for 3.8.
>
> * This series is based on the renesas/soc branch of the arm-soc tree.
> There will be a subquent 'SoC2' pull request which is based on this
> pull-request and a pull-request for boards.
Pulled into next/soc branch on top of the earlier shmobile soc changes.
Thanks,
Arnd
^ permalink raw reply
* [PATCH V2 0/5] SMP support for Armada XP
From: Gregory CLEMENT @ 2012-11-12 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351545108-18954-1-git-send-email-gregory.clement@free-electrons.com>
Hello,
On 10/29/2012 10:11 PM, Gregory CLEMENT wrote:
[...]
> Arnd, Olof, as this code is SoC specific will you be able to pull it
> through Jason tree? Or should I push the part added in
> arch/arm/mm/proc-v7.S to support PJ4B CPU through Russell tree?
Before sending a new series with the fixes related to Will comments, I
would like to know if I need to split the patches in order to send some
parts to Russell or if you (Arnd and Olof) will be able to take the whole
series (through Jason Cooper's git tree of course).
>
> Changelog:
> V1 -> V2:
> - Rebased on to v3.7-rc3
> - Fixed typos found by Alexandre Belloni
> - Added clk_prepare_enable() before getting rate clk in
> set_secondary_cpus_clock()
> - Add explanation in the binding documentation about the per-CPU
> interrupt registers: the address of the virtual register must be
> used.
> - Removed the armada_xp prefix in the coherency.c file to be more
> compliant with the name convention of the other files.
> - Coherency_init is now called from armada_370_xp_dt_init() and is no
> more an early_init() call. As the device tree is not available from
> an early_init(), it was useless to call coherency_init() so
> early. The need to be able to call some function very early during
> the boot were already resolved by using the hard code address of the
> register.
>
> Regards,
>
> Yehuda Yitschak (5):
> arm: mvebu: Added support for coherency fabric in mach-mvebu
> arm: mvebu: Added initial support for power managmement service unit
> arm: mvebu: Added IPI support via doorbells
> arm: mm: Added support for PJ4B cpu and init routines
> arm: mvebu: Added SMP support for Armada XP
>
> .../devicetree/bindings/arm/armada-370-xp-mpic.txt | 12 +-
> .../devicetree/bindings/arm/armada-370-xp-pmsu.txt | 20 ++++
> .../devicetree/bindings/arm/coherency-fabric.txt | 16 +++
> arch/arm/boot/dts/armada-370-xp.dtsi | 5 +
> arch/arm/boot/dts/armada-xp.dtsi | 12 +-
> arch/arm/configs/mvebu_defconfig | 3 +
> arch/arm/mach-mvebu/Kconfig | 3 +-
> arch/arm/mach-mvebu/Makefile | 4 +-
> arch/arm/mach-mvebu/armada-370-xp.c | 3 +
> arch/arm/mach-mvebu/armada-370-xp.h | 10 ++
> arch/arm/mach-mvebu/coherency.c | 89 ++++++++++++++
> arch/arm/mach-mvebu/coherency.h | 21 ++++
> arch/arm/mach-mvebu/common.h | 6 +
> arch/arm/mach-mvebu/headsmp.S | 66 +++++++++++
> arch/arm/mach-mvebu/hotplug.c | 30 +++++
> arch/arm/mach-mvebu/irq-armada-370-xp.c | 92 ++++++++++++++-
> arch/arm/mach-mvebu/platsmp.c | 124 ++++++++++++++++++++
> arch/arm/mach-mvebu/pmsu.c | 78 ++++++++++++
> arch/arm/mach-mvebu/pmsu.h | 16 +++
> arch/arm/mm/Kconfig | 4 +
> arch/arm/mm/proc-v7.S | 46 ++++++++
> 21 files changed, 648 insertions(+), 12 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
> create mode 100644 Documentation/devicetree/bindings/arm/coherency-fabric.txt
> create mode 100644 arch/arm/mach-mvebu/coherency.c
> create mode 100644 arch/arm/mach-mvebu/coherency.h
> create mode 100644 arch/arm/mach-mvebu/headsmp.S
> create mode 100644 arch/arm/mach-mvebu/hotplug.c
> create mode 100644 arch/arm/mach-mvebu/platsmp.c
> create mode 100644 arch/arm/mach-mvebu/pmsu.c
> create mode 100644 arch/arm/mach-mvebu/pmsu.h
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH V2 2/11] time: convert arch_gettimeoffset to a pointer
From: Stephen Warren @ 2012-11-12 20:51 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
Currently, whenever CONFIG_ARCH_USES_GETTIMEOFFSET is enabled, each
arch core provides a single implementation of arch_gettimeoffset(). In
many cases, different sub-architectures, different machines, or
different timer providers exist, and so the arch ends up implementing
arch_gettimeoffset() as a call-through-pointer anyway. Examples are
ARM, Cris, M68K, and it's arguable that the remaining architectures,
M32R and Blackfin, should be doing this anyway.
Modify arch_gettimeoffset so that it itself is a function pointer, which
the arch initializes. This will allow later changes to move the
initialization of this function into individual machine support or timer
drivers. This is particularly useful for code in drivers/clocksource
which should rely on an arch-independant mechanism to register their
implementation of arch_gettimeoffset().
This patch also converts the Cris architecture to set arch_gettimeoffset
directly to the final implementation in time_init(), because Cris already
had separate time_init() functions per sub-architecture. M68K and ARM
are converted to set arch_gettimeoffset the final implementation in later
patches, because they already have function pointers in place for this
purpose.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Hirokazu Takata <takata@linux-m32r.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2:
* s/gettimeoffset/get_arch_timeoffset/ to make the name less generic
and more arch-specific.
(Note: I've only reposted patch 2/11 this time around, and I still hope
to take it through the arm-soc tree due to dependencies, so I'm not
requesting this be applied by the timekeeping maintainers)
---
arch/arm/kernel/time.c | 6 +++++-
arch/blackfin/kernel/time.c | 6 +++++-
arch/cris/arch-v10/kernel/time.c | 6 ++++--
arch/cris/kernel/time.c | 11 -----------
arch/m32r/kernel/time.c | 4 +++-
arch/m68k/kernel/time.c | 16 ++++++++++------
include/linux/time.h | 4 +---
kernel/time/timekeeping.c | 26 ++++++++++++++++++++------
8 files changed, 48 insertions(+), 31 deletions(-)
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 09be0c3..b0190b4 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -70,7 +70,7 @@ EXPORT_SYMBOL(profile_pc);
#endif
#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
-u32 arch_gettimeoffset(void)
+static u32 arm_gettimeoffset(void)
{
if (system_timer->offset != NULL)
return system_timer->offset() * 1000;
@@ -164,6 +164,10 @@ device_initcall(timer_init_syscore_ops);
void __init time_init(void)
{
+#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
+ arch_gettimeoffset = arm_gettimeoffset;
+#endif
+
system_timer = machine_desc->timer;
system_timer->init();
sched_clock_postinit();
diff --git a/arch/blackfin/kernel/time.c b/arch/blackfin/kernel/time.c
index 2310b24..3126b92 100644
--- a/arch/blackfin/kernel/time.c
+++ b/arch/blackfin/kernel/time.c
@@ -85,7 +85,7 @@ time_sched_init(irqreturn_t(*timer_routine) (int, void *))
/*
* Should return useconds since last timer tick
*/
-u32 arch_gettimeoffset(void)
+static u32 blackfin_gettimeoffset(void)
{
unsigned long offset;
unsigned long clocks_per_jiffy;
@@ -141,6 +141,10 @@ void read_persistent_clock(struct timespec *ts)
void __init time_init(void)
{
+#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
+ arch_gettimeoffset = blackfin_gettimeoffset;
+#endif
+
#ifdef CONFIG_RTC_DRV_BFIN
/* [#2663] hack to filter junk RTC values that would cause
* userspace to have to deal with time values greater than
diff --git a/arch/cris/arch-v10/kernel/time.c b/arch/cris/arch-v10/kernel/time.c
index 162892f..fce7c54 100644
--- a/arch/cris/arch-v10/kernel/time.c
+++ b/arch/cris/arch-v10/kernel/time.c
@@ -55,9 +55,9 @@ unsigned long get_ns_in_jiffie(void)
return ns;
}
-unsigned long do_slow_gettimeoffset(void)
+static u32 cris_v10_gettimeoffset(void)
{
- unsigned long count;
+ u32 count;
/* The timer interrupt comes from Etrax timer 0. In order to get
* better precision, we check the current value. It might have
@@ -191,6 +191,8 @@ static struct irqaction irq2 = {
void __init
time_init(void)
{
+ arch_gettimeoffset = cris_v10_gettimeoffset;
+
/* probe for the RTC and read it if it exists
* Before the RTC can be probed the loops_per_usec variable needs
* to be initialized to make usleep work. A better value for
diff --git a/arch/cris/kernel/time.c b/arch/cris/kernel/time.c
index b063c92..fe6acda 100644
--- a/arch/cris/kernel/time.c
+++ b/arch/cris/kernel/time.c
@@ -39,17 +39,6 @@
extern unsigned long loops_per_jiffy; /* init/main.c */
unsigned long loops_per_usec;
-
-#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
-extern unsigned long do_slow_gettimeoffset(void);
-static unsigned long (*do_gettimeoffset)(void) = do_slow_gettimeoffset;
-
-u32 arch_gettimeoffset(void)
-{
- return do_gettimeoffset();
-}
-#endif
-
int set_rtc_mmss(unsigned long nowtime)
{
D(printk(KERN_DEBUG "set_rtc_mmss(%lu)\n", nowtime));
diff --git a/arch/m32r/kernel/time.c b/arch/m32r/kernel/time.c
index 84dd040..1a15f81 100644
--- a/arch/m32r/kernel/time.c
+++ b/arch/m32r/kernel/time.c
@@ -57,7 +57,7 @@ extern void smp_local_timer_interrupt(void);
static unsigned long latch;
-u32 arch_gettimeoffset(void)
+static u32 m32r_gettimeoffset(void)
{
unsigned long elapsed_time = 0; /* [us] */
@@ -165,6 +165,8 @@ void read_persistent_clock(struct timespec *ts)
void __init time_init(void)
{
+ arch_gettimeoffset = m32r_gettimeoffset;
+
#if defined(CONFIG_CHIP_M32102) || defined(CONFIG_CHIP_XNUX2) \
|| defined(CONFIG_CHIP_VDEC2) || defined(CONFIG_CHIP_M32700) \
|| defined(CONFIG_CHIP_OPSP) || defined(CONFIG_CHIP_M32104)
diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
index 5d0bcaa..c2994c8 100644
--- a/arch/m68k/kernel/time.c
+++ b/arch/m68k/kernel/time.c
@@ -80,14 +80,9 @@ void read_persistent_clock(struct timespec *ts)
}
}
-void __init time_init(void)
-{
- mach_sched_init(timer_interrupt);
-}
-
#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
-u32 arch_gettimeoffset(void)
+static u32 m68k_gettimeoffset(void)
{
return mach_gettimeoffset() * 1000;
}
@@ -106,3 +101,12 @@ static int __init rtc_init(void)
module_init(rtc_init);
#endif /* CONFIG_ARCH_USES_GETTIMEOFFSET */
+
+void __init time_init(void)
+{
+#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
+ arch_gettimeoffset = m68k_gettimeoffset;
+#endif
+
+ mach_sched_init(timer_interrupt);
+}
diff --git a/include/linux/time.h b/include/linux/time.h
index 4d358e9..05e32a7 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -142,9 +142,7 @@ void timekeeping_inject_sleeptime(struct timespec *delta);
* finer then tick granular time.
*/
#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
-extern u32 arch_gettimeoffset(void);
-#else
-static inline u32 arch_gettimeoffset(void) { return 0; }
+extern u32 (*arch_gettimeoffset)(void);
#endif
extern void do_gettimeofday(struct timeval *tv);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index e424970..00b58c7 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -140,6 +140,20 @@ static void tk_setup_internals(struct timekeeper *tk, struct clocksource *clock)
}
/* Timekeeper helper functions. */
+
+#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
+u32 (*arch_gettimeoffset)(void);
+
+u32 get_arch_timeoffset(void)
+{
+ if (likely(arch_gettimeoffset))
+ return arch_gettimeoffset();
+ return 0;
+}
+#else
+static inline u32 get_arch_timeoffset(void) { return 0; }
+#endif
+
static inline s64 timekeeping_get_ns(struct timekeeper *tk)
{
cycle_t cycle_now, cycle_delta;
@@ -156,8 +170,8 @@ static inline s64 timekeeping_get_ns(struct timekeeper *tk)
nsec = cycle_delta * tk->mult + tk->xtime_nsec;
nsec >>= tk->shift;
- /* If arch requires, add in gettimeoffset() */
- return nsec + arch_gettimeoffset();
+ /* If arch requires, add in get_arch_timeoffset() */
+ return nsec + get_arch_timeoffset();
}
static inline s64 timekeeping_get_ns_raw(struct timekeeper *tk)
@@ -176,8 +190,8 @@ static inline s64 timekeeping_get_ns_raw(struct timekeeper *tk)
/* convert delta to nanoseconds. */
nsec = clocksource_cyc2ns(cycle_delta, clock->mult, clock->shift);
- /* If arch requires, add in gettimeoffset() */
- return nsec + arch_gettimeoffset();
+ /* If arch requires, add in get_arch_timeoffset() */
+ return nsec + get_arch_timeoffset();
}
/* must hold write on timekeeper.lock */
@@ -210,8 +224,8 @@ static void timekeeping_forward_now(struct timekeeper *tk)
tk->xtime_nsec += cycle_delta * tk->mult;
- /* If arch requires, add in gettimeoffset() */
- tk->xtime_nsec += (u64)arch_gettimeoffset() << tk->shift;
+ /* If arch requires, add in get_arch_timeoffset() */
+ tk->xtime_nsec += (u64)get_arch_timeoffset() << tk->shift;
tk_normalize_xtime(tk);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ARM: implement optimized percpu variable access
From: Rob Herring @ 2012-11-12 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112165117.GB18863@mudshark.cambridge.arm.com>
On 11/12/2012 10:51 AM, Will Deacon wrote:
> On Mon, Nov 12, 2012 at 02:41:22PM +0000, Will Deacon wrote:
>> On Mon, Nov 12, 2012 at 02:21:27PM +0000, Rob Herring wrote:
>>> On 11/12/2012 04:23 AM, Will Deacon wrote:
>>>> Hi Rob,
>>>>
>>>> On Sun, Nov 11, 2012 at 03:20:40AM +0000, Rob Herring wrote:
>>>>> From: Rob Herring <rob.herring@calxeda.com>
>>>>>
>>>>> Use the previously unused TPIDRPRW register to store percpu offsets.
>>>>> TPIDRPRW is only accessible in PL1, so it can only be used in the kernel.
>>>>>
>>>>> This saves 2 loads for each percpu variable access which should yield
>>>>> improved performance, but the improvement has not been quantified.
>>>>
>>>> The patch looks largely fine to me (one minor comment below), but we should
>>>> try and see what the performance difference is like on a few cores before
>>>> merging this. Have you tried something like hackbench to see if the
>>>> difference is measurable there? If not, I guess we'll need something more
>>>> targetted.
>>>
>>> Looks like it's about a 1.4% improvement on Cortex-A9 (highbank) with
>>> hackbench.
>>>
>>> Average of 30 runs of "hackbench -l 1000":
>>>
>>> Before: 6.2190666667
>>> After: 6.1347666667
>>>
>>> I'll add this data to the commit msg.
>>
>> Wow, that's really cool! I'll take it for a spin on 11MPCore to test the v6
>> angle...
>
> Ok, similar numbers over here so it looks like this is definitely worth
> doing. However, I still object to the "cc", particularly after discussion
> with the tools guys here who agree that the behaviour you're seeing is
> indicative of a buggy compiler. It may even be part of a larger issue with
> GCC's definition of `reachability' for kernel entry points. For interest, I
> failed to reproduce with:
>
> gcc version 4.7.3 20121001 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2012.10-20121022 - Linaro GCC 2012.10)
> (http://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2)
>
> which sounds fairly close to the tools that you are using. Please can you
> file a bug in launchpad?
Strangely, I can't reproduce it either now...
Rob
^ permalink raw reply
* [PATCH 1/2] ARM: kirkwood: Add Plat'Home OpenBlocks A6 support
From: Nobuhiro Iwamatsu @ 2012-11-12 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112120535.GA22029@lunn.ch>
Hi, Andrew.
Thank you for your review.
On Mon, Nov 12, 2012 at 9:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> Hi Nobuhiro
>
> This is a good start. A few comments below.
>
> On Mon, Nov 12, 2012 at 08:46:59PM +0900, Nobuhiro Iwamatsu wrote:
>> Add support for Plat'Home OpenBlocks A6 using the device tree
>> where possible.
>> This commit supports SATA, USB, ether and serial console.
>>
>> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>> ---
>> arch/arm/boot/dts/Makefile | 3 +-
>> arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 39 ++++++++++++
>> arch/arm/configs/kirkwood_defconfig | 1 +
>> arch/arm/mach-kirkwood/Kconfig | 7 +++
>> arch/arm/mach-kirkwood/Makefile | 1 +
>> arch/arm/mach-kirkwood/board-dt.c | 4 ++
>> arch/arm/mach-kirkwood/board-openblocks_a6.c | 86 ++++++++++++++++++++++++++
>> arch/arm/mach-kirkwood/common.h | 6 ++
>> 8 files changed, 146 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/boot/dts/kirkwood-openblocks_a6.dts
>> create mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index b994045..ce053a4 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -41,7 +41,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
>> kirkwood-lschlv2.dtb \
>> kirkwood-lsxhl.dtb \
>> kirkwood-ts219-6281.dtb \
>> - kirkwood-ts219-6282.dtb
>> + kirkwood-ts219-6282.dtb \
>> + kirkwood-openblocks_a6.dtb
>> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
>> msm8960-cdp.dtb
>> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a6.dts b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
>> new file mode 100644
>> index 0000000..6493edc
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/kirkwood-openblocks_a6.dts
>> @@ -0,0 +1,39 @@
>> +/dts-v1/;
>> +
>> +/include/ "kirkwood.dtsi"
>> +
>> +/ {
>> + model = "Plat'Home OpenBlocksA6";
>> + compatible = "plathome,openblocks-a6", "marvell,kirkwood-88f6283", "marvell,kirkwood";
>
> Ah, interesting. A 88f6283. I'm a bit surprised this actually works!
> This variant is not listed in kirkwood_id(). So do you see messages
> like:
>
> "Device-Unknown"
>
> and
>
> "MPP setup: unknown kirkwood variant"
No, I can not see these message.
88f6283 is same as MV88F6282-Rev-A1. Because this has same CPU ID as
MV88F6282-Rev-A1.
What kind of value should I set here?
>
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x20000000>;
>> + };
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/nfs ip=bootp";
>
> Please remove root=/dev/nfs and ip=bootp. We want the box to boot on
> its own without help from the network.
>
This is my mistake.
I will fix.
>> + };
>> +
>> + ocp at f1000000 {
>> + serial at 12000 {
>> + clock-frequency = <200000000>;
>> + status = "ok";
>> + };
>> +
>> + serial at 12100 {
>> + clock-frequency = <200000000>;
>> + status = "ok";
>> + };
>> +
>> + nand at 3000000 {
>> + chip-delay = <25>;
>> + status = "ok";
>> + };
>> +
>> + sata at 80000 {
>> + nr-ports = <1>;
>> + status = "okay";
>> + };
>> + };
>> +};
>> diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
>> index 74eee0c..8b5988c 100644
>> --- a/arch/arm/configs/kirkwood_defconfig
>> +++ b/arch/arm/configs/kirkwood_defconfig
>> @@ -27,6 +27,7 @@ CONFIG_MACH_GOFLEXNET_DT=y
>> CONFIG_MACH_LSXL_DT=y
>> CONFIG_MACH_IOMEGA_IX2_200_DT=y
>> CONFIG_MACH_KM_KIRKWOOD_DT=y
>> +CONFIG_MACH_OPENBLOCKS_A6_DT=y
>> CONFIG_MACH_TS219=y
>> CONFIG_MACH_TS41X=y
>> CONFIG_MACH_DOCKSTAR=y
>> diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
>> index 50bca50..830bb5c 100644
>> --- a/arch/arm/mach-kirkwood/Kconfig
>> +++ b/arch/arm/mach-kirkwood/Kconfig
>> @@ -130,6 +130,13 @@ config MACH_KM_KIRKWOOD_DT
>> Say 'Y' here if you want your kernel to support the
>> Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
>>
>> +config MACH_OPENBLOCKS_A6_DT
>> + bool "Plat'Home OpenBlocks A6 (Flattened Device Tree)"
>> + select ARCH_KIRKWOOD_DT
>> + help
>> + Say 'Y' here if you want your kernel to support the
>> + Plat'Home OpenBlocks A6 (Flattened Device Tree).
>> +
>> config MACH_TS219
>> bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
>> help
>> diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
>> index 294779f..ee38f9d 100644
>> --- a/arch/arm/mach-kirkwood/Makefile
>> +++ b/arch/arm/mach-kirkwood/Makefile
>> @@ -31,3 +31,4 @@ obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
>> obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
>> obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT) += board-iomega_ix2_200.o
>> obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o
>> +obj-$(CONFIG_MACH_OPENBLOCKS_A6_DT) += board-openblocks_a6.o
>> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
>> index d94872f..c3aa0e2 100644
>> --- a/arch/arm/mach-kirkwood/board-dt.c
>> +++ b/arch/arm/mach-kirkwood/board-dt.c
>> @@ -94,6 +94,9 @@ static void __init kirkwood_dt_init(void)
>> if (of_machine_is_compatible("keymile,km_kirkwood"))
>> km_kirkwood_init();
>>
>> + if (of_machine_is_compatible("plathome,openblocks-a6"))
>> + openblocks_a6_init();
>> +
>> of_platform_populate(NULL, kirkwood_dt_match_table,
>> kirkwood_auxdata_lookup, NULL);
>> }
>> @@ -110,6 +113,7 @@ static const char *kirkwood_dt_board_compat[] = {
>> "buffalo,lsxl",
>> "iom,ix2-200",
>> "keymile,km_kirkwood",
>> + "plathome,openblocks-a6",
>> NULL
>> };
>>
>> diff --git a/arch/arm/mach-kirkwood/board-openblocks_a6.c b/arch/arm/mach-kirkwood/board-openblocks_a6.c
>> new file mode 100644
>> index 0000000..ee6f4c6
>> --- /dev/null
>> +++ b/arch/arm/mach-kirkwood/board-openblocks_a6.c
>> @@ -0,0 +1,86 @@
>> +/*
>> + * Copyright 2012 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>> + *
>> + * arch/arm/mach-kirkwood/board-openblocks_a6.c
>> + *
>> + * 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.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/mv643xx_eth.h>
>> +#include <linux/clk.h>
>> +#include <linux/clk-private.h>
>> +#include "common.h"
>> +#include "mpp.h"
>> +
>> +static struct mv643xx_eth_platform_data openblocks_ge00_data = {
>> + .phy_addr = MV643XX_ETH_PHY_ADDR(0),
>> +};
>> +
>> +static unsigned int openblocks_a6_mpp_config[] __initdata = {
>> + MPP0_NF_IO2,
>> + MPP1_NF_IO3,
>> + MPP2_NF_IO4,
>> + MPP3_NF_IO5,
>> + MPP4_NF_IO6,
>> + MPP5_NF_IO7,
>> + MPP6_SYSRST_OUTn,
>> + /* MPP7_GPO, */
>
> Any reason not to actually have MPP7_GPO here?
> Is it being used as a GPO line?
Yes. MPP7 is assigned to GPO in this target boatd.
And GPO is not used.
The following is also the same.
If unnecessary, I will delete these lines.
>
> Same question for all the other commented out GPIOs.
>
>> + MPP8_UART1_RTS,
>> + MPP9_UART1_CTS,
>> + MPP10_UART0_TXD,
>> + MPP11_UART0_RXD,
>> + /* MPP12_GPIO, */
>> + MPP13_UART1_TXD,
>> + MPP14_UART1_RXD,
>> + MPP15_UART0_RTS,
>> + MPP16_UART0_CTS,
>> + /* MPP17_GPIO, */
>> + MPP18_NF_IO0,
>> + MPP19_NF_IO1,
>> + MPP20_GPIO, /* CFG 0 */
>> + MPP21_GPIO, /* CFG 1 */
>> + MPP22_GPIO, /* CFG 2 */
>> + MPP23_GPIO, /* CFG 3 */
>
> Are these four above DIP switches?
Yes. I will change comment to DIP SW.
>
>> + MPP24_GPIO, /* GPIO 0 */
>> + MPP25_GPIO, /* GPIO 1 */
>> + MPP26_GPIO, /* GPIO 2 */
>> + MPP27_GPIO, /* GPIO 3 */
>> + MPP28_GPIO, /* GPIO 4 */
>> + MPP29_GPIO, /* GPIO 5 */
>> + MPP30_GPIO, /* GPIO 6 */
>> + MPP31_GPIO, /* GPIO 7 */
>> + /* MPP32_GPIO, */
>> + /* MPP33_GPO, */
>> + /* MPP34_GPIO, */
>> + /* MPP35_GPIO, */
>> + MPP36_TW1_SDA,
>> + MPP37_TW1_SCK,
>> + MPP38_GPIO, /* INIT */
>> + MPP39_GPIO, /* USB OC */
>> + /* MPP40_GPIO, */
>> + MPP41_GPIO, /* LED: Red */
>> + MPP42_GPIO, /* LED: Yellow */
>> + MPP43_GPIO, /* LED: Green */
>> + /* MPP44_GPIO, */
>> + /* MPP45_GPIO, */
>> + /* MPP46_GPIO, */
>> + /* MPP47_GPIO, */
>> + /* MPP48_GPIO, */
>> + /* MPP49_GPIO, */
>> + 0,
>> +};
>> +
>> +void __init openblocks_a6_init(void)
>> +{
>> + /*
>> + * Basic setup. Needs to be called early.
>> + */
>> + kirkwood_mpp_conf(openblocks_a6_mpp_config);
>> + kirkwood_uart0_init();
>
> You don't need this. The DT description is enough to get the uart
> working.
OK, I will remove.
>
>> + kirkwood_ehci_init();
>> + kirkwood_ge00_init(&openblocks_ge00_data);
>> +}
>> diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
>> index bcffd7c..0d0159e 100644
>> --- a/arch/arm/mach-kirkwood/common.h
>> +++ b/arch/arm/mach-kirkwood/common.h
>> @@ -112,6 +112,12 @@ void km_kirkwood_init(void);
>> static inline void km_kirkwood_init(void) {};
>> #endif
>>
>> +#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
>> +void openblocks_a6_init(void);
>> +#else
>> +static inline void openblocks_a6_init(void) {};
>> +#endif
>> +
>> /* early init functions not converted to fdt yet */
>> char *kirkwood_id(void);
>> void kirkwood_l2_init(void);
>> --
>> 1.7.10.4
>>
Thanks,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply
* [GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2
From: Arnd Bergmann @ 2012-11-12 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352446306-19945-1-git-send-email-horms@verge.net.au>
On Friday 09 November 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> please consider the following board enhancements for 3.8.
>
> * This pull request is based on a merge of
> a) The renesas/boards branch of the arm-soc tree
> b) The soc branch of the renesas tree,
> which I have sent a separate pull requst for
>
> * "sh: clkfwk: add sh_clk_fsidiv_register()" is a driver patch
> which is a dependency of
> - ARM: shmobile: sh7372: use sh_clk_fsidiv_register() for FSI-DIV clocks
> - ARM: shmobile: r8a7740: add FSI-DVI clocks
> I have spoken to the driver maintainer, Paul Mundt, and he has indicated
> that he thinks it is best to merge all in one go and acked the patch for
> inclusion in this pull-request.
>
> * The following patches
> - ARM: shmobile: use FSI driver's audio clock on ap4evb
> - ARM: shmobile: use FSI driver's audio clock on mackerel
> - ARM: shmobile: use FSI driver's audio clock on armadillo800eva
> Have a compile-time dependency on the following patch which is present in
> the for-next branch of Mark Brown's sound tree on kernel.org
> - ASoC: fsi: add master clock control functions
> (ab6f6d85210c4d0265cf48e9958c04e08595055a)
Hi Simon,
I've pulled this into a new next/boards2 branch because of the new dependency,
but I'm not entirely happy with the way that the dependency came in through
your tree.
It's generally ok to have external dependencies where they can't be avoided,
but please remember these rules:
* When you send a branch that has an external dependency, actually base your
branch on top of the other one, so that it can be independently verified.
If you have a dependency and send your patches without that one included,
it's clear that your code can't be tested in the version you are sending,
and it breaks any attempt to test just the arm-soc tree or your branch
rather than the entire for-next tree.
* Make sure that the branch you depend on will not get rebased before it
gets submitted to the mainline kernel.
* Always let the person that owns the dependency know that the changes in
their tree are also included elsewhere and that things go bad if those
changes get rebased after all, or won't make it into the merge window
for some reason.
I have taken Mark on Cc to let him know about the dependency now, and I've
merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
specific ASoC patches) into the next/boards2 branch before merging your
branch. This is still not perfect because it breaks bisection, but it's
the best I could do aside from forcing you do do another round-trip.
Arnd
^ permalink raw reply
* [PATCH] clk: spear: Add stub functions for spear3[0|1|2]0_clk_init()
From: Mike Turquette @ 2012-11-12 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x==ng3A66P=Vx+-C791LTGCS1fWVpMfUKDorU5G=ZXrjLQ@mail.gmail.com>
Quoting viresh kumar (2012-11-05 19:36:18)
> On Tue, Nov 6, 2012 at 8:04 AM, Axel Lin <axel.lin@ingics.com> wrote:
> > This fixes compile error if one of SPEAr3xx implementations is not selected.
> >
> > CC drivers/clk/spear/spear3xx_clock.o
> > drivers/clk/spear/spear3xx_clock.c: In function 'spear3xx_clk_init':
> > drivers/clk/spear/spear3xx_clock.c:599:3: error: implicit declaration of function 'spear300_clk_init' [-Werror=implicit-function-declaration]
> > drivers/clk/spear/spear3xx_clock.c:601:3: error: implicit declaration of function 'spear310_clk_init' [-Werror=implicit-function-declaration]
> > drivers/clk/spear/spear3xx_clock.c:603:3: error: implicit declaration of function 'spear320_clk_init' [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> > make[3]: *** [drivers/clk/spear/spear3xx_clock.o] Error 1
> > make[2]: *** [drivers/clk/spear] Error 2
> > make[1]: *** [drivers/clk] Error 2
> > make: *** [drivers] Error 2
> >
> > Signed-off-by: Axel Lin <axel.lin@ingics.com>
>
> Thanks..
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Taken into clk-next.
Thanks,
Mike
^ permalink raw reply
* [PATCH 1/2] ARM: kirkwood: Add Plat'Home OpenBlocks A6 support
From: Andrew Lunn @ 2012-11-12 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABMQnVK5SbT5mbugruZdNursXQiWJOQD4sreEMS1v6GO7PH0mw@mail.gmail.com>
Hi Nobuhiro
> >> + model = "Plat'Home OpenBlocksA6";
> >> + compatible = "plathome,openblocks-a6", "marvell,kirkwood-88f6283", "marvell,kirkwood";
> >
> > Ah, interesting. A 88f6283. I'm a bit surprised this actually works!
> > This variant is not listed in kirkwood_id(). So do you see messages
> > like:
> >
> > "Device-Unknown"
> >
> > and
> >
> > "MPP setup: unknown kirkwood variant"
>
> No, I can not see these message.
> 88f6283 is same as MV88F6282-Rev-A1. Because this has same CPU ID as
> MV88F6282-Rev-A1.
Ah. O.K.
Is it pin compatible? Please take a look at
https://github.com/lunn/linux/blob/v3.7-rc2-pinctrl-v2/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
and see if what is valid for 88f6282 is also valid for 88f6283.
If its not compatible, we need to add this variant to the table.
> What kind of value should I set here?
For the moment, keep to 88f6283. At the moment its not actually used.
However, when we add pinctrl we will need to this about this some
more, depending on if its pin compatible or not.
> >> +static unsigned int openblocks_a6_mpp_config[] __initdata = {
> >> + MPP0_NF_IO2,
> >> + MPP1_NF_IO3,
> >> + MPP2_NF_IO4,
> >> + MPP3_NF_IO5,
> >> + MPP4_NF_IO6,
> >> + MPP5_NF_IO7,
> >> + MPP6_SYSRST_OUTn,
> >> + /* MPP7_GPO, */
> >
> > Any reason not to actually have MPP7_GPO here?
> > Is it being used as a GPO line?
>
> Yes. MPP7 is assigned to GPO in this target boatd.
> And GPO is not used.
> The following is also the same.
> If unnecessary, I will delete these lines.
If they are not used, i would not list them.
Thanks for the quick response.
Andrew
^ permalink raw reply
* [PATCH 0/7] ARM: remove init_consistent_dma_size() stub
From: Arnd Bergmann @ 2012-11-12 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352360783-17523-1-git-send-email-m.szyprowski@samsung.com>
On Thursday 08 November 2012, Marek Szyprowski wrote:
> Commit e9da6e9905e639b0 ("ARM: dma-mapping: remove custom consistent dma
> region") replaced custom consistent memory handling, so setting
> consistent dma memory size is not longer required. This patch series
> cleans sub-architecture platform code to remove all calls to the
> obsolated init_consistent_dma_size() function and finally removes the
> init_consistent_dma_size() stub itself.
>
> Arnd, Olof: could You apply it to arm-soc cleanup branch?
>
Applied patches 2-7 to next/cleanup branch, with the Acks that came in.
Thanks,
Arnd
^ permalink raw reply
* possibility of parent clock selection through DT
From: Mike Turquette @ 2012-11-12 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPub148Bq=uwTuky25WzXn4yfCukJ+WacxkBvuyV5yTzGasGOQ@mail.gmail.com>
Quoting Shiraz Hashim (2012-11-06 22:36:10)
> On Wed, Nov 7, 2012 at 11:42 AM, Shiraz Hashim
> <shiraz.linux.kernel@gmail.com> wrote:
> > Hi Mike, Rob,
> >
> > Devices in a SoC can have multiple possible clock sources which is
> > perfectly captured through clk framework.
> >
> > But the device itself may not be aware of the complex hierarchy above it.
> > In this case how do you suggest a board (through DT) should select its
> > preference.
> >
> > Is there some work already going on in this direction ?
>
> Just to make it clear, I already have referred the clock DT bindings and
> Shawn Guo patch on removing clk look up registration from kernel code.
>
> Here I am talking about possibility of selecting desired clock hierarchy
> by the boards about which device nodes are not aware.
>
One way to achieve this is to use clk_set_rate as a way to switch
parents at run-time. The OMAP CCF code currently does this when
relocking PLLs and makes use of __clk_reparent to update the clock
framework's representation of the hierarchy dynamically.
Maybe something like the following is helpful to you:
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=arch/arm/mach-omap2/dpll3xxx.c;h=f72dedb4eee892ce4cd5bdf22cc8c22510f3d526;hb=clk-omap-3.8#l542
Regards,
Mike
> --
> regards
> Shiraz Hashim
^ permalink raw reply
* [PATCH 12/11] ARM: OMAP: Fix relative includes for fpga.h
From: Tony Lindgren @ 2012-11-12 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A0D3C6.4070206@ti.com>
* Benoit Cousson <b-cousson@ti.com> [121112 02:49]:
> Hi Tony,
>
> After rebasing on top of your omap-for-v3.8/tmp-merge, I realized that this patch is generating a build break due to removal of the fpga.h include from debug-leds.c.
>
> arch/arm/plat-omap/debug-leds.c: In function 'fpga_probe':
> arch/arm/plat-omap/debug-leds.c:114:9: error: 'H2P2_DBG_FPGA_SIZE' undeclared (first use in this function)
> arch/arm/plat-omap/debug-leds.c:114:9: note: each undeclared identifier is reported only once for each function it appears in
>
> It does not appear with the omap2plus_config but will appear if you enable the NEW_LEDS support that enable OMAP_DEBUG_LEDS.
>
> I'm not sure why the size is still hard coded. In theory, assuming the resource is properly initialized, resource_size should be usable.
> The patch below is fixing that.
Thanks looks like I missed that one. Applying into
omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3.
Regards,
Tony
^ permalink raw reply
* [PATCH V2 2/11] time: convert arch_gettimeoffset to a pointer
From: John Stultz @ 2012-11-12 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352753462-2915-1-git-send-email-swarren@wwwdotorg.org>
On 11/12/2012 12:51 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Currently, whenever CONFIG_ARCH_USES_GETTIMEOFFSET is enabled, each
> arch core provides a single implementation of arch_gettimeoffset(). In
> many cases, different sub-architectures, different machines, or
> different timer providers exist, and so the arch ends up implementing
> arch_gettimeoffset() as a call-through-pointer anyway. Examples are
> ARM, Cris, M68K, and it's arguable that the remaining architectures,
> M32R and Blackfin, should be doing this anyway.
>
> Modify arch_gettimeoffset so that it itself is a function pointer, which
> the arch initializes. This will allow later changes to move the
> initialization of this function into individual machine support or timer
> drivers. This is particularly useful for code in drivers/clocksource
> which should rely on an arch-independant mechanism to register their
> implementation of arch_gettimeoffset().
>
> This patch also converts the Cris architecture to set arch_gettimeoffset
> directly to the final implementation in time_init(), because Cris already
> had separate time_init() functions per sub-architecture. M68K and ARM
> are converted to set arch_gettimeoffset the final implementation in later
> patches, because they already have function pointers in place for this
> purpose.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Mike Frysinger <vapier@gentoo.org>
> Cc: Mikael Starvik <starvik@axis.com>
> Cc: Hirokazu Takata <takata@linux-m32r.org>
> Cc: John Stultz <johnstul@us.ibm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> v2:
> * s/gettimeoffset/get_arch_timeoffset/ to make the name less generic
> and more arch-specific.
>
> (Note: I've only reposted patch 2/11 this time around, and I still hope
> to take it through the arm-soc tree due to dependencies, so I'm not
> requesting this be applied by the timekeeping maintainers)
One last thing to watch out for: If you're trying to build a kernel that
mixes clocksource support with get_arch_timeoffset, you'll need to
rework the #ifdef in update_wall_time(), since we currently assume with
get_arch_timeoffset() that you're using tick + interpolation, so every
call to update_wall_time() only moves time forward by one jiffy.
Otherwise, thanks for the name tweak. Going through the arm-soc tree is
fine with me.
Acked-by: John Stultz <johnstul@us.ibm.com>
thanks
-john
^ permalink raw reply
* [GIT PULL] Ux500 pin changes
From: Arnd Bergmann @ 2012-11-12 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYjEmQRU530N3sP7t_RfM_NLhEcMf6YCBdf4LC7M7fQDQ@mail.gmail.com>
On Thursday 08 November 2012, Linus Walleij wrote:
> Hi ARM SoC guys,
>
> here is a set of pinctrl table patches all just hitting one and the same ux500
> file. Description in the signed tag, intended for v3.8.
>
> Please pull them in!
Pulled into next/drivers. Thanks,
Arnd
^ permalink raw reply
* [PATCH V3 00/13] ARM: OMAP: DMTIMER fixes
From: Jon Hunter @ 2012-11-12 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112203440.GL6801@atomide.com>
On 11/12/2012 02:34 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [121112 10:22]:
>> This series includes several fixes for the OMAP DMTIMER driver. This is
>> based upon Tony Lindgren's current master branch [1].
>
> You should be able to use omap-for-v3.8/dt as the base now with
> the cleanup merged there. The master branch is just a merge of the
> various topic branches, and can't be used as a base for pull requests.
Ok, great will base on top of that branch.
Cheers
Jon
^ permalink raw reply
* [PATCH] [TRIVIAL] ARM: cns3xxx: drop unnessesary symbol selection
From: Arnd Bergmann @ 2012-11-12 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352353029-2725-1-git-send-email-kaloz@openwrt.org>
On Thursday 08 November 2012, Imre Kaloz wrote:
> ARCH_CNS3XXX already selects MIGHT_HAVE_PCI, so boards don't have to
>
> Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Applied on next/fixes-non-critical branch, with the subject line fixup.
Thanks,
Arnd
^ permalink raw reply
* [PATCH 7/7] ARM i.MX51 babbage: Add display support
From: Martin Fuzzey @ 2012-11-12 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352733809-27230-8-git-send-email-s.hauer@pengutronix.de>
Hi Sascha,
On Mon, Nov 12, 2012 at 4:23 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> + display at di1 {
> + compatible = "fsl,imx-parallel-display";
> + crtcs = <&ipu 1>;
This works but Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
says "crtc" (without the s). Looks like the doc has a typo.
I ran into that problem today on i.MX53
Regards,
Martin
^ permalink raw reply
* [GIT PULL 1/1] omap fixes for v3.7-rc4
From: Arnd Bergmann @ 2012-11-12 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <pull-1352308631-821072>
On Wednesday 07 November 2012, Tony Lindgren wrote:
> The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
>
> Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc4/fixes-signed
>
> for you to fetch changes up to 5dfcb3b58c6c8934dec8898827736a1e26732cdd:
>
> Merge tag 'omap-fixes-b2-for-3.7-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.7-rc4/fixes (2012-11-06 09:55:20 -0800)
>
Pulled into fixes branch, sorry for the delay.
Arnd
^ 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