Re: [PATCH 00/10] Orion Watchdog fixes

[Andrew Lunn]

On Mon, Jul 15, 2013 at 08:32:33PM -0300, Ezequiel Garcia wrote:
> This patchset introduces a bunch of fixes that removes the direct use of
> the shared timer control register, and also removes the need to include
> a mach-specific header.
> 
> With this changes the driver can be included in multiplatforms builds,
> and in particular be used for the Armada 370/XP SoC.

Hi Ezequiel

Maybe i'm missing something here. You are making use of
orion_timer_ctrl_clrset() from time-orion.c. How will this work on
370/XP which has a different clocksource driver?

Thanks
Andrew
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Thomas Petazzoni]

Dear Andrew Lunn,

On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:

> Maybe i'm missing something here. You are making use of
> orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> 370/XP which has a different clocksource driver?

I *think* the idea is that the Armada 370/XP driver will expose the
same function, so from the point of view of the watchdog driver, it
will just work. This set of patches is just some preparation patches on
the Orion watchdog driver, to later make it usable on Armada 370/XP.
The patches enabling its usage on Armada 370/XP will follow.

But Ezequiel will confirm all that, we had a discussion together about
this yesterday, so I guess what I said should be the plan, but it's
better if Ezequiel confirms, obviously :)

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Andrew Lunn]

On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:
> 
> > Maybe i'm missing something here. You are making use of
> > orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> > 370/XP which has a different clocksource driver?
> 
> I *think* the idea is that the Armada 370/XP driver will expose the
> same function, so from the point of view of the watchdog driver, it
> will just work.

Hi Thomas

That was what i was thinking would happen. And then i started to
wonder how well the kernel linker deals with multiple definitions of
the same symbol. Dove and 370/XP can end up in the same kernel. So we
need to have both orion-timer and the 370/XP timer in the same kernel,
so we end up with the same symbol in the kernel twice...

Lets wait for Ezequiel to answer.

   Andrew
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Sebastian Hesselbarth]

Andrew, Thomas,

In the discussion about orion clocksource Russell was proposing a generic 
thread-safe write. That puts a single lock around all those writes. Of 
course, it will also blocked by totally unrelated thread-safe register 
accesses but should prevent us from having dozens of locks and solves the 
symbol issue.


Sebastian



On July 16, 2013 9:31:01 AM Andrew Lunn  wrote:

On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:
> > Maybe i'm missing something here. You are making use of
> > orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> > 370/XP which has a different clocksource driver?
> I *think* the idea is that the Armada 370/XP driver will expose the
> same function, so from the point of view of the watchdog driver, it
> will just work.

Hi Thomas

That was what i was thinking would happen. And then i started to
wonder how well the kernel linker deals with multiple definitions of
the same symbol. Dove and 370/XP can end up in the same kernel. So we
need to have both orion-timer and the 370/XP timer in the same kernel,
so we end up with the same symbol in the kernel twice...

Lets wait for Ezequiel to answer.

   Andrew



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v3 2/2] drivers: dma-contiguous: add initialization from device tree

[Marek Szyprowski]

Hello Grant,

On 7/11/2013 4:56 PM, Grant Likely wrote:

Hi Marek,

Thanks for working on this. Comments below...

On Wed, Jun 26, 2013 at 2:40 PM, Marek Szyprowski
 wrote:
> Add device tree support for contiguous memory regions defined in device
> tree. Initialization is done in 2 steps. First, the contiguous memory is
> reserved, what happens very early when only flattened device tree is
> available. Then on device initialization the corresponding cma regions are
> assigned to each device structure.
>
> Signed-off-by: Marek Szyprowski 
> Acked-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/contiguous-memory.txt  |   94 ++
>  arch/arm/boot/dts/skeleton.dtsi|7 +-
>  drivers/base/dma-contiguous.c  |  132 

>  3 files changed, 232 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
>
> diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt 
b/Documentation/devicetree/bindings/contiguous-memory.txt
> new file mode 100644
> index 000..a733df2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/contiguous-memory.txt
> @@ -0,0 +1,94 @@
> +*** Contiguous Memory binding ***
> +
> +The /chosen/contiguous-memory node provides runtime configuration of
> +contiguous memory regions for Linux kernel. Such regions can be created
> +for special usage by various device drivers. A good example are
> +contiguous memory allocations or memory sharing with other operating
> +system(s) on the same hardware board. Those special memory regions might
> +depend on the selected board configuration and devices used on the target
> +system.
> +
> +Parameters for each memory region can be encoded into the device tree
> +with the following convention:
> +
> +contiguous-memory {
> +
> +   (name): region@(base-address) {
> +   reg = <(baseaddr) (size)>;
> +   (linux,default-contiguous-region);
> +   device = <&device_0 &device_1 ...>
> +   };
> +};

Okay, I've gone and read all of the backlog on the 3 versions of the
patch series, and I think I understand the issues. I actually think it
was better off to have the regions specified as children of the memory
node. I understand the argument about how would firmware know what
size the kernel wants and that it would be better to have a kernel
parameter to override the default. However, it is also reasonable for
the kernel to be provided with a default amount of CMA based on the
usage profile of the device. In that regard it is absolutely
appropriate to put the CMA region data into the memory node. I don't
think /chosen is the right place for that.


Thanks for your comments! I will prepare a new version, which will use
/memory node as it was in the first version. I hope that with Your ack
such version can be finally merged.


> +
> +name:  an name given to the defined region;

In the above node example, "name:" is a label used for creating
phandles. That information doesn't appear in the resulting .dtb
output. The label is actually optional It should instead be:
 [(label):] (name)@(address) { }

> +base-address:  the base address of the defined region;
> +size:  the size of the memory region (bytes);

The reg property should follow the normal reg rules which are well
defined. That also means that a memory region could have multiple reg
entries if appropriate.


Well, I'm not sure if it really makes sense to support multiple reg 
entries.
I also wonder how to provide entries for LPAE systems. They are 32-bit 
systems,
but physical addresses can be up to 36bit. How to specify them in device 
tree?



> +linux,default-contiguous-region: property indicating that the region
> +   is the default region for all contiguous memory
> +   allocations, Linux specific (optional);
> +device:array of phandles to the client device nodes, which
> +   will use the defined contiguous region.

This is backwards compared to the way device references usually work.
It would be more consistent for each device node to have a
"dma-memory-region" property with phandles to one or more memory
regions that it cares about.

> +Each defined region must use unique name. It is optional to specify the
> +base address, so if one wants to use autoconfiguration of the base
> +address, he must specify the '0' as base address in the 'reg' property
> +and assign ann uniqe name to such regions, following the convention:
> +'region@0', 'region@1', 'region@2', ...

Drop the use of 'region'. "name@0" is more typical. It would be
appropriate to have compatible = "reserved-memory-region" in each of
the reserved regions. That would avoid the problem of two regions
based at the same address having a conflict in name.


Ok.

> ...

Best regards
--
Marek Szyprowski
Samsung R&D Institute Poland


___
devicetree-discuss mai

[PATCH v1 21/24] [media] fsl-viu: OF clock lookup, prepare before enable

[Gerhard Sittig]

device tree based clock lookup, must prepare clocks before enabling
them, unprepare after disable, error check in the clock setup

Signed-off-by: Gerhard Sittig 
---
 drivers/media/platform/fsl-viu.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 221ec42..b95aa43 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -1582,8 +1582,11 @@ static int viu_of_probe(struct platform_device *op)
dev_err(&op->dev, "failed to find the clock module!\n");
ret = -ENODEV;
goto err_clk;
-   } else {
-   clk_enable(viu_dev->clk);
+   }
+   ret = clk_prepare_enable(viu_dev->clk);
+   if (ret) {
+   dev_err(&op->dev, "failed to enable the clock!\n");
+   goto err_clk_put;
}
 
/* reset VIU module */
@@ -1602,7 +1605,8 @@ static int viu_of_probe(struct platform_device *op)
return ret;
 
 err_irq:
-   clk_disable(viu_dev->clk);
+   clk_disable_unprepare(viu_dev->clk);
+err_clk_put:
clk_put(viu_dev->clk);
 err_clk:
video_unregister_device(viu_dev->vdev);
@@ -1626,7 +1630,7 @@ static int viu_of_remove(struct platform_device *op)
free_irq(dev->irq, (void *)dev);
irq_dispose_mapping(dev->irq);
 
-   clk_disable(dev->clk);
+   clk_disable_unprepare(dev->clk);
clk_put(dev->clk);
 
video_unregister_device(dev->vdev);
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v1 22/24] powerpc/fsl-pci: OF clock lookup, prepare before enable

[Gerhard Sittig]

device tree based clock lookup, must prepare clocks before enabling
them, error check in the clock setup

this change implements non-fatal clock lookup for compatibility with
platforms that don't provide OF clock specs, but failure to enable a
specified clock is considered fatal

Signed-off-by: Gerhard Sittig 
---
 arch/powerpc/sysdev/fsl_pci.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..cb2ed92 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -17,6 +17,8 @@
  * Free Software Foundation;  either version 2 of the  License, or (at your
  * option) any later version.
  */
+
+#include 
 #include 
 #include 
 #include 
@@ -741,6 +743,7 @@ err0:
 
 int __init mpc83xx_add_bridge(struct device_node *dev)
 {
+   struct clk *clk;
int ret;
int len;
struct pci_controller *hose;
@@ -758,6 +761,18 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
}
pr_debug("Adding PCI host bridge %s\n", dev->full_name);
 
+   /* non-fatal OF clock lookup, but fatal when a clock
+* was specified yet could not get enabled */
+   clk = of_clk_get_by_name(dev, "per");
+   if (!IS_ERR(clk)) {
+   ret = clk_prepare_enable(clk);
+   clk_put(clk);
+   if (ret) {
+   pr_err("Could not enable peripheral clock\n");
+   return ret;
+   }
+   }
+
/* Fetch host bridge registers address */
if (of_address_to_resource(dev, 0, &rsrc_reg)) {
printk(KERN_WARNING "Can't get pci register base!\n");
-- 
1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v1 23/24] clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK

[Gerhard Sittig]

completely switch to, i.e. unconditionally use COMMON_CLK for the
MPC512x platform, and retire the PPC_CLOCK implementation for that
platform after the transition has completed

Signed-off-by: Gerhard Sittig 
---
 arch/powerpc/platforms/512x/Kconfig  |   14 +-
 arch/powerpc/platforms/512x/Makefile |3 +-
 arch/powerpc/platforms/512x/clock.c  |  753 --
 3 files changed, 2 insertions(+), 768 deletions(-)
 delete mode 100644 arch/powerpc/platforms/512x/clock.c

diff --git a/arch/powerpc/platforms/512x/Kconfig 
b/arch/powerpc/platforms/512x/Kconfig
index c5fcdd0..5aa3f4b 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -1,21 +1,9 @@
-config MPC512x_COMMON_CLK
-   bool "MPC512x platform uses COMMON_CLK"
-   default y
-   depends on PPC_MPC512x
-   help
- This option is only here to support tests and comparison
- during development and migration.  This option will get
- removed after the COMMON_CLK support for MPC512x has become
- fully operational and all drivers were adjusted to explicitly
- acquire their required clocks.
-
 config PPC_MPC512x
bool "512x-based boards"
depends on 6xx
+   select COMMON_CLK
select FSL_SOC
select IPIC
-   select PPC_CLOCK if !MPC512x_COMMON_CLK
-   select COMMON_CLK if MPC512x_COMMON_CLK
select PPC_PCI_CHOICE
select FSL_PCI if PCI
select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/arch/powerpc/platforms/512x/Makefile 
b/arch/powerpc/platforms/512x/Makefile
index 1e05f9d..bb20116 100644
--- a/arch/powerpc/platforms/512x/Makefile
+++ b/arch/powerpc/platforms/512x/Makefile
@@ -1,8 +1,7 @@
 #
 # Makefile for the Freescale PowerPC 512x linux kernel.
 #
-obj-$(CONFIG_PPC_CLOCK)+= clock.o
-obj-$(CONFIG_COMMON_CLK)   += clock-commonclk.o
+obj-y  += clock-commonclk.o
 obj-y  += mpc512x_shared.o
 obj-$(CONFIG_MPC5121_ADS)  += mpc5121_ads.o mpc5121_ads_cpld.o
 obj-$(CONFIG_MPC512x_GENERIC)  += mpc512x_generic.o
diff --git a/arch/powerpc/platforms/512x/clock.c 
b/arch/powerpc/platforms/512x/clock.c
deleted file mode 100644
index e504166..000
--- a/arch/powerpc/platforms/512x/clock.c
+++ /dev/null
@@ -1,753 +0,0 @@
-/*
- * Copyright (C) 2007,2008 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: John Rigby 
- *
- * Implements the clk api defined in include/linux/clk.h
- *
- *Original based on linux/arch/arm/mach-integrator/clock.c
- *
- *Copyright (C) 2004 ARM Limited.
- *Written by Deep Blue Solutions Limited.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include "mpc512x.h"
-
-#undef CLK_DEBUG
-
-static int clocks_initialized;
-
-#define CLK_HAS_RATE   0x1 /* has rate in MHz */
-#define CLK_HAS_CTRL   0x2 /* has control reg and bit */
-
-struct clk {
-   struct list_head node;
-   char name[32];
-   int flags;
-   struct device *dev;
-   unsigned long rate;
-   struct module *owner;
-   void (*calc) (struct clk *);
-   struct clk *parent;
-   int reg, bit;   /* CLK_HAS_CTRL */
-   int div_shift;  /* only used by generic_div_clk_calc */
-};
-
-static LIST_HEAD(clocks);
-static DEFINE_MUTEX(clocks_mutex);
-
-static struct clk *mpc5121_clk_get(struct device *dev, const char *id)
-{
-   struct clk *p, *clk = ERR_PTR(-ENOENT);
-   int dev_match;
-   int id_match;
-
-   if (dev == NULL || id == NULL)
-   return clk;
-
-   mutex_lock(&clocks_mutex);
-   list_for_each_entry(p, &clocks, node) {
-   dev_match = id_match = 0;
-
-   if (dev == p->dev)
-   dev_match++;
-   if (strcmp(id, p->name) == 0)
-   id_match++;
-   if ((dev_match || id_match) && try_module_get(p->owner)) {
-   clk = p;
-   break;
-   }
-   }
-   mutex_unlock(&clocks_mutex);
-
-   return clk;
-}
-
-#ifdef CLK_DEBUG
-static void dump_clocks(void)
-{
-   struct clk *p;
-
-   mutex_lock(&clocks_mutex);
-   printk(KERN_INFO "CLOCKS:\n");
-   list_for_each_entry(p, &clocks, node) {
-   pr_info("  %s=%ld", p->name, p->rate);
-   if (p->parent)
-   pr_cont(" %s=%ld", p->parent->name,
-  p->parent->rate);
-   if (p->flags & CLK_HAS_CTRL)
-   pr_cont(" reg/bit=%d/%d", p->reg, p->bit);
-   pr_cont("\n");
-   }
-   mutex_unlock(&clocks_mutex);
-}
-#define

[PATCH v1 24/24] net: can: mscan: remove MPC512x non-COMMON_CLK code path

[Gerhard Sittig]

transition to the COMMON_CLK framework has completed for the MPC512x
platform, remove the now obsolete code path of the mpc5xxx mscan
driver which accessed clock control module registers directly

Signed-off-by: Gerhard Sittig 
---
 drivers/net/can/mscan/mpc5xxx_can.c |  136 ---
 1 file changed, 136 deletions(-)

diff --git a/drivers/net/can/mscan/mpc5xxx_can.c 
b/drivers/net/can/mscan/mpc5xxx_can.c
index dd26ab6..cf5e4cfc 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,9 +108,6 @@ static u32 mpc52xx_can_get_clock(struct platform_device 
*ofdev,
 #endif /* CONFIG_PPC_MPC52xx */
 
 #ifdef CONFIG_PPC_MPC512x
-
-#if IS_ENABLED(CONFIG_COMMON_CLK)
-
 static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
 const char *clock_source, int *mscan_clksrc)
 {
@@ -244,139 +241,6 @@ err_notavail:
dev_err(&ofdev->dev, "cannot acquire or setup clock source\n");
return 0;
 }
-#else  /* COMMON_CLK */
-struct mpc512x_clockctl {
-   u32 spmr;   /* System PLL Mode Reg */
-   u32 sccr[2];/* System Clk Ctrl Reg 1 & 2 */
-   u32 scfr1;  /* System Clk Freq Reg 1 */
-   u32 scfr2;  /* System Clk Freq Reg 2 */
-   u32 reserved;
-   u32 bcr;/* Bread Crumb Reg */
-   u32 pccr[12];   /* PSC Clk Ctrl Reg 0-11 */
-   u32 spccr;  /* SPDIF Clk Ctrl Reg */
-   u32 cccr;   /* CFM Clk Ctrl Reg */
-   u32 dccr;   /* DIU Clk Cnfg Reg */
-   u32 mccr[4];/* MSCAN Clk Ctrl Reg 1-3 */
-};
-
-static struct of_device_id mpc512x_clock_ids[] = {
-   { .compatible = "fsl,mpc5121-clock", },
-   {}
-};
-
-static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
-const char *clock_name, int *mscan_clksrc)
-{
-   struct mpc512x_clockctl __iomem *clockctl;
-   struct device_node *np_clock;
-   struct clk *sys_clk, *ref_clk;
-   int plen, clockidx, clocksrc = -1;
-   u32 sys_freq, val, clockdiv = 1, freq = 0;
-   const u32 *pval;
-
-   np_clock = of_find_matching_node(NULL, mpc512x_clock_ids);
-   if (!np_clock) {
-   dev_err(&ofdev->dev, "couldn't find clock node\n");
-   return 0;
-   }
-   clockctl = of_iomap(np_clock, 0);
-   if (!clockctl) {
-   dev_err(&ofdev->dev, "couldn't map clock registers\n");
-   goto exit_put;
-   }
-
-   /* Determine the MSCAN device index from the peripheral's
-* physical address. Register address offsets against the
-* IMMR base are:  0x1300, 0x1380, 0x2300, 0x2380
-*/
-   pval = of_get_property(ofdev->dev.of_node, "reg", &plen);
-   BUG_ON(!pval || plen < sizeof(*pval));
-   clockidx = (*pval & 0x80) ? 1 : 0;
-   if (*pval & 0x2000)
-   clockidx += 2;
-
-   /*
-* Clock source and divider selection: 3 different clock sources
-* can be selected: "ip", "ref" or "sys". For the latter two, a
-* clock divider can be defined as well. If the clock source is
-* not specified by the device tree, we first try to find an
-* optimal CAN source clock based on the system clock. If that
-* is not posslible, the reference clock will be used.
-*/
-   if (clock_name && !strcmp(clock_name, "ip")) {
-   *mscan_clksrc = MSCAN_CLKSRC_IPS;
-   freq = mpc5xxx_get_bus_frequency(ofdev->dev.of_node);
-   } else {
-   *mscan_clksrc = MSCAN_CLKSRC_BUS;
-
-   pval = of_get_property(ofdev->dev.of_node,
-  "fsl,mscan-clock-divider", &plen);
-   if (pval && plen == sizeof(*pval))
-   clockdiv = *pval;
-   if (!clockdiv)
-   clockdiv = 1;
-
-   if (!clock_name || !strcmp(clock_name, "sys")) {
-   sys_clk = clk_get(&ofdev->dev, "sys_clk");
-   if (IS_ERR(sys_clk)) {
-   dev_err(&ofdev->dev, "couldn't get sys_clk\n");
-   goto exit_unmap;
-   }
-   /* Get and round up/down sys clock rate */
-   sys_freq = 100 *
-   ((clk_get_rate(sys_clk) + 49) / 100);
-
-   if (!clock_name) {
-   /* A multiple of 16 MHz would be optimal */
-   if ((sys_freq % 1600) == 0) {
-   clocksrc = 0;
-   clockdiv = sys_freq / 1600;
-   freq = sys_freq / clockdiv;
-   }
-   } else {
-   clocksrc = 0;
-  

Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates

[Lorenzo Pieralisi]

On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote:
> On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote:
> > On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote:
> >> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
> >>  wrote:
> >>> In order to extend the current cpu nodes bindings to newer CPUs
> >>> inclusive of AArch64 and to update support for older ARM CPUs this
> >>> patch updates device tree documentation for the cpu nodes bindings.
> >>
> >> Sorry for the long delay on this, but I'm still not happy with the binding 
> >> here.
> > 
> > I had to ask Russell again to drop the bindings patches from the patch
> > system, and this is not acceptable since two months have passed and the
> > entire series was reviewed, acked and partially merged. I will review
> > these bindings again but I would like to understand who should give the 
> > final
> > go ahead to get these patches queued for upstreaming, I can't continue
> > updating this stuff forever.
> 
> Most of my comments are for 64-bit. So don't blame me that it had to be
> reverted. I said up front I was concerned about this change breaking
> things and it appears it did. New kernels must not require a new DT.

The patches in Russell's tree do not break anything, I asked him to drop
them since, if we change the bindings again, those patches change and have
to be reworked. It was not meant to blame you at all, just saying that
the process to get this stuff in the kernel should be defined properly
and patches reviewed in a timely fashion.

And for legacy reasons the situation related to cpu/cpus node bindings
is a complicated one, there are bindings in the ePAPR, bindings in the
kernel, people are confused and with this set we wanted to draw a
line. For arm64 this is an absolute must.

I disagree with you on the "new kernels must not require a new DT".
That's true if bindings are well defined, not for a mix of legacy ePAPR and
bindings-in-the-kernel.

What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ?
A combination thereof ? Things are not clear cut and I do not like that, it
is confusing.

> But yes, this should have been reviewed more quickly. We're working on a
> plan to help address DT binding reviews. We have not enforced that Grant
> and I must ack all bindings, but in this case you certainly need mine
> since I have reviewed it and if you want to me to pull it.

Good, that's all I wanted to know, thanks.

> >>> Main changes:
> >>> - adds 64-bit bindings
> >>> - define usage of #address-cells
> >>> - define 32/64 dts compatibility settings
> >>> - defines behaviour on pre and post v7 uniprocessor systems
> >>> - adds ARM 11MPcore specific reg property definition
> >>>
> >>> Signed-off-by: Lorenzo Pieralisi 
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/cpus.txt | 459 
> >>> ++---
> >>>  1 file changed, 412 insertions(+), 47 deletions(-)
> >>
> >> [snip]
> >>
> >>> +   # On ARM v8 64-bit systems, where the reg property
> >>> + size can be 1 or 2 cells (as defined by cpus 
> >>> node's
> >>> + #address-cells property), this property is
> >>> + required and matches:
> >>> +
> >>> + - On systems running the OS in AArch32:
> >>
> >> The DTS cannot change based on 32-bit or 64-bit OS.
> > 
> > "On systems running the OS in AArch32" implies a dependency on the
> > HW execution state. Since the DT is used to configure OSs I thought that
> > could be a valid sentence. Unfortunately this stuff is not C, so I
> > reiterate my point above, before changing it I would like to understand
> > who should say the wording is ok otherwise we could argue forever.
> 
> It does configure the OS, but not for 32 vs. 64 bit. That is more of a
> problem for the bootloader to know which mode to boot in and covered
> under something like Documentation/arm/Booting. Booting ARM vs. Thumb
> mode would be similar situation.
> 
> Think about how your PC boots and add to that having a DTB as part of
> the firmware shipped with your PC. Then the end user can install a
> 32-bit or 64-bit OS on it. That is the usecase that needs to be
> supported and having different DTB for 32 and 64 bit is totally broken
> and doesn't even help solve that problem.

I will give it more thought, point taken.

> >>> +
> >>> +   - cpu-release-addr
> >>> +   Usage: required for systems that have an "enable-method"
> >>> +  property value of "spin-table".
> >>> +   Value type: 
> >>> +   Definition:
> >>> +   # On ARM v8 64-bit systems must be a two cell
> >>> + property identifying a 64-bit zero-initialised
> >>> + memory location.
> >>
> >> As I mentioned previously, isn't some wake-up method needed? Most
> >> systems will be in wfi or wfe rather than continuously spinning.

Re: [PATCH] gpio-rcar: Add interrupt controller support to the DT bindings

[Laurent Pinchart]

Hi Linus,

On Thursday 04 July 2013 19:44:39 Laurent Pinchart wrote:
> Update the DT bindings documentation with the interrupt-controller
> and #interrupt-cells properties.

Patches that make use of this binding have been merged to Simon's tree. Could 
you consider merging this patch in your tree (or tell me I've got something 
completely wrong and ask me to fix it :-)) ?

> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index
> cb3dc7b..8655df9 100644
> --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
> @@ -23,6 +23,10 @@ Required Properties:
>  Please refer to gpio.txt in this directory for details of gpio-ranges
> property and the common GPIO bindings used by client devices.
> 
> +The GPIO controller also acts as an interrupt controller. It uses the
> default
> +two cells specifier as described in Documentation/devicetree/bindings/
> +interrupt-controller/interrupts.txt.
> +
>  Example: R8A7779 (R-Car H1) GPIO controller nodes
> 
>   gpio0: gpio@ffc4 {
> @@ -33,6 +37,8 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes
>   #gpio-cells = <2>;
>   gpio-controller;
>   gpio-ranges = <&pfc 0 0 32>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
>   };
>   ...
>   gpio6: gpio@ffc46000 {
> @@ -43,4 +49,6 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes
>   #gpio-cells = <2>;
>   gpio-controller;
>   gpio-ranges = <&pfc 0 192 9>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
>   };
-- 
Regards,

Laurent Pinchart

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Philipp Zabel]

Hi Shawn,

Am Dienstag, den 16.07.2013, 12:10 +0800 schrieb Shawn Guo:
> On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
> > > It's a little bit late to register gpio-reset driver at module_init
> > > time, because gpio-reset provides reset control via gpio for other
> > > devices which are mostly probed at module_init time too.  And it
> > > becomes even worse, when the gpio comes from IO expander on I2C bus,
> > > e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> > > bus driver which is generally ready at subsys_initcall time.  Let's
> > > register gpio-reset driver in arch_initcall() to have it ready early
> > > enough.
> > 
> > There's no need for the reset driver to be registered before its users;
> > the users of the reset GPIO will simply have their probe deferred until
> > the reset controller is available, and then everything will work out
> > just fine.
> > 
> > > The defer probe mechanism is not used here, because a reset controller
> > > driver should be reasonably registered early than other devices.  More
> > > importantly, defer probe doe not help in some nasty cases, e.g. the
> > > gpio-pca953x device itself needs a reset from gpio-reset driver to start
> > > working.
> > 
> > That should work fine with deferred probe.
> 
> I should probably rework the commit log.  But I do not see a problem
> to register gpio-reset driver a little bit earlier.  On the other hand,
> if we reply on deferred probe, many drivers probe could be deferred.
> For example, on my system, the gpio-pca953x on I2C bus works as a GPIO
> controller and provides resets to many board level components.
> Deferring probe of gpio-pca953x on I2C bus means every single probe of
> all these components gets deferred.  IMO, this situation should be
> reasonably avoided.

so you want to have gpio-reset probed at arch_initcall time and you have
gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset
devices that use gpios on pca953x to reset other peripherals need to be
deferred?

regards
Philipp

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Philipp Zabel]

Am Dienstag, den 16.07.2013, 14:51 +0800 schrieb Shawn Guo:
> On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
> > Hi Philipp,
> > 
> > On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> > > This driver implements a reset controller device that toggle a gpio
> > > connected to a reset pin of a peripheral IC. The delay between assertion
> > > and de-assertion of the reset signal can be configured via device tree.
> > > 
> > > Signed-off-by: Philipp Zabel 
> > > Reviewed-by: Stephen Warren 
> > 
> > I see this patch is very useful, as GPIOs are widely used to reset
> > components/devices on board.  But I do not find the patch in v3.11-rc1.
> > What's your plan about it?
> > 
> > Also, I'm wondering if we should register the driver a little bit
> > early.  Please see the following patch.  If it makes sense to you,
> > I can send the patch to you, or you can just quash it into yours.
> 
> And here is another change request.

Looks good to me. I can squash it into the original patch and resend if
you like.

regards
Philipp

> Shawn
> 
> 8<---
> 
> From 822a0c4fb7c99b371844ba7e957affcaa8cb1cfe Mon Sep 17 00:00:00 2001
> From: Shawn Guo 
> Date: Sun, 14 Jul 2013 20:28:05 +0800
> Subject: [PATCH] ENGR00269945: reset: handle cansleep case in gpio-reset
> 
> Some gpio reset may be backed by a gpio that can sleep, e.g. pca953x
> gpio output.  For such gpio, gpio_set_value_cansleep() should be
> called.  Otherwise, the WARN_ON(chip->can_sleep) in gpiod_set_value()
> will be hit.  Add a gpio_cansleep() check to handle cansleep gpio.
> 
> Signed-off-by: Shawn Guo 
> ---
>  drivers/reset/gpio-reset.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
> index 5d2515a..4f372f9 100644
> --- a/drivers/reset/gpio-reset.c
> +++ b/drivers/reset/gpio-reset.c
> @@ -32,7 +32,10 @@ static void gpio_reset_set(struct reset_controller_dev 
> *rcdev, int asserted)
>   if (drvdata->active_low)
>   value = !value;
>  
> - gpio_set_value(drvdata->gpio, value);
> + if (gpio_cansleep(drvdata->gpio))
> + gpio_set_value_cansleep(drvdata->gpio, value);
> + else
> + gpio_set_value(drvdata->gpio, value);
>  }
>  
>  static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Philipp Zabel]

Hi Stephen,

Am Montag, den 15.07.2013, 21:35 -0600 schrieb Stephen Warren:
> On 07/15/2013 07:50 PM, Shawn Guo wrote:
> > Hi Philipp,
> > 
> > On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
> >> This driver implements a reset controller device that toggle a gpio
> >> connected to a reset pin of a peripheral IC. The delay between assertion
> >> and de-assertion of the reset signal can be configured via device tree.
> >>
> >> Signed-off-by: Philipp Zabel 
> >> Reviewed-by: Stephen Warren 
> > 
> > I see this patch is very useful, as GPIOs are widely used to reset
> > components/devices on board.  But I do not find the patch in v3.11-rc1.
> > What's your plan about it?
> > 
> > Also, I'm wondering if we should register the driver a little bit
> > early.  Please see the following patch.  If it makes sense to you,
> > I can send the patch to you, or you can just quash it into yours.
> > 
> > Shawn
> > 
> > ---8<
> > 
> > From 2f8ce9e5d6525b98f3828b707458e83fabb39d50 Mon Sep 17 00:00:00 2001
> > From: Shawn Guo 
> > Date: Sun, 14 Jul 2013 20:41:00 +0800
> > Subject: [PATCH] ENGR00269945: reset: register gpio-reset driver in
> >  arch_initcall
> > 
> > It's a little bit late to register gpio-reset driver at module_init
> > time, because gpio-reset provides reset control via gpio for other
> > devices which are mostly probed at module_init time too.  And it
> > becomes even worse, when the gpio comes from IO expander on I2C bus,
> > e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
> > bus driver which is generally ready at subsys_initcall time.  Let's
> > register gpio-reset driver in arch_initcall() to have it ready early
> > enough.
> 
> There's no need for the reset driver to be registered before its users;
> the users of the reset GPIO will simply have their probe deferred until
> the reset controller is available, and then everything will work out
> just fine.
> 
> > The defer probe mechanism is not used here, because a reset controller
> > driver should be reasonably registered early than other devices.  More
> > importantly, defer probe doe not help in some nasty cases, e.g. the
> > gpio-pca953x device itself needs a reset from gpio-reset driver to start
> > working.
> 
> That should work fine with deferred probe.

Deferred probing is fine, but it'd be nice to keep the probe deferral
loops to a minimum where possible and/or reasonable.

regards
Philipp

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH RFC v2 2/5] dma: mpc512x: add support for peripheral transfers

[Lars-Peter Clausen]

On 07/14/2013 02:01 PM, Gerhard Sittig wrote:
> From: Alexander Popov 
> 
> introduce support for slave s/g transfer preparation and the associated
> device control callback in the MPC512x DMA controller driver, which adds
> support for data transfers between memory and peripheral I/O to the
> previously supported mem-to-mem transfers
> 
> refuse to prepare chunked transfers (transfers with more than one part)
> as long as proper support for scatter/gather is lacking
> 
> keep MPC8308 operational by always starting transfers from software,
> this SoC appears to not have request lines for flow control when
> peripherals are involved in transfers

I had a look at the current driver and it seems that any channel can be used
for memcpy operation not only the MDDRC channel. Since the dmaengine API
will just pick one of the currently free channels when performing a memcpy
operation I think this patch breaks memcpy operations. You probably need to
register two dma controllers, one for memcpy operations one for slave
operations, that way you can ensure that only the MDDRC channel is used for
memcpy operations.

> 
> [ introduction of slave s/g preparation and device control ]
> Signed-off-by: Alexander Popov 
> [ execute() start condition, mpc8308 compat, terminate all, s/g length check, 
> reworded commit msg ]
> Signed-off-by: Gerhard Sittig 
> ---
[...]
> +
> +static int mpc_dma_device_control(struct dma_chan *chan, enum dma_ctrl_cmd 
> cmd,
> +   unsigned long arg)
> +{
> + struct mpc_dma_chan *mchan;
> + struct mpc_dma *mdma;
> + struct dma_slave_config *cfg;
> +
> + mchan = dma_chan_to_mpc_dma_chan(chan);
> + switch (cmd) {
> + case DMA_TERMINATE_ALL:
> + /* disable channel requests */
> + mdma = dma_chan_to_mpc_dma(chan);
> + out_8(&mdma->regs->dmacerq, chan->chan_id);
> + list_splice_tail_init(&mchan->prepared, &mchan->free);
> + list_splice_tail_init(&mchan->queued, &mchan->free);
> + list_splice_tail_init(&mchan->active, &mchan->free);

This probably need locking.

> + return 0;
[...]
> +}
> +
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates

[Dave Martin]

On Fri, Jul 12, 2013 at 09:47:17AM -0500, Rob Herring wrote:
> On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
>  wrote:
> > In order to extend the current cpu nodes bindings to newer CPUs
> > inclusive of AArch64 and to update support for older ARM CPUs this
> > patch updates device tree documentation for the cpu nodes bindings.
> 
> Sorry for the long delay on this, but I'm still not happy with the binding 
> here.
> 
> > Main changes:
> > - adds 64-bit bindings
> > - define usage of #address-cells
> > - define 32/64 dts compatibility settings
> > - defines behaviour on pre and post v7 uniprocessor systems
> > - adds ARM 11MPcore specific reg property definition
> >
> > Signed-off-by: Lorenzo Pieralisi 
> > ---
> >  Documentation/devicetree/bindings/arm/cpus.txt | 459 
> > ++---
> >  1 file changed, 412 insertions(+), 47 deletions(-)
> 
> [snip]
> 
> > +   # On ARM v8 64-bit systems, where the reg property
> > + size can be 1 or 2 cells (as defined by cpus 
> > node's
> > + #address-cells property), this property is
> > + required and matches:
> > +
> > + - On systems running the OS in AArch32:
> 
> The DTS cannot change based on 32-bit or 64-bit OS.
> 
> > +
> > +   * If the cpus node's #address-cells value is 2:
> > +
> > + The first reg cell must be set to 0.
> > +
> > + The second reg cell bits [23:0] must be set to
> > + bits [23:0] of MPIDR_EL1.
> > +
> > + All other bits in the reg cells must be set 
> > to 0.
> > +
> > +   * If the cpus node's #address-cells value is 1:
> > +
> > + Bits [23:0] in the reg cell must be set to
> > + bits [23:0] in MPIDR_EL1.
> > +
> > + All other bits in the reg cell must be 0.
> > +
> > + - On systems running the OS in AArch64:
> > +
> > +   * If the cpus node's #address-cells value is 2:
> > +
> > + The first reg cell bits [7:0] must be set to
> > + bits [39:32] of MPIDR_EL1.
> > +
> > + The second reg cell bits [23:0] must be set to
> > + bits [23:0] of MPIDR_EL1.
> > +
> > + All other bits in the reg cells must be set 
> > to 0.
> > +
> > +   * If the cpus node's #address-cells value is 1:
> > +
> > + MPIDR_EL1[63:32] is 0 on all processors in the
> > + system.
> 
> Your logic is backwards here. If the MPIDR_EL1[63:32] is 0, then
> #address-cells can be 1. You could say the upper bits are ignored and
> treated as 0. However, you should simplify all this and just mandate
> that #address-cells must be 2 for ARMv8 or more generally must match
> the size of the MPIDR. If we want to boot a 32-bit kernel, then the
> kernel will have to adapt to support this.

I'd support this, opting for a clean split.

Strictly speaking, it should be this:

AArch64-capable hardware: #address-cells = 2
non-AArch64-capable hardware: #address-cells = 1

The only time it is valid to have #address-cells = 1 on AArch64-capable
hardware is in an AArch32 virtual machine (in which case, the DT anyway
describes the VM and not the real hardware).


However, due to the awkwardness of defining precisely what "AArch64-
capable hardware" means in a world containing firmware and hypervisors,
it might be better (if slightly less correct) to go with:

v8 hardware: #address-cells must be 2
<=v7 hardware: #address-cells must be 1


If the firmware boots an AArch32 payload natively on AArch64-capable
v8 hardware, it's the firmware's job to ensure that non-addressable
CPUs are properly quiesced and shut down, otherwise the setup is
pretty broken -- DT can't solve that one, nor can Linux, so we shouldn't
try.  Linux just needs to discard the non-addressable CPUs and maybe
print out a warning.


Cheers
---Dave
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP

[Thomas Petazzoni]

Dear Nicolas Ferre,

On Tue, 16 Jul 2013 10:46:28 +0200, Nicolas Ferre wrote:

> > Ok, that make sense. I will use compatible names for the capabilities in
> > next version. Thanks.
> 
> Hold on a little bit Josh, I know that Jean-Christophe is not in favor 
> of the use of multiple compatible strings. So, as the code is already 
> there, let's wait and see if we find another argument...

I've asked exactly this question last week at Linaro Connect during the
ARM SoC consolidation panel/discussion, where Grant Likely, Arnd
Bergmann, Olof and others were answering Device Tree related questions.

My question, which precisely had the at91-adc DT binding in mind was
precisely whether we should use different compatible properties to
identify different revisions of an IP block and let the driver handle
those differences, or whether the DT binding should provide sufficient
properties (register offsets, bit numbers, etc.) to make the driver
independent of the IP revisions. And clearly, the answer was that
different compatible properties should be used to identify the
different versions of the IP block, and the driver should abstract out
the differences. I.e, was has been done for at91-adc is completely the
opposite of the best practices for Device Tree on ARM.

See
http://www.youtube.com/watch?v=zF_AXLgkFy4&feature=player_detailpage#t=1581s
where I ask exactly this question, and get answers from Olof Johansson
and Grant Likely. They clearly say that the solution of having separate
compatible properties and a driver that handles the differences is the
way to go. So the way at91-adc (and possibly other at91 drivers) is
using the Device Tree is wrong, there should have been multiple
compatible properties. It's a shame because this is something we did say
when we submitted at91-adc and during the reviews, but the maintainer
wasn't listening to our comments...

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] tty: serial: Add initial MSM UART High Speed Lite driver

[Ivan T. Ivanov]

Hi Greg, 

On Mon, 2013-07-01 at 12:11 +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" 
> 
> This is a tty driver with console support for Qualcomm's UART
> controllers found in the MSM8974 chipsets. Driver is completely
> based on implementation found in codeaurora.org msm_serial_hs_lite
> with Android dependences removed. Other changes include, moved to
> device managed resources and few cleanups.
> 
> Driver functionality was tested in LEGACY_HSUART mode.
> 

Please, could you take a look at this driver. It have been 
tested on these new Snapdragon 8074 based DragonBoards. 

If there is something that I have to fix or improve in 
the code please let me know.

Regards,
Ivan


> Signed-off-by: Ivan T. Ivanov 
> ---
>  .../bindings/tty/serial/msm_serial_hsl.txt |   52 +
>  drivers/tty/serial/Kconfig |   18 +
>  drivers/tty/serial/Makefile|1 +
>  drivers/tty/serial/msm_serial_hsl.c| 1399 
> 
>  drivers/tty/serial/msm_serial_hsl.h|  294 
>  5 files changed, 1764 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
>  create mode 100644 drivers/tty/serial/msm_serial_hsl.c
>  create mode 100644 drivers/tty/serial/msm_serial_hsl.h
> 
> diff --git a/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt 
> b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
> new file mode 100644
> index 000..972552f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
> @@ -0,0 +1,52 @@
> +* Qualcomm MSM HSUART Lite
> +
> +Required properties:
> +- compatible :
> + "qcom,msm-lsuart-v14" to be used for UARTDM Core v1.4
> +
> +- reg :
> + offset and length of the register set for both the device,
> + UART core and GBSI core
> +
> +- reg-names :
> + "uart_mem" to be used as name of the UART core
> + "gbsi_mem" to be used as name of the GBSI core
> +
> +The registers for the "qcom,msm-lsuart-v14" device have specify
> +UART core block. GSBI reg is optional if specified driver will use
> +GSBI specific functionality.
> +
> +- interrupts : interrupts for UART core
> +
> +- clocks : Must contain an entry for each entry in clock-names.
> +
> +- clock-names : Must include the following entries:
> +  "core_clk" - mandatory
> +  "iface_clk" - optional
> +
> +For details see:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Example:
> +
> + serial@f991e000 {
> + compatible = "qcom,msm-lsuart-v14";
> + reg = <0xf991e000 0x1000>;
> + reg-names = "uart_mem";
> + interrupts = <0 108 0>;
> + clocks = <&blsp1_uart2_apps_cxc>, <&blsp1_ahb_cxc>;
> + clock-names = "core_clk", "iface_clk";
> + };
> +
> +Aliases :
> +An alias may be optionally used to bind the UART device to a TTY device
> +(ttyHSL) with a given alias number. Aliases are of the form
> +uart where  is an integer representing the alias number to use.
> +On systems with multiple UART devices present, an alias may optionally be
> +defined for such devices. The alias value should be from 0 to 255.
> +
> +Example:
> +
> + aliases {
> + uart4 = &uart7; // This device will be enumerated as ttyHSL4
> + };
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 7e7006f..4482bc7 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1046,6 +1046,24 @@ config SERIAL_MSM_HS
> Choose M here to compile it as a module. The module will be
> called msm_serial_hs.
>  
> +config SERIAL_MSM_HSL
> + tristate "MSM High speed serial lite mode driver"
> + depends on ARM && ARCH_MSM
> + select SERIAL_CORE
> + default n
> + help
> +   Select this module to enable MSM high speed lite mode driver
> +   for UART controllers found in MSM8974 SoC's
> +
> +   Choose M here to compile it as a module. The module will be
> +   called msm_serial_hsl.
> +
> +config SERIAL_MSM_HSL_CONSOLE
> + bool "MSM High speed serial lite mode console support"
> + depends on SERIAL_MSM_HSL=y
> + select SERIAL_CORE_CONSOLE
> + default n
> +
>  config SERIAL_VT8500
>   bool "VIA VT8500 on-chip serial port support"
>   depends on ARCH_VT8500
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index eedfec4..86c023b 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
>  obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
>  obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
>  obj-$(CONFIG_SERIAL_MSM_HS) += msm_serial_hs.o
> +obj-$(CONFIG_SERIAL_MSM_HSL) += msm_serial_hsl.o
>  obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
>  obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
>  obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
> diff --git a/drivers/

[PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 sound/soc/fsl/imx-sgtl5000.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index 7a8bc12..25f310d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -129,8 +129,10 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
}
 
data->codec_clk = devm_clk_get(&codec_dev->dev, NULL);
-   if (IS_ERR(data->codec_clk))
+   if (IS_ERR(data->codec_clk)) {
+   ret = PTR_ERR(data->codec_clk);
goto fail;
+   }
 
data->clk_frequency = clk_get_rate(data->codec_clk);
 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Ezequiel Garcia]

Hi Thomas, Andrew:

Thanks for looking at this!

On Tue, Jul 16, 2013 at 09:31:01AM +0200, Andrew Lunn wrote:
> On Tue, Jul 16, 2013 at 09:20:59AM +0200, Thomas Petazzoni wrote:
> > 
> > On Tue, 16 Jul 2013 08:59:52 +0200, Andrew Lunn wrote:
> > 
> > > Maybe i'm missing something here. You are making use of
> > > orion_timer_ctrl_clrset() from time-orion.c. How will this work on
> > > 370/XP which has a different clocksource driver?
> > 
> > I *think* the idea is that the Armada 370/XP driver will expose the
> > same function, so from the point of view of the watchdog driver, it
> > will just work.

Indeed that was one of the ideas. As Thomas said, this was just
preparation work.

> 
> That was what i was thinking would happen. And then i started to
> wonder how well the kernel linker deals with multiple definitions of
> the same symbol. Dove and 370/XP can end up in the same kernel. So we
> need to have both orion-timer and the 370/XP timer in the same kernel,
> so we end up with the same symbol in the kernel twice...
> 

Yeah, well... I wasn't sure about using the same name, so another approach
would be adding a new compatible to the driver and then make it use the
appropriate function in the 370/XP clocksource driver (with a different name).

And, yet another approach, is what Sebastian just said, although I'm
not sure I understood it :). In any case, we have already several solutions,
which is why I'm not too worried about this particular issue.

On the other side, I'm much interested in knowing if you are OK with
breaking the watchdog DT compatibility. If you NACK this, then I'll
start preparing a different watchdog driver for 370/XP, since I don't
want to extend a driver that is a bit dirty.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Shawn Guo]

On Tue, Jul 16, 2013 at 11:51:19AM +0200, Philipp Zabel wrote:
> Looks good to me. I can squash it into the original patch and resend if
> you like.

Yes, please.  Thanks.

Shawn

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Ezequiel Garcia]

Hi Sebastian,

On Tue, Jul 16, 2013 at 09:48:56AM +0200, Sebastian Hesselbarth wrote:
> 
> In the discussion about orion clocksource Russell was proposing a generic 
> thread-safe write. That puts a single lock around all those writes. Of 
> course, it will also blocked by totally unrelated thread-safe register 
> accesses but should prevent us from having dozens of locks and solves the 
> symbol issue.
> 

Thanks for the insight! I'll try to dig this suggestion in the clocksource
discussion. Do you have any plans for posting the clocksource soon?
This way I can base this series on something that's in Jason's trees...

Thanks!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()

[Shawn Guo]

On Tue, Jul 16, 2013 at 08:05:07PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> 
> Signed-off-by: Wei Yongjun 

Acked-by: Shawn Guo 

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock

[Tony Lindgren]

* Roger Quadros  [130715 07:11]:
> Hi Tony,
> 
> On 06/18/2013 07:04 PM, Roger Quadros wrote:
> > Till the OMAP clocks are correctly defined in device tree, use
> > this temporary hack to provide clock alias to the USB PHY clocks.
> > 
> > Without this, USB Host & Ethernet will not be functional with
> > device tree boots on Panda and uEVM.
> 
> Looks like this one got missed out.
> 
> USB host no longer works on Panda with DT boot.
> Could you please queue this for next 3.11-rc? Thanks.

OK thanks for checking, applying into omap-for-v3.11/fixes.

Looks like I also have some pending the .dts changes in
omap-for-v3.11/dt branch:

4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB 
host supprot for Rev. Ax/Bx
9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB 
Host support
fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB host 
pin naming consistent
39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host 
support

Those should get merged as fixes, right? Can you please
check and see if they're still OK or if we also need
something else?

Regards,

Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/2] ASoC: tlv320aic3x: Add compatible strings for specific devices

[Mark Brown]

From: Mark Brown 

The driver supports a range of devices but currently doesn't allow those
device names to be used for enumeration on DT. Add the currently listed
I2C IDs as compatible strings.

Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/sound/tlv320aic3x.txt | 8 +++-
 sound/soc/codecs/tlv320aic3x.c  | 2 ++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt 
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index f47c3f5..26f65f9 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -3,7 +3,13 @@ Texas Instruments - tlv320aic3x Codec module
 The tlv320aic3x serial control bus communicates through I2C protocols
 
 Required properties:
-- compatible - "string" -  "ti,tlv320aic3x"
+
+- compatible - "string" - One of:
+"ti,tlv320aic3x" - Generic TLV320AIC3x device
+"ti,tlv320aic33" - TLV320AIC33
+"ti,tlv320aic3007" - TLV320AIC3007
+
+
 - reg -  -  I2C slave address
 
 
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index e5b9268..c9bb760 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -1582,6 +1582,8 @@ static int aic3x_i2c_remove(struct i2c_client *client)
 #if defined(CONFIG_OF)
 static const struct of_device_id tlv320aic3x_of_match[] = {
{ .compatible = "ti,tlv320aic3x", },
+   { .compatible = "ti,tlv320aic33" },
+   { .compatible = "ti,tlv320aic3007" },
{},
 };
 MODULE_DEVICE_TABLE(of, tlv320aic3x_of_match);
-- 
1.8.3.2

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 2/2] ASoC: tlv320aic3x: List tlv320aic3106 as a supported device

[Mark Brown]

From: Mark Brown 

Currently there is no specific handling for it but the tlv320aic3106 is
supported using this driver.

Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/sound/tlv320aic3x.txt | 1 +
 sound/soc/codecs/tlv320aic3x.c  | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt 
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 26f65f9..705a6b1 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -8,6 +8,7 @@ Required properties:
 "ti,tlv320aic3x" - Generic TLV320AIC3x device
 "ti,tlv320aic33" - TLV320AIC33
 "ti,tlv320aic3007" - TLV320AIC3007
+"ti,tlv320aic3106" - TLV320AIC3106
 
 
 - reg -  -  I2C slave address
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index c9bb760..cad4fb1 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -1492,6 +1492,7 @@ static const struct i2c_device_id aic3x_i2c_id[] = {
{ "tlv320aic3x", AIC3X_MODEL_3X },
{ "tlv320aic33", AIC3X_MODEL_33 },
{ "tlv320aic3007", AIC3X_MODEL_3007 },
+   { "tlv320aic3106", AIC3X_MODEL_3X },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, aic3x_i2c_id);
@@ -1584,6 +1585,7 @@ static const struct of_device_id tlv320aic3x_of_match[] = 
{
{ .compatible = "ti,tlv320aic3x", },
{ .compatible = "ti,tlv320aic33" },
{ .compatible = "ti,tlv320aic3007" },
+   { .compatible = "ti,tlv320aic3106" },
{},
 };
 MODULE_DEVICE_TABLE(of, tlv320aic3x_of_match);
-- 
1.8.3.2

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Shawn Guo]

On Tue, Jul 16, 2013 at 11:49:26AM +0200, Philipp Zabel wrote:
> so you want to have gpio-reset probed at arch_initcall time and you have
> gpio-pca953x probed at subsys_initcall time. Won't then all gpio-reset
> devices that use gpios on pca953x to reset other peripherals need to be
> deferred?

Yes, they will be deferred, but they will be probed and ready at
subsys_initcall time when gpio-pca953x probes.  This is still good since
most of component device drivers probes at module_init time.

Shawn

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] ARM: Kirkwood: Fix the internal register ranges translation

[Ezequiel Garcia]

Hi Gerlando,

On Tue, Jul 16, 2013 at 11:37:30AM +0200, Gerlando Falauto wrote:
> 
> apologies in advance for commenting on an already-merged patch.

Sure, no problem.

> 
> On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
> > Although the internal register window size is 1 MiB, the previous
> > ranges translation for the internal register space had a size of
> > 0x400. This was done to allow the crypto and nand node to access
> > the corresponding 'sram' and 'nand' decoding windows.
> >
> > In order to describe the hardware more accurately, we declare the
> > real 1 MiB internal register space in the ranges, and add a translation
> > entry for the nand node to access the 'nand' window.
> >
> > This commit will make future improvements on the MBus DT binding easier.
> >
> > Signed-off-by: Ezequiel Garcia 
> > 
> > ---
> > Tested on Plathome Openblocks A6 board.
> >
> >   arch/arm/boot/dts/kirkwood.dtsi | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/kirkwood.dtsi 
> > b/arch/arm/boot/dts/kirkwood.dtsi
> > index 8a1e3bb..910fabc 100644
> > --- a/arch/arm/boot/dts/kirkwood.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood.dtsi
> > @@ -38,7 +38,8 @@
> >
> > ocp@f100 {
> > compatible = "simple-bus";
> > -   ranges = <0x 0xf100 0x400
> > +   ranges = <0x 0xf100 0x010
> > + 0xf400 0xf400 0x400
> >   0xf500 0xf500 0x400>;
> 
> Apart from "consistency" with the following range (0xf500) used by 
> the crypto node, is there any reason why you did not do something like 
> this instead (which Valentin suggested, but I will take the blame for):
> 

I'm not sure the reason is "consistency with the crypto node".
There's an MBus window at 0xf400 for NAND, and that is what is described
in the snippet above; and this is a better reason.

That said, technically speaking, you can have any translation scheme you want,
as long as it ends up in 0xf400.

> - ranges = <0x 0xf100 0x400
> + ranges = <0x 0xf100 0x010
> +   0x0300 0xf400 0x400
> 0xf500 0xf500 0x400>;
> 
> This would keep a consistent addressing within the child device bus, and 

Could you explain how this "keeps a consistent addressing"?
Frankly, I don't understand why you choose 0x300 ... am I missing something?

Also, speaking of "device bus" this nand node should be behind a devicebus node.

ranges = ;

devbus {
status = "okay";
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x400>;

/* nand */
nand {
compatible = "marvell,orion-nand";
reg = <0 0x400>;
};
};

(notice this will allow you to relocate the base address of the NAND windows
easily if it conflicts with your PCIe needs).

> avoid a later incosistency between the "unit-address" and the first 
> "reg" address:
> 
> > #address-cells = <1>;
> > #size-cells = <1>;
> > @@ -171,7 +172,7 @@
>  >nand@300 {
>^^^

Oh, this should be fixed. I just missed it, and nobody noticed either.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock

[Arend van Spriel]

On 07/16/2013 03:12 PM, Arend van Spriel wrote:

On 07/15/2013 04:05 PM, Roger Quadros wrote:

Hi Tony,

On 06/18/2013 07:04 PM, Roger Quadros wrote:

Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.

Without this, USB Host & Ethernet will not be functional with
device tree boots on Panda and uEVM.


Looks like this one got missed out.


Could it be because you promised to resend it (see [1]). I was upgrading
our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine,
but no USB/ethernet. Should I pickup all four patches?


Nevermind. The first three seem to be in already.


Regards,
Arend

[1] http://mid.gmane.org/51c2ec5f.8050...@ti.com


USB host no longer works on Panda with DT boot.
Could you please queue this for next 3.11-rc? Thanks.

cheers,
-roger






___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock

[Arend van Spriel]

On 07/15/2013 04:05 PM, Roger Quadros wrote:

Hi Tony,

On 06/18/2013 07:04 PM, Roger Quadros wrote:

Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.

Without this, USB Host & Ethernet will not be functional with
device tree boots on Panda and uEVM.


Looks like this one got missed out.


Could it be because you promised to resend it (see [1]). I was upgrading 
our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine, 
but no USB/ethernet. Should I pickup all four patches?


Regards,
Arend

[1] http://mid.gmane.org/51c2ec5f.8050...@ti.com


USB host no longer works on Panda with DT boot.
Could you please queue this for next 3.11-rc? Thanks.

cheers,
-roger




___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 4/4] iio: lps331ap: Add support for DT

[Maxime Ripard]

Hi Jacek,

I find myself needing these bindings as well, so I'm definitely
interested by your patches.

On Tue, Jul 02, 2013 at 02:15:38PM +0200, Lukasz Czerwinski wrote:
> From: Jacek Anaszewski 
> 
> This patch adds DT support for the lps331ap barometer
> sensor.
> 
> Signed-off-by: Jacek Anaszewski 
> Signed-off-by: Kyungmin Park 
> ---
>  .../bindings/iio/pressure/st_pressure.txt  |   41 
> 
>  drivers/iio/pressure/st_pressure_i2c.c |9 +
>  drivers/iio/pressure/st_pressure_spi.c |9 +
>  3 files changed, 59 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/pressure/st_pressure.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt 
> b/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt
> new file mode 100644
> index 000..73a4b7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/pressure/st_pressure.txt
> @@ -0,0 +1,41 @@
> +* STMicroelectronics LPS331AP barometer sensor
> +
> +Required properties:
> +
> +  - compatible : should be "lps331ap"
> +  - reg : the I2C address of the barometer
> +
> +Optional properties:
> +
> +  - drdy-int-pin : redirect DRDY on pin INT1 (1) or pin INT2 (2) (u8)
> +  - interrupt-parent : phandle to the interrupt map subnode
> +  - interrupts : interrupt mapping for LPS331AP interrupt sources:
> + 2 sources: 0 - INT1, 1 - INT2

Maybe you could use interrupts-names here, instead of requiring to
hardcode the interrupt index. Plus, I guess that it's assuming that you
can only use INT2 when you already use INT1?

> +  - irq-map : irq sub-node defining interrupt map
> +   (all properties listed below are required):
> +  - #interrupt-cells : should be 1
> +  - #address-cells : should be 0
> +  - #size-cells : should be 0
> +  - interrupt-map : table of entries consisting of three child elements:
> +   - unit_interrupt_specifier - 0 : INT1, 1 : INT2
> +   - interrupt parent phandle
> +   - parent unit interrupt specifier consisiting of two elements:
> +   - index of the interrupt within the controller
> +   - flags : should be 0

I don't really get why it's needed. Isn't that redundant with the
interrupt parent and the interrupt number already defined by
interrupt-parent and interrupts in the top node?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 06/10] watchdog: orion: Update device-tree binding documentation

[Jason Cooper]

On Mon, Jul 15, 2013 at 08:32:39PM -0300, Ezequiel Garcia wrote:
> Now that the 'reg' property meaning has been changed,
> this commit updates the deivce-tree binding documentation.

nit. s/deivce/device/

> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  Documentation/devicetree/bindings/watchdog/orion-wdt.txt | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
> index 5dc8d30..48a71fc 100644
> --- a/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/orion-wdt.txt
> @@ -3,7 +3,8 @@
>  Required Properties:
>  
>  - Compatibility : "marvell,orion-wdt"
> -- reg: Address of the timer registers
> +- reg: First cell contains the register for the watchdog 
> counter.
> +   Second cell contains the register for the RSTOUT mask.
>  
>  Optional properties:
>  
> @@ -11,9 +12,10 @@ Optional properties:
>  
>  Example:
>  
> - wdt@20300 {
> + wdt@20324 {
>   compatible = "marvell,orion-wdt";
> - reg = <0x20300 0x28>;
> + reg = <0x20324 0x4
> +0x20108 0x4>;
>   timeout-sec = <10>;
>   status = "okay";
>   };
> -- 
> 1.8.1.5
> 
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock

[Roger Quadros]

On 07/16/2013 03:32 PM, Tony Lindgren wrote:
> * Roger Quadros  [130715 07:11]:
>> Hi Tony,
>>
>> On 06/18/2013 07:04 PM, Roger Quadros wrote:
>>> Till the OMAP clocks are correctly defined in device tree, use
>>> this temporary hack to provide clock alias to the USB PHY clocks.
>>>
>>> Without this, USB Host & Ethernet will not be functional with
>>> device tree boots on Panda and uEVM.
>>
>> Looks like this one got missed out.
>>
>> USB host no longer works on Panda with DT boot.
>> Could you please queue this for next 3.11-rc? Thanks.
> 
> OK thanks for checking, applying into omap-for-v3.11/fixes.

Thanks.

> 
> Looks like I also have some pending the .dts changes in
> omap-for-v3.11/dt branch:
> 
> 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB 
> host supprot for Rev. Ax/Bx
> 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB 
> Host support
> fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB 
> host pin naming consistent

Please disregard those. They are old versions.

Benoit had agreed to take the newer version of those for 3.12.

Please pick this one to get usb host working on 3.11 with DT.

http://www.spinics.net/lists/arm-kernel/msg253612.html

> 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB Host 
> support

This one is already in through Benoit.

cheers,
-roger
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock

[Tony Lindgren]

* Roger Quadros  [130716 06:45]:
> On 07/16/2013 03:32 PM, Tony Lindgren wrote:
> > * Roger Quadros  [130715 07:11]:
> >> Hi Tony,
> >>
> >> On 06/18/2013 07:04 PM, Roger Quadros wrote:
> >>> Till the OMAP clocks are correctly defined in device tree, use
> >>> this temporary hack to provide clock alias to the USB PHY clocks.
> >>>
> >>> Without this, USB Host & Ethernet will not be functional with
> >>> device tree boots on Panda and uEVM.
> >>
> >> Looks like this one got missed out.
> >>
> >> USB host no longer works on Panda with DT boot.
> >> Could you please queue this for next 3.11-rc? Thanks.
> > 
> > OK thanks for checking, applying into omap-for-v3.11/fixes.
> 
> Thanks.
> 
> > 
> > Looks like I also have some pending the .dts changes in
> > omap-for-v3.11/dt branch:
> > 
> > 4cf2198b1e3cee47a1cccbb500b67782c36615d5 ARM: dts: omap3-beagle-xm: Add USB 
> > host supprot for Rev. Ax/Bx
> > 9bc44515819a00c0ffaf751ad497ddf275089ede ARM: dts: omap3-beagle-xm: Add USB 
> > Host support
> > fd65d7df4598c1d2ad27d664c719611a1a070edc ARM: dts: omap3-beagle: Make USB 
> > host pin naming consistent
> 
> Please disregard those. They are old versions.

OK, poof that branch is now gone.
 
> Benoit had agreed to take the newer version of those for 3.12.
> 
> Please pick this one to get usb host working on 3.11 with DT.
> 
> http://www.spinics.net/lists/arm-kernel/msg253612.html
> 
> > 39ea891d9da6ae1824bc9f689db3f306f5ce0724 ARM: dts: omap4-panda: Add USB 
> > Host support
> 
> This one is already in through Benoit.

It's best that Benoit queue all those to avoid more confusion :)

Regards,

Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Jason Cooper]

On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote:
> On the other side, I'm much interested in knowing if you are OK with
> breaking the watchdog DT compatibility. If you NACK this, then I'll
> start preparing a different watchdog driver for 370/XP, since I don't
> want to extend a driver that is a bit dirty.

Apparently there is some agreement that the bindings are still in flux
and that they need to be for a bit longer in order to hammer out
problems such as this.

Arnd and Olof both mentioned that something (a doc, and email?) is
forthcoming about marking some bindings as stable.  Whatever form that
takes, this one wouldn't get the stable marking yet. ;-)

Oh, and one more nit.  The work 'fix' triggers a whole bunch of "get on
this right away, does it need to go to stable?  Has anyone confirmed it?
Which commit caused the regression? etc."  Although I hate the word, I
think 'refactoring' is much more appropriate description for this series.

thx,

Jason.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] ASoC: imx-sgtl5000: fix error return code in imx_sgtl5000_probe()

[Mark Brown]

On Tue, Jul 16, 2013 at 08:05:07PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.

Applied, thanks.


signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Ezequiel Garcia]

On Tue, Jul 16, 2013 at 09:44:22AM -0400, Jason Cooper wrote:
> On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote:
> > On the other side, I'm much interested in knowing if you are OK with
> > breaking the watchdog DT compatibility. If you NACK this, then I'll
> > start preparing a different watchdog driver for 370/XP, since I don't
> > want to extend a driver that is a bit dirty.
> 
> Apparently there is some agreement that the bindings are still in flux
> and that they need to be for a bit longer in order to hammer out
> problems such as this.
> 
> Arnd and Olof both mentioned that something (a doc, and email?) is
> forthcoming about marking some bindings as stable.  Whatever form that
> takes, this one wouldn't get the stable marking yet. ;-)
> 

Yup, that's my understanding as well. But on the other side, I don't
want to break possible users out there.

So, just to check, you say it's early enough to safely do such change?

In that case, I'll extend this patchset to include Armada 370/XP support
and post it as soon as Sebastian's clocksource stuff gets in.

> Oh, and one more nit.  The work 'fix' triggers a whole bunch of "get on
> this right away, does it need to go to stable?  Has anyone confirmed it?
> Which commit caused the regression? etc."  Although I hate the word, I
> think 'refactoring' is much more appropriate description for this series.
> 

Oh, good observation. I wrote the cover letter at 8 PM, after ten long
hours (*) of hacking and smashing this into something easy to review,
and that's the best title I could come up with. I'll change it on v2.

Thanks,

(*) yes, I have another pair of eyes, in case these wear out.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT register

[Andrew Lunn]

On Mon, Jul 15, 2013 at 08:32:38PM -0300, Ezequiel Garcia wrote:
> Instead of accessing the RSTOUT register directly, this commit
> adds a platform memory resource to map this register into the driver.

Hi Ezequiel

Have you looked at:

arch/arm/mach-mvebu/system-controller.c

It is also using this register. Are we going to have a similar problem
as the TIMER_CTRL register, which you refactered in an earlier patch?

"marvell,orion-system-controller" is not actually used yet, but once
kirkwood moves into mach-mvebu, it will start using it.

Andrew


> 
> Note that by adding a required 2nd-cell for the reg property,
> this change breaks the device-tree binding compatibility.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  arch/arm/mach-kirkwood/include/mach/bridge-regs.h |  1 +
>  arch/arm/mach-orion5x/include/mach/bridge-regs.h  |  1 +
>  arch/arm/plat-orion/common.c  | 10 ++
>  drivers/watchdog/orion_wdt.c  | 18 ++
>  4 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h 
> b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> index c3f361d..dead75a 100644
> --- a/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> +++ b/arch/arm/mach-kirkwood/include/mach/bridge-regs.h
> @@ -21,6 +21,7 @@
>  #define CPU_RESET0x0002
>  
>  #define RSTOUTn_MASK (BRIDGE_VIRT_BASE + 0x0108)
> +#define RSTOUT_PHYS_BASE (BRIDGE_PHYS_BASE + 0x0108)
>  #define WDT_RESET_OUT_EN 0x0002
>  #define SOFT_RESET_OUT_EN0x0004
>  
> diff --git a/arch/arm/mach-orion5x/include/mach/bridge-regs.h 
> b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
> index aa35de3..ccd91c9 100644
> --- a/arch/arm/mach-orion5x/include/mach/bridge-regs.h
> +++ b/arch/arm/mach-orion5x/include/mach/bridge-regs.h
> @@ -18,6 +18,7 @@
>  #define CPU_CTRL (ORION5X_BRIDGE_VIRT_BASE + 0x104)
>  
>  #define RSTOUTn_MASK (ORION5X_BRIDGE_VIRT_BASE + 0x108)
> +#define RSTOUT_PHYS_BASE (ORION5X_BRIDGE_PHYS_BASE + 0x108)
>  #define WDT_RESET_OUT_EN 0x0002
>  
>  #define CPU_SOFT_RESET   (ORION5X_BRIDGE_VIRT_BASE + 0x10c)
> diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
> index 77fac6c..37924f8 100644
> --- a/arch/arm/plat-orion/common.c
> +++ b/arch/arm/plat-orion/common.c
> @@ -594,14 +594,16 @@ void __init orion_spi_1_init(unsigned long mapbase)
>  
> /*
>   * Watchdog
>   
> /
> -static struct resource orion_wdt_resource =
> - DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04);
> +static struct resource orion_wdt_resource[] = {
> + DEFINE_RES_MEM(WDT_PHYS_BASE, 0x04),
> + DEFINE_RES_MEM(RSTOUT_PHYS_BASE, 0x04)
> +};
>  
>  static struct platform_device orion_wdt_device = {
>   .name   = "orion_wdt",
>   .id = -1,
> - .num_resources  = 1,
> - .resource   = &orion_wdt_resource,
> + .num_resources  = ARRAY_SIZE(orion_wdt_resource),
> + .resource   = orion_wdt_resource,
>  };
>  
>  void __init orion_wdt_init(void)
> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
> index 01bcf53..3c9b3d2 100644
> --- a/drivers/watchdog/orion_wdt.c
> +++ b/drivers/watchdog/orion_wdt.c
> @@ -43,6 +43,7 @@ static unsigned int wdt_max_duration;   /* (seconds) */
>  static struct clk *clk;
>  static unsigned int wdt_tclk;
>  static void __iomem *wdt_reg;
> +static void __iomem *rstout_reg;
>  static DEFINE_SPINLOCK(wdt_lock);
>  
>  static int orion_wdt_ping(struct watchdog_device *wdt_dev)
> @@ -74,9 +75,7 @@ static int orion_wdt_start(struct watchdog_device *wdt_dev)
>   orion_timer_ctrl_clrset(0, WDT_EN);
>  
>   /* Enable reset on watchdog */
> - reg = readl(RSTOUTn_MASK);
> - reg |= WDT_RESET_OUT_EN;
> - writel(reg, RSTOUTn_MASK);
> + writel(readl(rstout_reg) | WDT_RESET_OUT_EN, rstout_reg);
>  
>   spin_unlock(&wdt_lock);
>   return 0;
> @@ -84,14 +83,10 @@ static int orion_wdt_start(struct watchdog_device 
> *wdt_dev)
>  
>  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);
> + writel(readl(rstout_reg) & ~WDT_RESET_OUT_EN, rstout_reg);
>  
>   /* Disable watchdog timer */
>   orion_timer_ctrl_clrset(WDT_EN, 0);
> @@ -158,6 +153,13 @@ static int orion_wdt_probe(struct platform_device *pdev)
>   if (!wdt_reg)
>   return -ENOMEM;
>  
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res)
> + return -ENODEV;
> + rstout_reg = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (!rstout_

Re: [PATCH 05/10] watchdog: orion: Add a memory resource for RSTOUT register

[Ezequiel Garcia]

Andrew,

On Tue, Jul 16, 2013 at 04:04:15PM +0200, Andrew Lunn wrote:
> On Mon, Jul 15, 2013 at 08:32:38PM -0300, Ezequiel Garcia wrote:
> > Instead of accessing the RSTOUT register directly, this commit
> > adds a platform memory resource to map this register into the driver.
> 
> 
> Have you looked at:
> 
> arch/arm/mach-mvebu/system-controller.c
> 

Mmm... I saw the use of the RSTOUT register in kirkwood_restart()
but wasn't sure who should be the real 'owner' of this register.

> It is also using this register. Are we going to have a similar problem
> as the TIMER_CTRL register, which you refactered in an earlier patch?
> 

Probably.

> "marvell,orion-system-controller" is not actually used yet, but once
> kirkwood moves into mach-mvebu, it will start using it.
> 

I guess so. We should take that into account *now*. Let me think about
it and see if I can have something sane for v2.

Thanks!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 0/2] regulator: palmas-pmic: doc: update device tree bindings

[Nishanth Menon]

We seem to have a few missing updates to device tree bindings with the
latest set of changes getting merged in.

Based on v3.11-rc1 tag

Nishanth Menon (2):
  regulator: palmas-pmic: doc: fix typo for sleep-mode
  regulator: palmas-pmic: doc: remove ti,tstep

 .../devicetree/bindings/regulator/palmas-pmic.txt  |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
1.7.9.5

Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 2/2] regulator: palmas-pmic: doc: remove ti,tstep

[Nishanth Menon]

commit 28d1e8cd671a53d6b4f967abbbc2a55f7bd333f6
(regulator: palma: add ramp delay support through regulator constraints)

Removed the regulator's ti,step option from driver without updating the
documentation. remove the support from documentation and example as well.

Signed-off-by: Nishanth Menon 
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt 
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 04d67f0..30b0581 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -33,7 +33,6 @@ Optional nodes:
   ti,roof-floor - control voltage selection by pin(boolean)
   ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
   2 - eco, 3 - forced pwm
-  ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 
2.5mV/us
   ti,smps-range - OTP has the wrong range set for the hardware so 
override
   0 - low range, 1 - high range.
 
@@ -59,7 +58,6 @@ pmic {
ti,warm-reset;
ti,roof-floor;
ti,mode-sleep = <0>;
-   ti,tstep = <0>;
ti,smps-range = <1>;
};
 
-- 
1.7.9.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/2] regulator: palmas-pmic: doc: fix typo for sleep-mode

[Nishanth Menon]

commit 3c870e3f9d9d98f1ab98614b3b1fd5c79287d361
(regulator: palmas: Change the DT node property names to follow the convention)

Missed updating mode-sleep from sleep-mode. Fix the same.
Documentation seems proper for this property.

Signed-off-by: Nishanth Menon 
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt 
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index d5a3086..04d67f0 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -31,7 +31,7 @@ Optional nodes:
   Optional sub-node properties:
   ti,warm-reset - maintain voltage during warm reset(boolean)
   ti,roof-floor - control voltage selection by pin(boolean)
-  ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
+  ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
   2 - eco, 3 - forced pwm
   ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 
2.5mV/us
   ti,smps-range - OTP has the wrong range set for the hardware so 
override
-- 
1.7.9.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree bindings

[Nishanth Menon]

On 09:23-20130716, Nishanth Menon wrote:
> We seem to have a few missing updates to device tree bindings with the
> latest set of changes getting merged in.

Oops.. seems like I have an old mailID for Mark :(

> 
> Based on v3.11-rc1 tag
> 
> Nishanth Menon (2):
>   regulator: palmas-pmic: doc: fix typo for sleep-mode
>   regulator: palmas-pmic: doc: remove ti,tstep
> 
>  .../devicetree/bindings/regulator/palmas-pmic.txt  |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> Regards,
> Nishanth Menon

-- 
Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 00/10] Orion Watchdog fixes

[Jason Cooper]

On Tue, Jul 16, 2013 at 11:04:36AM -0300, Ezequiel Garcia wrote:
> On Tue, Jul 16, 2013 at 09:44:22AM -0400, Jason Cooper wrote:
> > On Tue, Jul 16, 2013 at 09:14:33AM -0300, Ezequiel Garcia wrote:
> > > On the other side, I'm much interested in knowing if you are OK with
> > > breaking the watchdog DT compatibility. If you NACK this, then I'll
> > > start preparing a different watchdog driver for 370/XP, since I don't
> > > want to extend a driver that is a bit dirty.
> > 
> > Apparently there is some agreement that the bindings are still in flux
> > and that they need to be for a bit longer in order to hammer out
> > problems such as this.
> > 
> > Arnd and Olof both mentioned that something (a doc, and email?) is
> > forthcoming about marking some bindings as stable.  Whatever form that
> > takes, this one wouldn't get the stable marking yet. ;-)
> > 
> 
> Yup, that's my understanding as well. But on the other side, I don't
> want to break possible users out there.

I agree, but living with a sub-standard binding is worse imho.

> So, just to check, you say it's early enough to safely do such change?

Well, it's not *safe*.  But most consumers on mainline kernels are
currently developer/hackers/distro maintainers.  eg, folks who can
handle it.  It's better to do it now.

> In that case, I'll extend this patchset to include Armada 370/XP support
> and post it as soon as Sebastian's clocksource stuff gets in.

Cool.

thx,

Jason.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v9] reset: Add driver for gpio-controlled reset pins

[Philipp Zabel]

This driver implements a reset controller device that toggle a gpio
connected to a reset pin of a peripheral IC. The delay between assertion
and de-assertion of the reset signal can be configured via device tree.

Signed-off-by: Philipp Zabel 
Reviewed-by: Stephen Warren 
---
Changes since v8, as suggested by Shawn:
 - added support for I2C gpios via gpio_set_value_cansleep
 - switched from module_init to arch_initcall to avoid unnecessary
   probe deferral of subsys_initcall drivers like gpio-pca953x.
---
 .../devicetree/bindings/reset/gpio-reset.txt   |  35 
 drivers/reset/Kconfig  |  11 ++
 drivers/reset/Makefile |   1 +
 drivers/reset/gpio-reset.c | 188 +
 4 files changed, 235 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/gpio-reset.txt
 create mode 100644 drivers/reset/gpio-reset.c

diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt 
b/Documentation/devicetree/bindings/reset/gpio-reset.txt
new file mode 100644
index 000..bca5348
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
@@ -0,0 +1,35 @@
+GPIO reset controller
+=
+
+A GPIO reset controller controls a single GPIO that is connected to the reset
+pin of a peripheral IC. Please also refer to reset.txt in this directory for
+common reset controller binding usage.
+
+Required properties:
+- compatible: Should be "gpio-reset"
+- reset-gpios: A gpio used as reset line. The gpio specifier for this property
+   depends on the gpio controller that provides the gpio.
+- #reset-cells: 0, see below
+
+Optional properties:
+- reset-delay-us: delay in microseconds. The gpio reset line will be asserted 
for
+  this duration to reset.
+- initially-in-reset: boolean. If not set, the initial state should be a
+  deasserted reset line. If this property exists, the
+  reset line should be kept in reset.
+
+example:
+
+sii902x_reset: gpio-reset {
+   compatible = "gpio-reset";
+   reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+   reset-delay-us = <1>;
+   initially-in-reset;
+   #reset-cells = <0>;
+};
+
+/* Device with nRESET pin connected to GPIO5_0 */
+sii902x@39 {
+   /* ... */
+   resets = <&sii902x_reset>; /* active-low GPIO5_0, 10 ms delay */
+};
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c9d04f7..1a862df 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -11,3 +11,14 @@ menuconfig RESET_CONTROLLER
  via GPIOs or SoC-internal reset controller modules.
 
  If unsure, say no.
+
+if RESET_CONTROLLER
+
+config RESET_GPIO
+   tristate "GPIO reset controller support"
+   depends on GPIOLIB && OF
+   help
+ This driver provides support for reset lines that are controlled
+ directly by GPIOs.
+
+endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1e2d83f..b854f20 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_RESET_CONTROLLER) += core.o
+obj-$(CONFIG_RESET_GPIO) += gpio-reset.o
diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
new file mode 100644
index 000..e9c15c0
--- /dev/null
+++ b/drivers/reset/gpio-reset.c
@@ -0,0 +1,188 @@
+/*
+ * GPIO Reset Controller driver
+ *
+ * Copyright 2013 Philipp Zabel, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct gpio_reset_data {
+   struct reset_controller_dev rcdev;
+   unsigned int gpio;
+   bool active_low;
+   s32 delay_us;
+};
+
+static void gpio_reset_set(struct reset_controller_dev *rcdev, int asserted)
+{
+   struct gpio_reset_data *drvdata = container_of(rcdev,
+   struct gpio_reset_data, rcdev);
+   int value = asserted;
+
+   if (drvdata->active_low)
+   value = !value;
+
+   gpio_set_value(drvdata->gpio, value);
+   if (gpio_cansleep(drvdata->gpio))
+   gpio_set_value_cansleep(drvdata->gpio, value);
+   else
+   gpio_set_value(drvdata->gpio, value);
+}
+
+static int gpio_reset(struct reset_controller_dev *rcdev, unsigned long id)
+{
+   struct gpio_reset_data *drvdata = container_of(rcdev,
+   struct gpio_reset_data, rcdev);
+
+   if (drvdata->delay_us < 0)
+   return -ENOSYS;
+
+   gpio_reset_set(rcdev, 1);
+   udelay(drvdata->delay_us);
+   gpio_reset_set(rcdev, 0);
+
+   return 0;
+}
+
+static int gpio_reset_assert(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   

Re: [PATCH -next] ARM: edma: remove duplicated include from edma.c

[Sekhar Nori]

On 6/26/2013 7:28 AM, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Remove duplicated include.
> 
> Signed-off-by: Wei Yongjun 

Sending this for inclusion in v3.11-rc2. This is technically a clean-up,
but this is still -rc1, so lets see.

Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Stephen Warren]

On 07/15/2013 10:10 PM, Shawn Guo wrote:
> On Mon, Jul 15, 2013 at 09:35:52PM -0600, Stephen Warren wrote:
>>> It's a little bit late to register gpio-reset driver at module_init
>>> time, because gpio-reset provides reset control via gpio for other
>>> devices which are mostly probed at module_init time too.  And it
>>> becomes even worse, when the gpio comes from IO expander on I2C bus,
>>> e.g. pca953x.  In that case, gpio-reset needs to be ready before I2C
>>> bus driver which is generally ready at subsys_initcall time.  Let's
>>> register gpio-reset driver in arch_initcall() to have it ready early
>>> enough.
>>
>> There's no need for the reset driver to be registered before its users;
>> the users of the reset GPIO will simply have their probe deferred until
>> the reset controller is available, and then everything will work out
>> just fine.
>>
>>> The defer probe mechanism is not used here, because a reset controller
>>> driver should be reasonably registered early than other devices.  More
>>> importantly, defer probe doe not help in some nasty cases, e.g. the
>>> gpio-pca953x device itself needs a reset from gpio-reset driver to start
>>> working.
>>
>> That should work fine with deferred probe.
> 
> I should probably rework the commit log.  But I do not see a problem
> to register gpio-reset driver a little bit earlier. 

Registering the driver earlier won't cause any bugs. However, it's not
the correct approach.

Deferred probe /is/ the approach for assuring correct dependencies
between drivers. It works and should be used. There are not enough
initcall levels to play games using initcalls and solve all the issues,
and the ordering requirements vary board-to-board. Deferred probe at
runtime handles this without having to manually place all the drivers
into specific initcall levels, and dynamically adjusts to board
differences, since it all happens automatically at run-time.

Consider a SoC that has:

* An external PMIC, which the CPU has to communicate with to enable
power to all SoC components outside the CPU and a single I2C instance
dedicated to communicating with the PMIC.
* An on-SoC reset controller (for on-SoC) modules that resets other
on-SoC I2C controllers
* An on-SoC I2C controller which communicates with a GPIO expander
* One of the GPIOs on that expander is the reset GPIO for some other
device connected by I2C

What initcall levels are you going to use for all the drivers
(PM-related I2C, PMIC, on-SoC reset controller, secondary I2C
controller, GPIO expander IC, GPIO-reset "device", the final device
affected by the GPIO reset controller).

Now wonder whether that same order is going to be suitable for every
single other board. That's quite unlikely...

 On the other hand,
> if we reply on deferred probe, many drivers probe could be deferred.
> For example, on my system, the gpio-pca953x on I2C bus works as a GPIO
> controller and provides resets to many board level components.
> Deferring probe of gpio-pca953x on I2C bus means every single probe of
> all these components gets deferred.  IMO, this situation should be
> reasonably avoided.

Yes, deferred probe will happen. If we want to solve that, I believe we
need a more generic solution specifically targeted at that, rather that
playing games with initcalls.

(It'd be nice if each DT node declared all its resources in a way the DT
core could parse them and determine the dependency graph itself, without
having to write code in all drivers to extract that information from DT.
This would need a standardized resource representation in DT, and as
such would mean throwing out all the bindings and starting again...
Perhaps some parallel set of properties could be invented to hint at the
order, but still fall back to deferred probe where that information was
missing or inaccurate.)
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Stephen Warren]

On 07/16/2013 12:51 AM, Shawn Guo wrote:
> On Tue, Jul 16, 2013 at 09:50:42AM +0800, Shawn Guo wrote:
>> Hi Philipp,
>>
>> On Thu, May 30, 2013 at 11:09:00AM +0200, Philipp Zabel wrote:
>>> This driver implements a reset controller device that toggle a gpio
>>> connected to a reset pin of a peripheral IC. The delay between assertion
>>> and de-assertion of the reset signal can be configured via device tree.
>>>
>>> Signed-off-by: Philipp Zabel 
>>> Reviewed-by: Stephen Warren 
>>
>> I see this patch is very useful, as GPIOs are widely used to reset
>> components/devices on board.  But I do not find the patch in v3.11-rc1.
>> What's your plan about it?
>>
>> Also, I'm wondering if we should register the driver a little bit
>> early.  Please see the following patch.  If it makes sense to you,
>> I can send the patch to you, or you can just quash it into yours.
> 
> And here is another change request.

> diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c

> - gpio_set_value(drvdata->gpio, value);
> + if (gpio_cansleep(drvdata->gpio))
> + gpio_set_value_cansleep(drvdata->gpio, value);
> + else
> + gpio_set_value(drvdata->gpio, value);

That's not right. Calling gpio_set_value() v.s.
gpio_set_value_cansleep() should be based on the properties of the
calling context, not the GPIO being controlled. In other words, if it's
permissible to call gpio_set_value_cansleep() at this point in the code,
simply always call that, and remove the conditional logic.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Stephen Warren]

On 07/16/2013 03:59 AM, Philipp Zabel wrote:
...
> Deferred probing is fine, but it'd be nice to keep the probe deferral
> loops to a minimum where possible and/or reasonable.

I agree, but manually selecting initcalls for drivers is not the
solution. See my other email.

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v9] reset: Add driver for gpio-controlled reset pins

[Stephen Warren]

On 07/16/2013 08:33 AM, Philipp Zabel wrote:
> This driver implements a reset controller device that toggle a gpio
> connected to a reset pin of a peripheral IC. The delay between assertion
> and de-assertion of the reset signal can be configured via device tree.
> 
> Signed-off-by: Philipp Zabel 
> Reviewed-by: Stephen Warren 
> ---
> Changes since v8, as suggested by Shawn:
>  - added support for I2C gpios via gpio_set_value_cansleep
>  - switched from module_init to arch_initcall to avoid unnecessary
>probe deferral of subsys_initcall drivers like gpio-pca953x.

For the record, I'm not convinced that either of those changes is correct.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support

[Lorenzo Pieralisi]

Hello,

version v5 of VExpress SPC driver, please read on the changelog for major
changes and explanations.

The probing scheme is unchanged, since after trying the early platform
devices approach it appeared that the end result was no better than the
current one. The only clean solution relies either on changing how
secondaries are brought up in the kernel (later than now) or enable
early platform device registration through DT. Please check this
thread for the related discussion:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html

The interface was adapted to regmap and again reverted to old driver for
the following reasons:

- Power down registers locking is hairy and requires arch spinlocks in
  the MCPM back end to work properly, normal spinlocks cannot be used
- Regmap adds unnecessary code to manage SPC since it is just a bunch of
  registers used to control power management flags, the overhead is just
  not worth it (talking about power down registers, not the vexpress config
  interface)
- The locking scheme behind regmap requires all registers in the map
  to be protected with the same lock, which is not exactly what we want
  here
- Given the reasons above, adding a regmap interface buys us nothing from
  a driver readability and maintainability perspective (again just talking
  about the power interface, a few registers) because for the SPC it would
  simply not be used

/drivers/mfd is probably not the right place for this code as it stands (but
probably will be when the entire driver, with DVFS and config interface, is
complete).

Thank you for the review in advance,
Lorenzo

This patch is v5 of a previous posting:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/177150.html

v5 changes:

- Completely removed vexpress-config interface waiting for refactoring
  based on regmap
- Removed frequency scaling interface and operating points programming
  retrieval
- Trimmed the driver code and DT bindings

v4 changes:
- Applied review comments (trimmed function names, added comments, refactored
  some APIs)
- Added comments throughout the set
- Fixed irq handler bug in checking the transaction status
- Improved commit log to explain early init synchro scheme
- Created a single static structure for variables dynamically allocated to
  remove usage of static
- Improved Kconfig entry

v3 changes:

- added __refdata to spc_check_loaded pointer
- removed some exported symbols
- added node pointer check in vexpress_spc_init()

v2 changes:

- Dropped timeout interface patch
- Converted interfaces to non-timeout ones, integrated and retested
- Removed mutex used at init
- Refactored code to work around init sections warning
- Fixed two minor bugs

Lorenzo Pieralisi (1):
  drivers: mfd: vexpress: add Serial Power Controller (SPC) support

 Documentation/devicetree/bindings/mfd/vexpress-spc.txt |  36 ++
 drivers/mfd/Kconfig|  10 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/vexpress-spc.c | 253 ++
 include/linux/vexpress.h   |  17 +
 5 files changed, 317 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/vexpress-spc.txt
 create mode 100644 drivers/mfd/vexpress-spc.c

-- 
1.8.2.2


___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

[Lorenzo Pieralisi]

The TC2 versatile express core tile integrates a logic block that provides the
interface between the dual cluster test-chip and the M3 microcontroller that
carries out power management. The logic block, called Serial Power Controller
(SPC), contains several memory mapped registers to control among other things
low-power states, wake-up irqs and per-CPU jump addresses registers.

This patch provides a driver that enables run-time control of features
implemented by the SPC power management control logic.

The SPC control logic is required to be programmed very early in the boot
process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
wake-up IRQs for power management. Hence, waiting for core changes to be
made in the device core code to enable early registration of platform
devices, the driver puts in place an early init scheme that allows kernel
drivers to initialize the SPC driver directly from the components requiring
it, if their initialization routine is called before the driver init
function by the boot process.

Device tree bindings documentation for the SPC component is provided with
the patchset.

Cc: Samuel Ortiz 
Cc: Olof Johansson 
Cc: Pawel Moll 
Cc: Amit Kucheria 
Cc: Jon Medhurst 
Signed-off-by: Achin Gupta 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Sudeep KarkadaNagesha 
---
 Documentation/devicetree/bindings/mfd/vexpress-spc.txt |  36 ++
 drivers/mfd/Kconfig|  10 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/vexpress-spc.c | 253 ++
 include/linux/vexpress.h   |  17 +
 5 files changed, 317 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt 
b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
new file mode 100644
index 000..1614725
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
@@ -0,0 +1,36 @@
+* ARM Versatile Express Serial Power Controller device tree bindings
+
+Latest ARM development boards implement a power management interface (serial
+power controller - SPC) that is capable of managing power states transitions,
+wake-up IRQs and resume addresses for ARM multiprocessor testchips.
+The serial controller can be programmed through a memory mapped interface
+that enables communication between firmware running on the microcontroller
+managing power states and the application processors.
+
+The SPC DT bindings are defined as follows:
+
+- spc node
+
+   - compatible:
+   Usage: required
+   Value type: 
+   Definition: must be
+   "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"
+   - reg:
+   Usage: required
+   Value type: 
+   Definition: A standard property that specifies the base address
+   and the size of the SPC address space
+   - interrupts:
+   Usage: required
+   Value type: 
+   Definition:  SPC interrupt configuration. A standard property
+that follows ePAPR interrupts specifications
+
+Example:
+
+spc: spc@7fff {
+   compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc";
+   reg = <0x7fff 0x1000>;
+   interrupts = <0 95 4>;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6959b8d..ebd23f4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1149,3 +1149,13 @@ config VEXPRESS_CONFIG
help
  Platform configuration infrastructure for the ARM Ltd.
  Versatile Express.
+
+config VEXPRESS_SPC
+   bool "Versatile Express SPC driver support"
+   depends on ARM
+   help
+ The Serial Power Controller (SPC) for ARM Ltd. test chips, is
+ an IP that provides a memory mapped interface to power controller
+ HW. The driver provides an API abstraction allowing to program
+ registers controlling low-level power management features like power
+ down flags, global and per-cpu wake-up IRQs.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..3a01203 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)  += sec-core.o sec-irq.o
 obj-$(CONFIG_MFD_SYSCON)   += syscon.o
 obj-$(CONFIG_MFD_LM3533)   += lm3533-core.o lm3533-ctrlbank.o
 obj-$(CONFIG_VEXPRESS_CONFIG)  += vexpress-config.o vexpress-sysreg.o
+obj-$(CONFIG_VEXPRESS_SPC) += vexpress-spc.o
 obj-$(CONFIG_MFD_RETU) += retu-mfd.o
 obj-$(CONFIG_MFD_AS3711)   += as3711.o
diff --git a/drivers/mfd/vexpress-spc.c b/drivers/mfd/vexpress-spc.c
new file mode 100644
index 000..aa8c2a4
--- /dev/null
+++ b/drivers/mfd/vexpress-spc.c
@@ -0,0 +1,253 @@
+/*
+ * Versatile Express Serial Power Controller (SPC) support
+ *
+ * Copyright (C) 2013 ARM Ltd.
+ *
+ * Authors: Sudeep KarkadaNagesha 
+ *  Achin Gup

Re: [PATCH 2/4] pinmux: Add TB10x pinmux driver

[Stephen Warren]

On 07/16/2013 02:47 AM, Christian Ruppert wrote:
> On Wed, Jul 10, 2013 at 01:27:52PM -0600, Stephen Warren wrote:
>> On 07/08/2013 07:02 AM, Christian Ruppert wrote:
>> ...
>>> OK, a small drawing of our hardware should make this clear, let's take
>>> an imaginary example of one port with 10 pins, one i2c interface, one
>>> spi interface and one GPIO bank:
>>>
>>>   | mux N-1|
>>>   ++
>>>   ||  2
>>>   |+--/-- i2c
>>>   ||
>>>10 ||  4
>>>Pins  --/--+ mux N  +--/-- spi
>>>   ||
>>>   ||  10
>>>   |+--/-- GPIO
>>>   ||
>>>   ++
>>>   | mux N+1|
>>>
>>> This example shows the mux N inside the pin controller. It controls
>>> all pins associated to port N through a single register value M. Let's
>>> assume the pins are configured as follows in function of the register
>>> value:
>>>
>>>  pin  M=0   M=1 M=2  M=3
>>>   0  GPIO0   SPI_MISO  GPIO0   SPI_MISO
>>>   1  GPIO1   SPI_MOSI  GPIO1   SPI_MOSI
>>>   2  GPIO2SPI_CK   GPIO2SPI_CK
>>>   3  GPIO3SPI_CS   GPIO3SPI_CS
>>>   4  GPIO4GPIO4GPIO4GPIO4
>>>   5  GPIO5GPIO5GPIO5GPIO5
>>>   6  GPIO6GPIO6GPIO6GPIO6
>>>   7  GPIO7GPIO7GPIO7GPIO7
>>>   8  GPIO8GPIO8   I2C_SDA  I2C_SDA
>>>   9  GPIO9GPIO9   I2C_SCL  I2C_SCL
>>
>>
>> In that scenario, in the language of Linux's pinctrl subsystem, what you
>> have is:
>>
>> 10 pins, named 0..9
>> 1 pin group, named perhaps "mux N".
>> 4 different functions; values M==0, 1, 2, 3.
>>
>>> We now have three pin groups defined, corresponding to the chip-side
>>> ports of the pin controller:
>>> GPIO = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
>>> SPI  = {0, 1, 2, 3}
>>> I2C  = {8, 9}
>>
>> You would usually only define pin groups for the pin/ball/package side
>> of the pinmux HW. IIRC, you're also wanting to define pin groups for the
>> intra-chip side of the pinmux HW. However, you're not muxing functions
>> onto those pingroups; they're just there to help with naming the
>> GPIO<->pinmux mapping. You only mux functions onto the pin/ball/package
>> side pins/pingroups.
> 
> Well, the GPIO<->pinmux mapping is not the only reason for defining
> these groups wrt. the chip-side of the pin controller. The other reasons
> are:
>   - Make different interfaces on the same MUX orthogonal wrt. each
> other, i.e. make it possible to request one independently of the
> other. In the example above, SPI and I2C can be requested completely
> independently and the pin controller driver decides which mode to
> use.

But the pinctrl subsystem and bindings don't have any concept of that;
what gets requested is the pins on the chip, or the "outer" side of the
pin controller. There's no concept of resource management for the
"inside" of the pin controller.

>   - Make pin allocation more fine-grained (in the example above, only
> pins 0-4 are "allocated" in case SPI is requested). This makes
> GPIO<->interface pin conflict management more natural.

I think you'd want to either:

a) Just deal with this in the driver; it knows the HW, and it knows
which mux function is selected for each mux, and hence knows exactly
which pins can be requested as GPIOs for each combination, and can
therefore allow/disallow any GPIO request or mux function change.

b) Extend the pinctrl core to know about this explicitly, and pass
information to the pinctrl core. Presumably, for each combination of
(pingroup, mux function), you'd need a list or bitmask indicating which
pins within the pingroup are actually used. Then, the pinctrl core can
perform all the validation. If you do this, you don't need to invent new
pinctrl groups in order to try and shoe-horn this into pinctrl.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 0/2] regulator: palmas-pmic: doc: update device tree bindings

[Mark Brown]

On Tue, Jul 16, 2013 at 09:27:10AM -0500, Nishanth Menon wrote:
> On 09:23-20130716, Nishanth Menon wrote:

> > We seem to have a few missing updates to device tree bindings with the
> > latest set of changes getting merged in.

> Oops.. seems like I have an old mailID for Mark :(

I'll need the actual patches as well...


signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH V2 1/2] regulator: palmas-pmic: doc: fix typo for sleep-mode

[Nishanth Menon]

commit 3c870e3f9d9d98f1ab98614b3b1fd5c79287d361
(regulator: palmas: Change the DT node property names to follow the convention)

Missed updating mode-sleep from sleep-mode. Fix the same.

Documentation example seems proper for this property.

Signed-off-by: Nishanth Menon 
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt 
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index d5a3086..04d67f0 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -31,7 +31,7 @@ Optional nodes:
   Optional sub-node properties:
   ti,warm-reset - maintain voltage during warm reset(boolean)
   ti,roof-floor - control voltage selection by pin(boolean)
-  ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
+  ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
   2 - eco, 3 - forced pwm
   ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 
2.5mV/us
   ti,smps-range - OTP has the wrong range set for the hardware so 
override
-- 
1.7.9.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH V2 0/2] regulator: palmas-pmic: doc: update device tree bindings

[Nishanth Menon]

We seem to have a few missing updates to device tree bindings with the
latest set of changes getting merged in.

Changes since V1:
Apologies on the spam, looks like I got the wrong mail ID first time 
around :(
minor commit message cleanups

V1: http://marc.info/?l=linux-doc&m=137398467901450&w=2

Based on v3.11-rc1 tag

Nishanth Menon (2):
  regulator: palmas-pmic: doc: fix typo for sleep-mode
  regulator: palmas-pmic: doc: remove ti,tstep

 .../devicetree/bindings/regulator/palmas-pmic.txt  |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
1.7.9.5

Regards,
Nishanth Menon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH V2 2/2] regulator: palmas-pmic: doc: remove ti,tstep

[Nishanth Menon]

commit 28d1e8cd671a53d6b4f967abbbc2a55f7bd333f6
(regulator: palma: add ramp delay support through regulator constraints)

Removed the regulator's ti,step option from driver without updating the
documentation.

So, remove from documentation and example as well.

Signed-off-by: Nishanth Menon 
---
 .../devicetree/bindings/regulator/palmas-pmic.txt  |2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt 
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 04d67f0..30b0581 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -33,7 +33,6 @@ Optional nodes:
   ti,roof-floor - control voltage selection by pin(boolean)
   ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
   2 - eco, 3 - forced pwm
-  ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 
2.5mV/us
   ti,smps-range - OTP has the wrong range set for the hardware so 
override
   0 - low range, 1 - high range.
 
@@ -59,7 +58,6 @@ pmic {
ti,warm-reset;
ti,roof-floor;
ti,mode-sleep = <0>;
-   ti,tstep = <0>;
ti,smps-range = <1>;
};
 
-- 
1.7.9.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH RFC v4] media: OF: add "sync-on-green-active" property

[Prabhakar Lad]

From: "Lad, Prabhakar" 

This patch adds 'sync-on-green-active' property as part
of endpoint property.

Signed-off-by: Lad, Prabhakar 
---
  Changes for v4:
  1: Fixed review comments pointed by Sylwester.
  
  Changes for v3:
  1: Fixed review comments pointed by Laurent and Sylwester.

  RFC v2 https://patchwork.kernel.org/patch/2578091/
  
  RFC V1 https://patchwork.kernel.org/patch/2572341/
  
 .../devicetree/bindings/media/video-interfaces.txt |3 +++
 drivers/media/v4l2-core/v4l2-of.c  |4 
 include/media/v4l2-mediabus.h  |2 ++
 3 files changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index e022d2d..5186c7e 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -101,6 +101,9 @@ Optional endpoint properties
   array contains only one entry.
 - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
   clock mode.
+- sync-on-green-active: polarity field when video synchronization is
+  Sync-On-Green. When set the driver determines whether it's a normal operation
+  or inverted operation.
 
 
 Example
diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..5c4c9f0 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -100,6 +100,10 @@ static void v4l2_of_parse_parallel_bus(const struct 
device_node *node,
if (!of_property_read_u32(node, "data-shift", &v))
bus->data_shift = v;
 
+   if (!of_property_read_u32(node, "sync-on-green-active", &v))
+   flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH :
+   V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW;
+
bus->flags = flags;
 
 }
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 83ae07e..d47eb81 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -40,6 +40,8 @@
 #define V4L2_MBUS_FIELD_EVEN_HIGH  (1 << 10)
 /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */
 #define V4L2_MBUS_FIELD_EVEN_LOW   (1 << 11)
+#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1 << 12)
+#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 << 13)
 
 /* Serial flags */
 /* How many lanes the client can use */
-- 
1.7.9.5

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH RESEND 1/2] ARM: mmp: Add compatible entries for OLPC XO laptops

[Daniel Drake]

Add compatible entries to enable booting of OLPC XO-1.75 (MMP2) and
OLPC XO-4 (MMP3).

Signed-off-by: Chris Ball 
Signed-off-by: Daniel Drake 
---
 Documentation/devicetree/bindings/arm/mrvl/intc.txt | 4 ++--
 Documentation/devicetree/bindings/arm/mrvl/mrvl.txt | 8 
 arch/arm/mach-mmp/irq.c | 1 +
 arch/arm/mach-mmp/mmp2-dt.c | 2 ++
 4 files changed, 13 insertions(+), 2 deletions(-)

Resending after 1 month with no response.

diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt 
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 8b53273..3554fb9 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -1,8 +1,8 @@
 * Marvell MMP Interrupt controller
 
 Required properties:
-- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or
-  "mrvl,mmp2-mux-intc"
+- compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
+  mrvl,mmp2-mux-intc
 - reg : Address and length of the register set of the interrupt controller.
   If the interrupt controller is intc, address and length means the range
   of the whold interrupt controller. If the interrupt controller is mux-intc,
diff --git a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt 
b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
index 117d741..236e884 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt
@@ -12,3 +12,11 @@ Required root node properties:
 MMP2 Brownstone Board
 Required root node properties:
- compatible = "mrvl,mmp2-brownstone";
+
+OLPC XO-1.75 (CL2) based on MMP2
+Required root node properties:
+   - compatible = "olpc,xo-1.75";
+
+OLPC XO-4 (CL4) based on MMP3
+Required root node properties:
+   - compatible = "olpc,xo-cl4";
diff --git a/arch/arm/mach-mmp/irq.c b/arch/arm/mach-mmp/irq.c
index 3c71246..d60b85a 100644
--- a/arch/arm/mach-mmp/irq.c
+++ b/arch/arm/mach-mmp/irq.c
@@ -329,6 +329,7 @@ void __init mmp2_init_icu(void)
 static const struct of_device_id intc_ids[] __initconst = {
{ .compatible = "mrvl,mmp-intc", .data = &mmp_conf },
{ .compatible = "mrvl,mmp2-intc", .data = &mmp2_conf },
+   { .compatible = "mrvl,mmp3-intc", .data = &mmp2_conf },
{}
 };
 
diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
index 4ac2567..e67bd9f 100644
--- a/arch/arm/mach-mmp/mmp2-dt.c
+++ b/arch/arm/mach-mmp/mmp2-dt.c
@@ -44,6 +44,8 @@ static void __init mmp2_dt_init(void)
 
 static const char *mmp2_dt_board_compat[] __initdata = {
"mrvl,mmp2-brownstone",
+   "olpc,xo-1.75",
+   "olpc,xo-cl4",
NULL,
 };
 
-- 
1.8.1.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH RESEND 2/2] ARM: mmp: irq: Improve DT layout

[Daniel Drake]

In the mmp2 device tree, the interrupt mux nodes were peers of the
interrupt controller, yet they mapped registers in conflict with the
interrupt controller's register block. Furthermore, the reg properties of
the muxes disagreed with the unit address specified after the node's @-sign.

Move the interrupt mux nodes underneath the interrupt controller node,
because the registers are subordinate to the interrupt controller device,
and update the documentation accordingly.

In the platform code, avoid using of_address_to_resource(). Treating a
reg value of 0x150 as a resource effectively is mapping to memory
location 0x150, which is not what's happening here. Use of_get_address()
instead, to better reflect that we're dealing with an address offset
being read from the device tree.

This adds support for the device tree shipped in the OLPC XO-4 and
additionally these code changes do not break compatibility with the
old DT layout.

Based on work by Mitch Bradley.

Signed-off-by: Daniel Drake 
---
 .../devicetree/bindings/arm/mrvl/intc.txt  |  41 ---
 arch/arm/boot/dts/mmp2.dtsi| 128 ++---
 arch/arm/mach-mmp/irq.c|  16 +--
 3 files changed, 95 insertions(+), 90 deletions(-)

Resending after 1 month with no response.

diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt 
b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
index 3554fb9..0c020ff 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
@@ -2,21 +2,24 @@
 
 Required properties:
 - compatible : One of: mrvl,mmp-intc mrvl,mmp2-intc mrvl,mmp3-intc
-  mrvl,mmp2-mux-intc
-- reg : Address and length of the register set of the interrupt controller.
-  If the interrupt controller is intc, address and length means the range
-  of the whold interrupt controller. If the interrupt controller is mux-intc,
-  address and length means one register. Since address of mux-intc is in the
-  range of intc. mux-intc is secondary interrupt controller.
-- reg-names : Name of the register set of the interrupt controller. It's
-  only required in mux-intc interrupt controller.
-- interrupts : Should be the port interrupt shared by mux interrupts. It's
-  only required in mux-intc interrupt controller.
+- reg : Address and length of the register set of the whole interrupt
+  controller.
 - interrupt-controller : Identifies the node as an interrupt controller.
 - #interrupt-cells : Specifies the number of cells needed to encode an
   interrupt source.
 - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
   controller.
+
+* Marvell MMP Secondary Interrupt controller (mux)
+
+Required properties:
+ - compatible : Shall be mrvl,mmp2-mux-intc
+  Address and length of one register offset into the register address space of
+  the parent interrupt controller node.
+- reg-names : Name of the register set of the interrupt controller.
+- interrupts : Should be the port interrupt shared by mux interrupts.
+- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
+  controller.
 - mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge
   detection first.
 
@@ -27,16 +30,16 @@ Example:
#interrupt-cells = <1>;
reg = <0xd4282000 0x1000>;
mrvl,intc-nr-irqs = <64>;
-   };
 
-   intcmux4@d4282150 {
-   compatible = "mrvl,mmp2-mux-intc";
-   interrupts = <4>;
-   interrupt-controller;
-   #interrupt-cells = <1>;
-   reg = <0x150 0x4>, <0x168 0x4>;
-   reg-names = "mux status", "mux mask";
-   mrvl,intc-nr-irqs = <2>;
+   intcmux4@150 {
+   compatible = "mrvl,mmp2-mux-intc";
+   interrupts = <4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x150 0x4>, <0x168 0x4>;
+   reg-names = "mux status", "mux mask";
+   mrvl,intc-nr-irqs = <2>;
+   };
};
 
 * Marvell Orion Interrupt controller
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 4e8b08c..1f63c8f 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -44,77 +44,77 @@
#interrupt-cells = <1>;
reg = <0xd4282000 0x1000>;
mrvl,intc-nr-irqs = <64>;
-   };
 
-   intcmux4: interrupt-controller@d4282150 {
-   compatible = "mrvl,mmp2-mux-intc";
-   interrupts = <4>;
-   interrupt-controller;
-   #interrupt-cells = <1>;
-   reg = <0x150 0x4>, <0x168 0x4>;
-   reg-names 

[PATCH RESEND 2/2] clk: mmp: add support for DT-defined clocks

[Daniel Drake]

Add support to the existing mmp clock drivers for clocks to be defined
in the device tree. This will be used on OLPC MMP2/MMP3-based laptops.

If clock info cannot be found in the device tree, we fall back to the
static clock initialization already present.

Signed-off-by: Daniel Drake 
---
 .../devicetree/bindings/clock/mmp-apbc.txt | 30 ++
 .../devicetree/bindings/clock/mmp-apmu.txt | 30 ++
 drivers/clk/mmp/clk-apbc.c | 66 +-
 drivers/clk/mmp/clk-apmu.c | 37 +++-
 drivers/clk/mmp/clk-mmp2.c | 19 ++-
 5 files changed, 179 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mmp-apbc.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mmp-apmu.txt

Resending after a month without review.

diff --git a/Documentation/devicetree/bindings/clock/mmp-apbc.txt 
b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
new file mode 100644
index 000..88e1253
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apbc.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Advanced Peripheral Bus clock
+
+Parent apb-clock node
+=
+Required properties:
+- reg: Address and length of the APB clock unit registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be "marvell,mmp-apb-clock"
+- #clock-cells : from common clock binding; shall be set to 1
+- clocks : parent clock, from common clock binding
+- clock-output-names : Array of clock names, from common clock binding
+- reg : Array of control register offsets into APB clock unit register space
+
+
+Example:
+apbc: apb-clock {
+   reg = <0xd4015000 0x1000>;
+
+   twsi-clocks {
+   compatible = "marvell,mmp-apb-clock";
+   #clock-cells = <1>;
+   clocks = <&vctvxo-clock>;
+   clock-output-names = "TWSI0", "TWSI1";
+   reg = <0x04 0x08>;
+   };
+};
diff --git a/Documentation/devicetree/bindings/clock/mmp-apmu.txt 
b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
new file mode 100644
index 000..18bb0f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp-apmu.txt
@@ -0,0 +1,30 @@
+* Clock bindings for Marvell MMP Application Subsystem Power Management Unit
+
+Parent apmu-clock node
+=
+Required properties:
+- reg: Address and length of the CPU Subsystem PMU registers
+
+
+Child peripheral clock nodes
+
+Required properties:
+- compatible : shall be "marvell,mmp-apmu-clock"
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : parent clock, from common clock binding
+- reg : Control register offsets into parent register space
+- enable-mask : The bits to be set in the register to enable the clock, or
+cleared to disable.
+
+Example:
+apmu-clock {
+   reg = <0xd4282800 0x1000>;
+
+   usb-clock {
+   compatible = "marvell,mmp-apmu-clock";
+   #clock-cells = <0>;
+   clocks = <&usb_pll>;
+   reg = <0x5c>;
+   enable-mask = <0x09>;
+   };
+};
diff --git a/drivers/clk/mmp/clk-apbc.c b/drivers/clk/mmp/clk-apbc.c
index 89a146a..d53bc79 100644
--- a/drivers/clk/mmp/clk-apbc.c
+++ b/drivers/clk/mmp/clk-apbc.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "clk.h"
 
@@ -129,8 +131,70 @@ struct clk *mmp_clk_register_apbc(const char *name, const 
char *parent_name,
apbc->hw.init = &init;
 
clk = clk_register(NULL, &apbc->hw);
-   if (IS_ERR(clk))
+   if (WARN_ON(IS_ERR(clk)))
kfree(apbc);
 
return clk;
 }
+
+static void __init mmp_apbc_dt_init(struct device_node *node)
+{
+   struct device_node *parent = of_get_parent(node);
+   const __be32 *regs;
+   struct clk *clk;
+   int rc;
+   int len;
+   int num_clocks;
+   int clock_num;
+   void __iomem *baseaddr;
+   const char *clock_name;
+   const char *parent_name;
+   struct clk **clks;
+   struct clk_onecell_data *clk_data;
+
+   regs = of_get_property(node, "reg", &len);
+   if (WARN_ON(!regs || (len % sizeof(__be32) != 0)))
+   return;
+   num_clocks = len / sizeof(__be32);
+
+   baseaddr = of_iomap(parent, 0);
+   of_node_put(parent);
+   if (WARN_ON(!baseaddr))
+   return;
+
+   clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
+   if (WARN_ON(!clk_data))
+   goto err_clk_data;
+
+   clks = kzalloc(num_clocks * sizeof(*clks), GFP_KERNEL);
+   if (WARN_ON(!clks))
+   goto err_clks;
+
+   clock_name = of_get_property(node, "clock-output-names", NULL);
+   parent_name = of_clk_get_parent_name(node, 0);
+
+   for (clock_num = 0; clock_num < num_clocks; clock_num++) {
+   voi

[PATCH RESEND 1/2] clk: mmp: use global clock lock

[Daniel Drake]

The mmp platform shares a lock between different clock types, and all
clocks are currently initialized by static bindings.

Move this static/private lock into global context so that it can
easily be shared by clocks that will be defined by the device tree in
followup patches.

Signed-off-by: Daniel Drake 
---
 drivers/clk/mmp/Makefile   |   2 +-
 drivers/clk/mmp/clk-apbc.c |  38 +--
 drivers/clk/mmp/clk-apmu.c |  20 ++--
 drivers/clk/mmp/clk-mmp2.c | 116 ++---
 drivers/clk/mmp/clk.h  |   8 ++--
 drivers/clk/mmp/common.c   |  13 +
 6 files changed, 92 insertions(+), 105 deletions(-)
 create mode 100644 drivers/clk/mmp/common.c

Resending after a month without review.

diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 392d780..31aacb5 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for mmp specific clk
 #
 
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o
+obj-y += common.o clk-apbc.o clk-apmu.o clk-frac.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-apbc.c b/drivers/clk/mmp/clk-apbc.c
index d14120e..89a146a 100644
--- a/drivers/clk/mmp/clk-apbc.c
+++ b/drivers/clk/mmp/clk-apbc.c
@@ -30,7 +30,6 @@ struct clk_apbc {
void __iomem*base;
unsigned intdelay;
unsigned intflags;
-   spinlock_t  *lock;
 };
 
 static int clk_apbc_prepare(struct clk_hw *hw)
@@ -43,8 +42,7 @@ static int clk_apbc_prepare(struct clk_hw *hw)
 * It may share same register as MUX clock,
 * and it will impact FNCLK enable. Spinlock is needed
 */
-   if (apbc->lock)
-   spin_lock_irqsave(apbc->lock, flags);
+   spin_lock_irqsave(&mmp_clk_lock, flags);
 
data = readl_relaxed(apbc->base);
if (apbc->flags & APBC_POWER_CTRL)
@@ -52,33 +50,26 @@ static int clk_apbc_prepare(struct clk_hw *hw)
data |= APBC_FNCLK;
writel_relaxed(data, apbc->base);
 
-   if (apbc->lock)
-   spin_unlock_irqrestore(apbc->lock, flags);
-
+   spin_unlock_irqrestore(&mmp_clk_lock, flags);
udelay(apbc->delay);
-
-   if (apbc->lock)
-   spin_lock_irqsave(apbc->lock, flags);
+   spin_lock_irqsave(&mmp_clk_lock, flags);
 
data = readl_relaxed(apbc->base);
data |= APBC_APBCLK;
writel_relaxed(data, apbc->base);
 
-   if (apbc->lock)
-   spin_unlock_irqrestore(apbc->lock, flags);
+   spin_unlock_irqrestore(&mmp_clk_lock, flags);
 
udelay(apbc->delay);
 
if (!(apbc->flags & APBC_NO_BUS_CTRL)) {
-   if (apbc->lock)
-   spin_lock_irqsave(apbc->lock, flags);
+   spin_lock_irqsave(&mmp_clk_lock, flags);
 
data = readl_relaxed(apbc->base);
data &= ~APBC_RST;
writel_relaxed(data, apbc->base);
 
-   if (apbc->lock)
-   spin_unlock_irqrestore(apbc->lock, flags);
+   spin_unlock_irqrestore(&mmp_clk_lock, flags);
}
 
return 0;
@@ -90,8 +81,7 @@ static void clk_apbc_unprepare(struct clk_hw *hw)
unsigned long data;
unsigned long flags = 0;
 
-   if (apbc->lock)
-   spin_lock_irqsave(apbc->lock, flags);
+   spin_lock_irqsave(&mmp_clk_lock, flags);
 
data = readl_relaxed(apbc->base);
if (apbc->flags & APBC_POWER_CTRL)
@@ -99,20 +89,15 @@ static void clk_apbc_unprepare(struct clk_hw *hw)
data &= ~APBC_FNCLK;
writel_relaxed(data, apbc->base);
 
-   if (apbc->lock)
-   spin_unlock_irqrestore(apbc->lock, flags);
-
+   spin_unlock_irqrestore(&mmp_clk_lock, flags);
udelay(10);
-
-   if (apbc->lock)
-   spin_lock_irqsave(apbc->lock, flags);
+   spin_lock_irqsave(&mmp_clk_lock, flags);
 
data = readl_relaxed(apbc->base);
data &= ~APBC_APBCLK;
writel_relaxed(data, apbc->base);
 
-   if (apbc->lock)
-   spin_unlock_irqrestore(apbc->lock, flags);
+   spin_unlock_irqrestore(&mmp_clk_lock, flags);
 }
 
 struct clk_ops clk_apbc_ops = {
@@ -122,7 +107,7 @@ struct clk_ops clk_apbc_ops = {
 
 struct clk *mmp_clk_register_apbc(const char *name, const char *parent_name,
void __iomem *base, unsigned int delay,
-   unsigned int apbc_flags, spinlock_t *lock)
+   unsigned int apbc_flags)
 {
struct clk_apbc *apbc;
struct clk *clk;
@@ -141,7 +126,6 @@ struct clk *mmp_clk_register_apbc(const char *name, const 
char *parent_name,
apbc->base = base;
apbc->delay = delay;
apbc->flags = apbc_flags;
-   apbc->lock = lock;
apbc->hw.init = &init;
 
clk = clk_register(NULL, &apbc->hw);
diff --git a/drivers/clk/mmp/clk-apmu.c b/drivers/clk/mmp/clk-apmu.c
index abe182b..4f4d

Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP

[Jonathan Cameron]

On 07/16/2013 12:30 PM, Thomas Petazzoni wrote:
> Dear Nicolas Ferre,
> 
> On Tue, 16 Jul 2013 10:46:28 +0200, Nicolas Ferre wrote:
> 
>>> Ok, that make sense. I will use compatible names for the capabilities in
>>> next version. Thanks.
>>
>> Hold on a little bit Josh, I know that Jean-Christophe is not in favor 
>> of the use of multiple compatible strings. So, as the code is already 
>> there, let's wait and see if we find another argument...
> 
> I've asked exactly this question last week at Linaro Connect during the
> ARM SoC consolidation panel/discussion, where Grant Likely, Arnd
> Bergmann, Olof and others were answering Device Tree related questions.
> 
> My question, which precisely had the at91-adc DT binding in mind was
> precisely whether we should use different compatible properties to
> identify different revisions of an IP block and let the driver handle
> those differences, or whether the DT binding should provide sufficient
> properties (register offsets, bit numbers, etc.) to make the driver
> independent of the IP revisions. And clearly, the answer was that
> different compatible properties should be used to identify the
> different versions of the IP block, and the driver should abstract out
> the differences. I.e, was has been done for at91-adc is completely the
> opposite of the best practices for Device Tree on ARM.
> 
> See
> http://www.youtube.com/watch?v=zF_AXLgkFy4&feature=player_detailpage#t=1581s
> where I ask exactly this question, and get answers from Olof Johansson
> and Grant Likely. They clearly say that the solution of having separate
> compatible properties and a driver that handles the differences is the
> way to go. So the way at91-adc (and possibly other at91 drivers) is
> using the Device Tree is wrong, there should have been multiple
> compatible properties. It's a shame because this is something we did say
> when we submitted at91-adc and during the reviews, but the maintainer
> wasn't listening to our comments...
> 

Thanks for getting some clarity on this Thomas.  So I'll ask the somewhat 
obvious
question - how do we unwind from where we are to where we want to be wrt to the
bindings?



___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 2/5] iio: at91: Use different prescal, startup mask in MR for different IP

[Thomas Petazzoni]

Dear Jonathan Cameron,

On Tue, 16 Jul 2013 20:03:38 +0100, Jonathan Cameron wrote:

> On 07/16/2013 12:30 PM, Thomas Petazzoni wrote:
> > I've asked exactly this question last week at Linaro Connect during the
> > ARM SoC consolidation panel/discussion, where Grant Likely, Arnd
> > Bergmann, Olof and others were answering Device Tree related questions.
> > 
> > My question, which precisely had the at91-adc DT binding in mind was
> > precisely whether we should use different compatible properties to
> > identify different revisions of an IP block and let the driver handle
> > those differences, or whether the DT binding should provide sufficient
> > properties (register offsets, bit numbers, etc.) to make the driver
> > independent of the IP revisions. And clearly, the answer was that
> > different compatible properties should be used to identify the
> > different versions of the IP block, and the driver should abstract out
> > the differences. I.e, was has been done for at91-adc is completely the
> > opposite of the best practices for Device Tree on ARM.
> > 
> > See
> > http://www.youtube.com/watch?v=zF_AXLgkFy4&feature=player_detailpage#t=1581s
> > where I ask exactly this question, and get answers from Olof Johansson
> > and Grant Likely. They clearly say that the solution of having separate
> > compatible properties and a driver that handles the differences is the
> > way to go. So the way at91-adc (and possibly other at91 drivers) is
> > using the Device Tree is wrong, there should have been multiple
> > compatible properties. It's a shame because this is something we did say
> > when we submitted at91-adc and during the reviews, but the maintainer
> > wasn't listening to our comments...
> > 
> 
> Thanks for getting some clarity on this Thomas.  So I'll ask the somewhat 
> obvious
> question - how do we unwind from where we are to where we want to be wrt to 
> the
> bindings?

During Linaro Connect last week, there was some discussion about
marking DT bindings as unstable for a little while, once they get
reviewed by a group of DT "experts" that mark them as stable. Until
they are stable, the kernel does not offer any ABI guarantees, and we
are free to change the DT bindings as needed.

Now, since this unstable/stable thing is not in place at the moment,
deciding whether to break or not existing bindings is something to be
decided by the maintainer of this platform, judging what is the best
option depending on whether there are already many users of the DT for
this platform or not, for example.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

[Rob Herring]

On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote:
> The TC2 versatile express core tile integrates a logic block that provides the
> interface between the dual cluster test-chip and the M3 microcontroller that
> carries out power management. The logic block, called Serial Power Controller
> (SPC), contains several memory mapped registers to control among other things
> low-power states, wake-up irqs and per-CPU jump addresses registers.
> 
> This patch provides a driver that enables run-time control of features
> implemented by the SPC power management control logic.
> 
> The SPC control logic is required to be programmed very early in the boot
> process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and
> wake-up IRQs for power management. Hence, waiting for core changes to be
> made in the device core code to enable early registration of platform
> devices, the driver puts in place an early init scheme that allows kernel
> drivers to initialize the SPC driver directly from the components requiring
> it, if their initialization routine is called before the driver init
> function by the boot process.
> 
> Device tree bindings documentation for the SPC component is provided with
> the patchset.

Just curious, wouldn't a TC2 PSCI implementation eliminate the need for
most/all of this code?

Rob

> 
> Cc: Samuel Ortiz 
> Cc: Olof Johansson 
> Cc: Pawel Moll 
> Cc: Amit Kucheria 
> Cc: Jon Medhurst 
> Signed-off-by: Achin Gupta 
> Signed-off-by: Lorenzo Pieralisi 
> Signed-off-by: Sudeep KarkadaNagesha 
> ---
>  Documentation/devicetree/bindings/mfd/vexpress-spc.txt |  36 ++
>  drivers/mfd/Kconfig|  10 +
>  drivers/mfd/Makefile   |   1 +
>  drivers/mfd/vexpress-spc.c | 253 ++
>  include/linux/vexpress.h   |  17 +
>  5 files changed, 317 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/vexpress-spc.txt 
> b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
> new file mode 100644
> index 000..1614725
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/vexpress-spc.txt
> @@ -0,0 +1,36 @@
> +* ARM Versatile Express Serial Power Controller device tree bindings
> +
> +Latest ARM development boards implement a power management interface (serial
> +power controller - SPC) that is capable of managing power states transitions,
> +wake-up IRQs and resume addresses for ARM multiprocessor testchips.
> +The serial controller can be programmed through a memory mapped interface
> +that enables communication between firmware running on the microcontroller
> +managing power states and the application processors.
> +
> +The SPC DT bindings are defined as follows:
> +
> +- spc node
> +
> + - compatible:
> + Usage: required
> + Value type: 
> + Definition: must be
> + "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"
> + - reg:
> + Usage: required
> + Value type: 
> + Definition: A standard property that specifies the base address
> + and the size of the SPC address space
> + - interrupts:
> + Usage: required
> + Value type: 
> + Definition:  SPC interrupt configuration. A standard property
> +  that follows ePAPR interrupts specifications
> +
> +Example:
> +
> +spc: spc@7fff {
> + compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc";
> + reg = <0x7fff 0x1000>;
> + interrupts = <0 95 4>;
> +};
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6959b8d..ebd23f4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1149,3 +1149,13 @@ config VEXPRESS_CONFIG
>   help
> Platform configuration infrastructure for the ARM Ltd.
> Versatile Express.
> +
> +config VEXPRESS_SPC
> + bool "Versatile Express SPC driver support"
> + depends on ARM
> + help
> +   The Serial Power Controller (SPC) for ARM Ltd. test chips, is
> +   an IP that provides a memory mapped interface to power controller
> +   HW. The driver provides an API abstraction allowing to program
> +   registers controlling low-level power management features like power
> +   down flags, global and per-cpu wake-up IRQs.
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 718e94a..3a01203 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -153,5 +153,6 @@ obj-$(CONFIG_MFD_SEC_CORE)+= sec-core.o sec-irq.o
>  obj-$(CONFIG_MFD_SYSCON) += syscon.o
>  obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
>  obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-config.o vexpress-sysreg.o
> +obj-$(CONFIG_VEXPRESS_SPC)   += vexpress-spc.o
>  obj-$(CONFIG_MFD_RETU)   += retu-mfd.o
>  obj-$(CONFIG_MFD_AS3711) += as3711.o
> diff --git a/driv

Re: [PATCH RFC v4] media: OF: add "sync-on-green-active" property

[Sylwester Nawrocki]

Hi Prabhakar,

On 07/16/2013 07:19 PM, Prabhakar Lad wrote:

From: "Lad, Prabhakar"

This patch adds 'sync-on-green-active' property as part
of endpoint property.

Signed-off-by: Lad, Prabhakar
---
   Changes for v4:
   1: Fixed review comments pointed by Sylwester.

   Changes for v3:
   1: Fixed review comments pointed by Laurent and Sylwester.

   RFC v2 https://patchwork.kernel.org/patch/2578091/

   RFC V1 https://patchwork.kernel.org/patch/2572341/

  .../devicetree/bindings/media/video-interfaces.txt |3 +++
  drivers/media/v4l2-core/v4l2-of.c  |4 
  include/media/v4l2-mediabus.h  |2 ++
  3 files changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt 
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index e022d2d..5186c7e 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -101,6 +101,9 @@ Optional endpoint properties
array contains only one entry.
  - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
clock mode.
+- sync-on-green-active: polarity field when video synchronization is
+  Sync-On-Green. When set the driver determines whether it's a normal operation
+  or inverted operation.


Would you mind adding this entry after pclk-sample property description ?
And how about describing it a bit more precisely and similarly to 
VSYNC/HSYNC,

e.g.

- sync-on-green-active: active state of Sync-on-green (SoG) signal,
  0/1 for LOW/HIGH respectively.

Otherwise looks good.


  Example
diff --git a/drivers/media/v4l2-core/v4l2-of.c 
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..5c4c9f0 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -100,6 +100,10 @@ static void v4l2_of_parse_parallel_bus(const struct 
device_node *node,
if (!of_property_read_u32(node, "data-shift",&v))
bus->data_shift = v;

+   if (!of_property_read_u32(node, "sync-on-green-active",&v))
+   flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH :
+   V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW;
+
bus->flags = flags;

  }
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 83ae07e..d47eb81 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -40,6 +40,8 @@
  #define V4L2_MBUS_FIELD_EVEN_HIGH (1<<  10)
  /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */
  #define V4L2_MBUS_FIELD_EVEN_LOW  (1<<  11)
+#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1<<  12)
+#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1<<  13)

  /* Serial flags */
  /* How many lanes the client can use */


Thanks,
Sylwester
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v4] Input: sysrq - DT binding for key sequence

[Mathieu Poirier]

On 15 July 2013 20:43, Rob Herring  wrote:

> On 07/15/2013 10:36 AM, mathieu.poir...@linaro.org wrote:
> > From: "Mathieu J. Poirier" 
> >
> > Adding a simple device tree binding for the specification of key
> sequences.
> > Definition of the keys found in the sequence are located in
> > 'include/uapi/linux/input.h'.
> >
> > For the sysrq driver, holding the sequence of keys down for a specific
> amount of time
> > will reset the system.
> >
> > Signed-off-by: Mathieu Poirier 
> > ---
> > changes for v4:
> >   - Moved seach of reset sequence nodes to a single call.
> > ---
> >  .../devicetree/bindings/input/input-reset.txt  | 34 ++
> >  drivers/tty/sysrq.c| 54
> ++
> >  2 files changed, 88 insertions(+)
> >  create mode 100644
> Documentation/devicetree/bindings/input/input-reset.txt
> >
> > diff --git a/Documentation/devicetree/bindings/input/input-reset.txt
> b/Documentation/devicetree/bindings/input/input-reset.txt
> > new file mode 100644
> > index 000..79504af
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/input-reset.txt
> > @@ -0,0 +1,34 @@
> > +Input: sysrq reset sequence
> > +
> > +A simple binding to represent a set of keys as described in
> > +include/uapi/linux/input.h.  This is to communicate a
> > +sequence of keys to the sysrq driver.  Upon holding the keys
> > +for a specified amount of time (if specified) the system is
> > +sync'ed and reset.
> > +
> > +Key sequences are global to the system but all the keys in a
> > +set must be coming from the same input device.
> > +
> > +The /chosen node should contain a 'linux,sysrq-reset-seq' child
> > +node to define a set of keys.
> > +
> > +Required property:
> > +sysrq-reset-seq: array of keycodes
> > +
> > +Optional property:
> > +timeout-ms: duration keys must be pressed together in microseconds
>
> milliseconds (ms) or microseconds (us)?
>
>
Right, milliseconds.


> > +before generating a sysrq
> > +
> > +Example:
> > +
> > + chosen {
> > +linux,sysrq-reset-seq {
> > +keyset = <0x03
> > +  0x04
> > +  0x0a>;
> > +timeout-ms = <3000>;
> > +};
> > + };
> > +
> > +Would represent KEY_2, KEY_3 and KEY_9.
> > +
> > diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> > index b51c154..01a8729 100644
> > --- a/drivers/tty/sysrq.c
> > +++ b/drivers/tty/sysrq.c
> > @@ -44,6 +44,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -671,6 +672,50 @@ static void sysrq_detect_reset_sequence(struct
> sysrq_state *state,
> >   }
> >  }
> >
> > +static void sysrq_of_get_keyreset_config(void)
> > +{
> > + unsigned short key;
> > + struct device_node *np;
> > + const struct property *prop;
> > + const __be32 *val;
> > + int count, i;
> > +
> > + np = of_find_node_by_path("/chosen/linux,sysrq-reset-seq");
> > + if (!np) {
> > + pr_debug("No sysrq node found");
> > + goto out;
> > + }
> > +
> > + prop = of_find_property(np, "keyset", NULL);
> > + if (!prop || !prop->value) {
> > + pr_err("Invalid input keyset");
> > + goto out;
> > + }
> > +
> > + count = prop->length / sizeof(u32);
> > + val = prop->value;
>
> None of the existing helpers to retrieve property arrays doesn't work here?
>

The problem here is that we never know how long the sequence will be.  As
such the 'of_property_read_uXY_array' functions won't work.  Or maybe
you're referring to another set of helpers... If so, please clarify.


>
> > +
> > + if (count > SYSRQ_KEY_RESET_MAX)
> > + count = SYSRQ_KEY_RESET_MAX;
> > +
> > + /* reset in case a __weak definition was present */
> > + sysrq_reset_seq_len = 0;
> > +
> > + for (i = 0; i < count; i++) {
> > + key = (unsigned short)be32_to_cpup(val++);
> > + if (key == KEY_RESERVED || key > KEY_MAX)
> > + break;
> > +
> > + sysrq_reset_seq[sysrq_reset_seq_len++] = key;
> > + }
> > +
> > + /* get reset timeout if any */
> > + of_property_read_u32(np, "timeout-ms", &sysrq_reset_downtime_ms);
> > +
> > + out:
> > + ;
> > +}
> > +
> >  static void sysrq_reinject_alt_sysrq(struct work_struct *work)
> >  {
> >   struct sysrq_state *sysrq =
> > @@ -688,6 +733,7 @@ static void sysrq_reinject_alt_sysrq(struct
> work_struct *work)
> >   input_inject_event(handle, EV_KEY, KEY_SYSRQ, 1);
> >   input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
> >
> > +
>
> spurious ws change


> >   input_inject_event(handle, EV_KEY, KEY_SYSRQ, 0);
> >   input_inject_event(handle, EV_KEY, alt_code, 0);
> >   input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
> > @@ -903,6 +949,7 @@ static inline void sysrq_register_handl

Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property

[Stephen Warren]

On 07/15/2013 05:02 PM, Stephen Warren wrote:
> On 07/15/2013 01:34 PM, Rob Herring wrote:
>> On 07/15/2013 01:40 PM, Stephen Warren wrote:
>>> From: Stephen Warren 
>>>
>>> This property is no longer required by the GPIO binding. Remove it.
>>
>> Won't this break compatibility with older kernel? It is one thing to
>> deprecate, but removal is another. If the relevant maintainers don't
>> care, then I guess it is fine.
> 
> Yes.
> 
> I had originally hoped this could sneak in late for 3.11, but I suppose
> it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
> protect.
> 
> Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.

One more thought here:

I know DT bindings are supposed to evolve so that a new kernel will
support arbitrary old DTs. I'll call that backwards-compatibility for
the DT parsing code.

However, this situation is the reverse; this patch would prevent a new
DT running on an older kernel. I'll call that forwards-compatibility.
I'm not sure if the intent is to support this or not? It's certainly the
first I explicitly thought about compatibility in this direction...
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

[Nicolas Pitre]

On Tue, 16 Jul 2013, Rob Herring wrote:

> On 07/16/2013 11:05 AM, Lorenzo Pieralisi wrote:
> > The TC2 versatile express core tile integrates a logic block that provides 
> > the
> > interface between the dual cluster test-chip and the M3 microcontroller that
> > carries out power management. The logic block, called Serial Power 
> > Controller
> > (SPC), contains several memory mapped registers to control among other 
> > things
> > low-power states, wake-up irqs and per-CPU jump addresses registers.
> > 
> > This patch provides a driver that enables run-time control of features
> > implemented by the SPC power management control logic.
> > 
> > The SPC control logic is required to be programmed very early in the boot
> > process to reset secondary CPUs on the TC2 testchip, set-up jump addresses 
> > and
> > wake-up IRQs for power management. Hence, waiting for core changes to be
> > made in the device core code to enable early registration of platform
> > devices, the driver puts in place an early init scheme that allows kernel
> > drivers to initialize the SPC driver directly from the components requiring
> > it, if their initialization routine is called before the driver init
> > function by the boot process.
> > 
> > Device tree bindings documentation for the SPC component is provided with
> > the patchset.
> 
> Just curious, wouldn't a TC2 PSCI implementation eliminate the need for
> most/all of this code?

There is a PSCI equivalent for the above already, in the sense that 
there is a simple MCPM backend that bypass most of the MCPM race 
avoidance code paths and simply calls into PSCI instead.  But not all 
the world is going to be PSCI, and therefore we need to ensure good 
support for non-PSCI platforms as well.

This is why TC2 supports both, and this also ensure that the PSCI 
implementation, which won't be part of the kernel and therefore unlikely 
to get the same level of scrutiny, is properly implemented and doesn't 
introduce any regression when compared to the non PSCI case.

Remember that TC2 is multi-cluster which means that the PSCI 
implementation has to carry the same amount of complexity as the whole 
in-kernel MCPM layer and that doesn't make me overly confident it is 
going to always be right.

All this to say that we do need this code despite PSCI availability.


Nicolas
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property

[Rob Herring]

On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren  wrote:
> On 07/15/2013 05:02 PM, Stephen Warren wrote:
>> On 07/15/2013 01:34 PM, Rob Herring wrote:
>>> On 07/15/2013 01:40 PM, Stephen Warren wrote:
 From: Stephen Warren 

 This property is no longer required by the GPIO binding. Remove it.
>>>
>>> Won't this break compatibility with older kernel? It is one thing to
>>> deprecate, but removal is another. If the relevant maintainers don't
>>> care, then I guess it is fine.
>>
>> Yes.
>>
>> I had originally hoped this could sneak in late for 3.11, but I suppose
>> it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
>> protect.
>>
>> Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.
>
> One more thought here:
>
> I know DT bindings are supposed to evolve so that a new kernel will
> support arbitrary old DTs. I'll call that backwards-compatibility for
> the DT parsing code.

That is the more common case.

> However, this situation is the reverse; this patch would prevent a new
> DT running on an older kernel. I'll call that forwards-compatibility.
> I'm not sure if the intent is to support this or not? It's certainly the
> first I explicitly thought about compatibility in this direction...

So you would be okay if your computer stopped booting a kernel after a
BIOS update? It's the same deal. It's both forwards and backwards
compatibility that is needed.

Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH -next] mtd: orion_nand: convert to use devm_* APIs

[Wei Yongjun]

From: Wei Yongjun 

Convert to use devm_* APIs to avoid resources leak on error handling case.

Signed-off-by: Wei Yongjun 
---
 drivers/mtd/nand/orion_nand.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 46f308d..ce711b4 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -85,25 +85,23 @@ static int __init orion_nand_probe(struct platform_device 
*pdev)
int ret = 0;
u32 val = 0;
 
-   nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info), 
GFP_KERNEL);
+   nc = devm_kzalloc(&pdev->dev,
+ sizeof(struct nand_chip) + sizeof(struct mtd_info),
+ GFP_KERNEL);
if (!nc) {
printk(KERN_ERR "orion_nand: failed to allocate device 
structure.\n");
-   ret = -ENOMEM;
-   goto no_res;
+   return -ENOMEM;
}
mtd = (struct mtd_info *)(nc + 1);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   ret = -ENODEV;
-   goto no_res;
-   }
+   if (!res)
+   return -ENODEV;
 
-   io_base = ioremap(res->start, resource_size(res));
+   io_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
if (!io_base) {
printk(KERN_ERR "orion_nand: ioremap failed\n");
-   ret = -EIO;
-   goto no_res;
+   return -EIO;
}
 
if (pdev->dev.of_node) {
@@ -111,8 +109,7 @@ static int __init orion_nand_probe(struct platform_device 
*pdev)
GFP_KERNEL);
if (!board) {
printk(KERN_ERR "orion_nand: failed to allocate board 
structure.\n");
-   ret = -ENOMEM;
-   goto no_res;
+   return -ENOMEM;
}
if (!of_property_read_u32(pdev->dev.of_node, "cle", &val))
board->cle = (u8)val;
@@ -186,10 +183,6 @@ no_dev:
clk_disable_unprepare(clk);
clk_put(clk);
}
-   iounmap(io_base);
-no_res:
-   kfree(nc);
-
return ret;
 }
 
@@ -201,10 +194,6 @@ static int orion_nand_remove(struct platform_device *pdev)
 
nand_release(mtd);
 
-   iounmap(nc->IO_ADDR_W);
-
-   kfree(nc);
-
clk = clk_get(&pdev->dev, NULL);
if (!IS_ERR(clk)) {
clk_disable_unprepare(clk);

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v4] Input: sysrq - DT binding for key sequence

[Rob Herring]

On Tue, Jul 16, 2013 at 5:24 PM, Mathieu Poirier
 wrote:
>
>
>
> On 15 July 2013 20:43, Rob Herring  wrote:
>>
>> On 07/15/2013 10:36 AM, mathieu.poir...@linaro.org wrote:
>> > From: "Mathieu J. Poirier" 
>> >

[snip]

>> > + prop = of_find_property(np, "keyset", NULL);
>> > + if (!prop || !prop->value) {
>> > + pr_err("Invalid input keyset");
>> > + goto out;
>> > + }
>> > +
>> > + count = prop->length / sizeof(u32);
>> > + val = prop->value;
>>
>> None of the existing helpers to retrieve property arrays doesn't work
>> here?
>
>
> The problem here is that we never know how long the sequence will be.  As
> such the 'of_property_read_uXY_array' functions won't work.  Or maybe you're
> referring to another set of helpers... If so, please clarify.

What about of_property_for_each_u32? Or we should make
of_property_read_uXY_array work with arrays that can be less than some
max size.

Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V2 5/5] ARM: remove #gpio-ranges-cells property

[Stephen Warren]

On 07/16/2013 07:50 PM, Rob Herring wrote:
> On Tue, Jul 16, 2013 at 6:30 PM, Stephen Warren  wrote:
>> On 07/15/2013 05:02 PM, Stephen Warren wrote:
>>> On 07/15/2013 01:34 PM, Rob Herring wrote:
 On 07/15/2013 01:40 PM, Stephen Warren wrote:
> From: Stephen Warren 
>
> This property is no longer required by the GPIO binding. Remove it.

 Won't this break compatibility with older kernel? It is one thing to
 deprecate, but removal is another. If the relevant maintainers don't
 care, then I guess it is fine.
>>>
>>> Yes.
>>>
>>> I had originally hoped this could sneak in late for 3.11, but I suppose
>>> it's too late now. vf610.dtsi is a new file in 3.11 so has no legacy to
>>> protect.
>>>
>>> Admittedly, the #gpio-cells property was added into the SPEAr files in 3.10.
>>
>> One more thought here:
>>
>> I know DT bindings are supposed to evolve so that a new kernel will
>> support arbitrary old DTs. I'll call that backwards-compatibility for
>> the DT parsing code.
> 
> That is the more common case.
> 
>> However, this situation is the reverse; this patch would prevent a new
>> DT running on an older kernel. I'll call that forwards-compatibility.
>> I'm not sure if the intent is to support this or not? It's certainly the
>> first I explicitly thought about compatibility in this direction...
> 
> So you would be okay if your computer stopped booting a kernel after a
> BIOS update? It's the same deal. It's both forwards and backwards
> compatibility that is needed.

I would strongly hope the BIOS/bootloader/... would have nothing to do
with the DT content. There's a reason that Grant asserted early on that
DTBs shouldn't be part of the BIOS/bootloader, but rather stored
separately, so the DTB could be updated without updating firmware, just
like the kernel. And I see no real problem with a new DTB requiring a
new kernel or even vice-versa to be honest.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Shawn Guo]

On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
> Registering the driver earlier won't cause any bugs. However, it's not
> the correct approach.
> 
> Deferred probe /is/ the approach for assuring correct dependencies
> between drivers. It works and should be used. There are not enough
> initcall levels to play games using initcalls and solve all the issues,
> and the ordering requirements vary board-to-board. Deferred probe at
> runtime handles this without having to manually place all the drivers
> into specific initcall levels, and dynamically adjusts to board
> differences, since it all happens automatically at run-time.

I do not quite follow the argument here.  I agree with you that
deferred probe is the approach to solve dependencies.  But it does not
necessarily mean that initcall can not be used to help it save some
nasty or nested deferring.  Deferred probe and initcalls are not two
mutually exclusive mechanisms but two which can help each other.

Shawn

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC PATCH v4 03/18] Documentation: devicetree: arm: cpus/cpu nodes bindings updates

[Rob Herring]

On 07/16/2013 04:45 AM, Lorenzo Pieralisi wrote:
> On Mon, Jul 15, 2013 at 07:50:46PM +0100, Rob Herring wrote:
>> On 07/15/2013 04:34 AM, Lorenzo Pieralisi wrote:
>>> On Fri, Jul 12, 2013 at 03:47:17PM +0100, Rob Herring wrote:
 On Fri, May 17, 2013 at 10:20 AM, Lorenzo Pieralisi
  wrote:
> In order to extend the current cpu nodes bindings to newer CPUs
> inclusive of AArch64 and to update support for older ARM CPUs this
> patch updates device tree documentation for the cpu nodes bindings.

 Sorry for the long delay on this, but I'm still not happy with the binding 
 here.
>>>
>>> I had to ask Russell again to drop the bindings patches from the patch
>>> system, and this is not acceptable since two months have passed and the
>>> entire series was reviewed, acked and partially merged. I will review
>>> these bindings again but I would like to understand who should give the 
>>> final
>>> go ahead to get these patches queued for upstreaming, I can't continue
>>> updating this stuff forever.
>>
>> Most of my comments are for 64-bit. So don't blame me that it had to be
>> reverted. I said up front I was concerned about this change breaking
>> things and it appears it did. New kernels must not require a new DT.
> 
> The patches in Russell's tree do not break anything, I asked him to drop
> them since, if we change the bindings again, those patches change and have
> to be reworked. It was not meant to blame you at all, just saying that
> the process to get this stuff in the kernel should be defined properly
> and patches reviewed in a timely fashion.
> 
> And for legacy reasons the situation related to cpu/cpus node bindings
> is a complicated one, there are bindings in the ePAPR, bindings in the
> kernel, people are confused and with this set we wanted to draw a
> line. For arm64 this is an absolute must.
> 
> I disagree with you on the "new kernels must not require a new DT".
> That's true if bindings are well defined, not for a mix of legacy ePAPR and
> bindings-in-the-kernel.

Well defined depends on the platform. For purposes of a single cluster
ARM system, the ePAPR was pretty much sufficient for cpu node
description. The initial discussion was whether we even needed cpu nodes
at all.

We're always going to have something new that we did not account for. So
even for well defined bindings, we'll have to make changes/extensions at
some point. It just needs to be years, not months for changes.

> What's the DT standard for ARM cpu/cpus node ? ePAPR ? In kernel docs ?
> A combination thereof ? Things are not clear cut and I do not like that, it
> is confusing.

ePAPR is a guideline, but in the end it is a PowerPC document. In some
cases we can just use what it defines and in others we need to deviate.
In an ideal world, we would create the equivalent for ARM or figure out
how to merge ARM requirements with ePAPR. However, since UEFI and ACPI
are going to solve all our problems, no one seems interested in defining
a more formal document.

To further complicate things, there is also the original OF
specification to follow as well. So I would say all the docs apply and
the order of priority is DT binding docs, ePAPR, OF specs. The DT
binding docs need to be complete enough to avoid confusion.

Rob

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support

[Nicolas Pitre]

On Tue, 16 Jul 2013, Lorenzo Pieralisi wrote:

> Hello,
> 
> version v5 of VExpress SPC driver, please read on the changelog for major
> changes and explanations.
> 
> The probing scheme is unchanged, since after trying the early platform
> devices approach it appeared that the end result was no better than the
> current one. The only clean solution relies either on changing how
> secondaries are brought up in the kernel (later than now) or enable
> early platform device registration through DT. Please check this
> thread for the related discussion:
> 
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-June/036542.html
> 
> The interface was adapted to regmap and again reverted to old driver for
> the following reasons:
> 
> - Power down registers locking is hairy and requires arch spinlocks in
>   the MCPM back end to work properly, normal spinlocks cannot be used
> - Regmap adds unnecessary code to manage SPC since it is just a bunch of
>   registers used to control power management flags, the overhead is just
>   not worth it (talking about power down registers, not the vexpress config
>   interface)
> - The locking scheme behind regmap requires all registers in the map
>   to be protected with the same lock, which is not exactly what we want
>   here
> - Given the reasons above, adding a regmap interface buys us nothing from
>   a driver readability and maintainability perspective (again just talking
>   about the power interface, a few registers) because for the SPC it would
>   simply not be used
> 
> /drivers/mfd is probably not the right place for this code as it stands (but
> probably will be when the entire driver, with DVFS and config interface, is
> complete).
> 
> Thank you for the review in advance,
> Lorenzo

I've integrated this patch in my MCPM backend for TC2 patch series.

ACKs from concerned/interested people would be appreciated so I could 
send this for ARM-SOC inclusion right away.


Nicolas
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v8] reset: Add driver for gpio-controlled reset pins

[Shawn Guo]

On Tue, Jul 16, 2013 at 09:47:02AM -0600, Stephen Warren wrote:
> > diff --git a/drivers/reset/gpio-reset.c b/drivers/reset/gpio-reset.c
> 
> > -   gpio_set_value(drvdata->gpio, value);
> > +   if (gpio_cansleep(drvdata->gpio))
> > +   gpio_set_value_cansleep(drvdata->gpio, value);
> > +   else
> > +   gpio_set_value(drvdata->gpio, value);
> 
> That's not right. Calling gpio_set_value() v.s.
> gpio_set_value_cansleep() should be based on the properties of the
> calling context, not the GPIO being controlled. In other words, if it's
> permissible to call gpio_set_value_cansleep() at this point in the code,
> simply always call that, and remove the conditional logic.

Ah, yes.  I was confused by the API gpio_cansleep().  Which API we
should call depends on the calling context.  And the context should
come from the gpio-reset client device driver.  IOW, we have no idea
what the context is in gpio-reset driver.  To start with something
simple, we may want to define the gpio-reset as a sleepable interface
and always call gpio_set_value_cansleep() in there.

Shawn

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

[Thierry Reding]

On Fri, Jun 14, 2013 at 02:38:49PM +0200, Arnd Bergmann wrote:
> On Friday 14 June 2013 12:53:11 Thierry Reding wrote:
> > 
> > I think the biggest missing piece is pci_common_exit(), the counterpart
> > of pci_common_init(), to cleanup a host bridge on ARM. I haven't looked
> > in detail at the other architectures, but I suspect there must be some
> > code to call when a host bridge is removed.
> > 
> > Looking at drivers/pci/remove.c, it seems like pci_remove_root_bus()
> > might be what we're looking at. It isn't exported so it can't be used by
> > modules, but that can be changed. Is that how a host bridge is typically
> > removed from the system?
> 
> It's fairly new to have host bridges in loadable modules, so I'm pretty
> sure it's not supported by the core yet, but it also doesn't seem hard
> to do. I think you are right with regard to pci_remove_root_bus,
> and Bjorn might be able to provide more information.
> 
> Ideally we should be able to load and unload the pci host driver
> in a loop indefinitely without crashing or exposing any races
> or leaks, but I would not bet on that working without bugs in the
> core, since that goes beyond the normal pci (device) hotplug case.

I've done some preliminary testing on Tegra using sysfs to unbind and
rebind the device from and to the driver. Some code needs to be added
for this to work, but it doesn't crash and PCI even continues to work
after unbinding and rebinding (tested using gigabit ethernet).

However I haven't looked for leaks yet, and I'm pretty sure some more
code is required to undo some of what pci_common_init() does on ARM.
Looking more closely, I think most (if not all) remaining leaks could
be fixed by keeping the list of pci_sys_data structures around and
cleaning them up properly.

Given the experimental nature of this I don't want to make that part of
the driver for 3.12 and I've opted to just disable any means of removing
the driver for now. But I do want to get back to this after the driver
has been merged.

Thierry


pgptZkAgaVWRI.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH -next] Input: olpc_apsp - remove redundant dev_err call in olpc_apsp_probe()

[Wei Yongjun]

From: Wei Yongjun 

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun 
---
 drivers/input/serio/olpc_apsp.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
index 818aa46..c96e3bd 100644
--- a/drivers/input/serio/olpc_apsp.c
+++ b/drivers/input/serio/olpc_apsp.c
@@ -187,10 +187,8 @@ static int olpc_apsp_probe(struct platform_device *pdev)
return -ENOENT;
 
priv->base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(priv->base)) {
-   dev_err(&pdev->dev, "Failed to map WTM registers\n");
+   if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
-   }
 
priv->irq = platform_get_irq(pdev, 0);
if (priv->irq < 0)

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH] msm_serial: add missing iounmap() on error in msm_request_port()

[Wei Yongjun]

From: Wei Yongjun 

Add the missing iounmap() before return from msm_request_port()
in the error handling case.

Signed-off-by: Wei Yongjun 
---
 drivers/tty/serial/msm_serial.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 2c6cfb3..0b38b28 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -637,7 +637,7 @@ static int msm_request_port(struct uart_port *port)
if (!request_mem_region(gsbi_resource->start, size,
 "msm_serial")) {
ret = -EBUSY;
-   goto fail_release_port;
+   goto fail_release_port_membase;
}
 
msm_port->gsbi_base = ioremap(gsbi_resource->start, size);
@@ -651,6 +651,8 @@ static int msm_request_port(struct uart_port *port)
 
 fail_release_gsbi:
release_mem_region(gsbi_resource->start, size);
+fail_release_port_membase:
+   iounmap(port->membase);
 fail_release_port:
release_mem_region(port->mapbase, size);
return ret;

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v9 1/8] drivers: phy: add generic PHY framework

[Greg KH]

On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> +menuconfig GENERIC_PHY
> + tristate "PHY Subsystem"
> + help
> +   Generic PHY support.
> +
> +   This framework is designed to provide a generic interface for PHY
> +   devices present in the kernel. This layer will have the generic
> +   API by which phy drivers can create PHY using the phy framework and
> +   phy users can obtain reference to the PHY.

Shouldn't this be something that other drivers select?  How will anyone
know if they need this or not?

> --- /dev/null
> +++ b/drivers/phy/phy-core.c
> @@ -0,0 +1,544 @@
> +/*
> + * phy-core.c  --  Generic Phy framework.
> + *
> + * Copyright (C) 2013 Texas Instruments
> + *
> + * Author: Kishon Vijay Abraham I 
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.

You really mean "any later version" (I have to ask)?

> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .

Are these two paragraphs needed?  This isn't a "program", and they got a
copy of the GPL already with the kernel.

> +static struct class *phy_class;

Why do you need a class?

When modifying/adding new sysfs stuff, you need a Documentation/ABI/
entry as well.

thanks,

greg k-h
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss