* [PATCH v5 05/20] watchdog: orion: Remove unused macros
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
These are not used anywhere so it's safe to remove them.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/watchdog/orion_wdt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index b92a991..6746033 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -33,8 +33,6 @@
#define WDT_VAL 0x0024
#define WDT_MAX_CYCLE_COUNT 0xffffffff
-#define WDT_IN_USE 0
-#define WDT_OK_TO_CLOSE 1
#define WDT_RESET_OUT_EN BIT(1)
#define WDT_INT_REQ BIT(3)
--
1.8.1.5
^ permalink raw reply related
* [PATCH v5 04/20] watchdog: orion: Use atomic access for shared registers
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
Since the timer control register is shared with the clocksource driver,
use the recently introduced atomic_io_clear_set() to access such register.
Given the watchdog core already provides serialization for all the
watchdog ops, this commit allows to remove the spinlock entirely.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/watchdog/orion_wdt.c | 42 +++++-------------------------------------
1 file changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 7f19fa3..b92a991 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -20,7 +20,6 @@
#include <linux/watchdog.h>
#include <linux/init.h>
#include <linux/io.h>
-#include <linux/spinlock.h>
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/of.h>
@@ -46,25 +45,16 @@ static unsigned int wdt_max_duration; /* (seconds) */
static struct clk *clk;
static unsigned int wdt_tclk;
static void __iomem *wdt_reg;
-static DEFINE_SPINLOCK(wdt_lock);
static int orion_wdt_ping(struct watchdog_device *wdt_dev)
{
- spin_lock(&wdt_lock);
-
/* Reload watchdog duration */
writel(wdt_tclk * wdt_dev->timeout, wdt_reg + WDT_VAL);
-
- spin_unlock(&wdt_lock);
return 0;
}
static int orion_wdt_start(struct watchdog_device *wdt_dev)
{
- u32 reg;
-
- spin_lock(&wdt_lock);
-
/* Set watchdog duration */
writel(wdt_tclk * wdt_dev->timeout, wdt_reg + WDT_VAL);
@@ -72,48 +62,26 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
writel(~WDT_INT_REQ, BRIDGE_CAUSE);
/* Enable watchdog timer */
- reg = readl(wdt_reg + TIMER_CTRL);
- reg |= WDT_EN;
- writel(reg, wdt_reg + TIMER_CTRL);
+ atomic_io_modify(wdt_reg + TIMER_CTRL, WDT_EN, WDT_EN);
/* Enable reset on watchdog */
- reg = readl(RSTOUTn_MASK);
- reg |= WDT_RESET_OUT_EN;
- writel(reg, RSTOUTn_MASK);
-
- spin_unlock(&wdt_lock);
+ atomic_io_modify(RSTOUTn_MASK, WDT_RESET_OUT_EN, WDT_RESET_OUT_EN);
return 0;
}
static int orion_wdt_stop(struct watchdog_device *wdt_dev)
{
- u32 reg;
-
- spin_lock(&wdt_lock);
-
/* Disable reset on watchdog */
- reg = readl(RSTOUTn_MASK);
- reg &= ~WDT_RESET_OUT_EN;
- writel(reg, RSTOUTn_MASK);
+ atomic_io_modify(RSTOUTn_MASK, WDT_RESET_OUT_EN, 0);
/* Disable watchdog timer */
- reg = readl(wdt_reg + TIMER_CTRL);
- reg &= ~WDT_EN;
- writel(reg, wdt_reg + TIMER_CTRL);
-
- spin_unlock(&wdt_lock);
+ atomic_io_modify(wdt_reg + TIMER_CTRL, WDT_EN, 0);
return 0;
}
static unsigned int orion_wdt_get_timeleft(struct watchdog_device *wdt_dev)
{
- unsigned int time_left;
-
- spin_lock(&wdt_lock);
- time_left = readl(wdt_reg + WDT_VAL) / wdt_tclk;
- spin_unlock(&wdt_lock);
-
- return time_left;
+ return readl(wdt_reg + WDT_VAL) / wdt_tclk;
}
static int orion_wdt_set_timeout(struct watchdog_device *wdt_dev,
--
1.8.1.5
^ permalink raw reply related
* [PATCH v5 03/20] watchdog: orion: Add clock error handling
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
This commit adds a check for clk_prepare_enable success and introduces
an error path to disable the clock properly.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/watchdog/orion_wdt.c | 29 +++++++++++++++++++----------
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index f7722a4..7f19fa3 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -151,17 +151,24 @@ static int orion_wdt_probe(struct platform_device *pdev)
clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "Orion Watchdog missing clock\n");
- return -ENODEV;
+ return PTR_ERR(clk);
}
- clk_prepare_enable(clk);
+ ret = clk_prepare_enable(clk);
+ if (ret)
+ return ret;
wdt_tclk = clk_get_rate(clk);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
+ if (!res) {
+ ret = -ENODEV;
+ goto disable_clk;
+ }
+
wdt_reg = devm_ioremap(&pdev->dev, res->start, resource_size(res));
- if (!wdt_reg)
- return -ENOMEM;
+ if (!wdt_reg) {
+ ret = -ENOMEM;
+ goto disable_clk;
+ }
wdt_max_duration = WDT_MAX_CYCLE_COUNT / wdt_tclk;
@@ -171,14 +178,16 @@ static int orion_wdt_probe(struct platform_device *pdev)
watchdog_set_nowayout(&orion_wdt, nowayout);
ret = watchdog_register_device(&orion_wdt);
- if (ret) {
- clk_disable_unprepare(clk);
- return ret;
- }
+ if (ret)
+ goto disable_clk;
pr_info("Initial timeout %d sec%s\n",
orion_wdt.timeout, nowayout ? ", nowayout" : "");
return 0;
+
+disable_clk:
+ clk_disable_unprepare(clk);
+ return ret;
}
static int orion_wdt_remove(struct platform_device *pdev)
--
1.8.1.5
^ permalink raw reply related
* [PATCH v5 02/20] clocksource: orion: Use atomic access for shared registers
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
Replace the driver-specific thread-safe shared register API
by the recently introduced atomic_io_clear_set().
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
drivers/clocksource/time-orion.c | 28 ++++++++++------------------
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
index 9c7f018..3f14e56 100644
--- a/drivers/clocksource/time-orion.c
+++ b/drivers/clocksource/time-orion.c
@@ -35,20 +35,6 @@
#define ORION_ONESHOT_MAX 0xfffffffe
static void __iomem *timer_base;
-static DEFINE_SPINLOCK(timer_ctrl_lock);
-
-/*
- * Thread-safe access to TIMER_CTRL register
- * (shared with watchdog timer)
- */
-void orion_timer_ctrl_clrset(u32 clr, u32 set)
-{
- spin_lock(&timer_ctrl_lock);
- writel((readl(timer_base + TIMER_CTRL) & ~clr) | set,
- timer_base + TIMER_CTRL);
- spin_unlock(&timer_ctrl_lock);
-}
-EXPORT_SYMBOL(orion_timer_ctrl_clrset);
/*
* Free-running clocksource handling.
@@ -68,7 +54,8 @@ static int orion_clkevt_next_event(unsigned long delta,
{
/* setup and enable one-shot timer */
writel(delta, timer_base + TIMER1_VAL);
- orion_timer_ctrl_clrset(TIMER1_RELOAD_EN, TIMER1_EN);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER1_RELOAD_EN | TIMER1_EN, TIMER1_EN);
return 0;
}
@@ -80,10 +67,13 @@ static void orion_clkevt_mode(enum clock_event_mode mode,
/* setup and enable periodic timer at 1/HZ intervals */
writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD);
writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL);
- orion_timer_ctrl_clrset(0, TIMER1_RELOAD_EN | TIMER1_EN);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER1_RELOAD_EN | TIMER1_EN,
+ TIMER1_RELOAD_EN | TIMER1_EN);
} else {
/* disable timer */
- orion_timer_ctrl_clrset(TIMER1_RELOAD_EN | TIMER1_EN, 0);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER1_RELOAD_EN | TIMER1_EN, 0);
}
}
@@ -131,7 +121,9 @@ static void __init orion_timer_init(struct device_node *np)
/* setup timer0 as free-running clocksource */
writel(~0, timer_base + TIMER0_VAL);
writel(~0, timer_base + TIMER0_RELOAD);
- orion_timer_ctrl_clrset(0, TIMER0_RELOAD_EN | TIMER0_EN);
+ atomic_io_modify(timer_base + TIMER_CTRL,
+ TIMER0_RELOAD_EN | TIMER0_EN,
+ TIMER0_RELOAD_EN | TIMER0_EN);
clocksource_mmio_init(timer_base + TIMER0_VAL, "orion_clocksource",
clk_get_rate(clk), 300, 32,
clocksource_mmio_readl_down);
--
1.8.1.5
^ permalink raw reply related
* [PATCH v5 01/20] ARM: Introduce atomic MMIO modify
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
Some SoC have MMIO regions that are shared across orthogonal
subsystems. This commit implements a possible solution for the
thread-safe access of such regions through a spinlock-protected API.
Concurrent access is protected with a single spinlock for the
entire MMIO address space. While this protects shared-registers,
it also serializes access to unrelated/unshared registers.
We add relaxed and non-relaxed variants, by using writel_relaxed and writel,
respectively. The rationale for this is that some users may not require
register write completion but only thread-safe access to a register.
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Russell,
Can you confirm this patch is on its way to v3.14?
arch/arm/include/asm/io.h | 6 ++++++
arch/arm/kernel/io.c | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index fbeb39c..8aa4cca 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -38,6 +38,12 @@
#define isa_bus_to_virt phys_to_virt
/*
+ * Atomic MMIO-wide IO modify
+ */
+extern void atomic_io_modify(void __iomem *reg, u32 mask, u32 set);
+extern void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set);
+
+/*
* Generic IO read/write. These perform native-endian accesses. Note
* that some architectures will want to re-define __raw_{read,write}w.
*/
diff --git a/arch/arm/kernel/io.c b/arch/arm/kernel/io.c
index dcd5b4d..9203cf8 100644
--- a/arch/arm/kernel/io.c
+++ b/arch/arm/kernel/io.c
@@ -1,6 +1,41 @@
#include <linux/export.h>
#include <linux/types.h>
#include <linux/io.h>
+#include <linux/spinlock.h>
+
+static DEFINE_RAW_SPINLOCK(__io_lock);
+
+/*
+ * Generic atomic MMIO modify.
+ *
+ * Allows thread-safe access to registers shared by unrelated subsystems.
+ * The access is protected by a single MMIO-wide lock.
+ */
+void atomic_io_modify_relaxed(void __iomem *reg, u32 mask, u32 set)
+{
+ unsigned long flags;
+ u32 value;
+
+ raw_spin_lock_irqsave(&__io_lock, flags);
+ value = readl_relaxed(reg) & ~mask;
+ value |= (set & mask);
+ writel_relaxed(value, reg);
+ raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify_relaxed);
+
+void atomic_io_modify(void __iomem *reg, u32 mask, u32 set)
+{
+ unsigned long flags;
+ u32 value;
+
+ raw_spin_lock_irqsave(&__io_lock, flags);
+ value = readl_relaxed(reg) & ~mask;
+ value |= (set & mask);
+ writel(value, reg);
+ raw_spin_unlock_irqrestore(&__io_lock, flags);
+}
+EXPORT_SYMBOL(atomic_io_modify);
/*
* Copy data from IO memory space to "real" memory space.
--
1.8.1.5
^ permalink raw reply related
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
A new round, mostly fixing some minor nitpicks.
This entire series depends on latest irqchip-orion fixes by Sebastian.
Namely, this one: https://lkml.org/lkml/2014/1/23/594.
How should we handle this dependency?
Changes from v4 are:
* Provided better commit subject and commit log for patch 7:
"watchdog: orion: Handle the interrupt so it's properly acked".
* Corrected the misnamed fuction try_rstout_ioremap().
* A bunch of s/interruption/interrupt fixes
* Dropped the '0' as a valid IRQ in the platform_get_irq() check, given
it should return a positive virq-space number.
Changes from v3 are:
* It wasn't nice to break DT compatibility by adding a second resource
requirement, so we provided a fallback to use the RSTOUT address.
All in all, the solution doesn't look too bad.
* Added a full watchdog stop at driver probe time, *before* the call
to request_irq().
Notice that currently the request_irq() doesn't seem to clear the
pending interrupt. This means the BRIDGE_CAUSE clear removal is
still not safe.
This should be fixed sooner than later and, of course, before this
gets merged.
* Rework the interrupt request, to use devm_request_irq() and
avoid dealing with IRQ releasing.
* Added proper clock error handling and fixed the probe() error path.
* Typos and minor issues got fixed
Changes from v2:
* Add proper error checking on clk_prepare_enable() and return
PTR_ERR instead of ENODEV. Suggested by Fabio Estevam.
* After the usage of the atomic I/O and considering the watchdog core
does its own serialization, the driver's spinlock was completely
redundant and was removed. Also suggested by Fabio.
* Instead of making the driver dependent on PLAT_ORION, added a dependency
to ARCH_MVEBU. This was proposed by Sebastian and Andrew, given
we're working on PLAT_ORION removal.
Changes from v1:
* Watchdog RSTOUT enable.
While v1 enabled the RSTOUT at each machine initialization, Jason Gunthorpe
later pointed out [2] that such enabling might lead to a spurious watchdog
trigger, in the event of the watchdog expired event not being cleared.
Therefore, the current patchset adds RSTOUT as a second address resource
(or 'reg' entry in devicetree words) to allow different platforms specify
the corresponding address of the register. This change allows to build the
driver on multiplatforms builds as helps remove a mach-specific header.
The drawback of this is that the DT backwards compatibility gets broken;
this was timely discussed but no better solution was achieved or proposed.
* BRIDGE CAUSE clear removal
The watchdog cause clear should be done by the bridge irqchip driver, so
it's fine to remove it from the watchdog driver and instead request the
interrupt.
However, there are still a few platforms (orion5x, and legacy
kirkwood/dove) that doesn't have this bridge irqchip support enabled.
On these platforms the bridge cause clear is simply *not* done.
If we are paranoid about this, maybe we can simply add the clear on each
mach-xxx/irq.c, together with the other irq is initialization.
Once again, thanks to everyone who helped reviewing this.
Ezequiel Garcia (20):
ARM: Introduce atomic MMIO modify
clocksource: orion: Use atomic access for shared registers
watchdog: orion: Add clock error handling
watchdog: orion: Use atomic access for shared registers
watchdog: orion: Remove unused macros
watchdog: orion: Make sure the watchdog is initially stopped
watchdog: orion: Handle the interrupt so it's properly acked
watchdog: orion: Make RSTOUT register a separate resource
watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
watchdog: orion: Introduce an orion_watchdog device structure
watchdog: orion: Introduce per-compatible of_device_id data
watchdog: orion: Add per-compatible clock initialization
watchdog: orion: Add per-compatible watchdog start implementation
watchdog: orion: Add support for Armada 370 and Armada XP SoC
ARM: mvebu: Enable Armada 370/XP watchdog in the devicetree
ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
ARM: dove: Enable Dove watchdog in the devicetree
watchdog: orion: Enable the build on ARCH_MVEBU
ARM: mvebu: Enable watchdog support in defconfig
ARM: dove: Enable watchdog support in the defconfig
.../devicetree/bindings/watchdog/marvel.txt | 8 +-
arch/arm/boot/dts/armada-370-xp.dtsi | 4 +
arch/arm/boot/dts/armada-370.dtsi | 5 +
arch/arm/boot/dts/armada-xp.dtsi | 6 +
arch/arm/boot/dts/dove.dtsi | 8 +
arch/arm/boot/dts/kirkwood.dtsi | 2 +-
arch/arm/configs/dove_defconfig | 2 +
arch/arm/configs/mvebu_defconfig | 2 +
arch/arm/include/asm/io.h | 6 +
arch/arm/kernel/io.c | 35 ++
arch/arm/mach-dove/include/mach/bridge-regs.h | 1 +
arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
arch/arm/mach-mv78xx0/include/mach/bridge-regs.h | 1 +
arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
arch/arm/plat-orion/common.c | 10 +-
drivers/clocksource/time-orion.c | 28 +-
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/orion_wdt.c | 369 ++++++++++++++++-----
18 files changed, 383 insertions(+), 108 deletions(-)
--
1.8.1.5
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Ben Dooks @ 2014-01-27 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1401271549280.23931@axis700.grange>
On Mon, Jan 27, 2014 at 04:13:56PM +0100, Guennadi Liakhovetski wrote:
> Hi all,
>
> I'm working on an MMC driver with a DMA capability. All has been working
> well, until at some point I've got a bus error, when the mmc driver had
> been handed in a buffer at 0x3000 physical RAM address. The reason is,
> that on Zynq arch bus masters cannot access RAM below 0x80000. Therefore
> my question: how shall I configure this in software?
>
> The way I found was to use ARM-specific struct dmabounce_device_info and
> implement its .needs_bounce() method to return true for those addresses.
> Is this the right way or is there a better / more straight-forward one?
>
> To do the above I have to enable CONFIG_DMABOUNCE, which then selects
> CONFIG_ZONE_DMA. Having done just that I suddenly discover, that 0x3000
> buffers aren't used any more, so, I cannot actually verify my
> implementation :) Looking at ZONE_DMA it looks like it is still covering
> the whole RAM range (/proc/zoneinfo shows start_pfn=0 in zone DMA), so, I
> don't see why 0x3000 should be excluded now.
>
> So, is using the .needs_bounce() method the correct way to support DMA on
> this arch or is there a better one?
I have a similar issue with Renesas R8A7790 where there is a bus bridge
that can only deal with transactions to one half of the available RAM.
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* [PATCH 1/9] ARM: dts: imx6qdl: remove the use of pingrp macros
From: Shawn Guo @ 2014-01-27 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127151638.GN15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 03:16:39PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 11:05:11PM +0800, Shawn Guo wrote:
> > On Mon, Jan 27, 2014 at 02:37:45PM +0000, Russell King - ARM Linux wrote:
> > > On Sun, Jan 26, 2014 at 12:43:03AM +0800, Shawn Guo wrote:
> > > > arch/arm/boot/dts/imx6dl-hummingboard.dts | 5 +-
> > > > arch/arm/boot/dts/imx6qdl-microsom.dtsi | 5 +-
> > >
> > > I've merged your changes here into my local copy of these just to reduce
> > > the conflicts - unfortunately, it's taken soo long to deal with the above
> > > that the cubox-i has now been released, which has prompted some
> > > reorganisation between the above two files.
> > >
> > > I would much rather you dropped these two entirely, and let me push them
> > > upstream, rather than having some nasty conflicts which result from this.
> >
> > So you're basically asking me to drop patch [1] from imx/dt branch (tag
> > imx-dt-3.14), which I have sent to Olof for 3.14 inclusion. Yes, I
> > still hope Olof can pull it with this turn-around series applied on top.
> > So please let's wait for Olof's word to see if we can make it. If it's
> > still a NO for some reason, I will be certainly fine with you pushing
> > hummingboard stuff upstream, and will drop it from my tree.
>
> My point is that the DT files I _now_ have are quite different in
> organisation to the ones I submitted to you, so there's going to be
> conflicts if your version goes in.
>
> Moreover, I don't want the old ones in 3.14 as-is, because I don't want
> declarations which should not have been in the microsom file but in the
> hummingboard file being in a final release of the mainline kernel.
We can take care of them with incremental patches during early -rc.
Shawn
^ permalink raw reply
* [RFC/PATCH] ARM: dove: Remove UBI support from defconfig
From: Jason Cooper @ 2014-01-27 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127151429.GB3036@localhost>
On Mon, Jan 27, 2014 at 12:14:30PM -0300, Ezequiel Garcia wrote:
> On Mon, Jan 27, 2014 at 10:00:40AM -0500, Jason Cooper wrote:
> > On Mon, Jan 27, 2014 at 10:26:29AM -0300, Ezequiel Garcia wrote:
> > > As NAND support is not enabled by default, it's hard to see
> > > why we'd want to have UBI support. Let's remove it.
> >
> > I'd rather add support for the nand.
> >
>
> Well, there isn't any Dove board (that we currently support) with a NAND
> device. Would you still want to add it?
sh*t. you're right. My memory is failing me. I'll queue this up.
thx,
Jason.
^ permalink raw reply
* [PATCH 1/9] ARM: dts: imx6qdl: remove the use of pingrp macros
From: Russell King - ARM Linux @ 2014-01-27 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127150509.GD4765@S2101-09.ap.freescale.net>
On Mon, Jan 27, 2014 at 11:05:11PM +0800, Shawn Guo wrote:
> On Mon, Jan 27, 2014 at 02:37:45PM +0000, Russell King - ARM Linux wrote:
> > On Sun, Jan 26, 2014 at 12:43:03AM +0800, Shawn Guo wrote:
> > > arch/arm/boot/dts/imx6dl-hummingboard.dts | 5 +-
> > > arch/arm/boot/dts/imx6qdl-microsom.dtsi | 5 +-
> >
> > I've merged your changes here into my local copy of these just to reduce
> > the conflicts - unfortunately, it's taken soo long to deal with the above
> > that the cubox-i has now been released, which has prompted some
> > reorganisation between the above two files.
> >
> > I would much rather you dropped these two entirely, and let me push them
> > upstream, rather than having some nasty conflicts which result from this.
>
> So you're basically asking me to drop patch [1] from imx/dt branch (tag
> imx-dt-3.14), which I have sent to Olof for 3.14 inclusion. Yes, I
> still hope Olof can pull it with this turn-around series applied on top.
> So please let's wait for Olof's word to see if we can make it. If it's
> still a NO for some reason, I will be certainly fine with you pushing
> hummingboard stuff upstream, and will drop it from my tree.
My point is that the DT files I _now_ have are quite different in
organisation to the ones I submitted to you, so there's going to be
conflicts if your version goes in.
Moreover, I don't want the old ones in 3.14 as-is, because I don't want
declarations which should not have been in the microsom file but in the
hummingboard file being in a final release of the mainline kernel.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC/PATCH] ARM: dove: Remove UBI support from defconfig
From: Ezequiel Garcia @ 2014-01-27 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127150040.GH29184@titan.lakedaemon.net>
On Mon, Jan 27, 2014 at 10:00:40AM -0500, Jason Cooper wrote:
> On Mon, Jan 27, 2014 at 10:26:29AM -0300, Ezequiel Garcia wrote:
> > As NAND support is not enabled by default, it's hard to see
> > why we'd want to have UBI support. Let's remove it.
>
> I'd rather add support for the nand.
>
Well, there isn't any Dove board (that we currently support) with a NAND
device. Would you still want to add it?
In that case, we should consider adding UBIFS as well. Having CONFIG_UBI
by itself doesn't make any sense.
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Guennadi Liakhovetski @ 2014-01-27 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm working on an MMC driver with a DMA capability. All has been working
well, until at some point I've got a bus error, when the mmc driver had
been handed in a buffer at 0x3000 physical RAM address. The reason is,
that on Zynq arch bus masters cannot access RAM below 0x80000. Therefore
my question: how shall I configure this in software?
The way I found was to use ARM-specific struct dmabounce_device_info and
implement its .needs_bounce() method to return true for those addresses.
Is this the right way or is there a better / more straight-forward one?
To do the above I have to enable CONFIG_DMABOUNCE, which then selects
CONFIG_ZONE_DMA. Having done just that I suddenly discover, that 0x3000
buffers aren't used any more, so, I cannot actually verify my
implementation :) Looking at ZONE_DMA it looks like it is still covering
the whole RAM range (/proc/zoneinfo shows start_pfn=0 in zone DMA), so, I
don't see why 0x3000 should be excluded now.
So, is using the .needs_bounce() method the correct way to support DMA on
this arch or is there a better one?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Heikki Krogerus @ 2014-01-27 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121144725.GF30451@saruman.home>
Hi Felipe,
On Tue, Jan 21, 2014 at 08:47:25AM -0600, Felipe Balbi wrote:
> On Tue, Jan 21, 2014 at 03:41:38PM +0530, Kishon Vijay Abraham I wrote:
> > Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> > do not return from probe if the USB PHY library returns -ENODEV as that
>
> this isn't correct, they all have PHYs, some of them might not be
> controllable.
>
> > indicates the platform does not have PHY.
>
> not really, that indicates the current platform tried to grab a PHY and
> the PHY doesn't exist. If there's anybody with a non-controllable PHY
> and someone gives me a really good reason for not using the generic
> no-op PHY, then we should add a flag and we could:
>
> if (!likely(dwc->flags & DWC3_USB2PHY_DRIVER_NOT_NEEDED))
> dwc3_grab_phys(dwc);
Why would you need to know if the PHY drivers are needed or not
explicitly in your controller driver?
> But I really want to see the argument against using no-op. As far as I
> could see, everybody needs a PHY driver one way or another, some
> platforms just haven't sent any PHY driver upstream and have their own
> hacked up solution to avoid using the PHY layer.
Not true in our case. Platforms using Intel's SoCs and chip sets may
or may not have controllable USB PHY. Quite often they don't. The
Baytrails have usually ULPI PHY for USB2, but that does not mean they
provide any vendor specific functions or any need for a driver in any
case.
Are we talking about the old USB PHY library or the new PHY framework
with the no-op PHY driver?
Well, in any case, I don't understand what is the purpose of the no-op
PHY driver. What are you drying to achieve with that?
Thanks,
--
heikki
^ permalink raw reply
* [PATCH 1/9] ARM: dts: imx6qdl: remove the use of pingrp macros
From: Shawn Guo @ 2014-01-27 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127143745.GM15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 02:37:45PM +0000, Russell King - ARM Linux wrote:
> On Sun, Jan 26, 2014 at 12:43:03AM +0800, Shawn Guo wrote:
> > arch/arm/boot/dts/imx6dl-hummingboard.dts | 5 +-
> > arch/arm/boot/dts/imx6qdl-microsom.dtsi | 5 +-
>
> I've merged your changes here into my local copy of these just to reduce
> the conflicts - unfortunately, it's taken soo long to deal with the above
> that the cubox-i has now been released, which has prompted some
> reorganisation between the above two files.
>
> I would much rather you dropped these two entirely, and let me push them
> upstream, rather than having some nasty conflicts which result from this.
So you're basically asking me to drop patch [1] from imx/dt branch (tag
imx-dt-3.14), which I have sent to Olof for 3.14 inclusion. Yes, I
still hope Olof can pull it with this turn-around series applied on top.
So please let's wait for Olof's word to see if we can make it. If it's
still a NO for some reason, I will be certainly fine with you pushing
hummingboard stuff upstream, and will drop it from my tree.
Shawn
[1] https://git.linaro.org/people/shawn.guo/linux-2.6.git/commit/8544f6c92801b1ba70f790cc17f543f7aa13f17f
^ permalink raw reply
* [PATCH v2 0/5] ARM: sun6i: Add support for the A31 I2C controller
From: Maxime Ripard @ 2014-01-27 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389609293-2824-1-git-send-email-maxime.ripard@free-electrons.com>
Hi Wolfram,
On Mon, Jan 13, 2014 at 11:34:48AM +0100, Maxime Ripard wrote:
> Hi everyone,
>
> This patchset adds support the A31 i2c controller. This is mostly the
> same controller as the one found in the other Allwinner SoCs, except
> for the interrupts acking.
>
> On the other SoCs using this driver, the interrupts are acked by
> clearing the INT_FLAG bit in the control register, while on the A31,
> the interrupt is acked by writing that bit into the control register.
>
> The other difference is that the I2C IP is maintained in reset by a
> reset controller, so we're adding optionnal support for the reset
> framework in the driver to deassert the device from reset.
Do you have any comments on this?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140127/4998546e/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/4] clk: sunxi: Add support for PLL6 on the A31
From: Maxime Ripard @ 2014-01-27 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117221402.4167.78251@quantum>
Hi Mike,
On Fri, Jan 17, 2014 at 02:14:02PM -0800, Mike Turquette wrote:
> Quoting Maxime Ripard (2014-01-16 09:11:22)
> > The A31 has a slightly different PLL6 clock. Add support for this new clock in
> > our driver.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> This looks good to me. I guess it will be going in for 3.15 based on the
> comments in the coverletter.
Yes, indeed it is 3.15 materials.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140127/99d8f2d3/attachment.sig>
^ permalink raw reply
* [RFC/PATCH] ARM: dove: Remove UBI support from defconfig
From: Jason Cooper @ 2014-01-27 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390829189-25073-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Mon, Jan 27, 2014 at 10:26:29AM -0300, Ezequiel Garcia wrote:
> As NAND support is not enabled by default, it's hard to see
> why we'd want to have UBI support. Let's remove it.
I'd rather add support for the nand.
thx,
Jason.
>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
> arch/arm/configs/dove_defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
> index 1101054..7242b11 100644
> --- a/arch/arm/configs/dove_defconfig
> +++ b/arch/arm/configs/dove_defconfig
> @@ -48,7 +48,6 @@ CONFIG_MTD_CFI_INTELEXT=y
> CONFIG_MTD_CFI_STAA=y
> CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_M25P80=y
> -CONFIG_MTD_UBI=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_COUNT=1
> --
> 1.8.1.5
>
^ permalink raw reply
* [PATCH] sunxi: dts: add a note that memory size is adjusted by boot loader.
From: Maxime Ripard @ 2014-01-27 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E399F4.1040300@redhat.com>
Hi Ian, Hans,
On Sat, Jan 25, 2014 at 12:03:16PM +0100, Hans de Goede wrote:
> Hmm, I've no idea what the default / preferred way of handling this is,
> I assume Maxime knows, so lets wait for his input on this.
I got the habit of setting the memory node to the max size the RAM
controller can handle from previous work on imx, but I don't really
have a preferrence here.
If that confuses people, we can just remove it from the DTSI
altogether. It will be patched by u-boot anyway, and we won't have to
create DTS variants this way.
Just don't do it for the A31 for the moment, since we don't have
DT-enabled u-boot for now.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140127/e91902ab/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Hans de Goede @ 2014-01-27 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127144349.GJ3867@lukather>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On 01/27/2014 03:43 PM, Maxime Ripard wrote:
> Hi Hans,
>
> Mostly looking good, but I have a few comments below.
>
> On Wed, Jan 22, 2014 at 10:36:24PM +0100, Hans de Goede wrote:
>> From: Roman Byshko <rbyshko@gmail.com>
>>
>> Add register definitions for the usb-clk register found on sun4i, sun5i and sun7i SoCs.
>>
>> Signed-off-by: Roman Byshko <rbyshko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- Documentation/devicetree/bindings/clock/sunxi.txt | 5 +++++ drivers/clk/sunxi/clk-sunxi.c | 12 ++++++++++++ 2 files changed, 17 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index 79c7197..8bccb6a 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -37,6 +37,8 @@ Required properties: "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31 "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks "allwinner,sun7i-a20-out-clk" - for the external output clocks + "allwinner,sun4i-usb-gates-clk" - for usb gates + resets on A10 / A20 +
>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
>
> Maybe we can just remove the gates from there? Even though they are gates, they are also (a bit) more than that.
To be clear you mean s/usb-gates-clk/usb-clk/ right ?
That sounds reasonable :)
>
>> Required properties for all clocks: - reg : shall be the control register address for the clock. @@ -49,6 +51,9 @@ Required properties for all clocks: Additionally, "allwinner,*-gates-clk" clocks require: - clock-output-names : the corresponding gate names that the clock controls
>>
>> +And "allwinner,*-usb-gates-clk" clocks also require: +- reset-cells : shall be set to 1 +
>
> You should also document what value we should put in the cells, and where to refer to to find the right one.
Ok.
>
>> Clock consumers should specify the desired clocks they use with a "clocks" phandle cell. Consumers that are using a gated clock should provide an additional ID in their clock property. This ID is the diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index f1a147c..18cbc3c 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++ b/drivers/clk/sunxi/clk-sunxi.c @@ -813,6 +813,16 @@ static const struct gates_data sun4i_ahb_gates_data __initconst = { .mask = {0x7F77FFF, 0x14FB3F}, };
>>
>> +static const struct gates_data sun4i_usb_gates_data __initconst = { + .mask = {0x1C0}, + .reset_mask = 0x07, +}; + +static const struct gates_data sun5i_a13_usb_gates_data __initconst = { + .mask = {0x140}, + .reset_mask = 0x03, +}; +
>
> I guess that means that we will have the OHCI0 gate declared with <&...-gates-clk 6>, while it's actually the first gate for this clock?
Correct.
> Maybe introducing an offset field in the gates_data would be a good idea, so that we always start from indexing the gates from 0 in the DT?
Well for the other "gates" type clks we also have holes in the range, and
we always refer to the clk with the bit number in the reg as the clock-cell
value.
Here the hole just happens to be at the start, but it seems best to me
to be consistent and keep using the bit nr inside the reg as clock-cell
value, without an offset.
>
>> static const struct gates_data sun5i_a10s_ahb_gates_data __initconst = { .mask = {0x147667e7, 0x185915}, }; @@ -1159,6 +1169,8 @@ static const struct of_device_id clk_gates_match[] __initconst = { {.compatible = "allwinner,sun6i-a31-apb1-gates-clk", .data = &sun6i_a31_apb1_gates_data,}, {.compatible = "allwinner,sun7i-a20-apb1-gates-clk", .data = &sun7i_a20_apb1_gates_data,}, {.compatible = "allwinner,sun6i-a31-apb2-gates-clk", .data = &sun6i_a31_apb2_gates_data,}, + {.compatible = "allwinner,sun4i-usb-gates-clk", .data = &sun4i_usb_gates_data,}, + {.compatible =
>> "allwinner,sun5i-a13-usb-gates-clk", .data = &sun5i_a13_usb_gates_data,}, {} };
>
> Thanks a lot! Maxime
Regards,
Hans
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLmcxYACgkQF3VEtJrzE/vjVgCfT8pMd/WAl2lr5HVURDcr6zz6
pDsAnjStUQa3j6WGOHPstjO2kV3WwkKO
=ozuq
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v4 00/18] Armada 370/XP watchdog support
From: Ezequiel Garcia @ 2014-01-27 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E19A44.7040308@gmail.com>
Hi Sebastian,
On Thu, Jan 23, 2014 at 11:40:04PM +0100, Sebastian Hesselbarth wrote:
> On 01/23/2014 12:04 AM, Ezequiel Garcia wrote:
> > After some lengthy discussion on the [v2] and [v3] patchsets, here's a new
> > round. I hope I haven't forgotten anything.
> >
>
> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>
As currently Dove doesn't have watchdog support in the devicetree, I've added
it to the v5 (which I'll submit now) with your Tested-by on all the patchset.
Thanks a lot for the test,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 1/6] audit: Enable arm64 support
From: Catalin Marinas @ 2014-01-27 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E5EAC1.2070306@linaro.org>
On Mon, Jan 27, 2014 at 05:12:33AM +0000, AKASHI Takahiro wrote:
> [To audit maintainers]
>
> On 01/23/2014 11:18 PM, Catalin Marinas wrote:
> > On Fri, Jan 17, 2014 at 08:13:14AM +0000, AKASHI Takahiro wrote:
> >> --- a/include/uapi/linux/audit.h
> >> +++ b/include/uapi/linux/audit.h
> >> @@ -327,6 +327,8 @@ enum {
> >> /* distinguish syscall tables */
> >> #define __AUDIT_ARCH_64BIT 0x80000000
> >> #define __AUDIT_ARCH_LE 0x40000000
> >> +#define AUDIT_ARCH_AARCH64 (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> >> +#define AUDIT_ARCH_AARCH64EB (EM_AARCH64|__AUDIT_ARCH_64BIT)
> >> #define AUDIT_ARCH_ALPHA (EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE)
> >> #define AUDIT_ARCH_ARM (EM_ARM|__AUDIT_ARCH_LE)
> >> #define AUDIT_ARCH_ARMEB (EM_ARM)
> >> diff --git a/init/Kconfig b/init/Kconfig
> >> index 79383d3..3aae602 100644
> >> --- a/init/Kconfig
> >> +++ b/init/Kconfig
> >> @@ -284,7 +284,7 @@ config AUDIT
> >>
> >> config AUDITSYSCALL
> >> bool "Enable system-call auditing support"
> >> - depends on AUDIT && (X86 || PARISC || PPC || S390 || IA64 || UML || SPARC64 || SUPERH || (ARM && AEABI && !OABI_COMPAT))
> >> + depends on AUDIT && (X86 || PARISC || PPC || S390 || IA64 || UML || SPARC64 || SUPERH || (ARM && AEABI && !OABI_COMPAT) || ARM64)
> >
> > The usual comment for such changes: could you please clean this up and
> > just use something like "depends on HAVE_ARCH_AUDITSYSCALL"?
>
> Do you agree to this change?
>
> If so, I can create a patch, but have some concerns:
> 1) I can't verify it on other architectures than (arm &) arm64.
You could try to build. It's really a trivial change, could get away
with code inspection (and some automatic building when it gets to
linux-next).
In init/Kconfig:
config HAVE_ARCH_AUDITSYSCALL
bool
and:
- depends on AUDIT && (X86 || PARISC || PPC || S390 || IA64 || UML || SPARC64 || SUPERH || (ARM && AEABI && !OABI_COMPAT))
+ depends on HAVE_ARCH_AUDITSYSCALL
In the corresponding arch/*/Kconfig:
select HAVE_ARCH_AUDITSYSCALL
> 2) Some architectures (microblaze, mips, openrisc) are not listed here, but
For those, you don't need to select HAVE_ARCH_AUDITSYSCALL.
> their ptrace.c have a call to audit_syscall_entry/exit().
> (audit_syscall_entry/exit are null if !AUDITSYSCALL, though)
They are not NULL but empty inline functions, so they don't have any
effect.
> So I'm afraid that the change might break someone's assumption.
I'm pretty sure it won't ;).
--
Catalin
^ permalink raw reply
* [PATCH v2 0/5] clk: sunxi: Add support for USB clocks and reset bits
From: Maxime Ripard @ 2014-01-27 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390426587-16287-1-git-send-email-hdegoede@redhat.com>
On Wed, Jan 22, 2014 at 10:36:22PM +0100, Hans de Goede wrote:
> Hi Emilio, Maxime, et al,
>
> Emilio, here is v2 of my patch-set adding support for sunxi-clk USB clocks and
> reset bits. This addresses all your review comments from v1.
>
> Can you add the first 2 patches to your queue of patches for Mike for 3.15 ?
>
> Maxime, can you add patch 3-5 which add the dt bindings for this to your
> tree please ?
Apart from the comments I had on patch 2, it looks good for me. Once
we agree on something, you have my Acked-by.
Thanks for working on this!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140127/cce4f6e6/attachment.sig>
^ permalink raw reply
* [PATCH 05/11] pinctrl: mvebu: fix misdesigned resource allocation
From: Thomas Petazzoni @ 2014-01-27 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390674856-4993-6-git-send-email-sebastian.hesselbarth@gmail.com>
Dear Sebastian Hesselbarth,
On Sat, 25 Jan 2014 19:34:10 +0100, Sebastian Hesselbarth wrote:
> Allocating the pinctrl resource in common pinctrl-mvebu was a misdesign,
> as it does not allow SoC specific parts to access the allocated resource.
> This moves resource allocation from mvebu_pinctrl_probe to SoC specific
> _probe functions and passes the base address to common pinctrl driver
> instead.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
I definitely agree with that: I had the same problem several months ago
when I started doing the pinctrl driver for Orion5x, which has a
non-linear MPP register set.
However, I'd like this to go a little bit further if possible. See
below.
> - return mvebu_pinctrl_probe(pdev);
> + return mvebu_pinctrl_probe(pdev, base);
I think there is no need to pass "base" to mvebu_pinctrl_probe(). The
only reason we have this is because the base gets stored in the
mvebu_pinctrl structure so that the mvebu_common_mpp_get() and
mvebu_common_mpp_set() functions that are the default behavior
for mvebu_pinconf_group_get() and mvebu_pinconf_group_set() work
properly.
Shouldn't we turn these functions mvebu_common_mpp_get() and
mvebu_common_mpp_set() into helper functions, accessible from the
per-SoC pinctrl drivers, so that they can easily implement their
->mpp_get() and ->mpp_set() callbacks?
This way, the "base" thing is completely owned by the per-SoC driver,
which would be more logical I believe.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-01-27 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390426587-16287-3-git-send-email-hdegoede@redhat.com>
Hi Hans,
Mostly looking good, but I have a few comments below.
On Wed, Jan 22, 2014 at 10:36:24PM +0100, Hans de Goede wrote:
> From: Roman Byshko <rbyshko@gmail.com>
>
> Add register definitions for the usb-clk register found on sun4i, sun5i and
> sun7i SoCs.
>
> Signed-off-by: Roman Byshko <rbyshko@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 5 +++++
> drivers/clk/sunxi/clk-sunxi.c | 12 ++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 79c7197..8bccb6a 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -37,6 +37,8 @@ Required properties:
> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> + "allwinner,sun4i-usb-gates-clk" - for usb gates + resets on A10 / A20
> + "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
Maybe we can just remove the gates from there? Even though they are
gates, they are also (a bit) more than that.
> Required properties for all clocks:
> - reg : shall be the control register address for the clock.
> @@ -49,6 +51,9 @@ Required properties for all clocks:
> Additionally, "allwinner,*-gates-clk" clocks require:
> - clock-output-names : the corresponding gate names that the clock controls
>
> +And "allwinner,*-usb-gates-clk" clocks also require:
> +- reset-cells : shall be set to 1
> +
You should also document what value we should put in the cells, and
where to refer to to find the right one.
> Clock consumers should specify the desired clocks they use with a
> "clocks" phandle cell. Consumers that are using a gated clock should
> provide an additional ID in their clock property. This ID is the
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index f1a147c..18cbc3c 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -813,6 +813,16 @@ static const struct gates_data sun4i_ahb_gates_data __initconst = {
> .mask = {0x7F77FFF, 0x14FB3F},
> };
>
> +static const struct gates_data sun4i_usb_gates_data __initconst = {
> + .mask = {0x1C0},
> + .reset_mask = 0x07,
> +};
> +
> +static const struct gates_data sun5i_a13_usb_gates_data __initconst = {
> + .mask = {0x140},
> + .reset_mask = 0x03,
> +};
> +
I guess that means that we will have the OHCI0 gate declared with
<&...-gates-clk 6>, while it's actually the first gate for this clock?
Maybe introducing an offset field in the gates_data would be a good
idea, so that we always start from indexing the gates from 0 in the DT?
> static const struct gates_data sun5i_a10s_ahb_gates_data __initconst = {
> .mask = {0x147667e7, 0x185915},
> };
> @@ -1159,6 +1169,8 @@ static const struct of_device_id clk_gates_match[] __initconst = {
> {.compatible = "allwinner,sun6i-a31-apb1-gates-clk", .data = &sun6i_a31_apb1_gates_data,},
> {.compatible = "allwinner,sun7i-a20-apb1-gates-clk", .data = &sun7i_a20_apb1_gates_data,},
> {.compatible = "allwinner,sun6i-a31-apb2-gates-clk", .data = &sun6i_a31_apb2_gates_data,},
> + {.compatible = "allwinner,sun4i-usb-gates-clk", .data = &sun4i_usb_gates_data,},
> + {.compatible = "allwinner,sun5i-a13-usb-gates-clk", .data = &sun5i_a13_usb_gates_data,},
> {}
> };
Thanks a lot!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- 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/20140127/3605b147/attachment.sig>
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Thomas Petazzoni @ 2014-01-27 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390673950-4521-1-git-send-email-sebastian.hesselbarth@gmail.com>
Dear Sebastian Hesselbarth,
On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
>
> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
> registered before core clocks driver. Unfortunately, we cannot
> return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
> init order for our drivers is always core clocks before clock gating,
> we maintain init order ourselves by hooking CLK_OF_DECLARE to one
> init function that will register core clocks before clock gating
> driver.
>
> This patch is based on pre-v3.14-rc1 mainline and should go in as
> fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
> I suggest Jason picks it up as a topic branch.
I'm not sure I really like the solution you're proposing here. I'd very
much prefer to keep one CLK_OF_DECLARE() per clock type, associated to
one function registering only this clock type.
Instead, shouldn't the clock framework be improved to *not* register a
clock until its parent have been registered? If the DT you have the
gatable clocks that depend on the core clocks, then the gatable clocks
should not be registered if the core clocks have not yet been
registered.
Do you think this is possible? Am I missing something here?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox