* [PATCH 14/15] KVM: ARM: Handle I/O aborts
From: Dave Martin @ 2012-10-01 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349104329.2160.71.camel@linaro1.home>
On Mon, Oct 01, 2012 at 04:12:09PM +0100, Jon Medhurst (Tixy) wrote:
> On Mon, 2012-10-01 at 13:53 +0100, Dave Martin wrote:
> > On Sun, Sep 30, 2012 at 05:49:21PM -0400, Christoffer Dall wrote:
> > > On Thu, Sep 27, 2012 at 11:11 AM, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Sat, Sep 15, 2012 at 04:35:59PM +0100, Christoffer Dall wrote:
> > > > I'm afraid you're not going to thank me much for this, but it's high time we
> > > > unified the various instruction decoding functions we have under arch/arm/
> > > > and this seems like a good opportunity for that. For example, look at the
> > > > following snippets (there is much more in the files I list) in addition to
> > > > what you have:
> > > >
> > >
> > > I think it would be great if we had a set of unified decoding functions!
> > >
> > > However, I think it's a shame if we can't merge KVM because we want to
> > > clean up this code. There would be nothing in the way of breaking API
> > > or anything like that preventing us from cleaning this up after the
> > > code has been merged.
> > >
> > > Please consider reviewing the code for correctness and consider if the
> > > code could be merged as is.
> > >
> > > On the other hand, if you or Dave or anyone else wants to create a set
> > > of patches that cleans this up in a timely manner, I will be happy to
> > > merge them for my code as well ;)
> >
> > The time I would have available to put into this is rather limited, but
> > I have some initial ideas, as outlined below.
> >
> > Tixy (who did the kprobes implementation, which is probably the most
> > sophisticated opcode handling we have in the kernel right now) may have
> > ideas too. I would hope that any common framework could reuse a fair
> > chunk of his implementation and test coverage.
>
> To my thinking, the kprobes code is very tailored to the job it needs to
> do and that turning it into something generic is just going to make
> everything bigger and more complex - because a generic framework would
> be bigger (as it's trying to be generic) and then things like kprobes
> will probably end up having an additional framework layered over the top
> to bend it to it's purposes. Perhaps I'm being too pessimistic.
Perhaps kprobes is a bit of a double-edged example. It's an example of
an implementation with some good features, but because it is larger
the amount of adaptation required to convert to a common framework
would necessarily be larger also.
Yet, kprobes isn't trying to solve radically different problems from
other subsystems in the kernel. It doesn't just want to descode and
manipulate the properties of instructions, it is actually interested in
many of the same properties (for example, whether an instruction is
a load or store, whether it modifies the PC etc.) as some other
subsystems.
I worry that by default every implementation of this ends up rather
deeply tailored to its correcponding subsystem -- so we gradually
accumulate more incompatible partially-overlapping duplicates of this
functionality over time. This doesn't feel like a good thing.
> It would also requiring an inordinate amount of time to thrash out
> requirements, design, prototype, and to implement. (I don't think I'm
> being overly pessimistic about that ;-)
>
> So, unless some-one has serious quantities of spare time lying around...
Well, I don't suggest that we should expect to get there in one go:
such an effort won't ever the off the ground for sure.
If we can consolidate a few simpler subsystems' opcode handling then
that would still be a step in the right direction, even if integrating
kprobes could not happen until much later.
If we do nothing, the situation will just gradually get worse.
Cheers
---Dave
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Jason Gunthorpe @ 2012-10-01 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001153952.GB2100@linaro.org>
On Mon, Oct 01, 2012 at 04:39:53PM +0100, Dave Martin wrote:
> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > LOAD 0x008000 0xc0008000 0x00008000 0x372244 0x3a4310 RWE 0x8000
>
> Not related directly to your patch, but I wonder why we don't we see
> separate r-x and rw- segments?
I think this is because the sections are not aligned when the
protections change, and the sections are not sorted by protection
type.
[ 1] .head.text PROGBITS c0008000 008000 0001c0 00 AX 0 0 32
[ 2] .text PROGBITS c00081c0 0081c0 1dc880 00 AX 0 0 32
[ 3] .rodata PROGBITS c01e5000 1e5000 060a80 00 A 0 0 32
[ 4] __bug_table PROGBITS c0245a80 245a80 002a78 00 A 0 0 1
[ 5] .pci_fixup PROGBITS c02484f8 2484f8 000090 00 A 0 0 4
[ 6] __param PROGBITS c0248588 248588 000280 00 A 0 0 4
[ 7] __modver PROGBITS c0248808 248808 0007f8 00 A 0 0 4
[ 8] .init.text PROGBITS c0249000 249000 01af20 00 AX 0 0 32
[ 9] .exit.text PROGBITS c0263f20 263f20 000c0c 00 AX 0 0 4
[10] .init.proc.info PROGBITS c0264b2c 264b2c 00009c 00 AX 0 0 1
[11] .init.arch.info PROGBITS c0264bc8 264bc8 000044 00 A 0 0 4
[12] .init.tagtable PROGBITS c0264c0c 264c0c 000040 00 A 0 0 4
[13] .init.data PROGBITS c0264c60 264c60 0f481c 00 WA 0 0 32
[14] .data PROGBITS c035a000 35a000 020220 00 WA 0 0 32
[15] .notes NOTE c037a220 37a220 000024 00 AX 0 0 4
[16] .bss NOBITS c037a260 37a244 0320b0 00 WA 0 0 32
[17] .comment PROGBITS 00000000 37a244 000021 01 MS 0 0 1
> > +/* If we have a known, fixed physical load address then set LOAD_OFFSET
> > + and generate an ELF that has the physical load address in the program
> > + headers. */
> > +#ifndef CONFIG_ARM_PATCH_PHYS_VIRT
> > +#define LOAD_OFFSET (PAGE_OFFSET - PHYS_OFFSET)
> > +#endif
> > +
>
> What happens if CONFIG_ARM_PATCH_PHYS_VIRT=y? This will be used
> increasingly, especially for multiplatform kernels.
Then LOAD_OFFSET is unset and include/asm-generic/vmlinux.lds.h does:
#ifndef LOAD_OFFSET
#define LOAD_OFFSET 0
#endif
Which is exactly the same case we have today. LOAD_OFFSET is not a
name I invented, it is the standard kernel name for the functionality.
> If the kernel is intended to be loadable at a physical address which is
> not statically known, no ELF loader that does not ignore the ELF
> phdr
In this case you can't really use a standard ELF loader to load the
kernel so, LOAD_OFFSET = 0 is fine. My case is using an ELF loader,
and I have set options for a static physical load address.
> > OUTPUT_ARCH(arm)
> > -ENTRY(stext)
> > +ENTRY(phys_start)
>
> This is debatable. In fact, stext has the property that its virtual
> (runtime) and load addresses are the same.
This is what other arches using LOAD_OFFSET do (eg see ia64), and is
sensible. ENTRY is *only* used by the ELF loader and specifies where
the loader should jump. It must be a physical address since the loader
only works with physical addresse. I don't understand your comment
that .stext has the same load and virtual address, that is clearly not
true for the ELF images my build is producing:
c0008000 T _text
c0008000 T stext
The physical address of that symbol is 0x8000.
> To represent this correctly in the linker scripts, the
> position-independent head.S code should be split out into a separate
> section to which LOAD_OFFSET is not applied.
I'm not sure, the linker script should use addresses that are correct
during runtime, and if the PIC code does not care about its PC then it
is fine to keep it at the virtual address to minimize confusion once
the MMU is on.
> Setting vaddr and paddr to PAGE_OFFSET (as we do now) and having the
> loader choose the appropriate board-specific place to load the kernel
> image makes this irrelevant, if I've understood the situation correctly.
Yes, if you use more loader stages then the load headers are ignored.
Our boot loaders on our boards boot straight ELF vmlinux.gz so they
need correct load headers.
Jason
^ permalink raw reply
* [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Mark Brown @ 2012-10-01 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EA92A1D@DBDE01.ent.ti.com>
On Thu, Sep 27, 2012 at 06:57:49AM +0000, Hebbar, Gururaja wrote:
> I have no knowledge about multi-platform builds yet.
> Currently this driver is shared between OMAP & DaVinci and both of them
> doesn't exist in single image build.
...due to issues like having compile time things selecting between the
platforms. In other words what these ifdefs would do is move us further
away from that goal rather than towards it as we should be doing.
> There was a effort done for this SRAM Consolidation [1] but it didn't progress.
> Hence I took this approach as a time-being/workaround. This was we can get
> affected platforms (like AM335x) get going/working.
Looks like it just needs more people pushing it...
^ permalink raw reply
* [PATCH v2] leds: leds-gpio: adopt pinctrl support
From: Tony Lindgren @ 2012-10-01 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ_NxST-oJ=MWC5L=r8uQD_71eHUVUR85v4jfsYpqz=UQ@mail.gmail.com>
* Linus Walleij <linus.walleij@linaro.org> [121001 01:25]:
> On Mon, Oct 1, 2012 at 9:03 AM, AnilKumar, Chimata <anilkumar@ti.com> wrote:
>
> > I have gone through the "Don Aisheng" patch series, which
> > adds "pinctrl_dt_add_gpio_ranges" support but not accepted
> > yet. With this patch series we can overcome the driver changes.
>
> OK then this is the direction we need to go.
>
> > 4. The current pinctrl driver has support for these APIs
> > pinctrl_request_gpio(), pinctrl_free_gpio(),
> > pinctrl_gpio_direction_input/output()
> > no API for slew rate control, pulled down/up control
> > how can we handle this?
>
> You are not supposed to handle that from the GPIO level
> of the API. That is supposed to be handled by pinctrl.
>
> These two subsystems are orthogonal, with the exception
> of the above calls. If you need to pass more information
> between the GPIO and pinctrl interfaces it usually means
> you're doing something wrong.
>
> The reason why pinctrl was created in the first place
> was that Grant didn't like that we started to shoehorn all
> kind of pin control into the GPIO subsystem.
Agreed.
> > 5. pinctrl-single driver has to modify to provide separate handles
> > for pinmux and pinconfig. And we need separate pin configuration
> > bit masks and values/flags to take care of pull-up/down, slew rate,
> > receiver in/out and mux mode control.
>
> OK that is typical pinctrl driver implementation work.
> I hope Tony can advice on this?
I think we're best off to just stick to alternative named modes
passed from device tree. For example, for GPIO wake-ups you can
have named modes such as "default", "enabled" and "idle" where
"idle" muxes things for GPIO wake-ups for the duration of idle.
It seems that should also work for leds-gpio. And you can
define more named modes as needed.
You really don't want the client driver or the GPIO driver doing
things like pull-up/down automatically as that is board specific and
can also depend on things like externall pull resistors.
> > 6. This is for my understanding, on which node do we have to add
> > pinctrl data i.e., pin mux-mode data. In leds-gpio node (mostly not)
> > and if it is in gpio node then how can we pass pinmux data with
> > the existing API pinctrl_request_gpio(gpio);? Here we are passing
> > only gpio number.
>
> So with the pinctrl_request_gpio() call you are requesting a single
> pin to be used as GPIO, nothing else.
>
> No additional data should be passed with that call.
Yeah I agree.
> Implementing it is up to the pinctrl driver, the pinctrl subsystem
> API does not say anything about how this should be done, but
> there are a few examples.
>
> The pinctrl maps of muxes and config from the pin control
> subsystem are for entire devices, and the single-pin GPIO
> reservation API is orthogonal to this, please consult
> Documentation/pinctrl.txt if you are uncertain about what
> I mean with this, I've really tried to explain it there.
>
> The docs were recently amended to reflect some corner-case
> GPIO uses, see e.g.:
> http://marc.info/?l=linux-arm-kernel&m=134763067415678&w=2
>
> > Few more driver patches are pending along with this (leds-gpio DT
> > data additions according to this patch, similarly other drivers
> > like matrix keypad and volume keys)
>
> OK so the threshold is that we need to get it right for the first
> one and then the others will look good too.
It seems we want to keep leds-gpio, gpio framework and pinctrl
framework generic. It also seems you should be able to do
what you're describing using the pinctrl named modes.
Regards,
Tony
^ permalink raw reply
* [PATCH v3] GPIO: Add support for GPIO on CLPS711X-target platform
From: Alexander Shiyan @ 2012-10-01 15:42 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 | 27 +++++
drivers/gpio/Kconfig | 4 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-clps711x.c | 152 ++++++++++++++++++++++++++++
5 files changed, 185 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 2f88d8d..e73bf9d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -384,6 +384,7 @@ config ARCH_CLPS711X
bool "Cirrus Logic CLPS711x/EP721x/EP731x-based"
select CPU_ARM720T
select ARCH_USES_GETTIMEOFFSET
+ select ARCH_REQUIRE_GPIOLIB
select NEED_MACH_MEMORY_H
help
Support for Cirrus Logic 711x/721x/731x based boards.
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..cbcc985
--- /dev/null
+++ b/arch/arm/mach-clps711x/include/mach/gpio.h
@@ -0,0 +1,27 @@
+/*
+ * 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))
+
+/* Temporaty definitions for GPIO-ports */
+/* Will be removed after remove clps_read(write) macros */
+#include <mach/hardware.h>
+#define _PADR (CLPS711X_VIRT_BASE + PADR)
+#define _PBDR (CLPS711X_VIRT_BASE + PBDR)
+#define _PCDR (CLPS711X_VIRT_BASE + PCDR)
+#define _PDDR (CLPS711X_VIRT_BASE + PDDR)
+#define _PADDR (CLPS711X_VIRT_BASE + PADDR)
+#define _PBDDR (CLPS711X_VIRT_BASE + PBDDR)
+#define _PCDDR (CLPS711X_VIRT_BASE + PCDDR)
+#define _PDDDR (CLPS711X_VIRT_BASE + PDDDR)
+#define _PEDR (CLPS711X_VIRT_BASE + PEDR)
+#define _PEDDR (CLPS711X_VIRT_BASE + PEDDR)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ba7926f5..636eda6 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 153cace..6a41f79 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -15,6 +15,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..c2576f9
--- /dev/null
+++ b/drivers/gpio/gpio-clps711x.c
@@ -0,0 +1,152 @@
+/*
+ * 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>
+
+#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 const void __iomem *clps711x_ports[] = {
+ _PADR, _PBDR, _PCDR, _PDDR, _PEDR,
+};
+
+static const void __iomem *clps711x_pdirs[] = {
+ _PADDR, _PBDDR, _PCDDR, _PDDDR, _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 = kzalloc(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;
+ 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] [ARM] Use AT() in the linker script to create correct program headers
From: Dave Martin @ 2012-10-01 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120930232116.GC30637@obsidianresearch.com>
On Sun, Sep 30, 2012 at 05:21:16PM -0600, Jason Gunthorpe wrote:
> The standard linux asm-generic/vmlinux.lds.h already supports this,
> and it seems other architectures do as well.
>
> The goal is to create an ELF file that has correct program headers. We
> want to see the VirtAddr be the runtime address of the kernel with the
> MMU turned on, and PhysAddr be the physical load address for the section
> with no MMU.
>
> This allows ELF based boot loaders to properly load vmlinux:
>
> $ readelf -l vmlinux
> Entry point 0x8000
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x008000 0xc0008000 0x00008000 0x372244 0x3a4310 RWE 0x8000
Not related directly to your patch, but I wonder why we don't we see
separate r-x and rw- segments?
Perhaps the linker script needs tidyup, or there are wrong attributes on
some sections somewhere.
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> arch/arm/include/asm/memory.h | 2 +-
> arch/arm/kernel/vmlinux.lds.S | 47 ++++++++++++++++++++++++----------------
> 2 files changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 5f6ddcc..4ce5b6d 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -283,7 +283,7 @@ static inline __deprecated void *bus_to_virt(unsigned long x)
> #define arch_is_coherent() 0
> #endif
>
> -#endif
> +#endif /* __ASSEMBLY__ */
>
> #include <asm-generic/memory_model.h>
>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 36ff15b..07942b6 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -3,6 +3,13 @@
> * Written by Martin Mares <mj@atrey.karlin.mff.cuni.cz>
> */
>
> +/* If we have a known, fixed physical load address then set LOAD_OFFSET
> + and generate an ELF that has the physical load address in the program
> + headers. */
> +#ifndef CONFIG_ARM_PATCH_PHYS_VIRT
> +#define LOAD_OFFSET (PAGE_OFFSET - PHYS_OFFSET)
> +#endif
> +
What happens if CONFIG_ARM_PATCH_PHYS_VIRT=y? This will be used
increasingly, especially for multiplatform kernels.
Currently, it looks like we will just fail to link the kernel with
ARM_PATCH_PHYS_VIRT... or have I overlooked something?
If the kernel is intended to be loadable at a physical address which is
not statically known, no ELF loader that does not ignore the ELF phdr
address fields can work. There is no correct way to represent this
situation using an ET_EXEC image, unless we specify explicitly that
the addresses must be ignored as part of our boot protocol. (We ran into
the same situation with uImages, which bake the load address into the
image. The eventual answer was to fix U-Boot.)
Really, LOAD_OFFSET (in your terminology) is something that has to be
inferred by the loader in the general case, and in that case the ELF
paddr might as well be the same as the vaddr.
> #include <asm-generic/vmlinux.lds.h>
> #include <asm/cache.h>
> #include <asm/thread_info.h>
> @@ -39,7 +46,7 @@
> #endif
>
> OUTPUT_ARCH(arm)
> -ENTRY(stext)
> +ENTRY(phys_start)
This is debatable. In fact, stext has the property that its virtual
(runtime) and load addresses are the same. To represent this correctly
in the linker scripts, the position-independent head.S code should be
split out into a separate section to which LOAD_OFFSET is not applied.
This may cause confusion elsewhere though, since _text probably needs
to coincide with the virtual image of stext.
Setting vaddr and paddr to PAGE_OFFSET (as we do now) and having the
loader choose the appropriate board-specific place to load the kernel
image makes this irrelevant, if I've understood the situation correctly.
Cheers
---Dave
>
> #ifndef __ARMEB__
> jiffies = jiffies_64;
> @@ -86,11 +93,13 @@ SECTIONS
> #else
> . = PAGE_OFFSET + TEXT_OFFSET;
> #endif
> - .head.text : {
> + .head.text : AT(ADDR(.head.text) - LOAD_OFFSET) {
> _text = .;
> + phys_start = . - LOAD_OFFSET;
> HEAD_TEXT
> }
> - .text : { /* Real text segment */
> + /* Real text segment */
> + .text : AT(ADDR(.text) - LOAD_OFFSET) {
> _stext = .; /* Text and read-only data */
> __exception_text_start = .;
> *(.exception.text)
> @@ -119,12 +128,12 @@ SECTIONS
> * Stack unwinding tables
> */
> . = ALIGN(8);
> - .ARM.unwind_idx : {
> + .ARM.unwind_idx : AT(ADDR(.ARM.unwind_idx) - LOAD_OFFSET) {
> __start_unwind_idx = .;
> *(.ARM.exidx*)
> __stop_unwind_idx = .;
> }
> - .ARM.unwind_tab : {
> + .ARM.unwind_tab : AT(ADDR(.ARM.unwind_tab) - LOAD_OFFSET) {
> __start_unwind_tab = .;
> *(.ARM.extab*)
> __stop_unwind_tab = .;
> @@ -139,35 +148,35 @@ SECTIONS
> #endif
>
> INIT_TEXT_SECTION(8)
> - .exit.text : {
> + .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
> ARM_EXIT_KEEP(EXIT_TEXT)
> }
> - .init.proc.info : {
> + .init.proc.info : AT(ADDR(.init.proc.info) - LOAD_OFFSET) {
> ARM_CPU_DISCARD(PROC_INFO)
> }
> - .init.arch.info : {
> + .init.arch.info : AT(ADDR(.init.arch.info) - LOAD_OFFSET) {
> __arch_info_begin = .;
> *(.arch.info.init)
> __arch_info_end = .;
> }
> - .init.tagtable : {
> + .init.tagtable : AT(ADDR(.init.tagtable) - LOAD_OFFSET) {
> __tagtable_begin = .;
> *(.taglist.init)
> __tagtable_end = .;
> }
> #ifdef CONFIG_SMP_ON_UP
> - .init.smpalt : {
> + .init.smpalt : AT(ADDR(.init.smpalt) - LOAD_OFFSET) {
> __smpalt_begin = .;
> *(.alt.smp.init)
> __smpalt_end = .;
> }
> #endif
> - .init.pv_table : {
> + .init.pv_table : AT(ADDR(.init.pv_table) - LOAD_OFFSET) {
> __pv_table_begin = .;
> *(.pv_table)
> __pv_table_end = .;
> }
> - .init.data : {
> + .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
> #ifndef CONFIG_XIP_KERNEL
> INIT_DATA
> #endif
> @@ -178,7 +187,7 @@ SECTIONS
> INIT_RAM_FS
> }
> #ifndef CONFIG_XIP_KERNEL
> - .exit.data : {
> + .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
> ARM_EXIT_KEEP(EXIT_DATA)
> }
> #endif
> @@ -196,7 +205,7 @@ SECTIONS
> __data_loc = .;
> #endif
>
> - .data : AT(__data_loc) {
> + .data : AT(__data_loc - LOAD_OFFSET) {
> _data = .; /* address in memory */
> _sdata = .;
>
> @@ -245,7 +254,7 @@ SECTIONS
> * free it after init has commenced and TCM contents have
> * been copied to its destination.
> */
> - .tcm_start : {
> + .tcm_start : AT(ADDR(.tcm_start) - LOAD_OFFSET) {
> . = ALIGN(PAGE_SIZE);
> __tcm_start = .;
> __itcm_start = .;
> @@ -257,7 +266,7 @@ SECTIONS
> * and we'll upload the contents from RAM to TCM and free
> * the used RAM after that.
> */
> - .text_itcm ITCM_OFFSET : AT(__itcm_start)
> + .text_itcm ITCM_OFFSET : AT(__itcm_start - LOAD_OFFSET)
> {
> __sitcm_text = .;
> *(.tcm.text)
> @@ -272,12 +281,12 @@ SECTIONS
> */
> . = ADDR(.tcm_start) + SIZEOF(.tcm_start) + SIZEOF(.text_itcm);
>
> - .dtcm_start : {
> + .dtcm_start : AT(ADDR(.dtcm_start) - LOAD_OFFSET) {
> __dtcm_start = .;
> }
>
> /* TODO: add remainder of ITCM as well, that can be used for data! */
> - .data_dtcm DTCM_OFFSET : AT(__dtcm_start)
> + .data_dtcm DTCM_OFFSET : AT(__dtcm_start - LOAD_OFFSET)
> {
> . = ALIGN(4);
> __sdtcm_data = .;
> @@ -290,7 +299,7 @@ SECTIONS
> . = ADDR(.dtcm_start) + SIZEOF(.data_dtcm);
>
> /* End marker for freeing TCM copy in linked object */
> - .tcm_end : AT(ADDR(.dtcm_start) + SIZEOF(.data_dtcm)){
> + .tcm_end : AT(ADDR(.dtcm_start) + SIZEOF(.data_dtcm) - LOAD_OFFSET){
> . = ALIGN(PAGE_SIZE);
> __tcm_end = .;
> }
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
From: ABRAHAM, KISHON VIJAY @ 2012-10-01 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001120907.GK4360@opensource.wolfsonmicro.com>
Hi,
On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Oct 01, 2012 at 05:23:15PM +0530, ABRAHAM, KISHON VIJAY wrote:
>> On Mon, Oct 1, 2012 at 5:14 PM, Mark Brown
>
>> > No, this is not at all sensible - if there's an mfd_remove_devices()
>> > function we really ought to be able to use it to remove the children.
>> > If we can't do that we should fix the API usability, not open code the
>> > same stuff in every user.
>
>> What makes more sense to me is extend mfd_add_devices to create child
>> devices from dt data. Then for removing devices, one can use
>> mfd_remove_devices().
>
> Why would that be helpful? Most platforms don't support DT at all, and
I'm not sure how to put it correctly. All I'm trying to tell is mfd is
a framework that exposes a set of API's to create and remove a device
among others. If a mfd child device is not created using mfd API,
it'll be unfair to expect that child be removed properly using mfd
API. Like in this patch, the device is created using
of_platform_populate (not a mfd API) but is removed using
mfd_remove_devices (mfd API) [which should result in an abort].
This means mfd framework does not have an API to create a device from
dt data or so do I think since of_platform_populate() is used. Thats
why I suggested the idea of extending mfd_add_devices() (or adding a
new API in mfd framework) to create child devices from dt data so that
we'll have API's in mfd framework to both create and delete a device.
Thanks
Kishon
^ permalink raw reply
* [PATCH 14/15] KVM: ARM: Handle I/O aborts
From: Jon Medhurst (Tixy) @ 2012-10-01 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001125326.GA2100@linaro.org>
On Mon, 2012-10-01 at 13:53 +0100, Dave Martin wrote:
> On Sun, Sep 30, 2012 at 05:49:21PM -0400, Christoffer Dall wrote:
> > On Thu, Sep 27, 2012 at 11:11 AM, Will Deacon <will.deacon@arm.com> wrote:
> > > On Sat, Sep 15, 2012 at 04:35:59PM +0100, Christoffer Dall wrote:
> > > I'm afraid you're not going to thank me much for this, but it's high time we
> > > unified the various instruction decoding functions we have under arch/arm/
> > > and this seems like a good opportunity for that. For example, look at the
> > > following snippets (there is much more in the files I list) in addition to
> > > what you have:
> > >
> >
> > I think it would be great if we had a set of unified decoding functions!
> >
> > However, I think it's a shame if we can't merge KVM because we want to
> > clean up this code. There would be nothing in the way of breaking API
> > or anything like that preventing us from cleaning this up after the
> > code has been merged.
> >
> > Please consider reviewing the code for correctness and consider if the
> > code could be merged as is.
> >
> > On the other hand, if you or Dave or anyone else wants to create a set
> > of patches that cleans this up in a timely manner, I will be happy to
> > merge them for my code as well ;)
>
> The time I would have available to put into this is rather limited, but
> I have some initial ideas, as outlined below.
>
> Tixy (who did the kprobes implementation, which is probably the most
> sophisticated opcode handling we have in the kernel right now) may have
> ideas too. I would hope that any common framework could reuse a fair
> chunk of his implementation and test coverage.
To my thinking, the kprobes code is very tailored to the job it needs to
do and that turning it into something generic is just going to make
everything bigger and more complex - because a generic framework would
be bigger (as it's trying to be generic) and then things like kprobes
will probably end up having an additional framework layered over the top
to bend it to it's purposes. Perhaps I'm being too pessimistic.
It would also requiring an inordinate amount of time to thrash out
requirements, design, prototype, and to implement. (I don't think I'm
being overly pessimistic about that ;-)
So, unless some-one has serious quantities of spare time lying around...
--
Tixy
^ permalink raw reply
* [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
From: Jon Hunter @ 2012-10-01 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001094517.GC20812@mudshark.cambridge.arm.com>
On 10/01/2012 04:45 AM, Will Deacon wrote:
> On Mon, Sep 24, 2012 at 10:45:06PM +0100, Jon Hunter wrote:
>> On 09/20/2012 04:09 PM, Will Deacon wrote:
>>> On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
>>>> Have queued most of these for 3.7 with the exception of the OMAP4430
>>>> CTI-related patches (which look to me like 3.8 material) and the PM
>>>> runtime suspend/resume patch (which looks to me like 3.7-rc material) --
>>>> assuming this series makes it in for 3.7 ...
>>>
>>> Ok, thanks for queueing what you did.
>>>
>>> Jon -- could you pick the pieces up from what's left please and shout if
>>> you need anything from me?
>>
>> Yes will do.
>
> Great, thanks! Do you want me to do anything with my perf/omap4 branch? Now
> that we have 3.6, I can try rebasing it but I don't know if it's worth the
> effort if some of the patches are being reworked. Of course, I'm happy to
> pick newer versions if they're available.
I think that we are ok for the minute. I was going to wait until
everything gets merged for 3.7 and then rebase my branch [1] and start
re-working omap4430 support. So I would not worry right now.
Cheers
Jon
[1] https://github.com/jonhunter/linux/tree/dev-pmu
^ permalink raw reply
* [PATCHv3 2/4] Input: keypad: Add smsc ece1099 keypad driver
From: Shubhrajyoti @ 2012-10-01 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349089310-22134-1-git-send-email-sourav.poddar@ti.com>
On Monday 01 October 2012 04:31 PM, Sourav Poddar wrote:
> +smsc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct smsc *smsc = dev_get_drvdata(pdev->dev.parent);
> + struct input_dev *input;
> + struct smsc_keypad *kp;
> + int ret = 0, error;
> + int col, i, max_keys, row_shift;
> + int irq;
> + int addr;
> +
> + kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
> +
> + input = input_allocate_device();
> + if (!kp || !input) {
> + error = -ENOMEM;
> + goto err1;
> + }
> +
> + error = smsc_keypad_parse_dt(&pdev->dev, kp);
> + if (error)
> + return error;
>
Are we leaking input here?
^ permalink raw reply
* [PATCH] [ARM] Build failure CONFIG_ARCH_KIRKWOOD_DT relies on CACHE_FEROCEON_L2
From: Olof Johansson @ 2012-10-01 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001044337.GA8446@obsidianresearch.com>
On Sun, Sep 30, 2012 at 9:43 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Sun, Sep 30, 2012 at 07:44:10PM -0700, Olof Johansson wrote:
>
>> > void __init kirkwood_l2_init(void)
>> > {
>> > +#ifdef CONFIG_CACHE_FEROCEON_L2
>> > #ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH
>>
>> Aren't these added ifdefs completely redundant? L2_WRITETHROUGH is
>> dependent on the outer options anyway.
>
> No, the complete new function is:
>
> void __init kirkwood_l2_init(void)
> {
> #ifdef CONFIG_CACHE_FEROCEON_L2
> #ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH
> writel(readl(L2_CONFIG_REG) | L2_WRITETHROUGH, L2_CONFIG_REG);
> feroceon_l2_init(1);
> #else
> writel(readl(L2_CONFIG_REG) & ~L2_WRITETHROUGH, L2_CONFIG_REG);
> feroceon_l2_init(0);
> #endif
> #endif
> }
Ah. diff took out the #else in the middle and I didn't look at the
file. Obviously correct as-is.
In some other places we choose to put the ifdef outside the function
and provide a static inline stub in the header file instead. Either
way works fine though.
-Olof
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Matt Porter @ 2012-10-01 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001123242.GJ5641@beef>
On Mon, Oct 01, 2012 at 08:32:42AM -0400, Matt Porter wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> > Hi Matt,
> >
> > On 9/29/2012 1:07 AM, Matt Porter wrote:
> > > L3RAM (shared SRAM) is needed for use by several drivers.
> > > This creates a genalloc pool and a hook for the platform code
> > > to provide the struct gen_pool * in platform data.
> > >
> > > Signed-off-by: Matt Porter <mporter@ti.com>
> >
> > I am not sure if any of the DaVinci devices have a need to allocate from
> > *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> > devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> > if there is much point in trying to allocate from there.
> >
> > Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> > allocation on DA850 makes sense for your case? If yes, can you repost
> > with Ben's patch included in your series instead of this patch? I would
> > prefer that over creating a new pool for shared RAM.
>
> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> pool mostly was so I didn't have to touch the PM code at all. That can
> continue using the private SRAM API with the ARM RAM as it is now. The
> idea here was to allow that to be separate since no other bus masters
> can access the ARM RAM anyway and do something that didn't require
> regression testing PM. Also, I figured there's really no reason to use
> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> and working fine for that use case.
>
> The other thing is that Ben's patch needs to be rewritten to at least
> have the hook I added so we can provide the gen_pool in platform data.
> If you prefer this path still, I can add the needed hook on top of his
> original patch. Ultimately, I only *need* genalloc support for the
> shared sram so I can remove the private SRAM API from uio_pruss...so I'm
> happy with any way to get at it.
>
> Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
> remove the private SRAM API usage from the davinci ASoC driver too.
[and replying to myself :)]
Looking at the older parts (DM355/365/DM64xx) in more detail now, I see
that to get rid of SRAM API in davinci ASoC, we'll have a similar hook
to get the local ARM RAM gen_pool pointer necessary to support ping-pong
to that pool since that's able to be accessed from EDMA on those parts.
Ultimately, the approach is the same, it's just a matter of if we want
to fully leverage both SRAM pools on DA850 and friends.
-Matt
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Ben Gardiner @ 2012-10-01 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001123242.GJ5641@beef>
On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter <mporter@ti.com> wrote:
> On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
>> Hi Matt,
>>
>> On 9/29/2012 1:07 AM, Matt Porter wrote:
>> > L3RAM (shared SRAM) is needed for use by several drivers.
>> > This creates a genalloc pool and a hook for the platform code
>> > to provide the struct gen_pool * in platform data.
>> >
>> > Signed-off-by: Matt Porter <mporter@ti.com>
>>
>> I am not sure if any of the DaVinci devices have a need to allocate from
>> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
>> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
>> if there is much point in trying to allocate from there.
>>
>> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
>> allocation on DA850 makes sense for your case? If yes, can you repost
>> with Ben's patch included in your series instead of this patch? I would
>> prefer that over creating a new pool for shared RAM.
>
> Hrm, I did look at Ben's earlier patch. The reason I added a separate
> pool mostly was so I didn't have to touch the PM code at all. That can
> continue using the private SRAM API with the ARM RAM as it is now. The
> idea here was to allow that to be separate since no other bus masters
> can access the ARM RAM anyway and do something that didn't require
> regression testing PM. Also, I figured there's really no reason to use
> even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
> and working fine for that use case.
> [...]
I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as
you said, Sekhar) in any fashion is preferable to moving suspend
support into shared RAM. There is more of it (128K on L138) but also
more pressure on allocations there since there are more clients.
I appreciate that you are trying to preserve prior efforts in
attempted merging of SRAM support -- thank you for that; however, that
patch [1] was just an import of Subashish Ghosh's patch [2] -- I
chose _that_ implementation option then mainly because I imagined it
would be the least risky to get accepted upstream and not because of
any particular technical merits.
Best Regards,
Ben Gardiner
[1] https://patchwork.kernel.org/patch/840552/
[2] https://patchwork.kernel.org/patch/549351/
---
Nanometrics Inc.
http://www.nanometrics.ca
^ permalink raw reply
* rcu self-detected stall messages on OMAP3, 4 boards
From: Paul E. McKenney @ 2012-10-01 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb2f18vwv9qXZkypPxM4UwyeTrDs4+JnpFtYRCzADzFPQ@mail.gmail.com>
On Mon, Oct 01, 2012 at 10:55:11AM +0200, Linus Walleij wrote:
> On Sat, Sep 22, 2012 at 11:59 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>
> > rcu: Fix day-one dyntick-idle stall-warning bug
>
> As mentioned in another thread this solves the same problem for ux500.
> Reported/Tested-by: Linus Walleij <linus.walleij@linaro.org>
>
> But now it appears that this commit didn't make it into v3.6 so
> it definately needs to be tagged with Cc: stable at kernel.org
> before it gets merged since the stall warnings are kinda scary.
Ingo submitting this to Linus Torvalds earlier today, so we should be
able to send to stable shortly.
Thanx, Paul
^ permalink raw reply
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Andrew Lunn @ 2012-10-01 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC_5wRgf-DGnUfzkrreT_E1v8i=G8U0qo_5t1DY6+L7c+w@mail.gmail.com>
On Mon, Oct 01, 2012 at 02:54:55PM +0200, Fabio Porcedda wrote:
> On Mon, Oct 1, 2012 at 2:48 PM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote:
> > On Mon, Oct 1, 2012 at 2:45 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
> >>> Tested on an at91sam9260 board (evk-pro3)
> >>>
> >>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> >>> ---
> >>> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
> >>> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
> >>> 2 files changed, 40 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >>> new file mode 100644
> >>> index 0000000..65c1755
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >>> @@ -0,0 +1,19 @@
> >>> +* Atmel Watchdog Timers
> >>> +
> >>> +** at91sam9-wdt
> >>> +
> >>> +Required properties:
> >>> +- compatible: must be "atmel,at91sam9260-wdt".
> >>> +- reg: physical base address of the controller and length of memory mapped
> >>> + region.
> >>> +
> >>> +Optional properties:
> >>> +- timeout: contains the watchdog timeout in seconds.
> >>> +
> >>> +Example:
> >>> +
> >>> + watchdog at fffffd40 {
> >>> + compatible = "atmel,at91sam9260-wdt";
> >>> + reg = <0xfffffd40 0x10>;
> >>> + timeout = <10>;
> >>> + };
> >>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
> >>> index 05e1be8..c9e6bfa 100644
> >>> --- a/drivers/watchdog/at91sam9_wdt.c
> >>> +++ b/drivers/watchdog/at91sam9_wdt.c
> >>> @@ -32,6 +32,7 @@
> >>> #include <linux/timer.h>
> >>> #include <linux/bitops.h>
> >>> #include <linux/uaccess.h>
> >>> +#include <linux/of.h>
> >>>
> >>> #include "at91sam9_wdt.h"
> >>>
> >>> @@ -254,6 +255,14 @@ static struct miscdevice at91wdt_miscdev = {
> >>> .fops = &at91wdt_fops,
> >>> };
> >>>
> >>> +static inline void __init at91wdt_probe_dt(struct device_node *node)
> >>> +{
> >>> + if (!node)
> >>> + return;
> >>> +
> >>> + of_property_read_u32(node, "timeout", &heartbeat);
> >>> +}
> >>> +
> >>
> >> In patch #1 you add a function to do this, and then you don't make use
> >> of it here ?
> >>
> >> Or am i missing something?
> >
> > I'm using it on the patch #2 for the orion_wdt driver.
> > Do you think it's better to join the #1 and the #2 patch?
> >
> > Best regards
> > --
> > Fabio Porcedda
>
> I'm sorry, only now i understand your question.
> The at91sam9_wdt driver don't use the watchdog core framework si i
> can't use that function cleanly.
> The patch #1 and #2 are for introducing the same property as the
> at91sam9_wdt driver.
So maybe split this up into two different patchsets. One patchset to
add the helper function, and the use of this helper to all watchdog
divers that can use it. I think the following drivers should be
modified:
orion_wdt.c
pnx4008_wdt.c
s3c2410_wdt.c
In a second patchset, convert the AT91SAM9 driver over to the watchdog
core framework, and then use the helper function.
Andrew
^ permalink raw reply
* [kvmarm] [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM support
From: Marc Zyngier @ 2012-10-01 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qKidvG_sOHM197F+1EDtEFTGnLksCJo=12T36JE3u6R4w@mail.gmail.com>
On Sun, 30 Sep 2012 15:21:54 -0400, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> On Thu, Sep 27, 2012 at 10:13 AM, Will Deacon <will.deacon@arm.com>
wrote:
>>
>> I think Marc (CC'd) had a go at this with some success.
>>
>
> great, if this improves the code, then I suggest someone rebases an
> appropriate patch and sends it to the kvmarm mailing list so we can
> have a look at it, but there are users out there looking to try
> kvm/arm and we should try to give it to them.
Incoming.
M.
--
Who you jivin' with that Cosmik Debris?
^ permalink raw reply
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Andrew Lunn @ 2012-10-01 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC_u+bMX7REU5G3u=cm3VGmOUn+AShruw+ERkPJWtZpxUg@mail.gmail.com>
On Mon, Oct 01, 2012 at 02:48:01PM +0200, Fabio Porcedda wrote:
> On Mon, Oct 1, 2012 at 2:45 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
> >> Tested on an at91sam9260 board (evk-pro3)
> >>
> >> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> >> ---
> >> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
> >> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
> >> 2 files changed, 40 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >> new file mode 100644
> >> index 0000000..65c1755
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> >> @@ -0,0 +1,19 @@
> >> +* Atmel Watchdog Timers
> >> +
> >> +** at91sam9-wdt
> >> +
> >> +Required properties:
> >> +- compatible: must be "atmel,at91sam9260-wdt".
> >> +- reg: physical base address of the controller and length of memory mapped
> >> + region.
> >> +
> >> +Optional properties:
> >> +- timeout: contains the watchdog timeout in seconds.
> >> +
> >> +Example:
> >> +
> >> + watchdog at fffffd40 {
> >> + compatible = "atmel,at91sam9260-wdt";
> >> + reg = <0xfffffd40 0x10>;
> >> + timeout = <10>;
> >> + };
> >> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
> >> index 05e1be8..c9e6bfa 100644
> >> --- a/drivers/watchdog/at91sam9_wdt.c
> >> +++ b/drivers/watchdog/at91sam9_wdt.c
> >> @@ -32,6 +32,7 @@
> >> #include <linux/timer.h>
> >> #include <linux/bitops.h>
> >> #include <linux/uaccess.h>
> >> +#include <linux/of.h>
> >>
> >> #include "at91sam9_wdt.h"
> >>
> >> @@ -254,6 +255,14 @@ static struct miscdevice at91wdt_miscdev = {
> >> .fops = &at91wdt_fops,
> >> };
> >>
> >> +static inline void __init at91wdt_probe_dt(struct device_node *node)
> >> +{
> >> + if (!node)
> >> + return;
> >> +
> >> + of_property_read_u32(node, "timeout", &heartbeat);
> >> +}
> >> +
> >
> > In patch #1 you add a function to do this, and then you don't make use
> > of it here ?
> >
> > Or am i missing something?
>
> I'm using it on the patch #2 for the orion_wdt driver.
> Do you think it's better to join the #1 and the #2 patch?
It makes little sense doing this here, because you are going to have
to clean this up sometime very soon and use the helper, unless there
is a very good reason not to use the helper.
Andrew
^ permalink raw reply
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Fabio Porcedda @ 2012-10-01 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC_u+bMX7REU5G3u=cm3VGmOUn+AShruw+ERkPJWtZpxUg@mail.gmail.com>
On Mon, Oct 1, 2012 at 2:48 PM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote:
> On Mon, Oct 1, 2012 at 2:45 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
>>> Tested on an at91sam9260 board (evk-pro3)
>>>
>>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>>> ---
>>> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
>>> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
>>> 2 files changed, 40 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>>> new file mode 100644
>>> index 0000000..65c1755
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>>> @@ -0,0 +1,19 @@
>>> +* Atmel Watchdog Timers
>>> +
>>> +** at91sam9-wdt
>>> +
>>> +Required properties:
>>> +- compatible: must be "atmel,at91sam9260-wdt".
>>> +- reg: physical base address of the controller and length of memory mapped
>>> + region.
>>> +
>>> +Optional properties:
>>> +- timeout: contains the watchdog timeout in seconds.
>>> +
>>> +Example:
>>> +
>>> + watchdog at fffffd40 {
>>> + compatible = "atmel,at91sam9260-wdt";
>>> + reg = <0xfffffd40 0x10>;
>>> + timeout = <10>;
>>> + };
>>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
>>> index 05e1be8..c9e6bfa 100644
>>> --- a/drivers/watchdog/at91sam9_wdt.c
>>> +++ b/drivers/watchdog/at91sam9_wdt.c
>>> @@ -32,6 +32,7 @@
>>> #include <linux/timer.h>
>>> #include <linux/bitops.h>
>>> #include <linux/uaccess.h>
>>> +#include <linux/of.h>
>>>
>>> #include "at91sam9_wdt.h"
>>>
>>> @@ -254,6 +255,14 @@ static struct miscdevice at91wdt_miscdev = {
>>> .fops = &at91wdt_fops,
>>> };
>>>
>>> +static inline void __init at91wdt_probe_dt(struct device_node *node)
>>> +{
>>> + if (!node)
>>> + return;
>>> +
>>> + of_property_read_u32(node, "timeout", &heartbeat);
>>> +}
>>> +
>>
>> In patch #1 you add a function to do this, and then you don't make use
>> of it here ?
>>
>> Or am i missing something?
>
> I'm using it on the patch #2 for the orion_wdt driver.
> Do you think it's better to join the #1 and the #2 patch?
>
> Best regards
> --
> Fabio Porcedda
I'm sorry, only now i understand your question.
The at91sam9_wdt driver don't use the watchdog core framework si i
can't use that function cleanly.
The patch #1 and #2 are for introducing the same property as the
at91sam9_wdt driver.
When the at91sam9_wdt is converted to the watchdog core framework, the
driver can use finally the new function.
Best regards
--
Fabio Porcedda
^ permalink raw reply
* [PATCH v2 0/7] uio_pruss cleanup and platform support
From: Matt Porter @ 2012-10-01 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1209291830270.20956@utopia.booyaka.com>
On Sat, Sep 29, 2012 at 06:34:54PM +0000, Paul Walmsley wrote:
>
> cc Omar
>
> Hi Matt
>
> On Fri, 28 Sep 2012, Matt Porter wrote:
>
> > The AM33xx support requires some help in hwmod due to the following
> > comment in arch/arm/mach-omap2/omap_hwmod.c:
> > /*
> > * If an IP block contains HW reset lines and any of them are
> > * asserted, we let integration code associated with that
> > * block handle the enable. We've received very little
> > * information on what those driver authors need, and until
> > * detailed information is provided and the driver code is
> > * posted to the public lists, this is probably the best we
> > * can do.
> > */
> >
> > The approach to deal with the hardware reset (for at least the pruss
> > hwmod) was to add a generic omap property to properly define this
> > hardware. The implementation simply deasserts any rst lines that
> > are called out in the property when the omap_device is
> > instantiated. This is not the ideal implementation as the sequence is
> > a bit wrong for pruss since the busy check during the hard reset
> > will fail, even though it fails in a benign manner. Ideally, we would
> > want the implementation to observe the ti,deassert-hard-reset property
> > and use that in omap_hwmod.c:_enable() *after* the module is unidled
> > and the clocks active. However, this is actually functional for purposes
> > of getting the uio_pruss driver up and running.
>
> Could you please sync with Omar on the hard reset handling? He posted
> some patches that change the hard reset code. Perhaps you can align on an
> approach with him?
Ok, yes, I looked over his series now and it goes some way to solving
the problem on PRUSS. My only concern is that the approach of loading up
function pointers in pdata for the assert/deassert calls gets a bit ugly on a
DT-only platform like AM33xx. I'll work with Omar on that.
> A few general comments: if some new per-IP block flag is needed to control
> this, the best place for it right now would be the hwmod data in
> arch/arm/mach-omap2/omap_hwmod_*_data.c, rather than DT. At some point
> soon, the hard reset handling will be split between a PRM driver and some
> hwmod bus driver, and it seems best to deal with the DT binding question
> at that time. That way we don't wind up with a legacy binding that has to
> be supported over the long term.
Ok, make sense.
Thanks,
Matt
^ permalink raw reply
* [PATCH 14/15] KVM: ARM: Handle I/O aborts
From: Dave Martin @ 2012-10-01 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qKFKU98EWNaOepjxab3h5vQypxdt_YoJbKV9kd31XUfaw@mail.gmail.com>
On Sun, Sep 30, 2012 at 05:49:21PM -0400, Christoffer Dall wrote:
> On Thu, Sep 27, 2012 at 11:11 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Sat, Sep 15, 2012 at 04:35:59PM +0100, Christoffer Dall wrote:
> >> When the guest accesses I/O memory this will create data abort
> >> exceptions and they are handled by decoding the HSR information
> >> (physical address, read/write, length, register) and forwarding reads
> >> and writes to QEMU which performs the device emulation.
> >>
> >> Certain classes of load/store operations do not support the syndrome
> >> information provided in the HSR and we therefore must be able to fetch
> >> the offending instruction from guest memory and decode it manually.
> >>
> >> We only support instruction decoding for valid reasonable MMIO operations
> >> where trapping them do not provide sufficient information in the HSR (no
> >> 16-bit Thumb instructions provide register writeback that we care about).
> >>
> >> The following instruciton types are NOT supported for MMIO operations
> >> despite the HSR not containing decode info:
> >> - any Load/Store multiple
> >> - any load/store exclusive
> >> - any load/store dual
> >> - anything with the PC as the dest register
> >
> > [...]
> >
> >> +
> >> +/******************************************************************************
> >> + * Load-Store instruction emulation
> >> + *****************************************************************************/
> >> +
> >> +/*
> >> + * Must be ordered with LOADS first and WRITES afterwards
> >> + * for easy distinction when doing MMIO.
> >> + */
> >> +#define NUM_LD_INSTR 9
> >> +enum INSTR_LS_INDEXES {
> >> + INSTR_LS_LDRBT, INSTR_LS_LDRT, INSTR_LS_LDR, INSTR_LS_LDRB,
> >> + INSTR_LS_LDRD, INSTR_LS_LDREX, INSTR_LS_LDRH, INSTR_LS_LDRSB,
> >> + INSTR_LS_LDRSH,
> >> + INSTR_LS_STRBT, INSTR_LS_STRT, INSTR_LS_STR, INSTR_LS_STRB,
> >> + INSTR_LS_STRD, INSTR_LS_STREX, INSTR_LS_STRH,
> >> + NUM_LS_INSTR
> >> +};
> >> +
> >> +static u32 ls_instr[NUM_LS_INSTR][2] = {
> >> + {0x04700000, 0x0d700000}, /* LDRBT */
> >> + {0x04300000, 0x0d700000}, /* LDRT */
> >> + {0x04100000, 0x0c500000}, /* LDR */
> >> + {0x04500000, 0x0c500000}, /* LDRB */
> >> + {0x000000d0, 0x0e1000f0}, /* LDRD */
> >> + {0x01900090, 0x0ff000f0}, /* LDREX */
> >> + {0x001000b0, 0x0e1000f0}, /* LDRH */
> >> + {0x001000d0, 0x0e1000f0}, /* LDRSB */
> >> + {0x001000f0, 0x0e1000f0}, /* LDRSH */
> >> + {0x04600000, 0x0d700000}, /* STRBT */
> >> + {0x04200000, 0x0d700000}, /* STRT */
> >> + {0x04000000, 0x0c500000}, /* STR */
> >> + {0x04400000, 0x0c500000}, /* STRB */
> >> + {0x000000f0, 0x0e1000f0}, /* STRD */
> >> + {0x01800090, 0x0ff000f0}, /* STREX */
> >> + {0x000000b0, 0x0e1000f0} /* STRH */
> >> +};
> >> +
> >> +static inline int get_arm_ls_instr_index(u32 instr)
> >> +{
> >> + return kvm_instr_index(instr, ls_instr, NUM_LS_INSTR);
> >> +}
> >> +
> >> +/*
> >> + * Load-Store instruction decoding
> >> + */
> >> +#define INSTR_LS_TYPE_BIT 26
> >> +#define INSTR_LS_RD_MASK 0x0000f000
> >> +#define INSTR_LS_RD_SHIFT 12
> >> +#define INSTR_LS_RN_MASK 0x000f0000
> >> +#define INSTR_LS_RN_SHIFT 16
> >> +#define INSTR_LS_RM_MASK 0x0000000f
> >> +#define INSTR_LS_OFFSET12_MASK 0x00000fff
> >
> > I'm afraid you're not going to thank me much for this, but it's high time we
> > unified the various instruction decoding functions we have under arch/arm/
> > and this seems like a good opportunity for that. For example, look at the
> > following snippets (there is much more in the files I list) in addition to
> > what you have:
> >
>
> I think it would be great if we had a set of unified decoding functions!
>
> However, I think it's a shame if we can't merge KVM because we want to
> clean up this code. There would be nothing in the way of breaking API
> or anything like that preventing us from cleaning this up after the
> code has been merged.
>
> Please consider reviewing the code for correctness and consider if the
> code could be merged as is.
>
> On the other hand, if you or Dave or anyone else wants to create a set
> of patches that cleans this up in a timely manner, I will be happy to
> merge them for my code as well ;)
The time I would have available to put into this is rather limited, but
I have some initial ideas, as outlined below.
Tixy (who did the kprobes implementation, which is probably the most
sophisticated opcode handling we have in the kernel right now) may have
ideas too. I would hope that any common framework could reuse a fair
chunk of his implementation and test coverage.
I think that a common framework would have to start out a lot more
generic that the special-purpose code in current subsystems, at least
initially. We should try to move all the knowledge about how
instructions are encoded out of subsystems and into the common
framework, so far as possible.
We might end up with an interface like this:
Instruction data in memory <-> __arm_mem_to_opcode*() and friends <-> canonical form
canonical form -> __arm_opcode_decode() -> decoded form
decoded form -> __arm_opcode_encode() -> canonical form
The decoded form might look something like this:
struct arm_insn {
u32 opcode;
u32 flags; /* common flags */
enum arm_insn_type type;
u32 insn_flags; /* insn specific flags */
enum arm_reg Rd;
enum arm_reg Rn;
enum arm_reg Rm;
enum arm_reg Rs;
enum arm_reg Rt;
enum arm_reg Ra;
/* ... */
};
... and so on. This just a sketch, and deliberately very incomplete.
The basic principle here is that the client gets the architectural,
encoding-independent view of the instruction: as far as possible, client
code should never need to know anything about how the encoding works.
The client code should not even need to know for most purposes whether
the instruction is ARM or Thumb, once decoded.
Identifying instruction classes (i.e., is this a VFP/NEON instruction,
does this access memory, does this change the PC) etc. should all be
abstracted as helper functions / macros.
All cleverness involving tables and hashes to accelerate decode and
identify instruction classes should move into the framework, but
we can start out with something stupid and simple: if we only need
to distinguish a few instruction types to begin with, a simple switch
statement for decode may be enough to get started. However, as
things mature, a more sophisticated table-driven approach could be
A good starting point would be load/store emulation as this seems to be a
common theme, and we would need a credible deployment for any new
framework so that we know it's fit for purpose.
So just refactoring the code that appears in the KVM patches could be a
good way of getting such a framework off the ground.
Subsystems could be migrated to the new framework incrementally after
its initial creation, while extending the framework as needed. This
means that the initial that the initial framework could be pretty simple
-- we don't need all the functionality all at once.
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Fabio Porcedda @ 2012-10-01 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001124546.GE11837@lunn.ch>
On Mon, Oct 1, 2012 at 2:45 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
>> Tested on an at91sam9260 board (evk-pro3)
>>
>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>> ---
>> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
>> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
>> 2 files changed, 40 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>>
>> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>> new file mode 100644
>> index 0000000..65c1755
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>> @@ -0,0 +1,19 @@
>> +* Atmel Watchdog Timers
>> +
>> +** at91sam9-wdt
>> +
>> +Required properties:
>> +- compatible: must be "atmel,at91sam9260-wdt".
>> +- reg: physical base address of the controller and length of memory mapped
>> + region.
>> +
>> +Optional properties:
>> +- timeout: contains the watchdog timeout in seconds.
>> +
>> +Example:
>> +
>> + watchdog at fffffd40 {
>> + compatible = "atmel,at91sam9260-wdt";
>> + reg = <0xfffffd40 0x10>;
>> + timeout = <10>;
>> + };
>> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
>> index 05e1be8..c9e6bfa 100644
>> --- a/drivers/watchdog/at91sam9_wdt.c
>> +++ b/drivers/watchdog/at91sam9_wdt.c
>> @@ -32,6 +32,7 @@
>> #include <linux/timer.h>
>> #include <linux/bitops.h>
>> #include <linux/uaccess.h>
>> +#include <linux/of.h>
>>
>> #include "at91sam9_wdt.h"
>>
>> @@ -254,6 +255,14 @@ static struct miscdevice at91wdt_miscdev = {
>> .fops = &at91wdt_fops,
>> };
>>
>> +static inline void __init at91wdt_probe_dt(struct device_node *node)
>> +{
>> + if (!node)
>> + return;
>> +
>> + of_property_read_u32(node, "timeout", &heartbeat);
>> +}
>> +
>
> In patch #1 you add a function to do this, and then you don't make use
> of it here ?
>
> Or am i missing something?
I'm using it on the patch #2 for the orion_wdt driver.
Do you think it's better to join the #1 and the #2 patch?
Best regards
--
Fabio Porcedda
^ permalink raw reply
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Andrew Lunn @ 2012-10-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349094281-28889-4-git-send-email-fabio.porcedda@gmail.com>
On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
> Tested on an at91sam9260 board (evk-pro3)
>
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> new file mode 100644
> index 0000000..65c1755
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
> @@ -0,0 +1,19 @@
> +* Atmel Watchdog Timers
> +
> +** at91sam9-wdt
> +
> +Required properties:
> +- compatible: must be "atmel,at91sam9260-wdt".
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +
> +Optional properties:
> +- timeout: contains the watchdog timeout in seconds.
> +
> +Example:
> +
> + watchdog at fffffd40 {
> + compatible = "atmel,at91sam9260-wdt";
> + reg = <0xfffffd40 0x10>;
> + timeout = <10>;
> + };
> diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
> index 05e1be8..c9e6bfa 100644
> --- a/drivers/watchdog/at91sam9_wdt.c
> +++ b/drivers/watchdog/at91sam9_wdt.c
> @@ -32,6 +32,7 @@
> #include <linux/timer.h>
> #include <linux/bitops.h>
> #include <linux/uaccess.h>
> +#include <linux/of.h>
>
> #include "at91sam9_wdt.h"
>
> @@ -254,6 +255,14 @@ static struct miscdevice at91wdt_miscdev = {
> .fops = &at91wdt_fops,
> };
>
> +static inline void __init at91wdt_probe_dt(struct device_node *node)
> +{
> + if (!node)
> + return;
> +
> + of_property_read_u32(node, "timeout", &heartbeat);
> +}
> +
In patch #1 you add a function to do this, and then you don't make use
of it here ?
Or am i missing something?
Thanks
Andrew
^ permalink raw reply
* [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
From: Matt Porter @ 2012-10-01 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506986B2.1030000@ti.com>
On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> Hi Matt,
>
> On 9/29/2012 1:07 AM, Matt Porter wrote:
> > L3RAM (shared SRAM) is needed for use by several drivers.
> > This creates a genalloc pool and a hook for the platform code
> > to provide the struct gen_pool * in platform data.
> >
> > Signed-off-by: Matt Porter <mporter@ti.com>
>
> I am not sure if any of the DaVinci devices have a need to allocate from
> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> if there is much point in trying to allocate from there.
>
> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> allocation on DA850 makes sense for your case? If yes, can you repost
> with Ben's patch included in your series instead of this patch? I would
> prefer that over creating a new pool for shared RAM.
Hrm, I did look at Ben's earlier patch. The reason I added a separate
pool mostly was so I didn't have to touch the PM code at all. That can
continue using the private SRAM API with the ARM RAM as it is now. The
idea here was to allow that to be separate since no other bus masters
can access the ARM RAM anyway and do something that didn't require
regression testing PM. Also, I figured there's really no reason to use
even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
and working fine for that use case.
The other thing is that Ben's patch needs to be rewritten to at least
have the hook I added so we can provide the gen_pool in platform data.
If you prefer this path still, I can add the needed hook on top of his
original patch. Ultimately, I only *need* genalloc support for the
shared sram so I can remove the private SRAM API from uio_pruss...so I'm
happy with any way to get at it.
Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
remove the private SRAM API usage from the davinci ASoC driver too.
Thanks,
Matt
^ permalink raw reply
* [PATCH v6 5/5] ARM: at91/dts: evk-pro3: enable watchdog
From: Fabio Porcedda @ 2012-10-01 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349094281-28889-1-git-send-email-fabio.porcedda@gmail.com>
Tested on evk-pro3.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
arch/arm/boot/dts/evk-pro3.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/evk-pro3.dts b/arch/arm/boot/dts/evk-pro3.dts
index b7354e6..ce959ee 100644
--- a/arch/arm/boot/dts/evk-pro3.dts
+++ b/arch/arm/boot/dts/evk-pro3.dts
@@ -26,6 +26,10 @@
atmel,vbus-gpio = <&pioC 5 0>;
status = "okay";
};
+
+ watchdog at fffffd40 {
+ status = "okay";
+ };
};
usb0: ohci at 00500000 {
--
1.7.11.3
^ permalink raw reply related
* [PATCH v6 4/5] ARM: at91/dts: add at91sam9_wdt driver to at91sam926x, at91sam9g45
From: Fabio Porcedda @ 2012-10-01 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349094281-28889-1-git-send-email-fabio.porcedda@gmail.com>
Tested on an at91sam9260 board (evk-pro3).
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
arch/arm/boot/dts/at91sam9260.dtsi | 6 ++++++
arch/arm/boot/dts/at91sam9263.dtsi | 6 ++++++
arch/arm/boot/dts/at91sam9g45.dtsi | 6 ++++++
3 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
index 7c95f76..7612193 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -236,6 +236,12 @@
trigger-external;
};
};
+
+ watchdog at fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
index 195019b..d822240 100644
--- a/arch/arm/boot/dts/at91sam9263.dtsi
+++ b/arch/arm/boot/dts/at91sam9263.dtsi
@@ -185,6 +185,12 @@
interrupts = <24 4 2>;
status = "disabled";
};
+
+ watchdog at fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand at 40000000 {
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
index 63751b1..df998ab 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -242,6 +242,12 @@
trigger-value = <0x6>;
};
};
+
+ watchdog at fffffd40 {
+ compatible = "atmel,at91sam9260-wdt";
+ reg = <0xfffffd40 0x10>;
+ status = "disabled";
+ };
};
nand0: nand at 40000000 {
--
1.7.11.3
^ 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