* Booting vanilla kernel on the beaglebone
From: Richard Cochran @ 2012-10-09 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9F27CE@DBDE01.ent.ti.com>
On Tue, Oct 09, 2012 at 04:27:03PM +0000, N, Mugunthan V wrote:
>
> I have implemented the CPTS hardware clock and will be submitting the
> patches soon to TI's kernel repo and also planning to submit the patches
> to Mainline kernel mailing lists soon.
I did see the stuff you added into arago for the DM814x, but it didn't
look correct to me.
Anyhow, I went ahead and wrote my own from stratch, based on the
AM335XPSP_04.06.00.08 branch, and it is working well. So go ahead and
post your driver, and I'll post mine, and we can go from there.
Right now, I can't for the life of me get a mainline kernel to boot on
the beaglebone, so I think we should focus on getting the mainline
support on the am335x stable before adding new drivers.
Thanks,
Richard
^ permalink raw reply
* [PATCH] pinctrl: sirf: remove sirfsoc_gpio_set_pull function
From: Barry Song @ 2012-10-09 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091535.56487.arnd@arndb.de>
Hi Arnd,
2012/10/9 Arnd Bergmann <arnd@arndb.de>:
> The prima2 platform advertises needing no mach/gpio.h header file,
> but its pinctrl driver now has a sirfsoc_gpio_set_pull function
> that uses constants defined in arch/arm/mach-prima2/include/mach/gpio.h,
> which fails to build.
>
> Fortunately, the sirfsoc_gpio_set_pull is not used anywhere in the
> kernel, so we can safely remove it. Any out of tree drivers using
> it will have to be converted to use proper pinctrl functions to
> do the same.
>
i understand we want to delete the mach/gpio.h. originally we had
sirfsoc_gpio_set_pull() as a prima2 customized pull config function.
i will take care moving to the dt mapping for pullup/down/none.
> Without this patch, building prima2_defconfig results in:
>
> drivers/pinctrl/pinctrl-sirf.c: In function 'sirfsoc_gpio_set_pull':
> drivers/pinctrl/pinctrl-sirf.c:1331:7: error: 'SIRFSOC_GPIO_PULL_NONE' undeclared (first use in this function)
> drivers/pinctrl/pinctrl-sirf.c:1331:7: note: each undeclared identifier is reported only once for each function it appears in
> drivers/pinctrl/pinctrl-sirf.c:1334:7: error: 'SIRFSOC_GPIO_PULL_UP' undeclared (first use in this function)
> drivers/pinctrl/pinctrl-sirf.c:1338:7: error: 'SIRFSOC_GPIO_PULL_DOWN' undeclared (first use in this function)
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Barry Song <Baohua.Song@csr.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Barry Song <Baohua.Song@csr.com>
>
> diff --git a/arch/arm/mach-prima2/include/mach/gpio.h b/arch/arm/mach-prima2/include/mach/gpio.h
> deleted file mode 100644
> index 1904bb0..0000000
> --- a/arch/arm/mach-prima2/include/mach/gpio.h
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -#ifndef __MACH_GPIO_H
> -#define __MACH_GPIO_H
> -
> -/* Pull up/down values */
> -enum sirfsoc_gpio_pull {
> - SIRFSOC_GPIO_PULL_NONE,
> - SIRFSOC_GPIO_PULL_UP,
> - SIRFSOC_GPIO_PULL_DOWN,
> -};
> -
> -void sirfsoc_gpio_set_pull(unsigned gpio, unsigned mode);
> -
> -#endif
> diff --git a/drivers/pinctrl/pinctrl-sirf.c b/drivers/pinctrl/pinctrl-sirf.c
> index 675497c..9ecacf3 100644
> --- a/drivers/pinctrl/pinctrl-sirf.c
> +++ b/drivers/pinctrl/pinctrl-sirf.c
> @@ -1323,41 +1323,6 @@ static inline struct sirfsoc_gpio_bank *sirfsoc_gpio_to_bank(unsigned int gpio)
> return &sgpio_bank[gpio / SIRFSOC_GPIO_BANK_SIZE];
> }
>
> -void sirfsoc_gpio_set_pull(unsigned gpio, unsigned mode)
> -{
> - struct sirfsoc_gpio_bank *bank = sirfsoc_gpio_to_bank(gpio);
> - int idx = sirfsoc_gpio_to_offset(gpio);
> - u32 val, offset;
> - unsigned long flags;
> -
> - offset = SIRFSOC_GPIO_CTRL(bank->id, idx);
> -
> - spin_lock_irqsave(&sgpio_lock, flags);
> -
> - val = readl(bank->chip.regs + offset);
> -
> - switch (mode) {
> - case SIRFSOC_GPIO_PULL_NONE:
> - val &= ~SIRFSOC_GPIO_CTL_PULL_MASK;
> - break;
> - case SIRFSOC_GPIO_PULL_UP:
> - val |= SIRFSOC_GPIO_CTL_PULL_MASK;
> - val |= SIRFSOC_GPIO_CTL_PULL_HIGH;
> - break;
> - case SIRFSOC_GPIO_PULL_DOWN:
> - val |= SIRFSOC_GPIO_CTL_PULL_MASK;
> - val &= ~SIRFSOC_GPIO_CTL_PULL_HIGH;
> - break;
> - default:
> - break;
> - }
> -
> - writel(val, bank->chip.regs + offset);
> -
> - spin_unlock_irqrestore(&sgpio_lock, flags);
> -}
> -EXPORT_SYMBOL(sirfsoc_gpio_set_pull);
> -
> static inline struct sirfsoc_gpio_bank *sirfsoc_irqchip_to_bank(struct gpio_chip *chip)
> {
> return container_of(to_of_mm_gpio_chip(chip), struct sirfsoc_gpio_bank, chip);
-barry
^ permalink raw reply
* [PATCH] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Stephen Warren @ 2012-10-09 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009150517.GA26952@kw.sim.vm.gnt>
On 10/09/2012 09:05 AM, Simon Guinot wrote:
> On Thu, Oct 04, 2012 at 09:41:06AM -0600, Stephen Warren wrote:
>> On 10/04/2012 01:53 AM, Simon Guinot wrote:
>>> On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
>>>>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++
>>>>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@
>>>>>>> static void __init kirkwood_dt_init(void) if
>>>>>>> (of_machine_is_compatible("keymile,km_kirkwood"))
>>>>>>> km_kirkwood_init();
>>>>>>>
>>>>>>> + if (of_machine_is_compatible("lacie,inetspace_v2") ||
>>>>>>> + of_machine_is_compatible("lacie,netspace_v2") || +
>>>>>>> of_machine_is_compatible("lacie,netspace_max_v2")) +
>>>>>>> ns2_init(); + of_platform_populate(NULL,
>>>>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup,
>>>>>>> NULL);
>>>>>>
>>>>>> I'm not a DT policy expert. Could this be one
>>>>>> compatibility string for all the boards? Maybe ask on the
>>>>>> DT mainline list?
>>>>>
>>>>> Maybe I could use "lacie,ns2_common" as a compatibility
>>>>> string. But this does not match any existing device. I
>>>>> don't know if it is correct.
...
>>> The status for this ns2 boards is more or less end-of-life. I
>>> mean, this boards are no longer in production. So I think it is
>>> safe to consider the code inside board-ns2.c as common and
>>> shareable between ns2, is2 and ns2max.
>>>
>>> Once this file will be removed, the compatibility checks will
>>> be removed as well. But one could easily forget to remove the
>>> useless compatibility string "lacie,ns2_common" from the
>>> dts...
>>
>> If that value is added to the DT, it should not be removed, and
>> the kernel should continue to support it indefinitely.
>
> I understand it is a strong requirement. But as I mentioned before,
> due to the production process, one could easily end up with an
> embedded DTB not matching exactly the hardware. It could even be
> worse. A end-of-life device could be replaced by a supposed
> compatible one. And sometimes the compatibility assumption is
> false. In a such scenario, maybe you don't want the kernel to
> support indefinitely a DT statement.
I'm not sure I fully understand that last paragraph. However, if the
board is replaced by a new board model, and that new board model is
not 100% SW-compatible with the old model, then you'll want to invent
a new compatible value to represent the new board version. Removing
support from the kernel for the old compatible value, or keeping the
same compatible value and changing how the kernel handles it in a way
that prevents the original board and .dts from working, is not
appropriate.
^ permalink raw reply
* Booting vanilla kernel on the beaglebone
From: N, Mugunthan V @ 2012-10-09 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50740AB0.7080102@ti.com>
> -------- Original Message --------
> Subject: Booting vanilla kernel on the beaglebone
> Date: Sun, 30 Sep 2012 10:28:02 +0200
> From: Richard Cochran <richardcochran@gmail.com>
> To: <linux-arm-kernel@lists.infradead.org>
>
>
> I just received by very own beaglebone, and I would like to add PTP
> hardware clock support for the CPTS unit, but I naturally want to do
> this with the latest mainstream kernel and not the hacked up arago 3.2
> kernel that ships with the board.
>
> Does any vanilla kernel even boot on this board?
> If so, which ones, and how?
>
> I have tried a few variations of kernel/u-boot without any luck.
> The u-boot that came with the board is
>
> U-Boot 2011.09-00000-gf63b270-dirty (Apr 24 2012 - 09:51:01)
> arm-angstrom-linux-gnueabi-gcc (GCC) 4.5.4 20120305 (prerelease)
> GNU ld (GNU Binutils) 2.20.1.20100303
>
> and I also tried the latest version:
>
> U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
> arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q1-203) 4.3.3
> GNU ld (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205
>
Richard
I have implemented the CPTS hardware clock and will be submitting the
patches soon to TI's kernel repo and also planning to submit the patches
to Mainline kernel mailing lists soon.
Regards
Mugunthan V N
> Thanks,
> Richard
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* [PATCH] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Stephen Warren @ 2012-10-09 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009111701.GQ11837@lunn.ch>
On 10/09/2012 05:17 AM, Andrew Lunn wrote:
>>>> The question is, what is the appropriate name. How common is
>>>> this common C code? Are there ns2 where this C code is not
>>>> appropriate. One thing to remember is that most of this C code
>>>> will soon disappear and become DT. All the mpp will be replaced
>>>> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT
>>>> as well. You are working on ns2_led, so all the C code will be
>>>> replaced by DT. So all we are really left with is power off GPIO
>>>> handling.
>>>>
>>>> So i think the danger of using lacie,ns2_common, and then finding
>>>> it does not work with some other ns2 device is quite low.
>>
>> lacie,ns2_common doesn't sound like a HW description, but rather a SW
>> invention. DT should be describing purely the HW. If there's no common
>> HW between these compatible boards (which seems unlikely), then there
>> shouldn't be a shared compatible value.
>
> Actually, there is common hardware between these boards:
>
> NS2 LED driver
> Pinctrl setup
> GPIO used for power off
> Ethernet configuration.
>
> At the moment, we don't have DT for these, so there is C code. The
> "lacie,ns2_common" compatibility string would be used to enable this C
> code for these boards.
The typical way to support this is to simply include a .dtsi file from
both board-specific .dts file. That .dtsi file will provide the
description of the two common pieces of hardware.
In the interim where you're stilling using some board file C code rather
than DT for this common part, just trigger that C code from any of the
compatible values for the boards where it's needed. Don't invent a new
compatible value that means "run this C code".
^ permalink raw reply
* ARM_ATAG_DTB_COMPAT fails on fdt_ro.c compiling
From: Fabio Estevam @ 2012-10-09 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50744DBA.3070900@wwwdotorg.org>
On Tue, Oct 9, 2012 at 1:15 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> I just tried building mainline now. It is at commit f5a246eab9.
>>>
>> The build still fails for me at this commit.
>
> I can't reproduce this.
Same here. It builds fine for me.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 2/9] ARM: export set_irq_flags
From: Thomas Gleixner @ 2012-10-09 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-3-git-send-email-arnd@arndb.de>
On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> The recently added Emma Mobile GPIO driver calls set_irq_flags
> and irq_set_chip_and_handler for the interrupts it exports and
> it can be built as a module, which currently fails with
>
> ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!
>
> We either need to replace the call to set_irq_flags with something
> else or export that function. This patch does the latter.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Magnus Damm <damm@opensource.se>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by-me
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> arch/arm/kernel/irq.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index 16cedb4..8961650 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -34,6 +34,7 @@
> #include <linux/list.h>
> #include <linux/kallsyms.h>
> #include <linux/proc_fs.h>
> +#include <linux/export.h>
>
> #include <asm/exception.h>
> #include <asm/mach/arch.h>
> @@ -109,6 +110,7 @@ void set_irq_flags(unsigned int irq, unsigned int iflags)
> /* Order is clear bits in "clr" then set bits in "set" */
> irq_modify_status(irq, clr, set & ~clr);
> }
> +EXPORT_SYMBOL_GPL(set_irq_flags);
>
> void __init init_IRQ(void)
> {
> --
> 1.7.10
>
>
^ permalink raw reply
* ARM_ATAG_DTB_COMPAT fails on fdt_ro.c compiling
From: Stephen Warren @ 2012-10-09 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009050109.GD21822@S2101-09.ap.freescale.net>
On 10/08/2012 11:01 PM, Shawn Guo wrote:
> On Tue, Oct 09, 2012 at 12:25:44AM -0400, Nicolas Pitre wrote:
>> On Tue, 9 Oct 2012, Shawn Guo wrote:
>>
>>> I have seen this error on mainline for a couple days when
>>> ARM_ATAG_DTB_COMPAT is enabled.
>>>
>>> CC arch/arm/boot/compressed/fdt_ro.o
>>> arch/arm/boot/compressed/fdt_ro.c: In function ?fdt_path_offset?:
>>> arch/arm/boot/compressed/fdt_ro.c:172:3: error: implicit declaration of function ?fdt_get_alias_namelen? [-Werror=implicit-function-declaration]
>>> arch/arm/boot/compressed/fdt_ro.c:172:5: warning: assignment makes pointer from integer without a cast [enabled by default]
>>> arch/arm/boot/compressed/fdt_ro.c: At top level:
>>> arch/arm/boot/compressed/fdt_ro.c:340:13: error: conflicting types for ?fdt_get_alias_namelen?
>>> arch/arm/boot/compressed/fdt_ro.c:172:7: note: previous implicit declaration of ?fdt_get_alias_namelen? was here
>>> cc1: some warnings being treated as errors
>>
>> I just tried building mainline now. It is at commit f5a246eab9.
>>
> The build still fails for me at this commit.
I can't reproduce this.
I tried both my local next-20121005-based dev branch and that exact
commit above. I tried both the crosstool-ng-based compiler I normally
use and Ubuntu 10.04's ARM compiler (possibly from a PPA). In both
cases, I ran git clean -f -d -x ; git reset --hard HEAD first, and then
build zImage, dtbs, and modules, and of course used your attached .config.
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Ian Campbell @ 2012-10-09 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091539.46274.arnd@arndb.de>
On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Ian Campbell wrote:
> > > * The tmem hypercall is not available on ARM
> > >
> > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> >
> > missing the end of this sentence?
>
> Right, I meant to say
>
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> Xen grant table code, so we must ensure that Xen support is only built
> on ARMv7-only kernels not combined ARMv6/v7 kernels.
>
> This should be fixed differently in the future.
Is this is a build time failure because gcc/gas/etc refuses to generate
these instructions if it is configured for v6?
I ask because if it is only a runtime issue then we can reason that if
we are running Xen specific grant table code, then we must be running on
Xen and therefore must necessarily be running on a v7 (because Xen only
support v7+virt extensions) even if the kernel happens to be capable of
running on v6 too.
Ian.
^ permalink raw reply
* [PATCH v4] GPIO: Add support for GPIO on CLPS711X-target platform
From: Russell King - ARM Linux @ 2012-10-09 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349798756-24777-1-git-send-email-shc_work@mail.ru>
On Tue, Oct 09, 2012 at 08:05:56PM +0400, Alexander Shiyan wrote:
> The CLPS711X CPUs provide some GPIOs for use in the system. This
> driver provides support for these via gpiolib. Due to platform
> limitations, driver does not support interrupts, only inputs and
> outputs.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
This is much better, thanks. As it's going via someone elses tree:
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/mach-clps711x/include/mach/gpio.h | 13 +++
> drivers/gpio/Kconfig | 4 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-clps711x.c | 163 ++++++++++++++++++++++++++++
> 5 files changed, 182 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-clps711x/include/mach/gpio.h
> create mode 100644 drivers/gpio/gpio-clps711x.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2867a77..343b0c3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -352,6 +352,7 @@ config ARCH_CLPS711X
> bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
> select CPU_ARM720T
> select ARCH_USES_GETTIMEOFFSET
> + select ARCH_REQUIRE_GPIOLIB
> select COMMON_CLK
> select CLKDEV_LOOKUP
> select NEED_MACH_MEMORY_H
> diff --git a/arch/arm/mach-clps711x/include/mach/gpio.h b/arch/arm/mach-clps711x/include/mach/gpio.h
> new file mode 100644
> index 0000000..8ac6889
> --- /dev/null
> +++ b/arch/arm/mach-clps711x/include/mach/gpio.h
> @@ -0,0 +1,13 @@
> +/*
> + * This file contains the CLPS711X GPIO definitions.
> + *
> + * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +/* Simple helper for convert port & pin to GPIO number */
> +#define CLPS711X_GPIO(port, bit) ((port) * 8 + (bit))
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index d055cee..fb76140 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -91,6 +91,10 @@ config GPIO_MAX730X
>
> comment "Memory mapped GPIO drivers:"
>
> +config GPIO_CLPS711X
> + def_bool y
> + depends on ARCH_CLPS711X
> +
> config GPIO_GENERIC_PLATFORM
> tristate "Generic memory-mapped GPIO controller support (MMIO platform device)"
> select GPIO_GENERIC
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 9aeed67..a28725e 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
> obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
> obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
> obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
> +obj-$(CONFIG_GPIO_CLPS711X) += gpio-clps711x.o
> obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
> obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
> obj-$(CONFIG_ARCH_DAVINCI) += gpio-davinci.o
> diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
> new file mode 100644
> index 0000000..ea21822
> --- /dev/null
> +++ b/drivers/gpio/gpio-clps711x.c
> @@ -0,0 +1,163 @@
> +/*
> + * CLPS711X GPIO driver
> + *
> + * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/gpio.h>
> +#include <linux/module.h>
> +#include <linux/spinlock.h>
> +#include <linux/platform_device.h>
> +
> +#include <mach/hardware.h>
> +
> +#define CLPS711X_GPIO_PORTS 5
> +#define CLPS711X_GPIO_NAME "gpio-clps711x"
> +
> +struct clps711x_gpio {
> + struct gpio_chip chip[CLPS711X_GPIO_PORTS];
> + spinlock_t lock;
> +};
> +
> +static void __iomem *clps711x_ports[] = {
> + CLPS711X_VIRT_BASE + PADR,
> + CLPS711X_VIRT_BASE + PBDR,
> + CLPS711X_VIRT_BASE + PCDR,
> + CLPS711X_VIRT_BASE + PDDR,
> + CLPS711X_VIRT_BASE + PEDR,
> +};
> +
> +static void __iomem *clps711x_pdirs[] = {
> + CLPS711X_VIRT_BASE + PADDR,
> + CLPS711X_VIRT_BASE + PBDDR,
> + CLPS711X_VIRT_BASE + PCDDR,
> + CLPS711X_VIRT_BASE + PDDDR,
> + CLPS711X_VIRT_BASE + PEDDR,
> +};
> +
> +#define clps711x_port(x) clps711x_ports[x->base / 8]
> +#define clps711x_pdir(x) clps711x_pdirs[x->base / 8]
> +
> +static int gpio_clps711x_get(struct gpio_chip *chip, unsigned offset)
> +{
> + return !!readb(clps711x_port(chip)) & (1 << offset);
> +}
> +
> +static void gpio_clps711x_set(struct gpio_chip *chip, unsigned offset,
> + int value)
> +{
> + int tmp;
> + unsigned long flags;
> + struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> + tmp = readb(clps711x_port(chip)) & ~(1 << offset);
> + if (value)
> + tmp |= 1 << offset;
> + writeb(tmp, clps711x_port(chip));
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +}
> +
> +static int gpio_clps711x_direction_in(struct gpio_chip *chip, unsigned offset)
> +{
> + int tmp;
> + unsigned long flags;
> + struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> + tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
> + writeb(tmp, clps711x_pdir(chip));
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +
> + return 0;
> +}
> +
> +static int gpio_clps711x_direction_out(struct gpio_chip *chip, unsigned offset,
> + int value)
> +{
> + int tmp;
> + unsigned long flags;
> + struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
> +
> + spin_lock_irqsave(&gpio->lock, flags);
> + tmp = readb(clps711x_pdir(chip)) | (1 << offset);
> + writeb(tmp, clps711x_pdir(chip));
> + tmp = readb(clps711x_port(chip)) & ~(1 << offset);
> + if (value)
> + tmp |= 1 << offset;
> + writeb(tmp, clps711x_port(chip));
> + spin_unlock_irqrestore(&gpio->lock, flags);
> +
> + return 0;
> +}
> +
> +struct clps711x_gpio_port {
> + char *name;
> + int nr;
> +};
> +
> +static const struct clps711x_gpio_port clps711x_gpio_ports[] __initconst = {
> + { "PORTA", 8, },
> + { "PORTB", 8, },
> + { "PORTC", 8, },
> + { "PORTD", 8, },
> + { "PORTE", 3, },
> +};
> +
> +static int __init gpio_clps711x_init(void)
> +{
> + int i;
> + struct platform_device *pdev;
> + struct clps711x_gpio *gpio;
> +
> + pdev = platform_device_alloc(CLPS711X_GPIO_NAME, 0);
> + if (!pdev) {
> + pr_err("Cannot create platform device: %s\n",
> + CLPS711X_GPIO_NAME);
> + return -ENOMEM;
> + }
> +
> + platform_device_add(pdev);
> +
> + gpio = devm_kzalloc(&pdev->dev, sizeof(struct clps711x_gpio),
> + GFP_KERNEL);
> + if (!gpio) {
> + dev_err(&pdev->dev, "GPIO allocating memory error\n");
> + platform_device_del(pdev);
> + platform_device_put(pdev);
> + return -ENOMEM;
> + }
> +
> + platform_set_drvdata(pdev, gpio);
> +
> + spin_lock_init(&gpio->lock);
> +
> + for (i = 0; i < CLPS711X_GPIO_PORTS; i++) {
> + gpio->chip[i].owner = THIS_MODULE;
> + gpio->chip[i].dev = &pdev->dev;
> + gpio->chip[i].label = clps711x_gpio_ports[i].name;
> + gpio->chip[i].base = i * 8;
> + gpio->chip[i].ngpio = clps711x_gpio_ports[i].nr;
> + gpio->chip[i].direction_input = gpio_clps711x_direction_in;
> + gpio->chip[i].get = gpio_clps711x_get;
> + gpio->chip[i].direction_output = gpio_clps711x_direction_out;
> + gpio->chip[i].set = gpio_clps711x_set;
> + WARN_ON(gpiochip_add(&gpio->chip[i]));
> + }
> +
> + dev_info(&pdev->dev, "GPIO driver initialized\n");
> +
> + return 0;
> +}
> +arch_initcall(gpio_clps711x_init);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Alexander Shiyan <shc_work@mail.ru>");
> +MODULE_DESCRIPTION("CLPS711X GPIO driver");
> --
> 1.7.8.6
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 0/9] ARM architecture fixes for 3.7
From: Russell King - ARM Linux @ 2012-10-09 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> Here are some patches that belong into your domain, I hope you can
> just send the lot to Linus the next time you send other patches.
>
> These bug fixes all address problems found with automated build testing.
> Some of them have been around for a long time, other bugs are
> regressions since the merge window.
Apart from the sliced off comment in one commit (which XEN people need
to confirm they're happy with the final version), I think these are
otherwise fine... I'll hold off pulling them until that can be fixed.
Thanks.
^ permalink raw reply
* [PATCH 4/9] ARM: export default read_current_timer
From: Russell King - ARM Linux @ 2012-10-09 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50744586.6010806@arm.com>
On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote:
> Hi Arnd,
>
> On 09/10/12 16:22, Arnd Bergmann wrote:
> > diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> > index 9d0a300..0dc5385 100644
> > --- a/arch/arm/lib/delay.c
> > +++ b/arch/arm/lib/delay.c
> > @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
> > *timer_val = delay_timer->read_current_timer();
> > return 0;
> > }
> > +EXPORT_SYMBOL_GPL(read_current_timer);
>
>
> Perhaps this fits better in armksyms.c? That way it lives with
> arm_delay_ops and friends.
It's always much better to put things next to where they're defined
rather than spreading them around.
armksyms.c is a reminant of the 1.x days of doing things... but still
remains to allow what are mostly assembly symbols to be exported.
^ permalink raw reply
* [PATCH v4] GPIO: Add support for GPIO on CLPS711X-target platform
From: Alexander Shiyan @ 2012-10-09 16:05 UTC (permalink / raw)
To: linux-arm-kernel
The CLPS711X CPUs provide some GPIOs for use in the system. This
driver provides support for these via gpiolib. Due to platform
limitations, driver does not support interrupts, only inputs and
outputs.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
arch/arm/Kconfig | 1 +
arch/arm/mach-clps711x/include/mach/gpio.h | 13 +++
drivers/gpio/Kconfig | 4 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-clps711x.c | 163 ++++++++++++++++++++++++++++
5 files changed, 182 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-clps711x/include/mach/gpio.h
create mode 100644 drivers/gpio/gpio-clps711x.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2867a77..343b0c3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -352,6 +352,7 @@ config ARCH_CLPS711X
bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
select CPU_ARM720T
select ARCH_USES_GETTIMEOFFSET
+ select ARCH_REQUIRE_GPIOLIB
select COMMON_CLK
select CLKDEV_LOOKUP
select NEED_MACH_MEMORY_H
diff --git a/arch/arm/mach-clps711x/include/mach/gpio.h b/arch/arm/mach-clps711x/include/mach/gpio.h
new file mode 100644
index 0000000..8ac6889
--- /dev/null
+++ b/arch/arm/mach-clps711x/include/mach/gpio.h
@@ -0,0 +1,13 @@
+/*
+ * This file contains the CLPS711X GPIO definitions.
+ *
+ * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+/* Simple helper for convert port & pin to GPIO number */
+#define CLPS711X_GPIO(port, bit) ((port) * 8 + (bit))
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d055cee..fb76140 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -91,6 +91,10 @@ config GPIO_MAX730X
comment "Memory mapped GPIO drivers:"
+config GPIO_CLPS711X
+ def_bool y
+ depends on ARCH_CLPS711X
+
config GPIO_GENERIC_PLATFORM
tristate "Generic memory-mapped GPIO controller support (MMIO platform device)"
select GPIO_GENERIC
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 9aeed67..a28725e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
+obj-$(CONFIG_GPIO_CLPS711X) += gpio-clps711x.o
obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_ARCH_DAVINCI) += gpio-davinci.o
diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
new file mode 100644
index 0000000..ea21822
--- /dev/null
+++ b/drivers/gpio/gpio-clps711x.c
@@ -0,0 +1,163 @@
+/*
+ * CLPS711X GPIO driver
+ *
+ * Copyright (C) 2012 Alexander Shiyan <shc_work@mail.ru>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/platform_device.h>
+
+#include <mach/hardware.h>
+
+#define CLPS711X_GPIO_PORTS 5
+#define CLPS711X_GPIO_NAME "gpio-clps711x"
+
+struct clps711x_gpio {
+ struct gpio_chip chip[CLPS711X_GPIO_PORTS];
+ spinlock_t lock;
+};
+
+static void __iomem *clps711x_ports[] = {
+ CLPS711X_VIRT_BASE + PADR,
+ CLPS711X_VIRT_BASE + PBDR,
+ CLPS711X_VIRT_BASE + PCDR,
+ CLPS711X_VIRT_BASE + PDDR,
+ CLPS711X_VIRT_BASE + PEDR,
+};
+
+static void __iomem *clps711x_pdirs[] = {
+ CLPS711X_VIRT_BASE + PADDR,
+ CLPS711X_VIRT_BASE + PBDDR,
+ CLPS711X_VIRT_BASE + PCDDR,
+ CLPS711X_VIRT_BASE + PDDDR,
+ CLPS711X_VIRT_BASE + PEDDR,
+};
+
+#define clps711x_port(x) clps711x_ports[x->base / 8]
+#define clps711x_pdir(x) clps711x_pdirs[x->base / 8]
+
+static int gpio_clps711x_get(struct gpio_chip *chip, unsigned offset)
+{
+ return !!readb(clps711x_port(chip)) & (1 << offset);
+}
+
+static void gpio_clps711x_set(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ int tmp;
+ unsigned long flags;
+ struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+
+ spin_lock_irqsave(&gpio->lock, flags);
+ tmp = readb(clps711x_port(chip)) & ~(1 << offset);
+ if (value)
+ tmp |= 1 << offset;
+ writeb(tmp, clps711x_port(chip));
+ spin_unlock_irqrestore(&gpio->lock, flags);
+}
+
+static int gpio_clps711x_direction_in(struct gpio_chip *chip, unsigned offset)
+{
+ int tmp;
+ unsigned long flags;
+ struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+
+ spin_lock_irqsave(&gpio->lock, flags);
+ tmp = readb(clps711x_pdir(chip)) & ~(1 << offset);
+ writeb(tmp, clps711x_pdir(chip));
+ spin_unlock_irqrestore(&gpio->lock, flags);
+
+ return 0;
+}
+
+static int gpio_clps711x_direction_out(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ int tmp;
+ unsigned long flags;
+ struct clps711x_gpio *gpio = dev_get_drvdata(chip->dev);
+
+ spin_lock_irqsave(&gpio->lock, flags);
+ tmp = readb(clps711x_pdir(chip)) | (1 << offset);
+ writeb(tmp, clps711x_pdir(chip));
+ tmp = readb(clps711x_port(chip)) & ~(1 << offset);
+ if (value)
+ tmp |= 1 << offset;
+ writeb(tmp, clps711x_port(chip));
+ spin_unlock_irqrestore(&gpio->lock, flags);
+
+ return 0;
+}
+
+struct clps711x_gpio_port {
+ char *name;
+ int nr;
+};
+
+static const struct clps711x_gpio_port clps711x_gpio_ports[] __initconst = {
+ { "PORTA", 8, },
+ { "PORTB", 8, },
+ { "PORTC", 8, },
+ { "PORTD", 8, },
+ { "PORTE", 3, },
+};
+
+static int __init gpio_clps711x_init(void)
+{
+ int i;
+ struct platform_device *pdev;
+ struct clps711x_gpio *gpio;
+
+ pdev = platform_device_alloc(CLPS711X_GPIO_NAME, 0);
+ if (!pdev) {
+ pr_err("Cannot create platform device: %s\n",
+ CLPS711X_GPIO_NAME);
+ return -ENOMEM;
+ }
+
+ platform_device_add(pdev);
+
+ gpio = devm_kzalloc(&pdev->dev, sizeof(struct clps711x_gpio),
+ GFP_KERNEL);
+ if (!gpio) {
+ dev_err(&pdev->dev, "GPIO allocating memory error\n");
+ platform_device_del(pdev);
+ platform_device_put(pdev);
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(pdev, gpio);
+
+ spin_lock_init(&gpio->lock);
+
+ for (i = 0; i < CLPS711X_GPIO_PORTS; i++) {
+ gpio->chip[i].owner = THIS_MODULE;
+ gpio->chip[i].dev = &pdev->dev;
+ gpio->chip[i].label = clps711x_gpio_ports[i].name;
+ gpio->chip[i].base = i * 8;
+ gpio->chip[i].ngpio = clps711x_gpio_ports[i].nr;
+ gpio->chip[i].direction_input = gpio_clps711x_direction_in;
+ gpio->chip[i].get = gpio_clps711x_get;
+ gpio->chip[i].direction_output = gpio_clps711x_direction_out;
+ gpio->chip[i].set = gpio_clps711x_set;
+ WARN_ON(gpiochip_add(&gpio->chip[i]));
+ }
+
+ dev_info(&pdev->dev, "GPIO driver initialized\n");
+
+ return 0;
+}
+arch_initcall(gpio_clps711x_init);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Alexander Shiyan <shc_work@mail.ru>");
+MODULE_DESCRIPTION("CLPS711X GPIO driver");
--
1.7.8.6
^ permalink raw reply related
* [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Russell King - ARM Linux @ 2012-10-09 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
On Tue, Oct 09, 2012 at 05:22:59PM +0200, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
> getting built on ARM.
>
> * The tmem hypercall is not available on ARM
>
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
"in the" what?
^ permalink raw reply
* [GIT PULL] ARM: OMAP: warnings/hwmod/clock fixes for pre-3.7-rc1
From: Paul Walmsley @ 2012-10-09 16:03 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-a-for-pre3.7
for you to fetch changes up to e9332b6eed82973a8f75f1f3d57babaa331d703c:
ARM: OMAP4/AM335x: hwmod: fix disable_module regression in hardreset handling (2012-10-08 23:08:15 -0600)
- ----------------------------------------------------------------
Some OMAP fixes for the 3.7 merge window, fixing mismerges, branch
integration issues, and bugs after the arm-soc merges.
Basic test logs are available here:
http://www.pwsan.com/omap/testlogs/devel_late_fixes_3.7/20121009084003/
N800 isn't booting; this is a problem present in the base commit and
is due to serial driver breakage:
http://www.spinics.net/lists/arm-kernel/msg196034.html
- ----------------------------------------------------------------
Jon Hunter (2):
ARM: OMAP2+: hwmod data: Fix PMU interrupt definitions
ARM: OMAP3: fix workaround for EMU clockdomain
Paul Walmsley (2):
ARM: OMAP: omap3evm: fix new sparse warning
ARM: OMAP4/AM335x: hwmod: fix disable_module regression in hardreset handling
Vaibhav Hiremath (1):
ARM: am33xx: clk: Update clkdev table to add mcasp alias
arch/arm/mach-omap2/board-omap3evm.c | 3 +-
arch/arm/mach-omap2/clock33xx_data.c | 2 +
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 44 ++++++++++----------
arch/arm/mach-omap2/omap_hwmod.c | 31 ++++++++++++--
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
6 files changed, 54 insertions(+), 30 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQdEqIAAoJEMePsQ0LvSpLjvYP/RlejvRetwDYUSpwjgre/xfz
BA+we3wgi/wgZ3xbdlcFKfdj2l+jzLxspr1pt6MSFzZqJJVKPj1xgHCPJZe4QFX3
waurd+p4OUcO7qKoLQo7up9nfzsI4vnxjyDXjEUCLjAaEq18qqMi4YQEdncotrZU
hOL8yFE9ol6Ds2dLtTulnxMfqbMILa5ek+NSVWizbQbVPh8opklRQwRSbYmAgCze
USY410kyP/WVXa1hern5UnyEo4nzVpXAFf4+3LVil05p/vWgB4i/JwUINAYNr1sr
L1ells+x0z9RKybTNsrDxTQmwY8Jr+TyZJ3uikccFTpqo+TfwcfZN++Qrx+/0Q5z
GCVB4dp2aH4QLas9yTFGp/3X2BiPx5AwKX9mqhnOR3peq1lBS1D9V+BTmKAHoY6n
w2XzAF3jpE2qNLnxIym46TJYRHGrc1o6U0U5dHxjQZVx796rgUHEIZEfVznWj6lS
GaU3b8YQKN3EPKbrdIQ2y5bVEf0SnLdiOjJo+tTVBGhQ7eiVMRN6btYt8Fod2Rlq
TXleGmDGKUKI43omeALn2fJWgNrm1GIPSPU1aa3TMZQN7qa/FHyAimcY5QOqU+HT
uCUmsSukw6oIfWvV8hyN/R7AovvqaKYpyPUvxOM09G/WnoRGahk3eFHpUcEGQGqD
6PQY5o1skH1C4B++o0EL
=Yvqo
-----END PGP SIGNATURE-----
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-09 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210091141270.1441-100000@iolanthe.rowland.org>
On 11:44 Tue 09 Oct , Alan Stern wrote:
> On Tue, 9 Oct 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> > > Why do you need to know the difference in your driver? We used to
> > > provide this information a long time ago, but it turned out to not be
> > > needed at all and just caused problems.
> > because on at91 I need to handle the mem standby at drviers level.
> >
> > We do it today already by a hack in different drivers at91_udc (usb device),
> > atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
> > to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
> > clock - this is done at soc level - but those IP have issue and need specific
> > care before doing so. Ohterwise when the SoC will wakeup but those IP will not
> >
> > in this patch series I send the update of those 3 drivers too
> > and kill the hack
>
> How about adding a platform-specific callback routine to tell drivers
> whether or not they will run from the slow clock? Something like:
>
> bool at91_suspend_will_use_slow_clock(void);
>
> That would not involve making any changes to the driver core, and your
> three drivers could still get the information they need.
I already do so and I want to drop it as the IP is shared with multiple ARCH
and I want to have a clean code no hack
and no platform data I do DT and drop board code so far, I've a dt code
without any platform data provide via c code
Best Regards,
J.
^ permalink raw reply
* [PATCH] mmc: mxs: fix build regression from mismerge
From: Chris Ball @ 2012-10-09 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091537.23659.arnd@arndb.de>
Hi,
On Tue, Oct 09 2012, Arnd Bergmann wrote:
> From all I can tell, the patches
>
> fc108d24 "mmc: mxs-mmc: fix deadlock caused by recursion loop"
> 829c1bf4 "mmc: spi: Pull out parts shared between MMC and SPI"
>
> came in through separate branches and cause this build error when
> combined.
>
> drivers/mmc/host/mxs-mmc.c: In function 'mxs_mmc_enable_sdio_irq':
> drivers/mmc/host/mxs-mmc.c:527:78: error: 'struct mxs_mmc_host' has no member named 'base'
> drivers/mmc/host/mxs-mmc.c:527:95: error: 'struct mxs_mmc_host' has no member named 'devid'
>
> This does the obvious missing change.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Attila Kinali <attila@kinali.ch>
> Cc: Lauri Hintsala <lauri.hintsala@bluegiga.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
> diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
> index bb4c2bf..80d1e6d 100644
> --- a/drivers/mmc/host/mxs-mmc.c
> +++ b/drivers/mmc/host/mxs-mmc.c
> @@ -525,7 +525,7 @@ static void mxs_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
> writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
> ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
> writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
> - host->base + HW_SSP_CTRL1(host) + STMP_OFFSET_REG_SET);
> + ssp->base + HW_SSP_CTRL1(ssp) + STMP_OFFSET_REG_SET);
> } else {
> writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
> ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
>
I'll send Marek's change to Linus once the main MMC merge has been pulled.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Alan Stern @ 2012-10-09 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009151704.GP12801@game.jcrosoft.org>
On Tue, 9 Oct 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > Why do you need to know the difference in your driver? We used to
> > provide this information a long time ago, but it turned out to not be
> > needed at all and just caused problems.
> because on at91 I need to handle the mem standby at drviers level.
>
> We do it today already by a hack in different drivers at91_udc (usb device),
> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
> clock - this is done at soc level - but those IP have issue and need specific
> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
>
> in this patch series I send the update of those 3 drivers too
> and kill the hack
How about adding a platform-specific callback routine to tell drivers
whether or not they will run from the slow clock? Something like:
bool at91_suspend_will_use_slow_clock(void);
That would not involve making any changes to the driver core, and your
three drivers could still get the information they need.
Alan Stern
^ permalink raw reply
* [PATCH] mmc: mxs: fix build regression from mismerge
From: Marek Vašut @ 2012-10-09 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091537.23659.arnd@arndb.de>
I sent a patch for that already, Chris was cced on it recently by Shawn
too. (Sorry for top posting, Android mail client)
Dne 9.10.2012 17:39 "Arnd Bergmann" <arnd@arndb.de> napsal(a):
> From all I can tell, the patches
>
> fc108d24 "mmc: mxs-mmc: fix deadlock caused by recursion loop"
> 829c1bf4 "mmc: spi: Pull out parts shared between MMC and SPI"
>
> came in through separate branches and cause this build error when
> combined.
>
> drivers/mmc/host/mxs-mmc.c: In function 'mxs_mmc_enable_sdio_irq':
> drivers/mmc/host/mxs-mmc.c:527:78: error: 'struct mxs_mmc_host' has no
> member named 'base'
> drivers/mmc/host/mxs-mmc.c:527:95: error: 'struct mxs_mmc_host' has no
> member named 'devid'
>
> This does the obvious missing change.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Attila Kinali <attila@kinali.ch>
> Cc: Lauri Hintsala <lauri.hintsala@bluegiga.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
> diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
> index bb4c2bf..80d1e6d 100644
> --- a/drivers/mmc/host/mxs-mmc.c
> +++ b/drivers/mmc/host/mxs-mmc.c
> @@ -525,7 +525,7 @@ static void mxs_mmc_enable_sdio_irq(struct mmc_host
> *mmc, int enable)
> writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
> ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
> writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
> - host->base + HW_SSP_CTRL1(host) +
> STMP_OFFSET_REG_SET);
> + ssp->base + HW_SSP_CTRL1(ssp) +
> STMP_OFFSET_REG_SET);
> } else {
> writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
> ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121009/2cf2c1ab/attachment-0001.html>
^ permalink raw reply
* [PATCH 4/9] ARM: export default read_current_timer
From: Jonathan Austin @ 2012-10-09 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-5-git-send-email-arnd@arndb.de>
Hi Arnd,
On 09/10/12 16:22, Arnd Bergmann wrote:
> read_current_timer is used by get_cycles since "ARM: 7538/1: delay:
> add registration mechanism for delay timer sources", and get_cycles
> can be used by device drivers in loadable modules, so it has to
> be exported.
>
> Without this patch, building imote2_defconfig fails with
>
> ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
[...]
> arch/arm/lib/delay.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
> index 9d0a300..0dc5385 100644
> --- a/arch/arm/lib/delay.c
> +++ b/arch/arm/lib/delay.c
> @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
> *timer_val = delay_timer->read_current_timer();
> return 0;
> }
> +EXPORT_SYMBOL_GPL(read_current_timer);
Perhaps this fits better in armksyms.c? That way it lives with
arm_delay_ops and friends.
I've got a patch doing it like that, which I can put in Russell's
patch-system, unless you prefer doing it in delay.c for any reason?
Jonny
(Here's the original patch sent to the kernel-janitors list and Will Deacon)
-------8<---------
On ARM, get_cycles() is implemented in terms of read_current_timer(), but
the latter is not exported to modules, resulting in failure to link:
ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
This patch exports the symbol as required.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
---
arch/arm/kernel/armksyms.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
index 60d3b73..6a37f8d 100644
--- a/arch/arm/kernel/armksyms.c
+++ b/arch/arm/kernel/armksyms.c
@@ -50,6 +50,7 @@ extern void fpundefinstr(void);
/* platform dependent support */
EXPORT_SYMBOL(arm_delay_ops);
+EXPORT_SYMBOL(read_current_timer);
/* networking */
EXPORT_SYMBOL(csum_partial);
--
1.7.1
^ permalink raw reply related
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Arnd Bergmann @ 2012-10-09 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796958.21847.219.camel@zakaz.uk.xensource.com>
On Tuesday 09 October 2012, Ian Campbell wrote:
> > * The tmem hypercall is not available on ARM
> >
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
>
> missing the end of this sentence?
Right, I meant to say
* ARMv6 does not support cmpxchg on 16-bit words that are used in the
Xen grant table code, so we must ensure that Xen support is only built
on ARMv7-only kernels not combined ARMv6/v7 kernels.
This should be fixed differently in the future.
Arnd
^ permalink raw reply
* [PATCH] mmc: mxs: fix build regression from mismerge
From: Arnd Bergmann @ 2012-10-09 15:37 UTC (permalink / raw)
To: linux-arm-kernel
>From all I can tell, the patches
fc108d24 "mmc: mxs-mmc: fix deadlock caused by recursion loop"
829c1bf4 "mmc: spi: Pull out parts shared between MMC and SPI"
came in through separate branches and cause this build error when
combined.
drivers/mmc/host/mxs-mmc.c: In function 'mxs_mmc_enable_sdio_irq':
drivers/mmc/host/mxs-mmc.c:527:78: error: 'struct mxs_mmc_host' has no member named 'base'
drivers/mmc/host/mxs-mmc.c:527:95: error: 'struct mxs_mmc_host' has no member named 'devid'
This does the obvious missing change.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Attila Kinali <attila@kinali.ch>
Cc: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Chris Ball <cjb@laptop.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index bb4c2bf..80d1e6d 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -525,7 +525,7 @@ static void mxs_mmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_SET);
writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
- host->base + HW_SSP_CTRL1(host) + STMP_OFFSET_REG_SET);
+ ssp->base + HW_SSP_CTRL1(ssp) + STMP_OFFSET_REG_SET);
} else {
writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
ssp->base + HW_SSP_CTRL0 + STMP_OFFSET_REG_CLR);
^ permalink raw reply related
* [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Stefano Stabellini @ 2012-10-09 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
Thanks for the patch and sorry for the build breakage!
On Tue, 9 Oct 2012, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
> getting built on ARM.
>
> * The tmem hypercall is not available on ARM
>
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
>
> * sys-hypervisor.c needs to include linux/err.h in order to use the
> IS_ERR/PTR_ERR/ERR_PTR family of functions.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel at lists.xensource.com
> ---
> arch/arm/Kconfig | 1 +
> drivers/xen/Kconfig | 2 ++
> drivers/xen/sys-hypervisor.c | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
> config XEN
> bool "Xen guest support on ARM (EXPERIMENTAL)"
> depends on EXPERIMENTAL && ARM && OF
> + depends on !CPU_V6
> help
> Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
Considering that we rely on the virtualization extensions, this one can
be:
depends on CPU_V7
The rest looks fine. I can submit a second patch to change !CPU_V6 into
CPU_V7 later, if you prefer.
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>
> config XEN_BALLOON
> bool "Xen memory balloon driver"
> + depends on !ARM
> default y
> help
> The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>
> config XEN_TMEM
> bool
> + depends on !ARM
> default y if (CLEANCACHE || FRONTSWAP)
> help
> Shim to interface in-kernel Transcendent Memory hooks
>
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/kobject.h>
> +#include <linux/err.h>
>
> #include <asm/xen/hypervisor.h>
> #include <asm/xen/hypercall.h>
> --
> 1.7.10
>
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Ian Campbell @ 2012-10-09 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-6-git-send-email-arnd@arndb.de>
On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote:
> * The XEN_BALLOON code requires the balloon infrastructure that is not
> getting built on ARM.
I've got patches to enable this, but not for 3.7 so this looks good for
now.
> * The tmem hypercall is not available on ARM
>
> * ARMv6 does not support cmpxchg on 16-bit words that are used in the
missing the end of this sentence?
> * sys-hypervisor.c needs to include linux/err.h in order to use the
> IS_ERR/PTR_ERR/ERR_PTR family of functions.
I tripped over this too. Not sure where that patch got to though.
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel at lists.xensource.com
> ---
> arch/arm/Kconfig | 1 +
> drivers/xen/Kconfig | 2 ++
> drivers/xen/sys-hypervisor.c | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6d2f7f5..85eaac3 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1846,6 +1846,7 @@ config XEN_DOM0
> config XEN
> bool "Xen guest support on ARM (EXPERIMENTAL)"
> depends on EXPERIMENTAL && ARM && OF
> + depends on !CPU_V6
> help
> Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index d4dffcd..126d8ce 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -3,6 +3,7 @@ menu "Xen driver support"
>
> config XEN_BALLOON
> bool "Xen memory balloon driver"
> + depends on !ARM
> default y
> help
> The balloon driver allows the Xen domain to request more memory from
> @@ -145,6 +146,7 @@ config SWIOTLB_XEN
>
> config XEN_TMEM
> bool
> + depends on !ARM
> default y if (CLEANCACHE || FRONTSWAP)
> help
> Shim to interface in-kernel Transcendent Memory hooks
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 5e5ad7e..66a0a14 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -11,6 +11,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/kobject.h>
> +#include <linux/err.h>
>
> #include <asm/xen/hypervisor.h>
> #include <asm/xen/hypercall.h>
^ permalink raw reply
* [PATCH] pinctrl: sirf: remove sirfsoc_gpio_set_pull function
From: Arnd Bergmann @ 2012-10-09 15:35 UTC (permalink / raw)
To: linux-arm-kernel
The prima2 platform advertises needing no mach/gpio.h header file,
but its pinctrl driver now has a sirfsoc_gpio_set_pull function
that uses constants defined in arch/arm/mach-prima2/include/mach/gpio.h,
which fails to build.
Fortunately, the sirfsoc_gpio_set_pull is not used anywhere in the
kernel, so we can safely remove it. Any out of tree drivers using
it will have to be converted to use proper pinctrl functions to
do the same.
Without this patch, building prima2_defconfig results in:
drivers/pinctrl/pinctrl-sirf.c: In function 'sirfsoc_gpio_set_pull':
drivers/pinctrl/pinctrl-sirf.c:1331:7: error: 'SIRFSOC_GPIO_PULL_NONE' undeclared (first use in this function)
drivers/pinctrl/pinctrl-sirf.c:1331:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/pinctrl/pinctrl-sirf.c:1334:7: error: 'SIRFSOC_GPIO_PULL_UP' undeclared (first use in this function)
drivers/pinctrl/pinctrl-sirf.c:1338:7: error: 'SIRFSOC_GPIO_PULL_DOWN' undeclared (first use in this function)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Barry Song <Baohua.Song@csr.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
diff --git a/arch/arm/mach-prima2/include/mach/gpio.h b/arch/arm/mach-prima2/include/mach/gpio.h
deleted file mode 100644
index 1904bb0..0000000
--- a/arch/arm/mach-prima2/include/mach/gpio.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __MACH_GPIO_H
-#define __MACH_GPIO_H
-
-/* Pull up/down values */
-enum sirfsoc_gpio_pull {
- SIRFSOC_GPIO_PULL_NONE,
- SIRFSOC_GPIO_PULL_UP,
- SIRFSOC_GPIO_PULL_DOWN,
-};
-
-void sirfsoc_gpio_set_pull(unsigned gpio, unsigned mode);
-
-#endif
diff --git a/drivers/pinctrl/pinctrl-sirf.c b/drivers/pinctrl/pinctrl-sirf.c
index 675497c..9ecacf3 100644
--- a/drivers/pinctrl/pinctrl-sirf.c
+++ b/drivers/pinctrl/pinctrl-sirf.c
@@ -1323,41 +1323,6 @@ static inline struct sirfsoc_gpio_bank *sirfsoc_gpio_to_bank(unsigned int gpio)
return &sgpio_bank[gpio / SIRFSOC_GPIO_BANK_SIZE];
}
-void sirfsoc_gpio_set_pull(unsigned gpio, unsigned mode)
-{
- struct sirfsoc_gpio_bank *bank = sirfsoc_gpio_to_bank(gpio);
- int idx = sirfsoc_gpio_to_offset(gpio);
- u32 val, offset;
- unsigned long flags;
-
- offset = SIRFSOC_GPIO_CTRL(bank->id, idx);
-
- spin_lock_irqsave(&sgpio_lock, flags);
-
- val = readl(bank->chip.regs + offset);
-
- switch (mode) {
- case SIRFSOC_GPIO_PULL_NONE:
- val &= ~SIRFSOC_GPIO_CTL_PULL_MASK;
- break;
- case SIRFSOC_GPIO_PULL_UP:
- val |= SIRFSOC_GPIO_CTL_PULL_MASK;
- val |= SIRFSOC_GPIO_CTL_PULL_HIGH;
- break;
- case SIRFSOC_GPIO_PULL_DOWN:
- val |= SIRFSOC_GPIO_CTL_PULL_MASK;
- val &= ~SIRFSOC_GPIO_CTL_PULL_HIGH;
- break;
- default:
- break;
- }
-
- writel(val, bank->chip.regs + offset);
-
- spin_unlock_irqrestore(&sgpio_lock, flags);
-}
-EXPORT_SYMBOL(sirfsoc_gpio_set_pull);
-
static inline struct sirfsoc_gpio_bank *sirfsoc_irqchip_to_bank(struct gpio_chip *chip)
{
return container_of(to_of_mm_gpio_chip(chip), struct sirfsoc_gpio_bank, chip);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox