* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Igor Grinberg @ 2012-10-24 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb_zO0G5hsU5hTqnmD6Zju_xBwdmnk6C=Ok1R7-oNT_iQ@mail.gmail.com>
On 10/24/12 10:16, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 8:09 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>
>> From: Kevin Hilman <khilman@ti.com>
>>
>> When debounce clocks are disabled, ensure that the banks
>> dbck_enable_mask is cleared also. Otherwise, context restore on
>> subsequent off-mode transition will restore previous value from the
>> shadow copies (bank->context.debounce*) leading to mismatch state
>> between driver state and hardware state.
>>
>> This was discovered when board code was doing
>>
>> gpio_request_one()
>> gpio_set_debounce()
>> gpio_free()
>>
>> which was leaving the GPIO debounce settings in a confused state.
>> Then, enabling off mode causing bogus state to be restored, leaving
>> GPIO debounce enabled which then prevented the CORE powerdomain from
>> transitioning.
>>
>> Reported-by: Paul Walmsley <paul@pwsan.com>
>> Cc: Igor Grinberg <grinberg@compulab.co.il>
>> Signed-off-by: Kevin Hilman <khilman@ti.com>
>
> Thanks! Applied with Felipe's and Santosh's ACKs.
If not too late:
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Kevin, thanks for the patch and sorry I could not respond on time.
--
Regards,
Igor.
^ permalink raw reply
* [PATCH] arm: mvebu: update defconfig with 3.7 changes
From: Gregory CLEMENT @ 2012-10-24 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350980269-6587-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/23/2012 10:17 AM, Thomas Petazzoni wrote:
> The split of 370 and XP into two Kconfig options and the multiplatform
> kernel support has changed a few Kconfig symbols, so let's update the
> mvebu_defconfig file with the latest changes.
Indeed this patch fixes the mvebu_defconfig which was broken.
But as now mvebu is part of multi_v7_defconfig, shouldn't we just
removed mvebu_defconfig ?
If we to keep it, then you can add my Acked-by.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> ---
> As this is a simple defconfig update against 3.7 changes, it should
> most likely go into 3.7.
> ---
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
From: Maxime Ripard @ 2012-10-24 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87liexrmoz.fsf@thor.barco.com>
Hi Peter,
Le 23/10/2012 21:51, Peter Korsgaard a ?crit :
>>>>>> "MR" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:
>
> Hi Maxime,
>
> I'm fine with the idea, but a few comments:
>
>
> MR> Allow the i2c-mux-gpio to be used by a device tree enabled device. The
> MR> bindings are inspired by the one found in the i2c-mux-pinctrl driver.
>
> MR> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> MR> ---
> MR> .../devicetree/bindings/i2c/i2c-mux-gpio.txt | 81 ++++++++++
> MR> drivers/i2c/muxes/i2c-mux-gpio.c | 169 +++++++++++++++-----
> MR> 2 files changed, 211 insertions(+), 39 deletions(-)
> MR> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
>
> MR> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
> MR> new file mode 100644
> MR> index 0000000..335fc4e
> MR> --- /dev/null
> MR> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
> MR> @@ -0,0 +1,81 @@
> MR> +GPIO-based I2C Bus Mux
> MR> +
> MR> +This binding describes an I2C bus multiplexer that uses GPIOs to
> MR> +route the I2C signals.
> MR> +
> MR> + +-----+ +-----+
> MR> + | dev | | dev |
> MR> + +------------+ +-----+ +-----+
> MR> + | SoC | | |
> MR> + | | /--------+--------+
> MR> + | +------+ | +------+ child bus A, on GPIO value set to 0
> MR> + | | I2C |-|--| Mux |
> MR> + | +------+ | +--+---+ child bus B, on GPIO value set to 1
> MR> + | | | \----------+--------+--------+
> MR> + | +------+ | | | | |
> MR> + | | GPIO |-|-----+ +-----+ +-----+ +-----+
> MR> + | +------+ | | dev | | dev | | dev |
> MR> + +------------+ +-----+ +-----+ +-----+
> MR> +
> MR> +Required properties:
> MR> +- compatible: i2c-mux-gpio
> MR> +- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
> MR> + port is connected to.
> MR> +- mux-gpios: list of gpios to use to control the muxer
>
> s/to use to/used to/
>
>
> MR> +* Standard I2C mux properties. See mux.txt in this directory.
> MR> +* I2C child bus nodes. See mux.txt in this directory.
> MR> +
> MR> +Optional properties:
> MR> +- idle-state: value to set to the muxer when idle. When no value is
>
> How about 'bitmask defining mux state when idle' instead?
Since the array documented as using the bitmasks in the platform_data
and described as an array of bitmasks is called "values", and the file
mux.txt talks about "numbers" to put into reg, won't this be confusing
to have three names for the exact same thing?
> MR> + given, it defaults to the last value used.
> MR> +
> MR> +For each i2c child node, an I2C child bus will be created. They will
> MR> +be numbered based on the reg property of each node.
>
> As far as I can see they are dynamically assigned numbers in the order
> they are listed in the dt.
Ah, yes.
> MR> +
> MR> +Whenever an access is made to a device on a child bus, the value set
> MR> +in the revelant node's reg property will be output using the list of
> MR> +GPIOs, the first in the list holding the most-significant value.
>
> Isn't it the other way around, E.G. first gpio in mux-gpios controlled
> by LSB of reg property, next gpio by lsb+1, ..?
True indeed.
> MR> +
> MR> +If an idle state is defined, using the idle-state (optional) property,
> MR> +whenever an access is not being made to a device on a child bus, the
> MR> +idle value will be programmed into the GPIOs.
>
> s/idle value will be programmed into the GPIOS/GPIOS set according to
> the idle value bitmask/
Once again, I'm really not fond of the term "bitmask".
[..]
> MR> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
> MR> index 566a675..7ebef01 100644
> MR> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
> MR> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
> MR> @@ -16,11 +16,13 @@
> MR> #include <linux/module.h>
> MR> #include <linux/slab.h>
> MR> #include <linux/gpio.h>
> MR> +#include <linux/of_i2c.h>
> MR> +#include <linux/of_gpio.h>
>
> MR> struct gpiomux {
> MR> struct i2c_adapter *parent;
> MR> struct i2c_adapter **adap; /* child busses */
> MR> - struct i2c_mux_gpio_platform_data data;
> MR> + struct i2c_mux_gpio_platform_data *data;
>
>
> Why this change? I don't see why it is needed and the patch would be a
> lot easier to review without all the s/.data/->data/ noise.
Ah yes, since mux is already allocated using kcalloc, we don't need to
do it for data as well. I will remove it.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-24 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023200249.GA2712@core.coreip.homeip.net>
Hi,
On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> > Hi Dimitry,
> >
> > On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > > Hi Sourav,
> > >
> > > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> > >> Adapt keypad to use pinctrl framework.
> > >>
> > >> Tested on omap4430 sdp with 3.7-rc1 kernel.
> > >
> > > I do not see anything in the driver that would directly use pinctrl. Is
> > > there a better place to select default pin configuration; maybe when
> > > instantiating platform device?
> >
> > Why?
> > The devm_pinctrl_get_select_default is using the pinctrl.
>
> No, I guess we ihave different understanding of what "directly use" means.
> This particular driver does directly use interrupts: it requests it and
> performs some actions when interrupt arrives. Same goes for IO memory -
> it gets requested, then we access it. With pinctrl we do not do anything
> - we just ask another layer to configure it and that is it.
this is true for almost anything we do:
- we ask another layer to allocate memory for us
- we ask another layer to call our ISR once the IRQ line is asserted
- we ask another layer to handle the input events we just received
- we ask another layer to transfer data through DMA for us
- we ask another layer to turn regulators on and off.
and so on. This is just how abstractions work, we group common parts in
a framework so that users don't need to know the details, but still need
to tell the framework when to fiddle with those resources.
> I have seen just in a few days 3 or 4 drivers having exactly the same
> change - call to devm_pinctrl_get_select_default(), and I guess I will
> receive the same patches for the rest of input drivers shortly.
> This suggests that the operation is done at the wrong level. Do the
> pin configuration as you parse DT data, the same way you set up i2c
> devices registers in of_i2c.c, and leave the individual drivers that do
> not care about specifics alone.
Makes no sense to hide that from drivers. The idea here is that driver
should know when it needs its pins to muxed correctly. 95% of the time
it will be done during probe() but then again, so what ?
doing that when parsing DT, or on bus notifiers is just plain wrong.
Drivers should be required to handle all of their resources.
> > That's why it is named "get_select_default" and not "get" only.
> > This API ensure that the pin will be set to the default state, and this
> > is all we need to do during the probe.
>
> Why during the probe and not by default? Realistically, the driver will
> be loaded as long as there is a matching device and pins will need to be
> configured.
likewise memory will be allocated when matching happens, IRQs will be
allocated, regulators will be turned on. So why don't we do all that by
default ? Because it is wrong.
> > There is no point to change the mux if the driver is not probed, because
> > potentially the pin can be use be another driver.
>
> What other driver would use it? Who would chose what driver to load?
Well, you _do_ know that on a SoC we have a limited amount of pins
right ?
Considering the amont of features which are packed inside a single die,
it's not farfetched to assume we will have a lot less pins then we
actually need, so we need muxers behind each pin in order to choose
which functionality we want.
If it happens that keypad's pins are shared with another IP (e.g. GPIO),
we need to give the final user (a OEM/ODM) the choice of using those
pins as either keypad or GPIOs, thus the need for pinctrl framework and
the calls in the drivers.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/5220f3db/attachment.sig>
^ permalink raw reply
* [PATCH] GPIO: clps711x: Fix direction logic for PORTD
From: Alexander Shiyan @ 2012-10-24 8:34 UTC (permalink / raw)
To: linux-arm-kernel
PORTD have different direction logic, i.e. "0" is output and "1" is input.
This patch fix this issue.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/gpio/gpio-clps711x.c | 65 +++++++++++++++++++++++++++++++++---------
1 files changed, 51 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
index 0753b3a..ad181db 100644
--- a/drivers/gpio/gpio-clps711x.c
+++ b/drivers/gpio/gpio-clps711x.c
@@ -65,7 +65,7 @@ static void gpio_clps711x_set(struct gpio_chip *chip, unsigned offset,
spin_unlock_irqrestore(&gpio->lock, flags);
}
-static int gpio_clps711x_direction_in(struct gpio_chip *chip, unsigned offset)
+static int gpio_clps711x_dir_in(struct gpio_chip *chip, unsigned offset)
{
int tmp;
unsigned long flags;
@@ -79,8 +79,8 @@ static int gpio_clps711x_direction_in(struct gpio_chip *chip, unsigned offset)
return 0;
}
-static int gpio_clps711x_direction_out(struct gpio_chip *chip, unsigned offset,
- int value)
+static int gpio_clps711x_dir_out(struct gpio_chip *chip, unsigned offset,
+ int value)
{
int tmp;
unsigned long flags;
@@ -98,17 +98,49 @@ static int gpio_clps711x_direction_out(struct gpio_chip *chip, unsigned offset,
return 0;
}
-struct clps711x_gpio_port {
+static int gpio_clps711x_dir_in_inv(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_dir_out_inv(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;
+}
+
+static struct {
char *name;
int nr;
-};
-
-static const struct clps711x_gpio_port clps711x_gpio_ports[] __initconst = {
- { "PORTA", 8, },
- { "PORTB", 8, },
- { "PORTC", 8, },
- { "PORTD", 8, },
- { "PORTE", 3, },
+ int inv_dir;
+} clps711x_gpio_ports[] __initconst = {
+ { "PORTA", 8, 0, },
+ { "PORTB", 8, 0, },
+ { "PORTC", 8, 0, },
+ { "PORTD", 8, 1, },
+ { "PORTE", 3, 0, },
};
static int __init gpio_clps711x_init(void)
@@ -145,10 +177,15 @@ static int __init gpio_clps711x_init(void)
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;
+ if (!clps711x_gpio_ports[i].inv_dir) {
+ gpio->chip[i].direction_input = gpio_clps711x_dir_in;
+ gpio->chip[i].direction_output = gpio_clps711x_dir_out;
+ } else {
+ gpio->chip[i].direction_input = gpio_clps711x_dir_in_inv;
+ gpio->chip[i].direction_output = gpio_clps711x_dir_out_inv;
+ }
WARN_ON(gpiochip_add(&gpio->chip[i]));
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Andrew Lunn @ 2012-10-24 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351065841-18654-3-git-send-email-gregory.clement@free-electrons.com>
On Wed, Oct 24, 2012 at 10:04:01AM +0200, Gregory CLEMENT wrote:
> Armada 370 and XP come with an unit called coherency fabric. This unit
> allows to use the Armada XP as a nearly coherent architecture. The
> coherency mechanism uses snoop filters to ensure the coherency between
> caches, DRAM and devices. This mechanism needs a synchronization
> barrier which guarantees that all memory write initiated by the
> devices has reached their target and do not reside in intermediate
> write buffers. That's why the architecture is not totally coherent and
> we need to provide our own functions for some DMA operations.
>
> Beside the use of the coherency fabric, the device units will have to
> set the attribute flag to select the accurate coherency process for
> the memory transaction. This is done each device driver programs the
> DRAM address windows. The value of the attribute set by the driver is
> retrieved through the orion_addr_map_cfg struct filled during the
> early initialization of the platform.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
> ---
> arch/arm/boot/dts/armada-370-xp.dtsi | 3 +-
> arch/arm/mach-mvebu/addr-map.c | 3 ++
> arch/arm/mach-mvebu/armada-370-xp.c | 1 +
> arch/arm/mach-mvebu/coherency.c | 87 ++++++++++++++++++++++++++++++++++
> arch/arm/mach-mvebu/common.h | 2 +
> 5 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 18ba60b..af22e53 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -38,7 +38,8 @@
>
> coherency-fabric at d0020200 {
> compatible = "marvell,coherency-fabric";
> - reg = <0xd0020200 0xb0>;
> + reg = <0xd0020200 0xb0>,
> + <0xd0021010 0x1c>;
> };
...
> int __init armada_370_xp_coherency_init(void)
> {
> struct device_node *np;
> @@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
> if (np) {
> pr_info("Initializing Coherency fabric\n");
> coherency_base = of_iomap(np, 0);
> + coherency_cpu_base = of_iomap(np, 1);
Is this already in the binding documentation?
Thanks
Andrew
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Linus Walleij @ 2012-10-24 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351015771-6308-1-git-send-email-khilman@deeprootsystems.com>
On Tue, Oct 23, 2012 at 8:09 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> From: Kevin Hilman <khilman@ti.com>
>
> When debounce clocks are disabled, ensure that the banks
> dbck_enable_mask is cleared also. Otherwise, context restore on
> subsequent off-mode transition will restore previous value from the
> shadow copies (bank->context.debounce*) leading to mismatch state
> between driver state and hardware state.
>
> This was discovered when board code was doing
>
> gpio_request_one()
> gpio_set_debounce()
> gpio_free()
>
> which was leaving the GPIO debounce settings in a confused state.
> Then, enabling off mode causing bogus state to be restored, leaving
> GPIO debounce enabled which then prevented the CORE powerdomain from
> transitioning.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
Thanks! Applied with Felipe's and Santosh's ACKs.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Gregory CLEMENT @ 2012-10-24 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2E2747FC8980BB40958FB06A958ED3550144C25FAD4F@IL-MB01.marvell.com>
On 10/24/2012 10:11 AM, Yehuda Yitschak wrote:
>
>
>> -----Original Message-----
>> From: Gregory CLEMENT [mailto:gregory.clement at free-electrons.com]
>> Sent: Wednesday, October 24, 2012 10:04 AM
>> To: Jason Cooper; Andrew Lunn; Gregory Clement
>> Cc: linux-arm-kernel at lists.infradead.org; Arnd Bergmann; Olof Johansson;
>> Russell King; Rob Herring; Ben Dooks; Ian Molton; Nicolas Pitre; Lior
>> Amsalem; Maen Suleiman; Tawfik Bayouk; Shadi Ammouri; Eran Ben-Avi;
>> Yehuda Yitschak; Nadav Haklai; Ike Pan; Jani Monoses; Chris Van Hoof; Dan
>> Frazier; Thomas Petazzoni; Leif Lindholm; Jon Masters; David Marlin;
>> Sebastian Hesselbarth; linux-kernel at vger.kernel.org
>> Subject: [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
>>
>> Armada 370 and XP come with an unit called coherency fabric. This unit
>> allows to use the Armada XP as a nearly coherent architecture. The
>> coherency mechanism uses snoop filters to ensure the coherency between
>> caches, DRAM and devices. This mechanism needs a synchronization barrier
>> which guarantees that all memory write initiated by the devices has
>> reached their target and do not reside in intermediate write buffers. That's
>> why the architecture is not totally coherent and we need to provide our
>> own functions for some DMA operations.
>>
>> Beside the use of the coherency fabric, the device units will have to set the
>> attribute flag to select the accurate coherency process for the memory
>> transaction. This is done each device driver programs the DRAM address
>> windows. The value of the attribute set by the driver is retrieved through
>> the orion_addr_map_cfg struct filled during the early initialization of the
>> platform.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
>> ---
>> arch/arm/boot/dts/armada-370-xp.dtsi | 3 +-
>> arch/arm/mach-mvebu/addr-map.c | 3 ++
>> arch/arm/mach-mvebu/armada-370-xp.c | 1 +
>> arch/arm/mach-mvebu/coherency.c | 87
>> ++++++++++++++++++++++++++++++++++
>> arch/arm/mach-mvebu/common.h | 2 +
>> 5 files changed, 95 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
>> b/arch/arm/boot/dts/armada-370-xp.dtsi
>> index 18ba60b..af22e53 100644
>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>> @@ -38,7 +38,8 @@
>>
>> coherency-fabric at d0020200 {
>> compatible = "marvell,coherency-fabric";
>> - reg = <0xd0020200 0xb0>;
>> + reg = <0xd0020200 0xb0>,
>> + <0xd0021010 0x1c>;
>> };
>>
>> soc {
>> diff --git a/arch/arm/mach-mvebu/addr-map.c b/arch/arm/mach-
>> mvebu/addr-map.c index fe454a4..595f6b7 100644
>> --- a/arch/arm/mach-mvebu/addr-map.c
>> +++ b/arch/arm/mach-mvebu/addr-map.c
>> @@ -108,6 +108,9 @@ static int __init armada_setup_cpu_mbus(void)
>>
>> addr_map_cfg.bridge_virt_base = mbus_unit_addr_decoding_base;
>>
>> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-
>> fabric"))
>> + addr_map_cfg.hw_io_coherency = 1;
>> +
>> /*
>> * Disable, clear and configure windows.
>> */
>> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-
>> mvebu/armada-370-xp.c
>> index 41431a1..3517f7d 100644
>> --- a/arch/arm/mach-mvebu/armada-370-xp.c
>> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
>> @@ -49,6 +49,7 @@ struct sys_timer armada_370_xp_timer = {
>>
>> static void __init armada_370_xp_dt_init(void) {
>> + armada_370_xp_coherency_iocache_init();
>> of_platform_populate(NULL, of_default_bus_match_table, NULL,
>> NULL); }
>>
>> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-
>> mvebu/coherency.c index 71e27ba..a596ca9 100644
>> --- a/arch/arm/mach-mvebu/coherency.c
>> +++ b/arch/arm/mach-mvebu/coherency.c
>> @@ -22,6 +22,10 @@
>> #include <linux/of_address.h>
>> #include <linux/io.h>
>> #include <linux/smp.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/platform_device.h>
>> +#include <asm/smp_plat.h>
>> +
>> #include "armada-370-xp.h"
>>
>> /* Some functions in this file are called very early during SMP @@ -31,16
>> +35,53 @@
>> * value matching its virtual mapping
>> */
>> static void __iomem *coherency_base = ARMADA_370_XP_REGS_VIRT_BASE
>> + 0x20200;
>> +static void __iomem *coherency_cpu_base;
>> +
>> +struct dma_map_ops armada_xp_dma_ops;
>>
>> /* Coherency fabric registers */
>> #define COHERENCY_FABRIC_CTL_OFFSET 0x0
>> #define COHERENCY_FABRIC_CFG_OFFSET 0x4
>>
>> +#define IO_SYNC_BARRIER_CTL_OFFSET 0x0
>> +
>> static struct of_device_id of_coherency_table[] = {
>> {.compatible = "marvell,coherency-fabric"},
>> { /* end of list */ },
>> };
>>
>> +static inline void armada_xp_sync_io_barrier(void) {
>> + writel(0x1, coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET);
>> + while (readl(coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET)
>> & 0x1);
>> +}
>> +
>> +dma_addr_t armada_xp_dma_map_page(struct device *dev, struct page
>> *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + struct dma_attrs *attrs)
>> +{
>> + if (dir != DMA_TO_DEVICE)
>> + armada_xp_sync_io_barrier();
>> + return pfn_to_dma(dev, page_to_pfn(page)) + offset; }
>> +
>> +
>> +void armada_xp_dma_unmap_page(struct device *dev, dma_addr_t
>> dma_handle,
>> + size_t size, enum dma_data_direction dir,
>> + struct dma_attrs *attrs)
>> +{
>> + if (dir != DMA_TO_DEVICE)
>> + armada_xp_sync_io_barrier();
>> +}
>> +
>> +void armada_xp_dma_sync(struct device *dev, dma_addr_t dma_handle,
>> + size_t size, enum dma_data_direction dir) {
>> + if (dir != DMA_TO_DEVICE)
>> + armada_xp_sync_io_barrier();
>> +}
>> +
>
> Shouldn't all the 4 functions above start with armada_370_xp and not armada_xp ?
>
Yes good catch!
>
>> int armada_xp_get_cpu_count(void)
>
> This function can be limited to CONFIG_SP
>
Right
>> {
>> int reg, cnt;
>> @@ -74,6 +115,42 @@ int armada_370_xp_set_cpu_coherent(unsigned int
>> hw_cpu_id, int smp_group_id)
>> return 0;
>> }
>>
>> +static int armada_xp_platform_notifier(struct notifier_block *nb,
>> + unsigned long event, void *__dev) {
>> + struct device *dev = __dev;
>> +
>> + if (event != BUS_NOTIFY_ADD_DEVICE)
>> + return NOTIFY_DONE;
>> + set_dma_ops(dev, &armada_xp_dma_ops);
>> +
>> + return NOTIFY_OK;
>> +}
>> +
>> +static struct notifier_block armada_xp_platform_nb = {
>> + .notifier_call = armada_xp_platform_notifier, };
>> +
>> +void __init armada_370_xp_coherency_iocache_init(void)
>> +{
>> + /* When the coherency fabric is available, the Armada XP and
>> + * Aramada 370 are close to a coherent architecture, so we based
>> + * our dma ops on the coherent one, and just changes the
>> + * operations which need a arch io sync */
>> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-
>> fabric")) {
>> + struct dma_map_ops *dma_ops = &armada_xp_dma_ops;
>> + memcpy(dma_ops, &arm_coherent_dma_ops,
>> sizeof(*dma_ops));
>> + dma_ops->map_page = armada_xp_dma_map_page;
>> + dma_ops->unmap_page = armada_xp_dma_unmap_page;
>> + dma_ops->unmap_sg = arm_dma_ops.unmap_sg;
>> + dma_ops->sync_single_for_cpu = armada_xp_dma_sync;
>> + dma_ops->sync_single_for_device = armada_xp_dma_sync;
>> + dma_ops->sync_sg_for_cpu =
>> arm_dma_ops.sync_sg_for_cpu;
>> + dma_ops->sync_sg_for_device =
>> arm_dma_ops.sync_sg_for_device;
>> + }
>> + bus_register_notifier(&platform_bus_type,
>> &armada_xp_platform_nb); }
>> +
>> int __init armada_370_xp_coherency_init(void)
>> {
>> struct device_node *np;
>> @@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
>> if (np) {
>> pr_info("Initializing Coherency fabric\n");
>> coherency_base = of_iomap(np, 0);
>> + coherency_cpu_base = of_iomap(np, 1);
>> + }
>> +#ifndef CONFIG_SMP
>> + if (coherency_base) {
>> + /* In UP case, cpu coherency is enabled here, in SMP case
>> cpu
>> + * coherency is enabled for each CPU by
>> + * armada_xp_smp_prepare_cpus() in platsmp.c */
>> + int hw_cpuid = cpu_logical_map(smp_processor_id());
>> + armada_370_xp_set_cpu_coherent(hw_cpuid, 0);
>> }
>> +#endif
>>
>> return 0;
>> }
>> diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-
>> mvebu/common.h index 86484bb..fff952e 100644
>> --- a/arch/arm/mach-mvebu/common.h
>> +++ b/arch/arm/mach-mvebu/common.h
>> @@ -23,6 +23,8 @@ void armada_370_xp_handle_irq(struct pt_regs *regs);
>>
>> void armada_xp_cpu_die(unsigned int cpu);
>>
>> +void armada_370_xp_coherency_iocache_init(void);
>> +
>> int armada_370_xp_coherency_init(void);
>> int armada_370_xp_pmsu_init(void);
>> void armada_xp_secondary_startup(void);
>> --
>> 1.7.9.5
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Yehuda Yitschak @ 2012-10-24 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351065841-18654-3-git-send-email-gregory.clement@free-electrons.com>
> -----Original Message-----
> From: Gregory CLEMENT [mailto:gregory.clement at free-electrons.com]
> Sent: Wednesday, October 24, 2012 10:04 AM
> To: Jason Cooper; Andrew Lunn; Gregory Clement
> Cc: linux-arm-kernel at lists.infradead.org; Arnd Bergmann; Olof Johansson;
> Russell King; Rob Herring; Ben Dooks; Ian Molton; Nicolas Pitre; Lior
> Amsalem; Maen Suleiman; Tawfik Bayouk; Shadi Ammouri; Eran Ben-Avi;
> Yehuda Yitschak; Nadav Haklai; Ike Pan; Jani Monoses; Chris Van Hoof; Dan
> Frazier; Thomas Petazzoni; Leif Lindholm; Jon Masters; David Marlin;
> Sebastian Hesselbarth; linux-kernel at vger.kernel.org
> Subject: [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
>
> Armada 370 and XP come with an unit called coherency fabric. This unit
> allows to use the Armada XP as a nearly coherent architecture. The
> coherency mechanism uses snoop filters to ensure the coherency between
> caches, DRAM and devices. This mechanism needs a synchronization barrier
> which guarantees that all memory write initiated by the devices has
> reached their target and do not reside in intermediate write buffers. That's
> why the architecture is not totally coherent and we need to provide our
> own functions for some DMA operations.
>
> Beside the use of the coherency fabric, the device units will have to set the
> attribute flag to select the accurate coherency process for the memory
> transaction. This is done each device driver programs the DRAM address
> windows. The value of the attribute set by the driver is retrieved through
> the orion_addr_map_cfg struct filled during the early initialization of the
> platform.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
> ---
> arch/arm/boot/dts/armada-370-xp.dtsi | 3 +-
> arch/arm/mach-mvebu/addr-map.c | 3 ++
> arch/arm/mach-mvebu/armada-370-xp.c | 1 +
> arch/arm/mach-mvebu/coherency.c | 87
> ++++++++++++++++++++++++++++++++++
> arch/arm/mach-mvebu/common.h | 2 +
> 5 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
> b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 18ba60b..af22e53 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -38,7 +38,8 @@
>
> coherency-fabric at d0020200 {
> compatible = "marvell,coherency-fabric";
> - reg = <0xd0020200 0xb0>;
> + reg = <0xd0020200 0xb0>,
> + <0xd0021010 0x1c>;
> };
>
> soc {
> diff --git a/arch/arm/mach-mvebu/addr-map.c b/arch/arm/mach-
> mvebu/addr-map.c index fe454a4..595f6b7 100644
> --- a/arch/arm/mach-mvebu/addr-map.c
> +++ b/arch/arm/mach-mvebu/addr-map.c
> @@ -108,6 +108,9 @@ static int __init armada_setup_cpu_mbus(void)
>
> addr_map_cfg.bridge_virt_base = mbus_unit_addr_decoding_base;
>
> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-
> fabric"))
> + addr_map_cfg.hw_io_coherency = 1;
> +
> /*
> * Disable, clear and configure windows.
> */
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-
> mvebu/armada-370-xp.c
> index 41431a1..3517f7d 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -49,6 +49,7 @@ struct sys_timer armada_370_xp_timer = {
>
> static void __init armada_370_xp_dt_init(void) {
> + armada_370_xp_coherency_iocache_init();
> of_platform_populate(NULL, of_default_bus_match_table, NULL,
> NULL); }
>
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-
> mvebu/coherency.c index 71e27ba..a596ca9 100644
> --- a/arch/arm/mach-mvebu/coherency.c
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -22,6 +22,10 @@
> #include <linux/of_address.h>
> #include <linux/io.h>
> #include <linux/smp.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/platform_device.h>
> +#include <asm/smp_plat.h>
> +
> #include "armada-370-xp.h"
>
> /* Some functions in this file are called very early during SMP @@ -31,16
> +35,53 @@
> * value matching its virtual mapping
> */
> static void __iomem *coherency_base = ARMADA_370_XP_REGS_VIRT_BASE
> + 0x20200;
> +static void __iomem *coherency_cpu_base;
> +
> +struct dma_map_ops armada_xp_dma_ops;
>
> /* Coherency fabric registers */
> #define COHERENCY_FABRIC_CTL_OFFSET 0x0
> #define COHERENCY_FABRIC_CFG_OFFSET 0x4
>
> +#define IO_SYNC_BARRIER_CTL_OFFSET 0x0
> +
> static struct of_device_id of_coherency_table[] = {
> {.compatible = "marvell,coherency-fabric"},
> { /* end of list */ },
> };
>
> +static inline void armada_xp_sync_io_barrier(void) {
> + writel(0x1, coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET);
> + while (readl(coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET)
> & 0x1);
> +}
> +
> +dma_addr_t armada_xp_dma_map_page(struct device *dev, struct page
> *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + if (dir != DMA_TO_DEVICE)
> + armada_xp_sync_io_barrier();
> + return pfn_to_dma(dev, page_to_pfn(page)) + offset; }
> +
> +
> +void armada_xp_dma_unmap_page(struct device *dev, dma_addr_t
> dma_handle,
> + size_t size, enum dma_data_direction dir,
> + struct dma_attrs *attrs)
> +{
> + if (dir != DMA_TO_DEVICE)
> + armada_xp_sync_io_barrier();
> +}
> +
> +void armada_xp_dma_sync(struct device *dev, dma_addr_t dma_handle,
> + size_t size, enum dma_data_direction dir) {
> + if (dir != DMA_TO_DEVICE)
> + armada_xp_sync_io_barrier();
> +}
> +
Shouldn't all the 4 functions above start with armada_370_xp and not armada_xp ?
> int armada_xp_get_cpu_count(void)
This function can be limited to CONFIG_SP
> {
> int reg, cnt;
> @@ -74,6 +115,42 @@ int armada_370_xp_set_cpu_coherent(unsigned int
> hw_cpu_id, int smp_group_id)
> return 0;
> }
>
> +static int armada_xp_platform_notifier(struct notifier_block *nb,
> + unsigned long event, void *__dev) {
> + struct device *dev = __dev;
> +
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> + set_dma_ops(dev, &armada_xp_dma_ops);
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block armada_xp_platform_nb = {
> + .notifier_call = armada_xp_platform_notifier, };
> +
> +void __init armada_370_xp_coherency_iocache_init(void)
> +{
> + /* When the coherency fabric is available, the Armada XP and
> + * Aramada 370 are close to a coherent architecture, so we based
> + * our dma ops on the coherent one, and just changes the
> + * operations which need a arch io sync */
> + if (of_find_compatible_node(NULL, NULL, "marvell,coherency-
> fabric")) {
> + struct dma_map_ops *dma_ops = &armada_xp_dma_ops;
> + memcpy(dma_ops, &arm_coherent_dma_ops,
> sizeof(*dma_ops));
> + dma_ops->map_page = armada_xp_dma_map_page;
> + dma_ops->unmap_page = armada_xp_dma_unmap_page;
> + dma_ops->unmap_sg = arm_dma_ops.unmap_sg;
> + dma_ops->sync_single_for_cpu = armada_xp_dma_sync;
> + dma_ops->sync_single_for_device = armada_xp_dma_sync;
> + dma_ops->sync_sg_for_cpu =
> arm_dma_ops.sync_sg_for_cpu;
> + dma_ops->sync_sg_for_device =
> arm_dma_ops.sync_sg_for_device;
> + }
> + bus_register_notifier(&platform_bus_type,
> &armada_xp_platform_nb); }
> +
> int __init armada_370_xp_coherency_init(void)
> {
> struct device_node *np;
> @@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
> if (np) {
> pr_info("Initializing Coherency fabric\n");
> coherency_base = of_iomap(np, 0);
> + coherency_cpu_base = of_iomap(np, 1);
> + }
> +#ifndef CONFIG_SMP
> + if (coherency_base) {
> + /* In UP case, cpu coherency is enabled here, in SMP case
> cpu
> + * coherency is enabled for each CPU by
> + * armada_xp_smp_prepare_cpus() in platsmp.c */
> + int hw_cpuid = cpu_logical_map(smp_processor_id());
> + armada_370_xp_set_cpu_coherent(hw_cpuid, 0);
> }
> +#endif
>
> return 0;
> }
> diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-
> mvebu/common.h index 86484bb..fff952e 100644
> --- a/arch/arm/mach-mvebu/common.h
> +++ b/arch/arm/mach-mvebu/common.h
> @@ -23,6 +23,8 @@ void armada_370_xp_handle_irq(struct pt_regs *regs);
>
> void armada_xp_cpu_die(unsigned int cpu);
>
> +void armada_370_xp_coherency_iocache_init(void);
> +
> int armada_370_xp_coherency_init(void);
> int armada_370_xp_pmsu_init(void);
> void armada_xp_secondary_startup(void);
> --
> 1.7.9.5
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: Use DT_MACHINE for mackerel
From: Simon Horman @ 2012-10-24 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351057680-4755-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
On Wed, Oct 24, 2012 at 02:48:00PM +0900, Nobuhiro Iwamatsu wrote:
> Use DT_MACHINE_START() on the sh7372 based mackerel board.
>
> Also include a tiny DTS file to describe the board and update the
> Kconfig dependencies to select CONFIG_USE_OF.
Thanks, I have applied this to the boards branch of
my renesas tree.
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support
From: Gregory CLEMENT @ 2012-10-24 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351065841-18654-1-git-send-email-gregory.clement@free-electrons.com>
Armada 370 and XP come with an unit called coherency fabric. This unit
allows to use the Armada XP as a nearly coherent architecture. The
coherency mechanism uses snoop filters to ensure the coherency between
caches, DRAM and devices. This mechanism needs a synchronization
barrier which guarantees that all memory write initiated by the
devices has reached their target and do not reside in intermediate
write buffers. That's why the architecture is not totally coherent and
we need to provide our own functions for some DMA operations.
Beside the use of the coherency fabric, the device units will have to
set the attribute flag to select the accurate coherency process for
the memory transaction. This is done each device driver programs the
DRAM address windows. The value of the attribute set by the driver is
retrieved through the orion_addr_map_cfg struct filled during the
early initialization of the platform.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 3 +-
arch/arm/mach-mvebu/addr-map.c | 3 ++
arch/arm/mach-mvebu/armada-370-xp.c | 1 +
arch/arm/mach-mvebu/coherency.c | 87 ++++++++++++++++++++++++++++++++++
arch/arm/mach-mvebu/common.h | 2 +
5 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 18ba60b..af22e53 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -38,7 +38,8 @@
coherency-fabric at d0020200 {
compatible = "marvell,coherency-fabric";
- reg = <0xd0020200 0xb0>;
+ reg = <0xd0020200 0xb0>,
+ <0xd0021010 0x1c>;
};
soc {
diff --git a/arch/arm/mach-mvebu/addr-map.c b/arch/arm/mach-mvebu/addr-map.c
index fe454a4..595f6b7 100644
--- a/arch/arm/mach-mvebu/addr-map.c
+++ b/arch/arm/mach-mvebu/addr-map.c
@@ -108,6 +108,9 @@ static int __init armada_setup_cpu_mbus(void)
addr_map_cfg.bridge_virt_base = mbus_unit_addr_decoding_base;
+ if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric"))
+ addr_map_cfg.hw_io_coherency = 1;
+
/*
* Disable, clear and configure windows.
*/
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 41431a1..3517f7d 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -49,6 +49,7 @@ struct sys_timer armada_370_xp_timer = {
static void __init armada_370_xp_dt_init(void)
{
+ armada_370_xp_coherency_iocache_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 71e27ba..a596ca9 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -22,6 +22,10 @@
#include <linux/of_address.h>
#include <linux/io.h>
#include <linux/smp.h>
+#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
+#include <asm/smp_plat.h>
+
#include "armada-370-xp.h"
/* Some functions in this file are called very early during SMP
@@ -31,16 +35,53 @@
* value matching its virtual mapping
*/
static void __iomem *coherency_base = ARMADA_370_XP_REGS_VIRT_BASE + 0x20200;
+static void __iomem *coherency_cpu_base;
+
+struct dma_map_ops armada_xp_dma_ops;
/* Coherency fabric registers */
#define COHERENCY_FABRIC_CTL_OFFSET 0x0
#define COHERENCY_FABRIC_CFG_OFFSET 0x4
+#define IO_SYNC_BARRIER_CTL_OFFSET 0x0
+
static struct of_device_id of_coherency_table[] = {
{.compatible = "marvell,coherency-fabric"},
{ /* end of list */ },
};
+static inline void armada_xp_sync_io_barrier(void)
+{
+ writel(0x1, coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET);
+ while (readl(coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET) & 0x1);
+}
+
+dma_addr_t armada_xp_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ if (dir != DMA_TO_DEVICE)
+ armada_xp_sync_io_barrier();
+ return pfn_to_dma(dev, page_to_pfn(page)) + offset;
+}
+
+
+void armada_xp_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ if (dir != DMA_TO_DEVICE)
+ armada_xp_sync_io_barrier();
+}
+
+void armada_xp_dma_sync(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir)
+{
+ if (dir != DMA_TO_DEVICE)
+ armada_xp_sync_io_barrier();
+}
+
int armada_xp_get_cpu_count(void)
{
int reg, cnt;
@@ -74,6 +115,42 @@ int armada_370_xp_set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
return 0;
}
+static int armada_xp_platform_notifier(struct notifier_block *nb,
+ unsigned long event, void *__dev)
+{
+ struct device *dev = __dev;
+
+ if (event != BUS_NOTIFY_ADD_DEVICE)
+ return NOTIFY_DONE;
+ set_dma_ops(dev, &armada_xp_dma_ops);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block armada_xp_platform_nb = {
+ .notifier_call = armada_xp_platform_notifier,
+};
+
+void __init armada_370_xp_coherency_iocache_init(void)
+{
+ /* When the coherency fabric is available, the Armada XP and
+ * Aramada 370 are close to a coherent architecture, so we based
+ * our dma ops on the coherent one, and just changes the
+ * operations which need a arch io sync */
+ if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric")) {
+ struct dma_map_ops *dma_ops = &armada_xp_dma_ops;
+ memcpy(dma_ops, &arm_coherent_dma_ops, sizeof(*dma_ops));
+ dma_ops->map_page = armada_xp_dma_map_page;
+ dma_ops->unmap_page = armada_xp_dma_unmap_page;
+ dma_ops->unmap_sg = arm_dma_ops.unmap_sg;
+ dma_ops->sync_single_for_cpu = armada_xp_dma_sync;
+ dma_ops->sync_single_for_device = armada_xp_dma_sync;
+ dma_ops->sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
+ dma_ops->sync_sg_for_device = arm_dma_ops.sync_sg_for_device;
+ }
+ bus_register_notifier(&platform_bus_type, &armada_xp_platform_nb);
+}
+
int __init armada_370_xp_coherency_init(void)
{
struct device_node *np;
@@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
if (np) {
pr_info("Initializing Coherency fabric\n");
coherency_base = of_iomap(np, 0);
+ coherency_cpu_base = of_iomap(np, 1);
+ }
+#ifndef CONFIG_SMP
+ if (coherency_base) {
+ /* In UP case, cpu coherency is enabled here, in SMP case cpu
+ * coherency is enabled for each CPU by
+ * armada_xp_smp_prepare_cpus() in platsmp.c */
+ int hw_cpuid = cpu_logical_map(smp_processor_id());
+ armada_370_xp_set_cpu_coherent(hw_cpuid, 0);
}
+#endif
return 0;
}
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 86484bb..fff952e 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -23,6 +23,8 @@ void armada_370_xp_handle_irq(struct pt_regs *regs);
void armada_xp_cpu_die(unsigned int cpu);
+void armada_370_xp_coherency_iocache_init(void);
+
int armada_370_xp_coherency_init(void);
int armada_370_xp_pmsu_init(void);
void armada_xp_secondary_startup(void);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] arm: plat-orion: Add coherency attribute when setup mbus target
From: Gregory CLEMENT @ 2012-10-24 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351065841-18654-1-git-send-email-gregory.clement@free-electrons.com>
Recent SoC such as Armada 370/XP came with the possibility to deal
with the I/O coherency by hardware. In this case the transaction
attribute of the window must be flagged as "Shared transaction". Once
this flag is set, then the transactions will be forced to be sent
through the coherency block, in other case transaction is driven
directly to DRAM.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Yehuda Yitschak <yehuday@marvell.com>
---
arch/arm/plat-orion/addr-map.c | 4 ++++
arch/arm/plat-orion/include/plat/addr-map.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm/plat-orion/addr-map.c b/arch/arm/plat-orion/addr-map.c
index a7b8060..febe386 100644
--- a/arch/arm/plat-orion/addr-map.c
+++ b/arch/arm/plat-orion/addr-map.c
@@ -42,6 +42,8 @@ EXPORT_SYMBOL_GPL(mv_mbus_dram_info);
#define WIN_REMAP_LO_OFF 0x0008
#define WIN_REMAP_HI_OFF 0x000c
+#define ATTR_HW_COHERENCY (0x1 << 4)
+
/*
* Default implementation
*/
@@ -163,6 +165,8 @@ void __init orion_setup_cpu_mbus_target(const struct orion_addr_map_cfg *cfg,
w = &orion_mbus_dram_info.cs[cs++];
w->cs_index = i;
w->mbus_attr = 0xf & ~(1 << i);
+ if (cfg->hw_io_coherency)
+ w->mbus_attr |= ATTR_HW_COHERENCY;
w->base = base & 0xffff0000;
w->size = (size | 0x0000ffff) + 1;
}
diff --git a/arch/arm/plat-orion/include/plat/addr-map.h b/arch/arm/plat-orion/include/plat/addr-map.h
index ec63e4a..b76c065 100644
--- a/arch/arm/plat-orion/include/plat/addr-map.h
+++ b/arch/arm/plat-orion/include/plat/addr-map.h
@@ -17,6 +17,7 @@ struct orion_addr_map_cfg {
const int num_wins; /* Total number of windows */
const int remappable_wins;
void __iomem *bridge_virt_base;
+ int hw_io_coherency;
/* If NULL, the default cpu_win_can_remap will be used, using
the value in remappable_wins */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] Add hardware I/O coherency support for Armada 370/XP
From: Gregory CLEMENT @ 2012-10-24 8:03 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
The purpose of this patch set is to add hardware I/O Coherency support
for Armada 370 and Armada XP. Theses SoCs come with an unit called
coherency fabric. A beginning of the support for this unit have been
introduced with the SMP patch set. This series extend this support:
the coherency fabric unit allows to use the Armada XP and the Armada
370 as nearly coherent architectures.
The second patches enables this new feature and register our own set
of DMA ops, to benefit this hardware enhancement.
The first patch introduces a new flag for the address decoding
configuration in order to be able to set the memory windows as
shared memory.
This series depend on the SMP patch set posted on Monday
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/194901).
Regards,
Gregory
Gregory CLEMENT (2):
arm: plat-orion: Add coherency attribute when setup mbus target
arm: mvebu: Add hardware I/O Coherency support
arch/arm/boot/dts/armada-370-xp.dtsi | 3 +-
arch/arm/mach-mvebu/addr-map.c | 3 +
arch/arm/mach-mvebu/armada-370-xp.c | 1 +
arch/arm/mach-mvebu/coherency.c | 87 +++++++++++++++++++++++++++
arch/arm/mach-mvebu/common.h | 2 +
arch/arm/plat-orion/addr-map.c | 4 ++
arch/arm/plat-orion/include/plat/addr-map.h | 1 +
7 files changed, 100 insertions(+), 1 deletion(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH] GPIO: clps711x: Fix return value for gpio_clps711x_get
From: Linus Walleij @ 2012-10-24 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351061937-11629-1-git-send-email-shc_work@mail.ru>
On Wed, Oct 24, 2012 at 8:58 AM, Alexander Shiyan <shc_work@mail.ru> wrote:
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> drivers/gpio/gpio-clps711x.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks, patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] i.MX fixes for -rc
From: Sascha Hauer @ 2012-10-24 7:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Please pull the following, mostly clock related, i.MX fixes for -rc.
Thanks
Sascha
The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9:
Linux 3.6 (2012-09-30 16:47:46 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-fixes
for you to fetch changes up to 92063cee118655d25b50d04eb77b012f3287357a:
ARM i.MX25: Fix PWM per clock lookups (2012-10-10 10:02:42 +0200)
----------------------------------------------------------------
ARM i.MX fixes for 3.7-rc
----------------------------------------------------------------
Fabio Estevam (3):
ARM: imx_v6_v7_defconfig: Enable CONFIG_GPIO_MC9S08DZ60
ARM: imx: clk-imx27: Fix divider width field
ARM: mxc: platform-mxc-mmc: Fix register region size
Sascha Hauer (3):
ARM i.MX25: Fix lcdc_ipg_per parent clock
ARM i.MX25 clk: Fix nfc_ipg_per parent
ARM i.MX25: Fix PWM per clock lookups
Wei Yongjun (2):
ARM: imx: fix return value check in imx3_init_l2x0()
ARM: imx: fix the return value check in imx_clk_busy_divider()
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
arch/arm/mach-imx/clk-busy.c | 2 +-
arch/arm/mach-imx/clk-imx25.c | 12 ++++++------
arch/arm/mach-imx/clk-imx27.c | 4 ++--
arch/arm/mach-imx/mm-imx3.c | 5 ++---
arch/arm/plat-mxc/devices/platform-mxc-mmc.c | 2 +-
6 files changed, 14 insertions(+), 13 deletions(-)
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: javier Martin @ 2012-10-24 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BpJAEdwKRVE47D+7wggLsvCXtPcv272UPYsZV6v3vKMg@mail.gmail.com>
On 23 October 2012 00:17, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Guennadi
>
> On Mon, Oct 22, 2012 at 7:07 PM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
>> ? I don't find a clock named "per" and associated with "mx2-camera.0" in
>> arch/arm/mach-imx/clk-imx27.c. I only find it in clk-imx25.c. Does this
>> mean, that this your patch is for i.MX25? But you're saying it's for
>> i.MX27. Confused...
>
> I provide this mx27 clock in the first patch of the series:
> http://patchwork.linuxtv.org/patch/14915/
Yes, I made the same mistake.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
^ permalink raw reply
* [PATCH 1/1] pinctrl: at91: fix typo on PULL_UP
From: Linus Walleij @ 2012-10-24 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351009680-15892-1-git-send-email-plagnioj@jcrosoft.com>
On Tue, Oct 23, 2012 at 6:28 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Ludovic Desroches <ludovic.desroches@atmel.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/pinctrl/pinctrl-at91.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index c87c2c5..0757e94 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -58,7 +58,7 @@ static struct at91_gpio_chip *gpio_chips[MAX_GPIO_BANKS];
>
> static int gpio_banks;
>
> -#define PULL_UP (0 << 1)
> +#define PULL_UP (1 << 0)
Makes perfect sense. Shall I just apply this to the at91 branch too?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
From: Benoit Cousson @ 2012-10-24 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5086C29C.5000209@ti.com>
On 10/23/2012 06:15 PM, Sebastien Guiriec wrote:
> Hi Benoit and John,
>
> On 10/23/2012 06:07 PM, Benoit Cousson wrote:
>> On 10/23/2012 05:59 PM, Jon Hunter wrote:
>>>
>>> On 10/23/2012 10:09 AM, Benoit Cousson wrote:
>>>> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>>>>> Hi Seb,
>>>>>
>>>>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>>>>>> Add base address and interrupt line inside Device Tree data for
>>>>>> OMAP5
>>>>>>
>>>>>> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
>>>>>> ---
>>>>>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++++
>>>>>> 1 file changed, 16 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi
>>>>>> b/arch/arm/boot/dts/omap5.dtsi
>>>>>> index 42c78be..9e39f9f 100644
>>>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>>>> @@ -104,6 +104,8 @@
>>>>>>
>>>>>> gpio1: gpio at 4ae10000 {
>>>>>> compatible = "ti,omap4-gpio";
>>>>>> + reg = <0x4ae10000 0x200>;
>>>>>> + interrupts = <0 29 0x4>;
>>>>>> ti,hwmods = "gpio1";
>>>>>> gpio-controller;
>>>>>> #gpio-cells = <2>;
>>>>>
>>>>> I am wondering if we should add the "interrupt-parent" property to add
>>>>> nodes in the device-tree source. I know that today the
>>>>> interrupt-parent
>>>>> is being defined globally, but when device-tree maps an interrupt
>>>>> for a
>>>>> device it searches for the interrupt-parent starting the current
>>>>> device
>>>>> node.
>>>>>
>>>>> So in other words, for gpio1 it will search the gpio1 binding for
>>>>> "interrupt-parent" and if not found move up a level and search
>>>>> again. It
>>>>> will keep doing this until it finds the "interrupt-parent".
>>>>>
>>>>> Therefore, I believe it will improve search time and hence, boot
>>>>> time if
>>>>> we have interrupt-parent defined in each node.
>>>>
>>>> Mmm, I'm not that sure. it will increase the size of the blob, so
>>>> increase the time to load it and then to parse it. Where in the current
>>>> case, it is just going up to the parent node using the already
>>>> un-flatten tree in memory and thus that should not take that much time.
>>>
>>> Yes it will definitely increase the size, so that could slow things
>>> down.
>>>
>>>> That being said, it might be interesting to benchmark that to see what
>>>> is the real impact.
>>>
>>> Right, I wonder what the key functions are we need to benchmark to get
>>> an overall feel for what is best? Right now I am seeing some people add
>>> the interrupt-parent for device nodes and others not. Ideally we should
>>> be consistent, but at the same time it is probably something that we can
>>> easily sort out later. So not a big deal either way.
>>
>> For consistency, I'd rather not add it at all for the moment.
>> Later, when we will only support DT boot, people will start complaining
>> about the boot time increase and then we will start optimizing a little
>> bit :-)
>
> I just do it like that to be consistent with what is inside OMAP4 dtsi
> for those IPs (GPIO/UART/MMC/I2C). Now after checking Peter already add
> the interrupt-parent for all audio IPs (OMAP3/4/5). But here we need
> also interrupts name. So here we should try to be consistent.
>
> So I can send back the series for OMAP5 and update the OMAP4 with
> interrupts-parent = <&gic>
No, you should not, as explained previously. You'd better remove the one
already in audio IPs for consistency.
Regards,
Benoit
^ permalink raw reply
* [PATCH 1/1] gpio/at91: auto request and configure the pio as input when the interrupt is used via DT
From: Linus Walleij @ 2012-10-24 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351000601-3141-1-git-send-email-plagnioj@jcrosoft.com>
On Tue, Oct 23, 2012 at 3:56 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> If we do this
>
> interrupt-parent = <&pioA>;
> interrupts = <7 0x0>;
>
> The current core map the irq correctly but the gpio is not configured as input.
> The pinctrl configure the pin as gpio with the correct mux parameter but is
> not responsible to configure it as input.
>
> So do it during the xlate
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Looks OK to me: do you want me to just apply it on my AT91 branch
on the pinctrl tree?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Felipe Balbi @ 2012-10-24 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k3ug7st2.fsf@deeprootsystems.com>
On Tue, Oct 23, 2012 at 03:00:09PM -0700, Kevin Hilman wrote:
> Felipe Balbi <balbi@ti.com> writes:
>
> > Hi,
> >
> > On Tue, Oct 23, 2012 at 11:09:31AM -0700, Kevin Hilman wrote:
> >> From: Kevin Hilman <khilman@ti.com>
> >>
> >> When debounce clocks are disabled, ensure that the banks
> >> dbck_enable_mask is cleared also. Otherwise, context restore on
> >> subsequent off-mode transition will restore previous value from the
> >> shadow copies (bank->context.debounce*) leading to mismatch state
> >> between driver state and hardware state.
> >>
> >> This was discovered when board code was doing
> >>
> >> gpio_request_one()
> >> gpio_set_debounce()
> >> gpio_free()
> >>
> >> which was leaving the GPIO debounce settings in a confused state.
> >> Then, enabling off mode causing bogus state to be restored, leaving
> >> GPIO debounce enabled which then prevented the CORE powerdomain from
> >> transitioning.
> >>
> >> Reported-by: Paul Walmsley <paul@pwsan.com>
> >> Cc: Igor Grinberg <grinberg@compulab.co.il>
> >> Signed-off-by: Kevin Hilman <khilman@ti.com>
> >
> > looks like this deserves a Cc: stable at vger.kernel.org tag.
> >
>
> Agreed. I think this goes all the way back to v3.5, but would've only
> been seen on boards using a request/gpio_set_debounce/free sequence
> combined with off-mode.
>
> Linus, feel free to add the Cc: stable when commiting. Thanks.
>
> >> ---
> >> Applies on v3.7-rc2, targetted for v3.7.
> >>
> >> drivers/gpio/gpio-omap.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> >> index 94cbc84..dee2856 100644
> >> --- a/drivers/gpio/gpio-omap.c
> >> +++ b/drivers/gpio/gpio-omap.c
> >> @@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank *bank)
> >> * to detect events and generate interrupts at least on OMAP3.
> >> */
> >> __raw_writel(0, bank->base + bank->regs->debounce_en);
> >> + bank->dbck_enable_mask = 0;
> >
> > shouldn't omap_gpio_restore_context() check for dbck_enabled instead of
> > the mask ? I mean:
> >
> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> > index 94cbc84..b3a39a7 100644
> > --- a/drivers/gpio/gpio-omap.c
> > +++ b/drivers/gpio/gpio-omap.c
> > @@ -1371,7 +1371,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
> > bank->base + bank->regs->dataout);
> > __raw_writel(bank->context.oe, bank->base + bank->regs->direction);
> >
> > - if (bank->dbck_enable_mask) {
> > + if (bank->dbck_enabled) {
> > __raw_writel(bank->context.debounce, bank->base +
> > bank->regs->debounce);
> > __raw_writel(bank->context.debounce_en,
> >
> > the outcome would be the same, so it doesn't really matter. Just that,
> > at least to me, it would look better.
>
> I tried your version, and unfortunately, the outcome is not the same,
> but don't plan to look into why. $SUBJECT version is targetted and
> tested. If you want to cleanup the cosmetics here, please do in a
> subsequent patch. This driver could certainly benefit from more
> readability cleanups.
>
> > No strong feelings though.
>
> Good. I'll take that as an Ack. :)
please do:
Acked-by: Felipe Balbi <balbi@ti.com>
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/c1558a7a/attachment.sig>
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Santosh Shilimkar @ 2012-10-24 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351015771-6308-1-git-send-email-khilman@deeprootsystems.com>
On Tuesday 23 October 2012 11:39 PM, Kevin Hilman wrote:
> From: Kevin Hilman <khilman@ti.com>
>
> When debounce clocks are disabled, ensure that the banks
> dbck_enable_mask is cleared also. Otherwise, context restore on
> subsequent off-mode transition will restore previous value from the
> shadow copies (bank->context.debounce*) leading to mismatch state
> between driver state and hardware state.
>
> This was discovered when board code was doing
>
> gpio_request_one()
> gpio_set_debounce()
> gpio_free()
>
> which was leaving the GPIO debounce settings in a confused state.
> Then, enabling off mode causing bogus state to be restored, leaving
> GPIO debounce enabled which then prevented the CORE powerdomain from
> transitioning.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: omap5: Update MMC with address space and interrupts
From: Sebastien Guiriec @ 2012-10-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351062434-22514-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b535d8e..304dd8d 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -304,6 +304,9 @@
mmc1: mmc at 4809c000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ interrupts = <0 83 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
@@ -311,24 +314,36 @@
mmc2: mmc at 480b4000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480b4000 0x400>;
+ interrupts = <0 86 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
};
mmc3: mmc at 480ad000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480ad000 0x400>;
+ interrupts = <0 94 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "mmc3";
ti,needs-special-reset;
};
mmc4: mmc at 480d1000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480d1000 0x400>;
+ interrupts = <0 96 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "mmc4";
ti,needs-special-reset;
};
mmc5: mmc at 480d5000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480d5000 0x400>;
+ interrupts = <0 59 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "mmc5";
ti,needs-special-reset;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: omap5: Update UART with address space and interrupts
From: Sebastien Guiriec @ 2012-10-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351062434-22514-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07d2607..b535d8e 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -250,36 +250,54 @@
uart1: serial at 4806a000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806a000 0x100>;
+ interrupts = <0 72 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
uart2: serial at 4806c000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806c000 0x100>;
+ interrupts = <0 73 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "uart2";
clock-frequency = <48000000>;
};
uart3: serial at 48020000 {
compatible = "ti,omap4-uart";
+ reg = <0x48020000 0x100>;
+ interrupts = <0 74 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
uart4: serial at 4806e000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806e000 0x100>;
+ interrupts = <0 70 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "uart4";
clock-frequency = <48000000>;
};
uart5: serial at 48066000 {
- compatible = "ti,omap5-uart";
+ compatible = "ti,omap4-uart";
+ reg = <0x48066000 0x100>;
+ interrupts = <0 105 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "uart5";
clock-frequency = <48000000>;
};
uart6: serial at 48068000 {
- compatible = "ti,omap6-uart";
+ compatible = "ti,omap4-uart";
+ reg = <0x48068000 0x100>;
+ interrupts = <0 106 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "uart6";
clock-frequency = <48000000>;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 2/4] ARM: dts: omap5: Update I2C with address space and interrupts
From: Sebastien Guiriec @ 2012-10-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351062434-22514-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 737a536..07d2607 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -200,6 +200,9 @@
i2c1: i2c at 48070000 {
compatible = "ti,omap4-i2c";
+ reg = <0x48070000 0x100>;
+ interrupts = <0 56 0x4>;
+ interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
@@ -207,6 +210,9 @@
i2c2: i2c at 48072000 {
compatible = "ti,omap4-i2c";
+ reg = <0x48072000 0x100>;
+ interrupts = <0 57 0x4>;
+ interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
@@ -214,20 +220,29 @@
i2c3: i2c at 48060000 {
compatible = "ti,omap4-i2c";
+ reg = <0x48060000 0x100>;
+ interrupts = <0 61 0x4>;
+ interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
};
- i2c4: i2c at 4807A000 {
+ i2c4: i2c at 4807a000 {
compatible = "ti,omap4-i2c";
+ reg = <0x4807a000 0x100>;
+ interrupts = <0 62 0x4>;
+ interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c4";
};
- i2c5: i2c at 4807C000 {
+ i2c5: i2c at 4807c000 {
compatible = "ti,omap4-i2c";
+ reg = <0x4807c000 0x100>;
+ interrupts = <0 60 0x4>;
+ interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c5";
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
From: Sebastien Guiriec @ 2012-10-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351062434-22514-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..737a536 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,6 +104,9 @@
gpio1: gpio at 4ae10000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4ae10000 0x200>;
+ interrupts = <0 29 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -113,6 +116,9 @@
gpio2: gpio at 48055000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48055000 0x200>;
+ interrupts = <0 30 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -122,6 +128,9 @@
gpio3: gpio at 48057000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48057000 0x200>;
+ interrupts = <0 31 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -131,6 +140,9 @@
gpio4: gpio at 48059000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48059000 0x200>;
+ interrupts = <0 32 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -140,6 +152,9 @@
gpio5: gpio at 4805b000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4805b000 0x200>;
+ interrupts = <0 33 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -149,6 +164,9 @@
gpio6: gpio at 4805d000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4805d000 0x200>;
+ interrupts = <0 34 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -158,6 +176,9 @@
gpio7: gpio at 48051000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48051000 0x200>;
+ interrupts = <0 35 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio7";
gpio-controller;
#gpio-cells = <2>;
@@ -167,6 +188,9 @@
gpio8: gpio at 48053000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48053000 0x200>;
+ interrupts = <0 121 0x4>;
+ interrupt-parent = <&gic>;
ti,hwmods = "gpio8";
gpio-controller;
#gpio-cells = <2>;
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox