Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

On Mon, Mar 16, 2015 at 8:24 PM, Tony Lindgren  wrote:
> * Sebastian Reichel  [150316 11:26]:
>> Hi,
>>
>> On Mon, Mar 16, 2015 at 08:29:39AM -0700, Tony Lindgren wrote:
>> > * Arnd Bergmann  [150315 05:10]:
>> > > On Sunday 15 March 2015 10:50:42 Eliad Peller wrote:
>> > > > yeah, i missed it :/
>> > > >
>> > > > looks like there's no platform that defines platform data for it.
>> > > > i'll replace the dev_get_platdata() with a function that only parses
>> > > > the clock-frequency properties (the irq is taken in this case from the
>> > > > spi_device).
>> > > > (or maybe i should just drop it, as no one actually uses it?)
>> > >
>> > > I don't think we should drop the driver, but dropping the platform_data
>> > > support sounds reasonable. New users of this driver should all be using
>> > > DT, and if there is a good reason to use platform_data, it's easily
>> > > put back.
>> >
>> > Well we have n8x0 and n900 using the spi driver. For those, n8x0 boot
>> > all in dts mode, but n900 still also boots in legacy mode. It seems the
>> > board-rx51-peripherals.c only passes the power_gpio though, so that
>> > should be easy to keep around.
>> >
>> > We should keep things still working for n900 in legacy mode until the
>> > pending regressions with device tree based booting have been cleared
>> > for at least one merge cycle. I believe the last pending issues is the
>> > support for ATAG_REVISION in device tree mode as posted by Pali.
>>
>> mh by migrating to newer gpiod interface platform data is no longer
>> needed (instead the boardfile would need a gpiod_lookup_table). That
>> way all of the dirty code is in the board file and will be removed
>> once the time comes. See for example rx51_fmtx_gpios_table.
>>
>> Note: This is independent of wl12xx changes, since N900 uses wl1251.
>
> Oh sorry yes sounds like that's different platform data then. In that
> case I see no reasons to drop the platform data for wl12xx.
>
great.
so i'll drop the relevant wlcore_spi platform data code, and rebase
the patches on top of v4.0-rc4 (probably tomorrow).

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kexec fails if OF_UNITTEST=y (was: Re: [PATCH v2] Removes OF_UNITTEST dependency on OF_DYNAMIC config symbol)

[Geert Uytterhoeven]

Hi Rob,

On Tue, Mar 17, 2015 at 1:25 AM, Rob Herring  wrote:
> On Mon, Mar 16, 2015 at 5:58 AM, Geert Uytterhoeven
>  wrote:
>> On Fri, Jan 23, 2015 at 2:03 PM, Geert Uytterhoeven
>>  wrote:
>>> On Sun, Jan 11, 2015 at 8:19 AM, Gaurav Minocha
>>>  wrote:
 This patch intends to remove the unittests dependency on
 the functions defined in dynamic.c. So, rather than calling
 of_attach_node defined in dynamic.c, minimal functionality
 required to attach a new node is re-defined in unittest.c.
 Also, now after executing the tests the test data is not
 removed from the device tree so there is no need to call
 of_detach_node.
>>>
>>> Could there be unwanted side effects of not removing the test data?
>>
>> Unfortunately I found a regression introduced by commit 3ce04b4a9fdc30b6
>> ("Removes OF_UNITTEST dependency on OF_DYNAMIC config symbol").
>>
>> If the test data is still present, kexec (kexec-tools 2.0.7 released 24
>> November 2014, 1:2.0.7-5 in Debian) fails with:
>>
>> unrecoverable error: short read
>> from"/proc/device-tree//testcase-data/large-property-PAGE_SIZEx8"
>>
>> Granted, this is a bug in kexec-tools, but I'm reporting it anyway, as it is
>> a kernel regression with existing userspace.
>>
>> I believe this bug was fixed in kexec-tools by commit d1932cd592e2a6aa
>> ("kexec/fs2dt: Use slurp_file_len to avoid partial read of files"), but I
>> haven't tested the fix yet.
>
> Is OF_UNITTEST enabled by default in Debian or this is a custom
> kernel? Perhaps we should require a command line option to actually
> populate the test data and run the tests?

It's not that bad, this is a custom kernel. I just had it still
enabled by accident.

I guess making it modular is not that easy?

> We just need more tests to slow down the boot enough people will not
> enable them by default. ;)

Apart from slowing down the boot, most tests don't have side effects.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Geert Uytterhoeven]

On Tue, Mar 17, 2015 at 1:46 AM, Peter Hurley  wrote:
> On 03/16/2015 08:35 PM, Andreas Schwab wrote:
>> Peter Hurley  writes:
>>> On 03/16/2015 08:19 PM, Andreas Schwab wrote:
 Peter Hurley  writes:
> I don't see this as a regression, but rather a misconfiguration.

 It breaks booting on PowerMac.
>>>
>>> It doesn't boot?
>>
>> Yes.
>
> Ok, thanks for the report.
>
> Can you attach
> 1) your .dts

Note that this is a PowerMac, so there's no DTS, only a real DT passed by
the Firmware.

> Do you have a serial console hooked up?

Most probably, the chosen/stdout-path is provided automatically by the
firmware, even if no serial console is present. Andreas, is that correct?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/5] arm64: Enable EDAC on ARM64

[Loc Ho]

Add an stub atomic_scrub and enable EDAC for arm64.

Signed-off-by: Loc Ho 
---
 arch/arm64/Kconfig|1 +
 arch/arm64/include/asm/edac.h |   31 +++
 2 files changed, 32 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/include/asm/edac.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e80cd74..d9c342a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -20,6 +20,7 @@ config ARM64
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
select COMMON_CLK
+   select EDAC_SUPPORT
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS
select GENERIC_ALLOCATOR
diff --git a/arch/arm64/include/asm/edac.h b/arch/arm64/include/asm/edac.h
new file mode 100644
index 000..1cedba6
--- /dev/null
+++ b/arch/arm64/include/asm/edac.h
@@ -0,0 +1,31 @@
+/*
+ * ARM64 EDAC Header File
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+#ifndef ASM_EDAC_H
+#define ASM_EDAC_H
+
+/*
+ * ECC atomic, DMA, SMP and interrupt safe scrub function.
+ * Implements the per arch atomic_scrub() that EDAC use for software
+ * ECC scrubbing.  It reads memory and then writes back the original
+ * value, allowing the hardware to detect and correct memory errors.
+ */
+static inline void atomic_scrub(void *va, u32 size)
+{
+   /* Stub function for now until an ARM64 HW has a way to test it. */
+}
+
+#endif
+
--
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 5/5] arm64: Add APM X-Gene SoC EDAC DTS entries

[Loc Ho]

This patch adds APM X-Gene SoC EDAC DTS entries.

Signed-off-by: Feng Kan 
Signed-off-by: Loc Ho 
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   98 
 1 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index a857794..c7b028f 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -354,6 +354,104 @@
};
};

+   edacmc0: edacmc0@7e80 {
+   compatible = "apm,xgene-edac-mc";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e20 0x0 0x1000>,
+ <0x0 0x7e70 0x0 0x1000>,
+ <0x0 0x7e72 0x0 0x1000>,
+ <0x0 0x7e80 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacmc1: edacmc1@7e84 {
+   compatible = "apm,xgene-edac-mc";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e20 0x0 0x1000>,
+ <0x0 0x7e70 0x0 0x1000>,
+ <0x0 0x7e72 0x0 0x1000>,
+ <0x0 0x7e84 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacmc2: edacmc2@7e88 {
+   compatible = "apm,xgene-edac-mc";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e20 0x0 0x1000>,
+ <0x0 0x7e70 0x0 0x1000>,
+ <0x0 0x7e72 0x0 0x1000>,
+ <0x0 0x7e88 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacmc3: edacmc3@7e8c {
+   compatible = "apm,xgene-edac-mc";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e20 0x0 0x1000>,
+ <0x0 0x7e70 0x0 0x1000>,
+ <0x0 0x7e72 0x0 0x1000>,
+ <0x0 0x7e8c 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacpmd0: edacpmd0@7c00 {
+   compatible = "apm,xgene-edac-pmd";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7c00 0x0 0x20>,
+ <0x0 0x1054a000 0x0 0x10>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacpmd1: edacpmd1@7c20 {
+   compatible = "apm,xgene-edac-pmd";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7c20 0x0 0x20>,
+ <0x0 0x1054a000 0x0 0x10>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacpmd2: edacpmd2@7c40 {
+   compatible = "apm,xgene-edac-pmd";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7c40 0x0 0x20>,
+ <0x0 0x1054a000 0x0 0x10>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacpmd3: edacpmd3@7c60 {
+   compatible = "apm,xgene-edac-pmd";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7c60 0x0 0x20>,
+ <0x0 0x1054a000 0x0 0x10>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacl3: edacl3@7e60 {
+   compatible = "apm,xgene-edac-l3";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e60 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacsoc: edacsoc@7e93 {
+   compatible = "apm,xgene-edac-soc";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e93 0x0 0x1000>,
+ <0x0 0x7e00 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>,
+  

[PATCH v6 3/5] Documentation: Add documentation for the APM X-Gene SoC EDAC DTS binding

[Loc Ho]

This patch adds documentation for the APM X-Gene SoC EDAC DTS binding.

Signed-off-by: Feng Kan 
Signed-off-by: Loc Ho 
---
 .../devicetree/bindings/edac/apm-xgene-edac.txt|   82 
 1 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt

diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt 
b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
new file mode 100644
index 000..db8c1c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
@@ -0,0 +1,82 @@
+* APM X-Gene SoC EDAC nodes
+
+EDAC nodes are defined to describe on-chip error detection and correction.
+There are four types of EDAC:
+
+  memory controller- Memory controller
+  PMD (L1/L2)  - Processor module unit (PMD) L1/L2 cache
+  L3   - CPU L3 cache
+  SoC  - SoC IP such as SATA, Ethernet, and etc
+
+The following section describes the memory controller DT node binding.
+
+Required properties:
+- compatible   : Shall be "apm,xgene-edac-mc".
+- reg  : First resource shall be the PCP resource.
+ Second resource shall be the CSW resource.
+ Third resource shall be the MCB-A resource.
+ Fourth resource shall be the MCB-B resource.
+ Fifth resource shall be the MCU resource.
+- interrupts: Interrupt-specifier for MCU error IRQ(s).
+
+The following section describes the L1/L2 DT node binding.
+
+- compatible   : Shall be "apm,xgene-edac-pmd".
+- reg  : First resource shall be the PCP resource.
+ Second resource shall be the PMD resource.
+ Third resource shall be the PMD efuse resource.
+- interrupts: Interrupt-specifier for PMD error IRQ(s).
+
+The following section describes the L3 DT node binding.
+
+- compatible   : Shall be "apm,xgene-edac-l3".
+- reg  : First resource shall be the PCP resource.
+ Second resource shall be the L3 resource.
+- interrupts: Interrupt-specifier for L3 error IRQ(s).
+
+The following section describes the SoC DT node binding.
+
+- compatible   : Shall be "apm,xgene-edac-soc"".
+- reg  : First resource shall be the PCP resource.
+ Second resource shall be the SoC resource.
+ Third resource shall be the register bus resource.
+- interrupts   : Interrupt-specifier for SoC error IRQ(s).
+
+Example:
+   edacmc0: edacmc0@7e80 {
+   compatible = "apm,xgene-edac-mc";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e20 0x0 0x1000>,
+ <0x0 0x7e70 0x0 0x1000>,
+ <0x0 0x7e72 0x0 0x1000>,
+ <0x0 0x7e80 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacl3: edacl3@7e60 {
+   compatible = "apm,xgene-edac-l3";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e60 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacpmd0: edacpmd0@7c00 {
+   compatible = "apm,xgene-edac-pmd";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7c00 0x0 0x20>,
+ <0x0 0x1054a000 0x0 0x10>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>;
+   };
+
+   edacsoc: edacsoc@7e93 {
+   compatible = "apm,xgene-edac-soc";
+   reg = <0x0 0x7880 0x0 0x1000>,
+ <0x0 0x7e93 0x0 0x1000>,
+ <0x0 0x7e00 0x0 0x1000>;
+   interrupts = <0x0 0x20 0x4>,
+<0x0 0x21 0x4>,
+<0x0 0x27 0x4>;
+   };
--
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/5] MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver

[Loc Ho]

This patch adds a MAINTAINERS entry for APM X-Gene SoC EDAC driver.

Signed-off-by: Loc Ho 
---
 MAINTAINERS |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index cd88eb6..d67ab7b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3724,6 +3724,14 @@ W:   bluesmoke.sourceforge.net
 S: Maintained
 F: drivers/edac/sb_edac.c

+EDAC-XGENE
+APPLIED MICRO (APM) X-GENE SOC EDAC
+M: Loc Ho 
+M: Feng Kan 
+S: Supported
+F: drivers/edac/xgene_edac.c
+F: Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
+
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
--
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 4/5] edac: Add APM X-Gene SoC EDAC driver

[Loc Ho]

This patch adds support for the APM X-Gene SoC EDAC driver.

Signed-off-by: Feng Kan 
Signed-off-by: Loc Ho 
---
 drivers/edac/Kconfig  |9 +-
 drivers/edac/Makefile |1 +
 drivers/edac/xgene_edac.c | 2183 +
 3 files changed, 2192 insertions(+), 1 deletions(-)
 create mode 100644 drivers/edac/xgene_edac.c

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index cb59619..6289dd9 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -10,7 +10,7 @@ config EDAC_SUPPORT
 menuconfig EDAC
bool "EDAC (Error Detection And Correction) reporting"
depends on HAS_IOMEM
-   depends on X86 || PPC || TILE || ARM || EDAC_SUPPORT
+   depends on X86 || PPC || TILE || ARM || ARM64 || EDAC_SUPPORT
help
  EDAC is designed to report errors in the core system.
  These are low-level errors that are reported in the CPU or
@@ -392,4 +392,11 @@ config EDAC_SYNOPSYS
  Support for error detection and correction on the Synopsys DDR
  memory controller.

+config EDAC_XGENE
+   tristate "APM X-Gene SoC"
+   depends on EDAC_MM_EDAC && ARM64
+   help
+ Support for error detection and correction on the
+ APM X-Gene family of SOCs.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index b255f36..28ef2a5 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o

 obj-$(CONFIG_EDAC_ALTERA_MC)   += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
+obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
new file mode 100644
index 000..2e1037f
--- /dev/null
+++ b/drivers/edac/xgene_edac.c
@@ -0,0 +1,2183 @@
+/*
+ * APM X-Gene SoC EDAC (error detection and correction) Module
+ *
+ * Copyright (c) 2015, Applied Micro Circuits Corporation
+ * Author: Feng Kan 
+ * Loc Ho 
+ *
+ * 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.
+ *
+ * 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "edac_core.h"
+
+#define EDAC_MOD_STR   "xgene_edac"
+
+static int edac_mc_idx;
+static int edac_mc_active_mask;
+static int edac_mc_registered_mask;
+static DEFINE_MUTEX(xgene_edac_lock);
+
+/* Global error configuration status registers (CSR) */
+#define PCPHPERRINTSTS 0x
+#define PCPHPERRINTMSK 0x0004
+#define  MCU_CTL_ERR_MASK  BIT(12)
+#define  IOB_PA_ERR_MASK   BIT(11)
+#define  IOB_BA_ERR_MASK   BIT(10)
+#define  IOB_XGIC_ERR_MASK BIT(9)
+#define  IOB_RB_ERR_MASK   BIT(8)
+#define  L3C_UNCORR_ERR_MASK   BIT(5)
+#define  MCU_UNCORR_ERR_MASK   BIT(4)
+#define  PMD3_MERR_MASKBIT(3)
+#define  PMD2_MERR_MASKBIT(2)
+#define  PMD1_MERR_MASKBIT(1)
+#define  PMD0_MERR_MASKBIT(0)
+#define PCPLPERRINTSTS 0x0008
+#define PCPLPERRINTMSK 0x000C
+#define  CSW_SWITCH_TRACE_ERR_MASK BIT(2)
+#define  L3C_CORR_ERR_MASK BIT(1)
+#define  MCU_CORR_ERR_MASK BIT(0)
+#define MEMERRINTSTS   0x0010
+#define MEMERRINTMSK   0x0014
+
+/* Memory controller error CSR */
+#define MCU_MAX_RANK   8
+#define MCU_RANK_STRIDE0x40
+
+#define MCUGECR0x0110
+#define  MCU_GECR_DEMANDUCINTREN_MASK  BIT(0)
+#define  MCU_GECR_BACKUCINTREN_MASKBIT(1)
+#define  MCU_GECR_CINTREN_MASK BIT(2)
+#define  MUC_GECR_MCUADDRERREN_MASKBIT(9)
+#define MCUGESR0x0114
+#define  MCU_GESR_ADDRNOMATCH_ERR_MASK BIT(7)
+#define  MCU_GESR_ADDRMULTIMATCH_ERR_MASK  BIT(6)
+#define  MCU_GESR_PHYP_ERR_MASKBIT(3)
+#define MCUESRR0   0x0314
+#define  MCU_ESRR_MULTUCERR_MASK   BIT(3)
+#define  MCU_ESRR_BACKUCERR_MASK   BIT(2)
+#define  MCU_ESRR_DEMANDUCERR_MASK BIT(1)
+#define  MCU_ESRR_CERR_MASKBIT(0)
+#define MCUESRRA0  0x0318
+#define MCUEBLRR0  0x031c
+#define  MCU_EBLRR_ERRBANK_RD(src) (((src)

[PATCH v6 0/4] edac: Add APM X-Gene SoC EDAC driver

[Loc Ho]

This patch adds support for the APM X-Gene SoC EDAC driver for DT.

v6:
* Rebase to 4.0.0-rc3
* Add memory scrub stub function and enable ARM64 EDAC support patch
* Add bit definition defines for L2RTOS registers
* Remove un-necessary clearing of all L1/L2 software generated registers
* Remove wrong notification of LSU un-correctable error
* Change L2 reporting of un-correcable error to correctable error
* Change clearing of the L2C L2RTO registers
* Add support for L2 HW version 1 and version 2 or above
* Add support for L3 HW version 1 and version 2 or above

v5:
* Rebase to 3.17.rc1 (next)
* Update binding documentation for additional SoC node binding resource
* Enable MCU correctable and uncorrectable interrupts if not enabled by
  firmware
* Enable top level interrupt only after all MCU registered. Otherwise,
  error interrupt will never get cleared by the corresponding MCU.
* Remove clearing of L1 and L2 errors during initialization time. Otherwise,
  they will not be captured between firmware booting and error configuration.
* Add capture and clearing SoC register bus errors
* Add register bus resource to SoC DT node

v4:
* Fix PMD l1/l2 error reading address due to wrong variable type
* Fix clearing of software generated and HW errors for l1/l2

v3:
* Update binding documentation for PMD DT node and exampples
* Add binding documentation for SoC DT node
* Change MC, PMD, and L3C driver error injection to use debugfs
* Add missing IRQ for MC correctable error (code and DT)
* Use true/false where appropriate instead 1/0
* Add bit definition for L1 MMUESR register and fully decode this error
* Remove the un-necessary dev variable from xgene_edac_pmd_ctx structure
* Add check for disabled PMD (code and DT)
* Switch to edac_printk instead pr_err
* Some minor comments update

v2:
* Add EDAC entry in MAINTAINERS for APM EDAC driver
* Remove the MC scrub patch
* Remove the word 'Caches' from Kconfig
* Change all MASK defines to use BIT(x)
* Update comment or remove them
* Wrap error injection code around CONFIG_EDAC_DEBUG
* Change function name xgene_edac_mc_hw_init to xgene_edac_mc_irq_ctl
* Change all function XXX_hw_init to XXX_hw_ctl
* Fix typo 'activie'
* Move calling function edac_mc_alloc after resource retrieval
* Check for NULL on platform_get_resource return if reference directly
* Add documentation for struct xgene_edac_pmd_ctx
* Move L1 and L2 check out of function xgene_edac_pmd_check to its own
  functions
* Use for loop for configure each CPU of an PMD
* Replace /2 by >> 1
* Remove unnecessary comment on edac_device_add_device failure
* Make mem_err_ip static const
* Unwind EDAC register correctly if failed
---
Loc Ho (5):
  arm64: Enable EDAC on ARM64
  MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver
  Documentation: Add documentation for the APM X-Gene SoC EDAC DTS
binding
  edac: Add APM X-Gene SoC EDAC driver
  arm64: Add APM X-Gene SoC EDAC DTS entries

 .../devicetree/bindings/edac/apm-xgene-edac.txt|   82 +
 MAINTAINERS|8 +
 arch/arm64/Kconfig |1 +
 arch/arm64/boot/dts/apm/apm-storm.dtsi |   98 +
 arch/arm64/include/asm/edac.h  |   31 +
 drivers/edac/Kconfig   |9 +-
 drivers/edac/Makefile  |1 +
 drivers/edac/xgene_edac.c  | 2183 
 8 files changed, 2412 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
 create mode 100644 arch/arm64/include/asm/edac.h
 create mode 100644 drivers/edac/xgene_edac.c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch v6 1/2] dt/bindings: qcom_adm: Fix channel specifiers

[Andy Gross]

This patch removes the crci information from the dma channel property.  At least
one client device requires using more than one CRCI value for a channel.  This
does not match the current binding and the crci information needs to be removed.

Instead, the client device will provide this information via other means.

Signed-off-by: Andy Gross 
---
 Documentation/devicetree/bindings/dma/qcom_adm.txt |   16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/qcom_adm.txt 
b/Documentation/devicetree/bindings/dma/qcom_adm.txt
index 9bcab91..38d45f8 100644
--- a/Documentation/devicetree/bindings/dma/qcom_adm.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_adm.txt
@@ -4,8 +4,7 @@ Required properties:
 - compatible: must contain "qcom,adm" for IPQ/APQ8064 and MSM8960
 - reg: Address range for DMA registers
 - interrupts: Should contain one interrupt shared by all channels
-- #dma-cells: must be <2>.  First cell denotes the channel number.  Second cell
-  denotes CRCI (client rate control interface) flow control assignment.
+- #dma-cells: must be <1>.  First cell denotes the channel number.
 - clocks: Should contain the core clock and interface clock.
 - clock-names: Must contain "core" for the core clock and "iface" for the
   interface clock.
@@ -22,7 +21,7 @@ Example:
compatible = "qcom,adm";
reg = <0x1830 0x10>;
interrupts = <0 170 0>;
-   #dma-cells = <2>;
+   #dma-cells = <1>;
 
clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>;
clock-names = "core", "iface";
@@ -35,15 +34,12 @@ Example:
qcom,ee = <0>;
};
 
-DMA clients must use the format descripted in the dma.txt file, using a three
+DMA clients must use the format descripted in the dma.txt file, using a two
 cell specifier for each channel.
 
-Each dmas request consists of 3 cells:
+Each dmas request consists of two cells:
  1. phandle pointing to the DMA controller
  2. channel number
- 3. CRCI assignment, if applicable.  If no CRCI flow control is required, use 
0.
-The CRCI is used for flow control.  It identifies the peripheral device 
that
-is the source/destination for the transferred data.
 
 Example:
 
@@ -56,7 +52,7 @@ Example:
 
cs-gpios = <&qcom_pinmux 20 0>;
 
-   dmas = <&adm_dma 6 9>,
-   <&adm_dma 5 10>;
+   dmas = <&adm_dma 6>,
+   <&adm_dma 5>;
dma-names = "rx", "tx";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch v6 2/2] dmaengine: Add ADM driver

[Andy Gross]

Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA
controller found in the MSM8x60 and IPQ/APQ8064 platforms.

The ADM supports both memory to memory transactions and memory
to/from peripheral device transactions.  The controller also provides flow
control capabilities for transactions to/from peripheral devices.

The initial release of this driver supports slave transfers to/from peripherals
and also incorporates CRCI (client rate control interface) flow control.

Signed-off-by: Andy Gross 
---
 drivers/dma/Kconfig|   10 +
 drivers/dma/Makefile   |1 +
 drivers/dma/qcom_adm.c |  900 
 3 files changed, 911 insertions(+)
 create mode 100644 drivers/dma/qcom_adm.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6e..6919013 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -473,4 +473,14 @@ config QCOM_BAM_DMA
  Enable support for the QCOM BAM DMA controller.  This controller
  provides DMA capabilities for a variety of on-chip devices.
 
+config QCOM_ADM
+   tristate "Qualcomm ADM support"
+   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   ---help---
+ Enable support for the Qualcomm ADM DMA controller.  This controller
+ provides DMA capabilities for both general purpose and on-chip
+ peripheral devices.
+
 endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index f915f61..7f0fbe6 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
 obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
 obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
+obj-$(CONFIG_QCOM_ADM) += qcom_adm.o
diff --git a/drivers/dma/qcom_adm.c b/drivers/dma/qcom_adm.c
new file mode 100644
index 000..7f8c119
--- /dev/null
+++ b/drivers/dma/qcom_adm.c
@@ -0,0 +1,900 @@
+/*
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+/* ADM registers - calculated from channel number and security domain */
+#define ADM_CHAN_MULTI 0x4
+#define ADM_CI_MULTI   0x4
+#define ADM_CRCI_MULTI 0x4
+#define ADM_EE_MULTI   0x800
+#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan)
+#define ADM_EE_OFFS(ee)(ADM_EE_MULTI * ee)
+#define ADM_CHAN_EE_OFFS(chan, ee) (ADM_CHAN_OFFS(chan) + ADM_EE_OFFS(ee))
+#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan)
+#define ADM_CI_OFFS(ci)(ADM_CHAN_OFF(ci))
+#define ADM_CH_CMD_PTR(chan, ee)   (ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_RSLT(chan, ee)  (0x40 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_FLUSH_STATE0(chan, ee)  (0x80 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_STATUS_SD(chan, ee) (0x200 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_CONF(chan)  (0x240 + ADM_CHAN_OFFS(chan))
+#define ADM_CH_RSLT_CONF(chan, ee) (0x300 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_SEC_DOMAIN_IRQ_STATUS(ee)  (0x380 + ADM_EE_OFFS(ee))
+#define ADM_CI_CONF(ci)(0x390 + ci * ADM_CI_MULTI)
+#define ADM_GP_CTL 0x3d8
+#define ADM_CRCI_CTL(crci, ee) (0x400 + crci * ADM_CRCI_MULTI + \
+   ADM_EE_OFFS(ee))
+
+/* channel status */
+#define ADM_CH_STATUS_VALIDBIT(1)
+
+/* channel result */
+#define ADM_CH_RSLT_VALID  BIT(31)
+#define ADM_CH_RSLT_ERRBIT(3)
+#define ADM_CH_RSLT_FLUSH  BIT(2)
+#define ADM_CH_RSLT_TPDBIT(1)
+
+/* channel conf */
+#define ADM_CH_CONF_SHADOW_EN  BIT(12)
+#define ADM_CH_CONF_MPU_DISABLEBIT(11)
+#define ADM_CH_CONF_PERM_MPU_CONF  BIT(9)
+#define ADM_CH_CONF_FORCE_RSLT_EN  BIT(7)
+#define ADM_CH_CONF_SEC_DOMAIN(ee) (((ee & 0x3) << 4) | ((ee & 0x4) << 11))
+
+/* channel result conf */
+#define ADM_CH_RSLT_CONF_FLUSH_EN  BIT(1)
+#define ADM_CH_RSLT_CONF_IRQ_ENBIT(0)
+
+/* CRCI CTL */
+#define ADM_CRCI_CTL_MUX_SEL   BIT(18)
+#define ADM_CRCI_CTL_RST   BIT(17)
+
+/* CI configuration */
+#define ADM_CI_RANGE_E

[Patch v6 0/2] Add Qualcomm ADM dmaengine driver

[Andy Gross]

This patch set introduces the dmaengine driver for the Qualcomm Application
Data Mover (ADM) DMA controller present on MSM8x60, APQ8064, and IPQ8064
devices.

The initial version of this driver will only support slave DMA operations
between system memory and peripherals.  Flow control via the CRCI (client rate
control interface) is supported and can be configured via device tree
configuration.  Flow control usage is required for some peripheral devices.

Changes from v5:
  - Fix erroneous adm_get_blksize for values of 192 and 256.

Changes from v4:
  - Fixed copyright date
  - Fixed error in EE offsets and usage
  - Changed namespace for registers and fields to ADM specific naming
  - Removed alloc_chan function
  - Removed control function and fixed up terminate_all and slave_config
  - Reworked descriptor processing code to make it more clean
  - Moved to use of_dma_xlate_by_chan_id
  - Fixed other small review comments

Changes from v3:
  - Remove .owner field

Changes from v2:
  - Removed extraneous achan variable from xlate function
  - Reworked crci check in slave_sg function
  - Added mux field to async_desc structure.
  - Reworked dma start function to use crci and mux values directly from
structure.
  - Added disable of clocks in probe error paths.
  - Changed to use #define for fixed number of channels.

Changes since v1:
  - Fixed various review comments
  - Fixed some descriptor programming issues.
  - Added single descriptors to support sub burst length transactions.
Selection of single or box descriptors depends on the sg length and burst
size.
  - Removed use of crci in the dmas property.  CRCI is now designated via the
slave_config structure and will be stored in slave_id.

Andy Gross (2):
  dt/bindings: qcom_adm: Fix channel specifiers
  dmaengine: Add ADM driver

 Documentation/devicetree/bindings/dma/qcom_adm.txt |   16 +-
 drivers/dma/Kconfig|   10 +
 drivers/dma/Makefile   |1 +
 drivers/dma/qcom_adm.c |  900 
 4 files changed, 917 insertions(+), 10 deletions(-)
 create mode 100644 drivers/dma/qcom_adm.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch v4 2/2] dmaengine: Add ADM driver

[Andy Gross]

On Mon, Mar 16, 2015 at 08:15:26AM -, sricha...@codeaurora.org wrote:
> Hi,
> 
> 
> >
> >>
> >> > +static int adm_get_blksize(unsigned int burst)
> >> > +{
> >> > +int ret;
> >> > +
> >> > +switch (burst) {
> >> > +case 16:
> >> > +ret = 0;
> >> > +break;
> >> > +case 32:
> >> > +ret = 1;
> >> > +break;
> >> > +case 64:
> >> > +ret = 2;
> >> > +break;
> >> > +case 128:
> >> > +ret = 3;
> >> > +break;
> >> > +case 192:
> >> > +ret = 4;
> >> > +break;
> >> > +case 256:
> >> > +ret = 5;
> >> > +break;
> >> ffs(burst>>4) ?
> >
> > that should work nicely.  thanks.
> >
>   Will not work for 192, 256 ?

you are right.  I'll have to separate those out into 2 more cases.  Good catch!

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] ARM: bcm2835: Add the mailbox to the device tree.

[Stephen Warren]

On 03/12/2015 08:32 PM, Eric Anholt wrote:
> Signed-off-by: Eric Anholt 
> Acked-by: Lee Jones 

Patches 2, 4,
Acked-by: Stephen Warren 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4 v4] mailbox: Enable BCM2835 mailbox support

[Stephen Warren]

On 03/12/2015 08:32 PM, Eric Anholt wrote:
> From: Lubomir Rintel 
> 
> Implement BCM2835 mailbox support as a device registered with the
> general purpose mailbox framework. Implementation based on commits by
> Lubomir Rintel [1], Suman Anna and Jassi Brar [2] on which to base the
> implementation.
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-rpi-kernel/2013-April/000528.html
> [2] http://lists.infradead.org/pipermail/linux-rpi-kernel/2013-May/000546.html
> 
> Signed-off-by: Lubomir Rintel 
> Signed-off-by: Craig McGeachie 
> Signed-off-by: Suman Anna 
> Signed-off-by: Jassi Brar 
> Signed-off-by: Eric Anholt 
> Cc: Jassi Brar 
> Acked-by: Lee Jones 

Acks often don't carry over when there are significant changes.

> diff --git a/drivers/mailbox/bcm2835-mailbox.c 
> b/drivers/mailbox/bcm2835-mailbox.c

> +#define MBOX_MSG(chan, data28)   (((data28) & ~0xf) | ((chan) & 
> 0xf))
> +#define MBOX_CHAN(msg)   ((msg) & 0xf)
> +#define MBOX_DATA28(msg) ((msg) & ~0xf)

Even the concept of storing channel IDs in the LSBs feels like it might
be RPi-firmware-specific rather than HW-specific?

> +static irqreturn_t bcm2835_mbox_irq(int irq, void *dev_id)
> +{
> + struct bcm2835_mbox *mbox = (struct bcm2835_mbox *) dev_id;
> + struct device *dev = mbox->dev;
> +
> + bcm2835_peripheral_read_workaround();
> +
> + while (!(readl(mbox->regs + MAIL0_STA) & ARM_MS_EMPTY)) {
> + u32 msg = readl(mbox->regs + MAIL0_RD);
> + unsigned int chan = MBOX_CHAN(msg);
> + u32 data = MBOX_DATA28(msg);
> +
> + if (!mbox->channel[chan].started) {
> + dev_err(dev, "Reply on stopped channel %d\n", chan);
> + continue;
> + }
> + dev_dbg(dev, "Reply 0x%08X\n", msg);

I think for complete safety, you'd need to put the peripheral workaround
call here too. Consider what happens if some module registers to receive
mailbox responses, then e.g. changes a GPIO right in the callback. Are
we going to add the workaround call to the bcm2835 GPIO, SDHCI, and USB
drivers too? If so, that might obviate the need to perform the
workaround here.

Either way though, wouldn't we need to at least move the workaround
that's already present in this function so that it happens before the
readl() inside the while() above every time, to handle the switch from
any HW access inside mbox_chan_received_data() to the HW access to the
mbox module here?

> + mbox_chan_received_data(mbox->channel[chan].link, &data);
> + }
> + return IRQ_HANDLED;
> +}

> +static int bcm2835_mbox_probe(struct platform_device *pdev)
...
> + /* Enable the interrupt on data reception */
> + writel(ARM_MC_IHAVEDATAIRQEN, mbox->regs + MAIL0_CNF);

I think that bcm2835_mbox_remove() needs to undo that, so that it
guarantees the IRQ handler won't be called after the function returns,
but before the devm IRQ unregister occurs.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] ARM: BCM2835: Add a function for doing an rmb() between device reads.

[Stephen Warren]

On 03/12/2015 08:32 PM, Eric Anholt wrote:
> Stephen Warren was concerned that the rmb() present in the new mailbox
> driver was unnecessary, and after seeing the docs, that it was just so
> surprising that somebody would come along and remove it later.  The
> explanation for the need for the rmb() is long enough that we won't
> want to place it at every callsite.  Make a wrapper with the whole
> explanation in it, so that anyone wondering what's going on sees the
> docs right there.

> diff --git a/include/soc/bcm2835/peripheral-workaround.h 
> b/include/soc/bcm2835/peripheral-workaround.h

> +static inline void bcm2835_peripheral_read_workaround(void)
> +{
> +#ifdef CONFIG_ARCH_BCM2835

Would this header be included if that wasn't defined? Perhaps that'll be
answered by a later patch...

> + /*
> +  * The BCM2835 bus is unusual in that it doesn't guarantee
> +  * ordering between reads from different peripherals (where
> +  * peripherals roughly correspond to Linux devices).  From
> +  * BCM2835 ARM Peripherals.pdf, page 7:

Many buses don't guarantee ordering; that's quite common. The issue is
that the CPU then doesn't match up the correct read request and
response, thus causing it to swap the results of read requests. That's
the unusual part. It would be useful to spell that out more explicitly
in this introduction, even though it is called out in the example below.

BTW, the ARM mailing list is linux-arm-ker...@lists.infradead.org not
linux-arm-ker...@vger.kernel.org.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/3] of/unittest: replace 'selftest' with 'unittest'

[Wang Long]

This patch just replace the string 'selftest' with 'unittest'
in OF unittest and data and binding file.

I have tested it successfully on ARM.

Signed-off-by: Gaurav Minocha 
Signed-off-by: Wang Long 
---
 Documentation/devicetree/bindings/unittest.txt |  44 +-
 drivers/of/unittest-data/tests-overlay.dtsi| 108 ++--
 drivers/of/unittest.c  | 706 -
 3 files changed, 429 insertions(+), 429 deletions(-)

diff --git a/Documentation/devicetree/bindings/unittest.txt 
b/Documentation/devicetree/bindings/unittest.txt
index 8933211..3bf58c2 100644
--- a/Documentation/devicetree/bindings/unittest.txt
+++ b/Documentation/devicetree/bindings/unittest.txt
@@ -1,60 +1,60 @@
-1) OF selftest platform device
+1) OF unittest platform device
 
-** selftest
+** unittest
 
 Required properties:
-- compatible: must be "selftest"
+- compatible: must be "unittest"
 
 All other properties are optional.
 
 Example:
-   selftest {
-   compatible = "selftest";
+   unittest {
+   compatible = "unittest";
status = "okay";
};
 
-2) OF selftest i2c adapter platform device
+2) OF unittest i2c adapter platform device
 
 ** platform device unittest adapter
 
 Required properties:
-- compatible: must be selftest-i2c-bus
+- compatible: must be unittest-i2c-bus
 
-Children nodes contain selftest i2c devices.
+Children nodes contain unittest i2c devices.
 
 Example:
-   selftest-i2c-bus {
-   compatible = "selftest-i2c-bus";
+   unittest-i2c-bus {
+   compatible = "unittest-i2c-bus";
status = "okay";
};
 
-3) OF selftest i2c device
+3) OF unittest i2c device
 
-** I2C selftest device
+** I2C unittest device
 
 Required properties:
-- compatible: must be selftest-i2c-dev
+- compatible: must be unittest-i2c-dev
 
 All other properties are optional
 
 Example:
-   selftest-i2c-dev {
-   compatible = "selftest-i2c-dev";
+   unittest-i2c-dev {
+   compatible = "unittest-i2c-dev";
status = "okay";
};
 
-4) OF selftest i2c mux device
+4) OF unittest i2c mux device
 
-** I2C selftest mux
+** I2C unittest mux
 
 Required properties:
-- compatible: must be selftest-i2c-mux
+- compatible: must be unittest-i2c-mux
 
-Children nodes contain selftest i2c bus nodes per channel.
+Children nodes contain unittest i2c bus nodes per channel.
 
 Example:
-   selftest-i2c-mux {
-   compatible = "selftest-i2c-mux";
+   unittest-i2c-mux {
+   compatible = "unittest-i2c-mux";
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
@@ -64,7 +64,7 @@ Example:
#size-cells = <0>;
i2c-dev {
reg = <8>;
-   compatible = "selftest-i2c-dev";
+   compatible = "unittest-i2c-dev";
status = "okay";
};
};
diff --git a/drivers/of/unittest-data/tests-overlay.dtsi 
b/drivers/of/unittest-data/tests-overlay.dtsi
index 244226c..02ba56c 100644
--- a/drivers/of/unittest-data/tests-overlay.dtsi
+++ b/drivers/of/unittest-data/tests-overlay.dtsi
@@ -4,94 +4,94 @@
overlay-node {
 
/* test bus */
-   selftestbus: test-bus {
+   unittestbus: test-bus {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
 
-   selftest100: test-selftest100 {
-   compatible = "selftest";
+   unittest100: test-unittest100 {
+   compatible = "unittest";
status = "okay";
reg = <100>;
};
 
-   selftest101: test-selftest101 {
-   compatible = "selftest";
+   unittest101: test-unittest101 {
+   compatible = "unittest";
status = "disabled";
reg = <101>;
};
 
-   selftest0: test-selftest0 {
-   compatible = "selftest";
+   unittest0: test-unittest0 {
+   compatible = "unittest";
status = "disabled";
reg = <0>;
};
 
-   selftest1: test-selftest1 {
-   compatible = "se

[PATCH v3 0/3] replace 'selftest' with 'unittest' and update the document.

[Wang Long]

This series patches replace 'selftest' with 'unittest' in the 
OF unittest, and update the document.

the first patch comes from Gaurav Minocha, and i update it. because
it can not apply on linux 4.0-rc4 when using 'git am' command.


* v3 <- v2:
- Rebase the patch on 4.0-rc4
- Re-adjust the sequence of the patches

* v2 <- v1:
- According to Gaurav's advice. make the rename
file patch correctly.

Wang Long (3):
  of/unittest: replace 'selftest' with 'unittest'
  Documentation: rename of_selftest.txt to of_unittest.txt
  Documentation: update the of_unittest.txt

 Documentation/devicetree/bindings/unittest.txt |  44 +-
 .../{of_selftest.txt => of_unittest.txt}   |  35 +-
 drivers/of/unittest-data/tests-overlay.dtsi| 108 ++--
 drivers/of/unittest.c  | 706 ++---
 4 files changed, 447 insertions(+), 446 deletions(-)
 rename Documentation/devicetree/{of_selftest.txt => of_unittest.txt} (87%)

-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] Documentation: update the of_unittest.txt

[Wang Long]

Since the directory "drivers/of/testcase-data" is renamed
to "drivers/of/unittest-data". so we should update the path
in the of_selftest.txt.

When the kernel is built with OF_UNITTEST enabled, the output
dtb is testcases.dtb instead of testcase.dtb, also update it
(s/testcase/testcases/).

Signed-off-by: Wang Long 
---
 Documentation/devicetree/of_unittest.txt | 35 
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/of_unittest.txt 
b/Documentation/devicetree/of_unittest.txt
index 57a808b..d79a6bc 100644
--- a/Documentation/devicetree/of_unittest.txt
+++ b/Documentation/devicetree/of_unittest.txt
@@ -1,11 +1,11 @@
-Open Firmware Device Tree Selftest
+Open Firmware Device Tree Unittest
 --
 
 Author: Gaurav Minocha 
 
 1. Introduction
 
-This document explains how the test data required for executing OF selftest
+This document explains how the test data required for executing OF unittest
 is attached to the live tree dynamically, independent of the machine's
 architecture.
 
@@ -22,31 +22,32 @@ most of the device drivers in various use cases.
 
 2. Test-data
 
-The Device Tree Source file (drivers/of/testcase-data/testcases.dts) contains
+The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
 the test data required for executing the unit tests automated in
-drivers/of/selftests.c. Currently, following Device Tree Source Include files
-(.dtsi) are included in testcase.dts:
+drivers/of/unittest.c. Currently, following Device Tree Source Include files
+(.dtsi) are included in testcases.dts:
 
-drivers/of/testcase-data/tests-interrupts.dtsi
-drivers/of/testcase-data/tests-platform.dtsi
-drivers/of/testcase-data/tests-phandle.dtsi
-drivers/of/testcase-data/tests-match.dtsi
+drivers/of/unittest-data/tests-interrupts.dtsi
+drivers/of/unittest-data/tests-platform.dtsi
+drivers/of/unittest-data/tests-phandle.dtsi
+drivers/of/unittest-data/tests-match.dtsi
+drivers/of/unittest-data/tests-overlay.dtsi
 
 When the kernel is build with OF_SELFTEST enabled, then the following make rule
 
 $(obj)/%.dtb: $(src)/%.dts FORCE
$(call if_changed_dep, dtc)
 
-is used to compile the DT source file (testcase.dts) into a binary blob
-(testcase.dtb), also referred as flattened DT.
+is used to compile the DT source file (testcases.dts) into a binary blob
+(testcases.dtb), also referred as flattened DT.
 
 After that, using the following rule the binary blob above is wrapped as an
-assembly file (testcase.dtb.S).
+assembly file (testcases.dtb.S).
 
 $(obj)/%.dtb.S: $(obj)/%.dtb
$(call cmd, dt_S_dtb)
 
-The assembly file is compiled into an object file (testcase.dtb.o), and is
+The assembly file is compiled into an object file (testcases.dtb.o), and is
 linked into the kernel image.
 
 
@@ -98,8 +99,8 @@ child11 -> sibling12 -> sibling13 -> sibling14 -> null
 Figure 1: Generic structure of un-flattened device tree
 
 
-Before executing OF selftest, it is required to attach the test data to
-machine's device tree (if present). So, when selftest_data_add() is called,
+Before executing OF unittest, it is required to attach the test data to
+machine's device tree (if present). So, when unittest_data_add() is called,
 at first it reads the flattened device tree data linked into the kernel image
 via the following kernel symbols:
 
@@ -186,10 +187,10 @@ update_node_properties().
 
 2.2. Removing the test data
 
-Once the test case execution is complete, selftest_data_remove is called in
+Once the test case execution is complete, unittest_data_remove is called in
 order to remove the device nodes attached initially (first the leaf nodes are
 detached and then moving up the parent nodes are removed, and eventually the
-whole tree). selftest_data_remove() calls detach_node_and_children() that uses
+whole tree). unittest_data_remove() calls detach_node_and_children() that uses
 of_detach_node() to detach the nodes from the live device tree.
 
 To detach a node, of_detach_node() either updates the child pointer of given
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] Documentation: rename of_selftest.txt to of_unittest.txt

[Wang Long]

Since the test of the devicetree's OF api use unittest as
its name. so we should rename of_selftest.txt to of_unittest.txt.

Signed-off-by: Wang Long 
---
 Documentation/devicetree/{of_selftest.txt => of_unittest.txt} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/{of_selftest.txt => of_unittest.txt} (100%)

diff --git a/Documentation/devicetree/of_selftest.txt 
b/Documentation/devicetree/of_unittest.txt
similarity index 100%
rename from Documentation/devicetree/of_selftest.txt
rename to Documentation/devicetree/of_unittest.txt
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dt/bindings: control CS via standard GPIO operations instead of SPI-HW

[Stephen Warren]

On 03/11/2015 09:21 AM, Martin Sperl wrote:
>> On 07.03.2015, at 06:47, Stephen Warren  wrote:
>>
>> These pins aren't used by anything on the board, but are rather part of
>> the expansion header. I wonder if we wouldn't be better off removing any
>> configuration of the pins from the DT. After all, we can't guarantee how
>> the user has connected them. The "default" usage, a/k/a the expansion
>> header signal naming, isn't any guarantee.
>>
>> Rather, the user should specify what they want to use the pin as; as a
>> GPIO input, GPIO output, or an SPI chip-select.
> ...
>> While the existing DT already has this issue, note that this forces
>> these pins to be driven as outputs. What if the user has hooked up an
>> external device that drives these signals, and wants to use the pins as
>> GPIO inputs?
> 
> Actually if you look at the Documentation on page 102 you will find that
> those pins are pulled high by default (if it is HW or firmware I am not
> sure) - so a hat designer needs to take this into consideration anyway.
> The only difference is that it is pulled high and not driven high/low.

Assuming that table shows HW defaults as opposed to the pin's
capabilities for pull-up-vs-down, then yes. Still, there is typically
quite a difference in strength between a pull-up and a drive-up.

> Also with the "new" models there is the Firmware that will read those 
> "hat-descriptors" from the eeprom and configure the GPIO "modes" and
> pullups based on this information.

Yes, my thinking is we should probably rely on that, or an explicit user
modification of the DT, to configure the pinmux, rather than making
assumptions.

> But then it means in principle that this is a more general issue
> that just became apparent now.

Yes.

>> This shouldn't be in the SoC .dtsi file. It's quite possible for someone
>> to use other GPIOs as SPI CS. It's board or even use-case specific
>> whether those are the correct values.
>>
>> I would argue that we should not put any cs-gpios into any in-kernel DT
>> file, since there's no on-board usage of SPI on the RPi boards.
> 
> but then: why not just make it optional and NOT configuring it at all
> and keep it "outside".

Sorry, I don't quite understand that comment; outside what?

>> For SPI to be useful, the user has to add a DT node to represent the SPI
>> device itself anyway, so adding some properties to the controller to
>> define which GPIOs to use for SPI CS can be done then too.
> 
> From what I have seen (and I am not an expert) is that with the 
> foundation device trees each "device" (spi/i2c/...) has a separate
> Gpio section, which gets referenced inside the spi/i2c/... block.
> 
> As far as I understood with this setup the GPIOs ALT only gets set
> up when the driver itself loads (probably while parsing the DT
> for the device)

Yes, that is certainly possible.

> So this is maybe the way forward for the whole default-dt?
> 
> For SPI it would look like this:
> &gpio {
> spi0_pins: spi0_pins {
> brcm,pins = <7 8 9 10 11>;
> brcm,function = <4>; /* alt0 */
> };
>   ...
> }
> 
> &spi0 {
>   ...
> pinctrl-0 = <&spi0_pins>;
>   ...
> }
> 
> And if you keep spi0 disabled in the dtsi files then the ALT
> modes should not be set.

Yes, so long as it's disabled by default that would be OK. However, I
wonder why we don't just rely on the firmware to set up the pinmux,
since as you mentioned it does it now?

> Obviously we could also split the gpio-block into 
> "normal SPI" and "CS" pins, which would allow changing the
> "defaults" also in the dts that gets build.
> 
> So how should we proceed?

If we do put any default CS GPIO setup in the kernel DT, we should
indeed put it into a separate node (pinctrl state) so that the user can
override it easily without any interactions with any other pins/...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/10] dt/bindings: Add binding for BCM2835 mailbox driver

[Stephen Warren]

On 03/12/2015 05:23 PM, Eric Anholt wrote:
...
> The power-domain rework ended up not working out -- it needs the 
> power-domain part of device/base to support throwing -EPROBE_DEFER
> if the driver hasn't probed yet,

That makese sense.

> unless we're willing to just bake in the power domain driver in
> static init ordering.

Indeed, that's quite unlikely to be acceptable.

> Device base maintainers weren't excited about my patch for
> -EPROBE_DEFER, because then a new DT would mean we start failing to
> probe the USB driver in an older kernel, which whould be a
> regression in the case that the user had U-Boot setting up USB for
> them.

The main ABI issue is that old DTs should work with new kernels. The
other way around is nice, but certainly not as strict a requirement. I
don't think that should block a change. Do you have a link to the
thread; I don't think I noticed it.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: am437x-gp-evm: add DT nodes for ov2659 sensor

[Tony Lindgren]

* Lad, Prabhakar  [150316 18:20]:
> Hi Tony,
> 
> On Mon, Mar 16, 2015 at 10:17 PM, Tony Lindgren  wrote:
> > * Lad Prabhakar  [150312 16:38]:
> >> From: "Lad, Prabhakar" 
> >>
> >> this patch does the following:
> >> 1: adds DT node for fixed oscillator.
> >> 2: adds DT node entries for ov2659 sensor
> >> 3: adds remote-endpoint entry for VPFE.
> >>
> >> Signed-off-by: Lad, Prabhakar 
> >
> > Applying into omap-for-v4.1/dt thanks.
> >
> I would like to get this one in via media tree to avoid dependency
> as I am still waiting for Acks from DT maintainers for the sensor
> driver.

OK dropping it.
 
> If I can get your Ack on this I'll queue it up along with sensor
> driver via media tree.

Sorry the chances are too big for pointless merge conflicts with
these files with constant patching going on.

Please just resend this patch alone again to me later on once the
driver changes are merged into Linux next and on their way to the
mainline kernel.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V5 2/2] ARM: dts: Add HS400 support for exynos5420 and exynos5800

[Kukjin Kim]

Alim Akhtar wrote:
> 
> Ping?
> 
Alim,

Can you please re-send it based on latest my tree?
It would be helpful for me ;)

Thanks,
Kukjin

> On Wed, Feb 25, 2015 at 12:05 PM, Jaehoon Chung  
> wrote:
> > Hi, Alim.
> >
> > Acked-by: Jaehoon Chung 
> >
> > Best Regards,
> > Jaehoon Chung
> >
> > On 01/29/2015 11:41 AM, Alim Akhtar wrote:
> >> From: Seungwon Jeon 
> >>
> >> HS400 timing values are added for SMDK5420, exynos5420-peach-pit
> >> and exynos5800-peach-pi boards.
> >> This also adds RCLK GPIO line, this gpio should be in pull-down
> >> state.
> >> This also enables HS400 on peach-pi and this updates the clock frequency
> >> to 800MHz to be set as input clock to controller.
> >>
> >> Signed-off-by: Seungwon Jeon 
> >> Signed-off-by: Alim Akhtar 
> >> [Alim: addressed review comments]
> >> ---
> >>  arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +++-
> >>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 +++
> >>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |4 +++-
> >>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |7 +--
> >>  4 files changed, 18 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> >> b/arch/arm/boot/dts/exynos5420-peach-
> pit.dts
> >> index 9a050e1..f7a44a4 100644
> >> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> >> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> >> @@ -569,8 +569,10 @@
> >>   samsung,dw-mshc-ciu-div = <3>;
> >>   samsung,dw-mshc-sdr-timing = <0 4>;
> >>   samsung,dw-mshc-ddr-timing = <0 2>;
> >> + samsung,dw-mshc-hs400-timing = <0 2>;
> >> + samsung,read-strobe-delay = <90>;
> >>   pinctrl-names = "default";
> >> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> >> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
> >>   bus-width = <8>;
> >>  };
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
> >> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> >> index ba686e4..8b15316 100644
> >> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> >> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> >> @@ -201,6 +201,13 @@
> >>   samsung,pin-drv = <3>;
> >>   };
> >>
> >> + sd0_rclk: sd0-rclk {
> >> + samsung,pins = "gpc0-7";
> >> + samsung,pin-function = <2>;
> >> + samsung,pin-pud = <1>;
> >> + samsung,pin-drv = <3>;
> >> + };
> >> +
> >>   sd1_cmd: sd1-cmd {
> >>   samsung,pins = "gpc1-1";
> >>   samsung,pin-function = <2>;
> >> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
> >> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> >> index 8be3d7b..2078a1f 100644
> >> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> >> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> >> @@ -80,8 +80,10 @@
> >>   samsung,dw-mshc-ciu-div = <3>;
> >>   samsung,dw-mshc-sdr-timing = <0 4>;
> >>   samsung,dw-mshc-ddr-timing = <0 2>;
> >> + samsung,dw-mshc-hs400-timing = <0 2>;
> >> + samsung,read-strobe-delay = <90>;
> >>   pinctrl-names = "default";
> >> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> >> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 
> >> &sd0_rclk>;
> >>   bus-width = <8>;
> >>   cap-mmc-highspeed;
> >>   };
> >> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> >> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >> index e8fdda8..96f0d61 100644
> >> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >> @@ -550,15 +550,18 @@
> >>   num-slots = <1>;
> >>   broken-cd;
> >>   mmc-hs200-1_8v;
> >> + mmc-hs400-1_8v;
> >>   cap-mmc-highspeed;
> >>   non-removable;
> >>   card-detect-delay = <200>;
> >> - clock-frequency = <4>;
> >> + clock-frequency = <8>;
> >>   samsung,dw-mshc-ciu-div = <3>;
> >>   samsung,dw-mshc-sdr-timing = <0 4>;
> >>   samsung,dw-mshc-ddr-timing = <0 2>;
> >> + samsung,dw-mshc-hs400-timing = <0 2>;
> >> + samsung,read-strobe-delay = <90>;
> >>   pinctrl-names = "default";
> >> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> >> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
> >>   bus-width = <8>;
> >>  };

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver

[Chanwoo Choi]

Hi Ivan,

On 03/16/2015 11:23 PM, Ivan T. Ivanov wrote:
> 
> Hi Roger, 
> 
> On Mon, 2015-03-16 at 15:11 +0200, Roger Quadros wrote:
>> Hi Ivan,
>>
>> On 16/03/15 14:32, Ivan T. Ivanov wrote:
>>> Hi,
>>>
>>> On Mon, 2015-02-02 at 12:21 +0200, Roger Quadros wrote:
 This driver observes the USB ID pin connected over a GPIO and
 updates the USB cable extcon states accordingly.

 The existing GPIO extcon driver is not suitable for this purpose
 as it needs to be taught to understand USB cable states and it
 can't handle more than one cable per instance.

 For the USB case we need to handle 2 cable states.
 1) USB (attach/detach)
 2) USB-HOST (attach/detach)

 This driver can be easily updated in the future to handle VBUS
 events in case it happens to be available on GPIO for any platform.

 Signed-off-by: Roger Quadros 
 ---
 v4:
 - got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
 - changed host cable name to "USB-HOST"
>>>
>>> I am sorry that I am getting a bit little late into this.
>>>
>>> Isn't supposed that we have to use strings defined in
>>> const char extcon_cable_name[][]?
>>>
>>>
 +
 +/* List of detectable cables */
 +enum {
 +   EXTCON_CABLE_USB = 0,
 +   EXTCON_CABLE_USB_HOST,
 +
>>>
>>> Same here: duplicated with enum extcon_cable_name
>>>
 +   EXTCON_CABLE_END,
 +};
 +
 +static const char *usb_extcon_cable[] = {
 +   [EXTCON_CABLE_USB] = "USB",
 +   [EXTCON_CABLE_USB_HOST] = "USB-HOST",
 +   NULL,
 +};
>>
>> I'm not exactly sure how else it is supposed to work if we
>> support only a subset of cables from the global extcon_cable_name[][].
> 
> I don't see issue that we use just 2 events. I think that we can
> reuse  enum extcon_cable_name and strings already defined in 
> extcon_cable_name[][] global variable. It is defined extern in
> extcon.h file exactly for this purpose, no?

'extcon_cable_name' global variable is not used on extcon driver directly.
It is just recommended cable name. 

I have plan to use standard cable name for extcon driver instead of that
each extcon driver define the cable name.

[snip]

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: am437x-gp-evm: add DT nodes for ov2659 sensor

[Lad, Prabhakar]

Hi Tony,

On Mon, Mar 16, 2015 at 10:17 PM, Tony Lindgren  wrote:
> * Lad Prabhakar  [150312 16:38]:
>> From: "Lad, Prabhakar" 
>>
>> this patch does the following:
>> 1: adds DT node for fixed oscillator.
>> 2: adds DT node entries for ov2659 sensor
>> 3: adds remote-endpoint entry for VPFE.
>>
>> Signed-off-by: Lad, Prabhakar 
>
> Applying into omap-for-v4.1/dt thanks.
>
I would like to get this one in via media tree to avoid dependency
as I am still waiting for Acks from DT maintainers for the sensor
driver.

If I can get your Ack on this I'll queue it up along with sensor
driver via media tree.

Cheers,
--Prabhakar Lad

> Tony
>
>> ---
>>  Note this patch depends on
>>  https://patchwork.kernel.org/patch/6000161/
>>
>>  arch/arm/boot/dts/am437x-gp-evm.dts | 42 
>> +++--
>>  1 file changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
>> b/arch/arm/boot/dts/am437x-gp-evm.dts
>> index f84d971..195f452 100644
>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>> @@ -106,6 +106,14 @@
>>   };
>>   };
>>   };
>> +
>> + /* fixed 12MHz oscillator */
>> + refclk: oscillator {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <1200>;
>> + };
>> +
>>  };
>>
>>  &am43xx_pinmux {
>> @@ -404,6 +412,21 @@
>>   regulator-always-on;
>>   };
>>   };
>> +
>> + ov2659@30 {
>> + compatible = "ovti,ov2659";
>> + reg = <0x30>;
>> +
>> + clocks = <&refclk 0>;
>> + clock-names = "xvclk";
>> +
>> + port {
>> + ov2659_0: endpoint {
>> + remote-endpoint = <&vpfe1_ep>;
>> + link-frequencies = /bits/ 64 <7000>;
>> + };
>> + };
>> + };
>>  };
>>
>>  &i2c1 {
>> @@ -423,6 +446,21 @@
>>   touchscreen-size-x = <1024>;
>>   touchscreen-size-y = <600>;
>>   };
>> +
>> + ov2659@30 {
>> + compatible = "ovti,ov2659";
>> + reg = <0x30>;
>> +
>> + clocks = <&refclk 0>;
>> + clock-names = "xvclk";
>> +
>> + port {
>> + ov2659_1: endpoint {
>> + remote-endpoint = <&vpfe0_ep>;
>> + link-frequencies = /bits/ 64 <7000>;
>> + };
>> + };
>> + };
>>  };
>>
>>  &epwmss0 {
>> @@ -626,7 +664,7 @@
>>
>>   port {
>>   vpfe0_ep: endpoint {
>> - /* remote-endpoint = <&sensor>; add once we have it */
>> + remote-endpoint = <&ov2659_1>;
>>   ti,am437x-vpfe-interface = <0>;
>>   bus-width = <8>;
>>   hsync-active = <0>;
>> @@ -643,7 +681,7 @@
>>
>>   port {
>>   vpfe1_ep: endpoint {
>> - /* remote-endpoint = <&sensor>; add once we have it */
>> + remote-endpoint = <&ov2659_0>;
>>   ti,am437x-vpfe-interface = <0>;
>>   bus-width = <8>;
>>   hsync-active = <0>;
>> --
>> 2.1.0
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 08:35 PM, Andreas Schwab wrote:
> Peter Hurley  writes:
> 
>> On 03/16/2015 08:19 PM, Andreas Schwab wrote:
>>> Peter Hurley  writes:
>>>
 I don't see this as a regression, but rather a misconfiguration.
>>>
>>> It breaks booting on PowerMac.
>>
>> It doesn't boot?
> 
> Yes.

Ok, thanks for the report.

Can you attach
1) your .dts
2) your .config
3) complete dmesg from 4.0-rc4 boot with that patch reverted?

Do you have a serial console hooked up?

Regards,
Peter Hurley
 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Peter Hurley  writes:

> On 03/16/2015 08:19 PM, Andreas Schwab wrote:
>> Peter Hurley  writes:
>> 
>>> I don't see this as a regression, but rather a misconfiguration.
>> 
>> It breaks booting on PowerMac.
>
> It doesn't boot?

Yes.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 08:19 PM, Andreas Schwab wrote:
> Peter Hurley  writes:
> 
>> I don't see this as a regression, but rather a misconfiguration.
> 
> It breaks booting on PowerMac.

It doesn't boot?

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/10] dt-bindings: add Marvell PMU documentation

[Rob Herring]

On Fri, Mar 13, 2015 at 11:23 AM, Russell King
 wrote:
> Add the required DT binding documentation for the Marvell PMU driver.
>
> Signed-off-by: Russell King 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/soc/dove/pmu.txt | 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/dove/pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/dove/pmu.txt 
> b/Documentation/devicetree/bindings/soc/dove/pmu.txt
> new file mode 100644
> index ..25d988e7ec35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/dove/pmu.txt
> @@ -0,0 +1,49 @@
> +Device Tree bindings for Marvell PMU
> +
> +Required properties:
> + - compatible: value should be "marvell,dove-pmu".
> + - reg: two base addresses and sizes of the PM controller and PMU.
> + - interrupts: single interrupt number for the PMU interrupt
> + - interrupt-controller: must be specified as the PMU itself is an
> +interrupt controller.
> + - #interrupt-cells: must be 1.
> + - #reset-cells: must be 1.
> +
> +Optional properties:
> + - None
> +
> +Power domain descriptions are listed as child nodes of the power management
> +node.  Each domain has the following properties:
> +
> +Required properties:
> + - #power-domain-cells: must be 0.
> +
> +Optional properties:
> + - marvell,pmu_pwr_mask: specifies the mask value for PMU power register
> + - marvell,pmu_iso_mask: specifies the mask value for PMU isolation register
> + - resets: points to the reset manager (PMU node) and reset index.
> +
> +Example:
> +
> +   pmu: power-management@d {
> +   compatible = "marvell,dove-pmu";
> +   reg = <0xd 0x8000>, <0xd8000 0x8000>;
> +   interrupts = <33>;
> +   interrupt-controller;
> +   #interrupt-cells = <1>;
> +   #reset-cells = <1>;
> +
> +   vpu_domain: vpu-domain {
> +   #power-domain-cells = <0>;
> +   marvell,pmu_pwr_mask = <0x0008>;
> +   marvell,pmu_iso_mask = <0x0001>;
> +   resets = <&pmu 16>;
> +   };
> +
> +   gpu_domain: gpu-domain {
> +   #power-domain-cells = <0>;
> +   marvell,pmu_pwr_mask = <0x0004>;
> +   marvell,pmu_iso_mask = <0x0002>;
> +   resets = <&pmu 18>;
> +   };
> +   };
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kexec fails if OF_UNITTEST=y (was: Re: [PATCH v2] Removes OF_UNITTEST dependency on OF_DYNAMIC config symbol)

[Rob Herring]

On Mon, Mar 16, 2015 at 5:58 AM, Geert Uytterhoeven
 wrote:
> On Fri, Jan 23, 2015 at 2:03 PM, Geert Uytterhoeven
>  wrote:
>> On Sun, Jan 11, 2015 at 8:19 AM, Gaurav Minocha
>>  wrote:
>>> This patch intends to remove the unittests dependency on
>>> the functions defined in dynamic.c. So, rather than calling
>>> of_attach_node defined in dynamic.c, minimal functionality
>>> required to attach a new node is re-defined in unittest.c.
>>> Also, now after executing the tests the test data is not
>>> removed from the device tree so there is no need to call
>>> of_detach_node.
>>
>> Could there be unwanted side effects of not removing the test data?
>
> Unfortunately I found a regression introduced by commit 3ce04b4a9fdc30b6
> ("Removes OF_UNITTEST dependency on OF_DYNAMIC config symbol").
>
> If the test data is still present, kexec (kexec-tools 2.0.7 released 24
> November 2014, 1:2.0.7-5 in Debian) fails with:
>
> unrecoverable error: short read
> from"/proc/device-tree//testcase-data/large-property-PAGE_SIZEx8"
>
> Granted, this is a bug in kexec-tools, but I'm reporting it anyway, as it is
> a kernel regression with existing userspace.
>
> I believe this bug was fixed in kexec-tools by commit d1932cd592e2a6aa
> ("kexec/fs2dt: Use slurp_file_len to avoid partial read of files"), but I
> haven't tested the fix yet.

Is OF_UNITTEST enabled by default in Debian or this is a custom
kernel? Perhaps we should require a command line option to actually
populate the test data and run the tests?

We just need more tests to slow down the boot enough people will not
enable them by default. ;)

Rob

>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Andreas Schwab]

Peter Hurley  writes:

> I don't see this as a regression, but rather a misconfiguration.

It breaks booting on PowerMac.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller

[Scott Branden]

Hi Brian,


On 15-03-16 04:46 PM, Brian Norris wrote:

On Mon, Mar 16, 2015 at 04:40:13PM -0700, Scott Branden wrote:


On 15-03-16 04:37 PM, Brian Norris wrote:

On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote:
So, what's the standard? Company prefix? Long name? Commas? Hyphens?


The problem with devicetree binding is there is no standard for much
of anything.  Some others use the vendor prefix for all their
binding documentation.  We can try to do the same?


Ok, but we already have 3 versions for Broadcom. I can use 'brcm,' if
that helps...


Yes, it helps if we try standardizing on the brcm vendor prefix in
Documentation/devicetree/bindings/vendor-prefixes.txt.  If you sift
through the bindings directory you will find some of the other vendors
have done the same.

Also, of note.
In Documentation/devicetree/bindings/submitting-patches.txt
it states the Documentation should be the first patch in the series.
Perhaps this helps the devicetree maintainer in reviewing bindings?

Scott



Brian



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller

[Brian Norris]

On Mon, Mar 16, 2015 at 04:40:13PM -0700, Scott Branden wrote:
> 
> On 15-03-16 04:37 PM, Brian Norris wrote:
> >On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote:
> >>On 15-03-06 05:18 PM, Brian Norris wrote:
> >>>Signed-off-by: Brian Norris 
> >>>---
> >>>  .../devicetree/bindings/mtd/brcmstb_nand.txt   | 109 
> >>> +
> >>>  1 file changed, 109 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> >>>
> >>>diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt 
> >>>b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> >>>new file mode 100644
> >>>index ..933d44943cbb
> >>>--- /dev/null
> >>
> >>Could you change the binding document with the vendor prefix to
> >>match all the other drivers we have been submitting? ie.
> >>"brcm,brcmnand.txt"
> >
> >$ find Documentation/devicetree/ -name 'broadcom*'
> >Documentation/devicetree/bindings/net/broadcom-systemport.txt
> >Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt
> >Documentation/devicetree/bindings/net/broadcom-mdio-unimac.txt
> >Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
> >Documentation/devicetree/bindings/net/broadcom-sf2.txt
> >
> >$ find Documentation/devicetree/ -name 'brcm[^,]*'
> >Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
> >
> >$ find Documentation/devicetree/ -name 'brcm,*'
> >Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
> >Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
> >Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
> >Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
> >Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
> >Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
> >Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
> >Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
> >Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
> >Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
> >Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
> >Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method
> >Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
> >Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt
> >
> >$ find Documentation/devicetree/bindings -name '*.txt' | grep -v ','| wc -l
> >1227
> >$ find Documentation/devicetree/bindings -name '*.txt' | grep ','| wc -l
> >352
> >
> >So, what's the standard? Company prefix? Long name? Commas? Hyphens?
> 
> The problem with devicetree binding is there is no standard for much
> of anything.  Some others use the vendor prefix for all their
> binding documentation.  We can try to do the same?

Ok, but we already have 3 versions for Broadcom. I can use 'brcm,' if
that helps...

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] mtd: nand: add Broadcom NAND controller support

[Brian Norris]

(Your HTML mail will likely get blocked by a lot of filters)

Hi Anatol,

On Mon, Mar 16, 2015 at 04:24:20PM -0700, Anatol Pomazau wrote:
> Hi Brian
> 
> Thanks for the patch series. I am going to test it on a Broadcom dev board.
> 
> Do you plan to add a patch for bcm-cygnus.dtsi similar to what is done
> here https://github.com/Broadcom/cygnus-linux/commit/
> 1de02697829c3a2ce48a1bc29a8535e4961999ca
> 
> ?

Not yet. As I note below, this does not work as-is on Cygnus. I wanted
to get the initial code out there, as this already supports some chips.
There as still some additions necessary to get iProc/Cygnus and BCM53xxx
chips working (WIP).

The code you link to is a hacked version from Ray. His changes have not
been integrated yet.

> On Fri, Mar 6, 2015 at 5:18 PM, Brian Norris 
> wrote:
>  Hi,
> 
>  This adds (long in coming) support for the Broadcom BCM7xxx Set-Top
>  Box NAND
>  controller. This controller has been used in a variety of Broadcom
>  SoCs.
> 
>  There are a few more features I'd like add in the near future, mostly
>  to
>  support more SoCs, but this is the base set, which should only need
>  relatively
>  minor additions to support chips like BCM63138, BCM3384, and Cygnus/
>  iProc.
>  Particularly, we may need to straighten out some endianness issues
>  for the data
>  path on iProc, and interrupt enabling/acking on iProc, BCM63xxx,
>  BCM3xxx, and
>  others.

^^^ Note the previous 2 sentences.


>  TODO: add this to the DTS(I) files for BCM7445.
> 
>  Happy reviewing! (Speaking of which, I need to catch up on reviewing
>  everybody
>  else's MTD submissions...)
> 
>  Brian

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller

[Scott Branden]

On 15-03-16 04:37 PM, Brian Norris wrote:

On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote:

On 15-03-06 05:18 PM, Brian Norris wrote:

Signed-off-by: Brian Norris 
---
  .../devicetree/bindings/mtd/brcmstb_nand.txt   | 109 +
  1 file changed, 109 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt

diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt 
b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
new file mode 100644
index ..933d44943cbb
--- /dev/null


Could you change the binding document with the vendor prefix to
match all the other drivers we have been submitting? ie.
"brcm,brcmnand.txt"


$ find Documentation/devicetree/ -name 'broadcom*'
Documentation/devicetree/bindings/net/broadcom-systemport.txt
Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt
Documentation/devicetree/bindings/net/broadcom-mdio-unimac.txt
Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
Documentation/devicetree/bindings/net/broadcom-sf2.txt

$ find Documentation/devicetree/ -name 'brcm[^,]*'
Documentation/devicetree/bindings/arm/brcm-brcmstb.txt

$ find Documentation/devicetree/ -name 'brcm,*'
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method
Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt

$ find Documentation/devicetree/bindings -name '*.txt' | grep -v ','| wc -l
1227
$ find Documentation/devicetree/bindings -name '*.txt' | grep ','| wc -l
352

So, what's the standard? Company prefix? Long name? Commas? Hyphens?


The problem with devicetree binding is there is no standard for much of 
anything.  Some others use the vendor prefix for all their binding 
documentation.  We can try to do the same?




Brian



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller

[Brian Norris]

On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote:
> On 15-03-06 05:18 PM, Brian Norris wrote:
> >Signed-off-by: Brian Norris 
> >---
> >  .../devicetree/bindings/mtd/brcmstb_nand.txt   | 109 
> > +
> >  1 file changed, 109 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> >
> >diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt 
> >b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> >new file mode 100644
> >index ..933d44943cbb
> >--- /dev/null
> 
> Could you change the binding document with the vendor prefix to
> match all the other drivers we have been submitting? ie.
> "brcm,brcmnand.txt"

$ find Documentation/devicetree/ -name 'broadcom*'
Documentation/devicetree/bindings/net/broadcom-systemport.txt
Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt
Documentation/devicetree/bindings/net/broadcom-mdio-unimac.txt
Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
Documentation/devicetree/bindings/net/broadcom-sf2.txt

$ find Documentation/devicetree/ -name 'brcm[^,]*'
Documentation/devicetree/bindings/arm/brcm-brcmstb.txt

$ find Documentation/devicetree/ -name 'brcm,*'
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
Documentation/devicetree/bindings/rng/brcm,bcm2835.txt
Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method
Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt

$ find Documentation/devicetree/bindings -name '*.txt' | grep -v ','| wc -l
1227
$ find Documentation/devicetree/bindings -name '*.txt' | grep ','| wc -l
352

So, what's the standard? Company prefix? Long name? Commas? Hyphens?

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps

[Sakari Ailus]

On Mon, Mar 16, 2015 at 02:19:04AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote:
> > The syscon register isn't part of the ISP, use it through the syscom driver
> > regmap instead. The syscom block is considered to be from 343x on ISP
> > revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  arch/arm/boot/dts/omap3.dtsi|2 +-
> >  arch/arm/mach-omap2/devices.c   |   10 --
> >  drivers/media/platform/omap3isp/isp.c   |   19 +++
> >  drivers/media/platform/omap3isp/isp.h   |   19 +--
> >  drivers/media/platform/omap3isp/ispcsiphy.c |   20 +---
> 
> I've noticed another issue, you need a "select MFD_SYSCON" in Kconfig.

Thanks, fixed!

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am57xx-beagle-x15: Do not include the atl header

[Tony Lindgren]

* Peter Ujfalusi  [150226 05:46]:
> AM57xx does not have ATL block integrated.
> 
> Signed-off-by: Peter Ujfalusi 

Applying into omap-for-v4.1/dt thanks.

Tony

> ---
>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 6463f9ef2b54..c1d82e830a96 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -8,7 +8,6 @@
>  /dts-v1/;
>  
>  #include "dra74x.dtsi"
> -#include 
>  #include 
>  #include 
>  
> -- 
> 2.3.0
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller

[Scott Branden]

Hi Brian,


On 15-03-06 05:18 PM, Brian Norris wrote:

Signed-off-by: Brian Norris 
---
  .../devicetree/bindings/mtd/brcmstb_nand.txt   | 109 +
  1 file changed, 109 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt

diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt 
b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
new file mode 100644
index ..933d44943cbb
--- /dev/null


Could you change the binding document with the vendor prefix to match 
all the other drivers we have been submitting? ie. "brcm,brcmnand.txt"


Regards,
 Scott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v15 02/11] ARM: qcom: Add Subsystem Power Manager (SPM) driver

[Lina Iyer]

On Mon, Mar 16 2015 at 15:51 -0600, Stephen Boyd wrote:

On 03/09/15 08:16, Lina Iyer wrote:

+
+static int qcom_idle_enter(int cpu, unsigned long index)
+{
+   if (!per_cpu(qcom_idle_ops, cpu)[index])
+   return -EOPNOTSUPP;


Is this case still happening?


I think, I can remove it safely now.

+
+   return per_cpu(qcom_idle_ops, cpu)[index](cpu);
+}
+
+const struct of_device_id qcom_idle_state_match[] __initconst = {


static?


Ok


+   { .compatible = "qcom,idle-state-stby", .data = qcom_cpu_standby },
+   { .compatible = "qcom,idle-state-spc", .data = qcom_cpu_spc },
+   { },
+};
+
+static int __init qcom_cpuidle_init(struct device_node *cpu_node, int cpu)
+{
+   const struct of_device_id *match_id;
+   struct device_node *state_node;
+   int i;
+   int state_count = 0;
+   idle_fn idle_fns[CPUIDLE_STATE_MAX];
+   idle_fn *fns;
+   cpumask_t mask;
+   bool use_scm_power_down = false;
+
+   for (i = 0; ; i++) {
+   state_node = of_parse_phandle(cpu_node, "cpu-idle-states", i);
+   if (!state_node)
+   break;
+
+   if (!of_device_is_available(state_node))
+   continue;
+
+   if (i == CPUIDLE_STATE_MAX) {
+   pr_warn("%s: cpuidle states reached max possible\n",
+   __func__);
+   break;
+   }
+
+   match_id = of_match_node(qcom_idle_state_match, state_node);
+   if (!match_id)
+   return -ENODEV;
+
+   idle_fns[state_count] = match_id->data;
+
+   /* Check if any of the states allow power down */
+   if (match_id->data == qcom_cpu_spc)
+   use_scm_power_down = true;
+
+   state_count++;
+   }
+
+   if (!state_count) {
+   pr_warn("No idle ops founds for cpu %d\n", cpu);


Maybe pr_debug? It's not the end of the world that we don't have cpuidle.


Sure.


+   return -ENODEV;
+   }
+
+   fns = kcalloc(state_count, sizeof(*fns), GFP_KERNEL);
+   if (!fns)
+   return -ENOMEM;
+
+   for (i = 0; i < state_count; i++)
+   fns[i] = idle_fns[i];
+
+   if (use_scm_power_down) {
+   /* We have atlease one power down mode */


s/atlease/at least/


Thanks!


+   cpumask_clear(&mask);
+   cpumask_set_cpu(cpu, &mask);
+   qcom_scm_set_warm_boot_addr(cpu_resume, &mask);
+   }
+
+   per_cpu(qcom_idle_ops, cpu) = fns;
+
+   /*
+* Condition: cpuidle_driver_register() needs to happen before
+* cpuidle_register_device().
+* Check if the SPM probe has happened -
+* - If SPM probed successfully before arm_idle_init(), then defer
+*   the registration of cpuidle_device back to arm_idle_init()
+* - If the SPM probe happens in the future, then let the SPM probe
+*   register the cpuidle device, return -ENOSYS.
+*/
+   return per_cpu(cpu_spm_drv, cpu) ? 0 : -ENOSYS;
+}
+
+struct cpuidle_ops qcom_kpss_v1_cpuidle_ops __initdata = {
+   .name = "qcom,kpss-acc-v1",
+   .suspend = qcom_idle_enter,
+   .init = qcom_cpuidle_init,
+};
+
+struct cpuidle_ops qcom_kpss_v2_cpuidle_ops __initdata = {
+   .name = "qcom,kpss-acc-v2",
+   .suspend = qcom_idle_enter,
+   .init = qcom_cpuidle_init,
+};
+



This just looks weird because of the macro magic in Daniel's series. Any
reason we can't use the linker instead of doing preprocessor magic so
that it looks like these structures are actually used?


Hmm.. Will wait on Daniel's response to your other mail.


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 02:35 PM, Hans de Goede wrote:
> Hi,
> 
> On 16-03-15 19:23, Peter Hurley wrote:
>> On 03/16/2015 02:12 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 16-03-15 18:49, Peter Hurley wrote:
 Hi Hans,

 On 03/16/2015 12:31 PM, Hans de Goede wrote:
> Hi All,
>
> While updating my local working tree to 4.0-rc4 this morning I noticed 
> that I no longer
> get console / kernel messages output on the hdmi output of my ARM board / 
> on tty0
>
> This is caused by:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>
> Reverting this commit fixes this for me.
>
> What is happening here is that the "add_preferred_console("stdout-path", 
> 0, NULL);"
> happens before the tty0 registers stopping tty0 from becoming part of the 
> console list
> since there already is a preferred console at that time.
>
> This is an undesirable behavior change caused by the commit in question, 
> on boards
> where there is both video output, and a serial console configured through 
> stdout-path
> we want to have console output on both as we do not know which of the 2 
> will actually
> be hooked up by the user.

 I don't see this as a regression, but rather a misconfiguration.
>>>
>>> As said it is an undesirable behavior change, whether you want to call that 
>>> a regression
>>> or not is not all that interesting. Fixing it however is important, as e.g. 
>>> Fedora
>>> ARM images rely on this behavior, both "regular" arm as well as aarch64.
>>
>> What dts file is causing this problem?
>> Is it in mainline or distributed only in Fedora?
> 
> This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based 
> boards, currently
> the setting of stdout-path on these boards is done by (an unmodified) 
> upstream u-boot.

You forgot to mention my patch is not very likely to break anything
in the wild since _you_ upstreamed the dependency only 3 weeks ago [1].

And what "Fedora ARM images rely on this behavior"?

I don't appreciate the deception.

Regards,
Peter Hurley

[1] git log from u-boot repo

commit f3133962f469a8b6b9ba237ba670f0ca7c88a02e
Author: Hans de Goede 
Date:   Fri Feb 20 16:55:12 2015 +0100

sunxi: Set the /chosen/stdout-path fdt property for sunxi boards

While discussing with some people how to get the Linux kernel to do the
right thing wrt sending output to both the serial console and the
hdmi out / lcd screen when booting on ARM devices, Grant Likely pointed out
that there already is a solution for this.

All we need to do is set the /chosen/stdout-path fdt property, and if no
console= arguments were specified on the kernel commandline the kernel
will honor this and add this device as a console (next to the primary
video output on hdmi).

And u-boot already has support for setting this, all we need to do is
define OF_STDOUT_PATH and then everything will just work ootb, without
people needing to meddle with adding console= arguments in extlinux.conf .

Signed-off-by: Hans de Goede 
Acked-by: Ian Campbell 
Reviewed-by: Tom Rini 

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index f5efebb..0b4f0a0 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -210,6 +210,20 @@ extern int soft_i2c_gpio_scl;
 #define CONFIG_CONS_INDEX  1   /* UART0 */
 #endif
 
+#if CONFIG_CONS_INDEX == 1
+#ifdef CONFIG_MACH_SUN9I
+#define OF_STDOUT_PATH "/soc/serial@0700:115200"
+#else
+#define OF_STDOUT_PATH "/soc@01c0/serial@01c28000:115200"
+#endif
+#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
+#define OF_STDOUT_PATH "/soc@01c0/serial@01c28400:115200"
+#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
+#define OF_STDOUT_PATH "/soc@01c0/serial@01f02800:115200"
+#else
+#error Unsupported console port nr. Please fix stdout-path in sunxi-common.h.
+#endif
+
 /* GPIO */
 #define CONFIG_SUNXI_GPIO
 #define CONFIG_SPL_GPIO_SUPPORT


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: DRA7: Remove ti,timer-dsp and ti,timer-pwm properties

[Tony Lindgren]

* Suman Anna  [150316 10:21]:
> Remove the 'ti,timer-dsp' and 'ti,timer-pwm' properties from the timer
> nodes that still have them. This seems to be copied from OMAP5, on
> which only certain timers are capable of providing PWM functionality
> or be able to interrupt the DSP. All the GPTimers On DRA7 are capable
> of PWM and interrupting any core (due to the presence of Crossbar).
> 
> These properties were used by the driver to add capabilities to each
> timer, and support requesting timers by capability. In the DT world,
> we expect any users of timers to use phandles to the respective timer,
> and use the omap_dm_timer_request_by_node() API. The API to request
> using capabilities, omap_dm_timer_request_by_cap() API should be
> deprecated eventually.
> 
> Signed-off-by: Suman Anna 

Applying into omap-for-v4.1/dt thanks.

Tony

> ---
>  arch/arm/boot/dts/dra7.dtsi | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 5827fedafd43..318d9409e8cd 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -658,7 +658,6 @@
>   reg = <0x4882 0x80>;
>   interrupts = ;
>   ti,hwmods = "timer5";
> - ti,timer-dsp;
>   };
>  
>   timer6: timer@48822000 {
> @@ -666,8 +665,6 @@
>   reg = <0x48822000 0x80>;
>   interrupts = ;
>   ti,hwmods = "timer6";
> - ti,timer-dsp;
> - ti,timer-pwm;
>   };
>  
>   timer7: timer@48824000 {
> @@ -675,7 +672,6 @@
>   reg = <0x48824000 0x80>;
>   interrupts = ;
>   ti,hwmods = "timer7";
> - ti,timer-dsp;
>   };
>  
>   timer8: timer@48826000 {
> @@ -683,8 +679,6 @@
>   reg = <0x48826000 0x80>;
>   interrupts = ;
>   ti,hwmods = "timer8";
> - ti,timer-dsp;
> - ti,timer-pwm;
>   };
>  
>   timer9: timer@4803e000 {
> @@ -706,7 +700,6 @@
>   reg = <0x48088000 0x80>;
>   interrupts = ;
>   ti,hwmods = "timer11";
> - ti,timer-pwm;
>   };
>  
>   timer13: timer@48828000 {
> -- 
> 2.3.2
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

[Jeffrey Hugo]

On 2/27/2015 3:30 PM, Bjorn Andersson wrote:

Add binding documentation for the Qualcomm Hardware Mutex.

Signed-off-by: Bjorn Andersson 
---


Reviewed-by: Jeffrey Hugo 

--
Jeffrey Hugo
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/2] ARM: devicetree: Remove unused ti,codec property

[Tony Lindgren]

* Peter Ujfalusi  [150316 00:16]:
> On 03/13/2015 10:40 PM, Marek Belisko wrote:
> > ti,codec in not parsed in omap-twl4030 sound driver. It's not necessary
> > to specify this property in DT because ti,twl4030-audio which ti,codec
> > was pointing to by phandle is mfd driver and device for ASoC ic created w/o
> > any DT property (codec name is hardcoded in ASoC driver).
> > 
> > Please see reply [1] from Peter Ujfalusi.
> 
> All:
> Acked-by: Peter Ujfalusi 

Applying both into omap-for-v4.1/dt thanks.

Tony 
 
> > Changes from v1:
> > - keep ti,codec property in Documentation as optional that the
> > existing dtbs do not become noncompliant after the change
> > 
> > [1]: http://comments.gmane.org/gmane.linux.ports.arm.omap/124273
> > 
> > Marek Belisko (2):
> >   ARM: dts: omap3: Remove all references to ti,codec property
> >   Documentation: omap-twl4030: Move ti,codec property to optional
> > 
> >  Documentation/devicetree/bindings/sound/omap-twl4030.txt | 3 +--
> >  arch/arm/boot/dts/omap3-beagle-xm.dts| 1 -
> >  arch/arm/boot/dts/omap3-beagle.dts   | 1 -
> >  arch/arm/boot/dts/omap3-cm-t3x30.dtsi| 1 -
> >  arch/arm/boot/dts/omap3-devkit8000.dts   | 1 -
> >  arch/arm/boot/dts/omap3-gta04.dtsi   | 1 -
> >  arch/arm/boot/dts/omap3-igep.dtsi| 1 -
> >  arch/arm/boot/dts/omap3-lilly-a83x.dtsi  | 1 -
> >  arch/arm/boot/dts/omap3-overo-base.dtsi  | 1 -
> >  arch/arm/boot/dts/omap3-tao3530.dtsi | 1 -
> >  10 files changed, 1 insertion(+), 11 deletions(-)
> > 
> 
> 
> -- 
> Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: am437x-gp-evm: add DT nodes for ov2659 sensor

[Tony Lindgren]

* Lad Prabhakar  [150312 16:38]:
> From: "Lad, Prabhakar" 
> 
> this patch does the following:
> 1: adds DT node for fixed oscillator.
> 2: adds DT node entries for ov2659 sensor
> 3: adds remote-endpoint entry for VPFE.
> 
> Signed-off-by: Lad, Prabhakar 

Applying into omap-for-v4.1/dt thanks.

Tony

> ---
>  Note this patch depends on
>  https://patchwork.kernel.org/patch/6000161/
>  
>  arch/arm/boot/dts/am437x-gp-evm.dts | 42 
> +++--
>  1 file changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index f84d971..195f452 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -106,6 +106,14 @@
>   };
>   };
>   };
> +
> + /* fixed 12MHz oscillator */
> + refclk: oscillator {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <1200>;
> + };
> +
>  };
>  
>  &am43xx_pinmux {
> @@ -404,6 +412,21 @@
>   regulator-always-on;
>   };
>   };
> +
> + ov2659@30 {
> + compatible = "ovti,ov2659";
> + reg = <0x30>;
> +
> + clocks = <&refclk 0>;
> + clock-names = "xvclk";
> +
> + port {
> + ov2659_0: endpoint {
> + remote-endpoint = <&vpfe1_ep>;
> + link-frequencies = /bits/ 64 <7000>;
> + };
> + };
> + };
>  };
>  
>  &i2c1 {
> @@ -423,6 +446,21 @@
>   touchscreen-size-x = <1024>;
>   touchscreen-size-y = <600>;
>   };
> +
> + ov2659@30 {
> + compatible = "ovti,ov2659";
> + reg = <0x30>;
> +
> + clocks = <&refclk 0>;
> + clock-names = "xvclk";
> +
> + port {
> + ov2659_1: endpoint {
> + remote-endpoint = <&vpfe0_ep>;
> + link-frequencies = /bits/ 64 <7000>;
> + };
> + };
> + };
>  };
>  
>  &epwmss0 {
> @@ -626,7 +664,7 @@
>  
>   port {
>   vpfe0_ep: endpoint {
> - /* remote-endpoint = <&sensor>; add once we have it */
> + remote-endpoint = <&ov2659_1>;
>   ti,am437x-vpfe-interface = <0>;
>   bus-width = <8>;
>   hsync-active = <0>;
> @@ -643,7 +681,7 @@
>  
>   port {
>   vpfe1_ep: endpoint {
> - /* remote-endpoint = <&sensor>; add once we have it */
> + remote-endpoint = <&ov2659_0>;
>   ti,am437x-vpfe-interface = <0>;
>   bus-width = <8>;
>   hsync-active = <0>;
> -- 
> 2.1.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] serial: omap_serial: document missing properties and add an example

[Tony Lindgren]

* Matt Porter  [150306 07:16]:
> The omap_serial.txt binding documentation lacks a number of properties
> that are used in DTS files for platforms incorporating this peripheral.
> Fix this by documenting the missing required and optional fields and
> add an example.
> 
> Signed-off-by: Matt Porter 

Applying the original version as they seem to be the same.

Regards,

Tony

> ---
>  .../devicetree/bindings/serial/omap_serial.txt   | 20 
> 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
> b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 342eedd..54c2a15 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -4,7 +4,27 @@ Required properties:
>  - compatible : should be "ti,omap2-uart" for OMAP2 controllers
>  - compatible : should be "ti,omap3-uart" for OMAP3 controllers
>  - compatible : should be "ti,omap4-uart" for OMAP4 controllers
> +- reg : address and length of the register space
> +- interrupts or interrupts-extended : Should contain the uart interrupt
> +  specifier or both the interrupt
> +  controller phandle and interrupt
> +  specifier.
>  - ti,hwmods : Must be "uart", n being the instance number (1-based)
>  
>  Optional properties:
>  - clock-frequency : frequency of the clock input to the UART
> +- dmas : DMA specifier, consisting of a phandle to the DMA controller
> + node and a DMA channel number.
> +- dma-names : "rx" for receive channel, "tx" for transmit channel.
> +
> +Example:
> +
> +uart4: serial@49042000 {
> +compatible = "ti,omap3-uart";
> +reg = <0x49042000 0x400>;
> +interrupts = <80>;
> +dmas = <&sdma 81 &sdma 82>;
> +dma-names = "tx", "rx";
> +ti,hwmods = "uart4";
> +clock-frequency = <4800>;
> +};
> -- 
> 1.8.4
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap3-beagle: Add NAND device

[Tony Lindgren]

* Roger Quadros  [150306 07:10]:
> The beagle board contains a 16-bit NAND device connected to
> chip select 0 of the GPMC controller.
> 
> Signed-off-by: Roger Quadros 

Applying into omap-for-v4.1/dt thanks.

Tony

> ---
>  arch/arm/boot/dts/omap3-beagle.dts | 52 
> ++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
> b/arch/arm/boot/dts/omap3-beagle.dts
> index c792391..bf28502 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -379,3 +379,55 @@
>   };
>   };
>  };
> +
> +&gpmc {
> + status = "ok";
> + ranges = <0 0 0x3000 0x100>;/* CS0 space, 16MB */
> +
> + /* Chip select 0 */
> + nand@0,0 {
> + reg = <0 0 4>;  /* NAND I/O window, 4 bytes */
> + interrupts = <20>;
> + ti,nand-ecc-opt = "ham1";
> + nand-bus-width = <16>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + gpmc,device-width = <2>;
> + gpmc,cs-on-ns = <0>;
> + gpmc,cs-rd-off-ns = <36>;
> + gpmc,cs-wr-off-ns = <36>;
> + gpmc,adv-on-ns = <6>;
> + gpmc,adv-rd-off-ns = <24>;
> + gpmc,adv-wr-off-ns = <36>;
> + gpmc,oe-on-ns = <6>;
> + gpmc,oe-off-ns = <48>;
> + gpmc,we-on-ns = <6>;
> + gpmc,we-off-ns = <30>;
> + gpmc,rd-cycle-ns = <72>;
> + gpmc,wr-cycle-ns = <72>;
> + gpmc,access-ns = <54>;
> + gpmc,wr-access-ns = <30>;
> +
> + partition@0 {
> + label = "X-Loader";
> + reg = <0 0x8>;
> + };
> + partition@8 {
> + label = "U-Boot";
> + reg = <0x8 0x1e>;
> + };
> + partition@1c {
> + label = "U-Boot Env";
> + reg = <0x26 0x2>;
> + };
> + partition@28 {
> + label = "Kernel";
> + reg = <0x28 0x40>;
> + };
> + partition@78 {
> + label = "Filesystem";
> + reg = <0x68 0xf98>;
> + };
> + };
> +};
> -- 
> 2.1.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] ARM: dts: AM4372: update hdq compatible property

[Tony Lindgren]

* Vignesh R  [150302 02:53]:
> This patch updates hdq node compatible property to "ti,am4372-hdq".
> 
> Signed-off-by: Vignesh R 

Looks like this is safe to apply even with the driver changes pending
as the driver is currently only parsing ti,omap3-1w property.
So applying this patch into omap-for-v4.1/dt thanks.

Tony

> ---
>  arch/arm/boot/dts/am4372.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 1943fc333e7c..ae0e8c15a6df 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -884,7 +884,7 @@
>   };
>  
>   hdq: hdq@48347000 {
> - compatible = "ti,am43xx-hdq";
> + compatible = "ti,am4372-hdq";
>   reg = <0x48347000 0x1000>;
>   interrupts = ;
>   clocks = <&func_12m_clk>;
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/3] ARM: dts: add openpandora device support

[Tony Lindgren]

* Marek Belisko  [150227 13:30]:
> changes from v2:
> - fix missing PIN_INPUT for penirq node
> - added Reviewed-by and Tested-by
> 
> changes from v1:
> - add new boards to makefile in patch 2,3 (don't add them
> in separate commit together), fix gpmc issues (reported by Tony Lindgren)
> 
> - fix various issues reported by Grazvydas Ignotas
> (drop internal pullups from pinmux as external are in place,
> fix gpio buttons active state ...)
> 
> This series of patches adds initial device tree support for the
> OpenPandora. The most important parts are working (display, keyboard,
> touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons).
> Not yet supported are: usb host port, nubs, wifi, bluetooth, audio.
> 
> First patch add common dtsi file which is then used in 600mhz and 1ghz
> variants of openpandora which support is added in patches 2 and 3.
> 
> H. Nikolaus Schaller (3):
>   ARM: dts: omap3-pandora: add common device tree
>   ARM: dts: omap3-pandora: add OMAP3530 600 MHz version
>   ARM: dts: omap3-pandora: add DM3730 1 GHz version

Thanks everybody for doing this, applying into omap-for-v4.1/dt.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] ARM: cpuidle: Add a cpuidle ops structure to be used for DT

[Stephen Boyd]

On 03/03/15 04:29, Daniel Lezcano wrote:
>
> The code is optimized to use the __init section intensively in order to reduce
> the memory footprint after the driver is initialized and unify the function
> names with ARM64.
>
> In order to prevent multiple declarations and the specific cpuidle ops to be
> spread across the different headers, a mechanism, similar to the cgroup 
> subsys,
> has been introduced.
>
> A new platform willing to add its cpuidle ops must add an entry in the file
> cpuidle_ops.h in the current form:
>
>  #if IS_ENABLED(CONFIG_ARM_FOO_CPUIDLE)
>  CPUIDLE_OPS(foo)
>  #endif
>
> ... and use the variable name in the specific low level code:
>
> struct cpuidle_ops foo_cpuidle_ops;
>
> The CPUIDLE_OPS macro will be processed in different way in the cpuidle.c 
> file,
> thus allowing to keep untouched the arm cpuidle core code in the future when
> a new platform is added.
[...]
> diff --git a/arch/arm/include/asm/cpuidle_ops.h 
> b/arch/arm/include/asm/cpuidle_ops.h
> new file mode 100644
> index 000..be0a612
> --- /dev/null
> +++ b/arch/arm/include/asm/cpuidle_ops.h
> @@ -0,0 +1,3 @@
> +/*
> + * List of cpuidle operations
> + */
> diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
> index 45969f8..25e9789c 100644
> --- a/arch/arm/kernel/cpuidle.c
> +++ b/arch/arm/kernel/cpuidle.c
> @@ -10,8 +10,29 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  
> +#define CPUIDLE_OPS(__x) extern struct cpuidle_ops __x ## _cpuidle_ops;
> +#include 
> +#undef CPUIDLE_OPS
> +
> +#define CPUIDLE_OPS(__x) __x ## _cpuidle_ops_id,
> +enum cpuidle_ops_id {
> +#include 
> +CPUIDLE_OPS_COUNT,
> +};
> +#undef CPUIDLE_OPS
> +
> +#define CPUIDLE_OPS(__x) [__x ## _cpuidle_ops_id ] = &__x ## _cpuidle_ops,
> +static struct cpuidle_ops *supported_cpuidle_ops[] __initconst = {
> +#include 
> +};
> +#undef CPUIDLE_OPS
> +
> +static struct cpuidle_ops cpuidle_ops[NR_CPUS];

Is there any reason why we aren't putting these structures into a linker
section like we do for the smp operations structures?

The nice thing about using the linker is it makes it clearer at the
location where we define the structure that it's actually used by
something. Right now the structures are defined non-static in a file and
then we have to know that a CPUIDLE_OPS() define has been made in
another architecture specific asm header file so that this macro magic
works. The commit text says something about multiple declarations and
ops spread across header files, which shouldn't apply if we're using the
linker to find these ops and merge them into an array we can iterate over.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: dra7xx-clocks: Add gate clock for CLKOUT2

[Tony Lindgren]

* Peter Ujfalusi  [150226 05:43]:
> To be able to control the gate for the clkout2 clock output.
> 
> Signed-off-by: Peter Ujfalusi 
> Signed-off-by: Jyri Sarha 

Applying into omap-for-v4.1/dt thanks.

Tony

> ---
>  arch/arm/boot/dts/dra7xx-clocks.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
> b/arch/arm/boot/dts/dra7xx-clocks.dtsi
> index 4bdcbd61ce47..2a9994f73974 100644
> --- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
> @@ -1421,6 +1421,14 @@
>   ti,dividers = <1>, <8>;
>   };
>  
> + clkout2_clk: clkout2_clk {
> + #clock-cells = <0>;
> + compatible = "ti,gate-clock";
> + clocks = <&clkoutmux2_clk_mux>;
> + ti,bit-shift = <8>;
> + reg = <0x06b0>;
> + };
> +
>   l3init_960m_gfclk: l3init_960m_gfclk {
>   #clock-cells = <0>;
>   compatible = "ti,gate-clock";
> -- 
> 2.3.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: DT: omap_serial: document missing properties and add an example

[Tony Lindgren]

* Matt Porter  [150226 07:42]:
> The omap_serial.txt binding documentation lacks a number of properties
> that are used in DTS files for platforms incorporating this peripheral.
> Fix this by documenting the missing required and optional fields and
> add an example.
> 
> Signed-off-by: Matt Porter 

I'll apply this into omap-for-v4.1/dt thanks.

Regards,

Tony

> ---
>  .../devicetree/bindings/serial/omap_serial.txt   | 20 
> 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
> b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 342eedd..54c2a15 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -4,7 +4,27 @@ Required properties:
>  - compatible : should be "ti,omap2-uart" for OMAP2 controllers
>  - compatible : should be "ti,omap3-uart" for OMAP3 controllers
>  - compatible : should be "ti,omap4-uart" for OMAP4 controllers
> +- reg : address and length of the register space
> +- interrupts or interrupts-extended : Should contain the uart interrupt
> +  specifier or both the interrupt
> +  controller phandle and interrupt
> +  specifier.
>  - ti,hwmods : Must be "uart", n being the instance number (1-based)
>  
>  Optional properties:
>  - clock-frequency : frequency of the clock input to the UART
> +- dmas : DMA specifier, consisting of a phandle to the DMA controller
> + node and a DMA channel number.
> +- dma-names : "rx" for receive channel, "tx" for transmit channel.
> +
> +Example:
> +
> +uart4: serial@49042000 {
> +compatible = "ti,omap3-uart";
> +reg = <0x49042000 0x400>;
> +interrupts = <80>;
> +dmas = <&sdma 81 &sdma 82>;
> +dma-names = "tx", "rx";
> +ti,hwmods = "uart4";
> +clock-frequency = <4800>;
> +};
> -- 
> 1.8.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] dts: cubox: Map gpio-keys to gpio3 8

[George Joseph]

The Cubox has a recessed button between the HDMI and RJ-45 connectors
that wasn't mapped in the device tree, so I've mapped it to gpio-keys
BTN_0.

Signed-off-by: George Joseph 
Tested-by: George Joseph 
---
 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi 
b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index 6a524ca..de6e3a8 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -3,6 +3,8 @@
  */
 #include "imx6qdl-microsom.dtsi"
 #include "imx6qdl-microsom-ar8035.dtsi"
+#include 
+#include 
 
 / {
ir_recv: ir-receiver {
@@ -66,6 +68,18 @@
spdif-controller = <&spdif>;
spdif-out;
};
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-0 = <&pinctrl_gpio_key>;
+   pinctrl-names = "default";
+
+   button_0 {
+   label = "Button 0";
+   gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
 };
 
 &hdmi {
@@ -170,6 +184,12 @@
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
>;
};
+
+   pinctrl_gpio_key: gpio-key {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_DA8__GPIO3_IO08  0x17059
+   >;
+   };
};
 };
 
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v15 02/11] ARM: qcom: Add Subsystem Power Manager (SPM) driver

[Stephen Boyd]

On 03/09/15 08:16, Lina Iyer wrote:
> +
> +static int qcom_idle_enter(int cpu, unsigned long index)
> +{
> + if (!per_cpu(qcom_idle_ops, cpu)[index])
> + return -EOPNOTSUPP;

Is this case still happening?

> +
> + return per_cpu(qcom_idle_ops, cpu)[index](cpu);
> +}
> +
> +const struct of_device_id qcom_idle_state_match[] __initconst = {

static?

> + { .compatible = "qcom,idle-state-stby", .data = qcom_cpu_standby },
> + { .compatible = "qcom,idle-state-spc", .data = qcom_cpu_spc },
> + { },
> +};
> +
> +static int __init qcom_cpuidle_init(struct device_node *cpu_node, int cpu)
> +{
> + const struct of_device_id *match_id;
> + struct device_node *state_node;
> + int i;
> + int state_count = 0;
> + idle_fn idle_fns[CPUIDLE_STATE_MAX];
> + idle_fn *fns;
> + cpumask_t mask;
> + bool use_scm_power_down = false;
> +
> + for (i = 0; ; i++) {
> + state_node = of_parse_phandle(cpu_node, "cpu-idle-states", i);
> + if (!state_node)
> + break;
> +
> + if (!of_device_is_available(state_node))
> + continue;
> +
> + if (i == CPUIDLE_STATE_MAX) {
> + pr_warn("%s: cpuidle states reached max possible\n",
> + __func__);
> + break;
> + }
> +
> + match_id = of_match_node(qcom_idle_state_match, state_node);
> + if (!match_id)
> + return -ENODEV;
> +
> + idle_fns[state_count] = match_id->data;
> +
> + /* Check if any of the states allow power down */
> + if (match_id->data == qcom_cpu_spc)
> + use_scm_power_down = true;
> +
> + state_count++;
> + }
> +
> + if (!state_count) {
> + pr_warn("No idle ops founds for cpu %d\n", cpu);

Maybe pr_debug? It's not the end of the world that we don't have cpuidle.

> + return -ENODEV;
> + }
> +
> + fns = kcalloc(state_count, sizeof(*fns), GFP_KERNEL);
> + if (!fns)
> + return -ENOMEM;
> +
> + for (i = 0; i < state_count; i++)
> + fns[i] = idle_fns[i];
> +
> + if (use_scm_power_down) {
> + /* We have atlease one power down mode */

s/atlease/at least/

> + cpumask_clear(&mask);
> + cpumask_set_cpu(cpu, &mask);
> + qcom_scm_set_warm_boot_addr(cpu_resume, &mask);
> + }
> +
> + per_cpu(qcom_idle_ops, cpu) = fns;
> +
> + /*
> +  * Condition: cpuidle_driver_register() needs to happen before
> +  * cpuidle_register_device().
> +  * Check if the SPM probe has happened -
> +  * - If SPM probed successfully before arm_idle_init(), then defer
> +  *   the registration of cpuidle_device back to arm_idle_init()
> +  * - If the SPM probe happens in the future, then let the SPM probe
> +  *   register the cpuidle device, return -ENOSYS.
> +  */
> + return per_cpu(cpu_spm_drv, cpu) ? 0 : -ENOSYS;
> +}
> +
> +struct cpuidle_ops qcom_kpss_v1_cpuidle_ops __initdata = {
> + .name = "qcom,kpss-acc-v1",
> + .suspend = qcom_idle_enter,
> + .init = qcom_cpuidle_init,
> +};
> +
> +struct cpuidle_ops qcom_kpss_v2_cpuidle_ops __initdata = {
> + .name = "qcom,kpss-acc-v2",
> + .suspend = qcom_idle_enter,
> + .init = qcom_cpuidle_init,
> +};
> +
>

This just looks weird because of the macro magic in Daniel's series. Any
reason we can't use the linker instead of doing preprocessor magic so
that it looks like these structures are actually used?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/10] ARM: dts: omap3: Add missing dmas for crypto

[Tony Lindgren]

* Pavel Machek  [150228 08:49]:
> On Thu 2015-02-26 14:49:56, Pali Rohár wrote:
> > This patch adds missing dma DTS definitions for omap aes and sham drivers.
> > Without it kernel drivers do not work.
> > 
> > Signed-off-by: Pali Rohár 
> 
> Acked-by: PavelMachek 

Applying this into omap-for-v4.0/fixes to remove the regression
for legacy vs DT based booting for GP omap3 boards.

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 5/5] MIPS: pistachio: Add an initial defconfig

[Andrew Bresticker]

From: Govindraj Raja 

Add a defconfig for Pistachio which enables drivers for all the
currently supported peripherals on the SoC.

Signed-off-by: Govindraj Raja 
Signed-off-by: Andrew Bresticker 
---
No changes from v1/v2.
---
 arch/mips/configs/pistachio_defconfig | 336 ++
 1 file changed, 336 insertions(+)
 create mode 100644 arch/mips/configs/pistachio_defconfig

diff --git a/arch/mips/configs/pistachio_defconfig 
b/arch/mips/configs/pistachio_defconfig
new file mode 100644
index 000..f22e92e
--- /dev/null
+++ b/arch/mips/configs/pistachio_defconfig
@@ -0,0 +1,336 @@
+CONFIG_MACH_PISTACHIO=y
+CONFIG_MIPS_MT_SMP=y
+CONFIG_MIPS_CPS=y
+# CONFIG_COMPACTION is not set
+CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
+CONFIG_ZSMALLOC=y
+CONFIG_NR_CPUS=4
+CONFIG_PREEMPT_VOLUNTARY=y
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_DEFAULT_HOSTNAME="localhost"
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IKCONFIG=m
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_NAMESPACES=y
+CONFIG_USER_NS=y
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_EMBEDDED=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_PROFILING=y
+CONFIG_CC_STACKPROTECTOR_STRONG=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_PM_DEBUG=y
+CONFIG_PM_ADVANCED_DEBUG=y
+CONFIG_CPU_IDLE=y
+# CONFIG_MIPS_CPS_CPUIDLE is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_NET_KEY=m
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_SYN_COOKIES=y
+CONFIG_INET_AH=m
+CONFIG_INET_ESP=m
+CONFIG_INET_IPCOMP=m
+CONFIG_INET_XFRM_MODE_TRANSPORT=m
+CONFIG_INET_XFRM_MODE_TUNNEL=m
+CONFIG_INET_XFRM_MODE_BEET=m
+# CONFIG_INET_DIAG is not set
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+CONFIG_TCP_CONG_LP=m
+CONFIG_TCP_MD5SIG=y
+CONFIG_IPV6=y
+CONFIG_INET6_AH=m
+CONFIG_INET6_ESP=m
+CONFIG_INET6_XFRM_MODE_TRANSPORT=m
+CONFIG_INET6_XFRM_MODE_TUNNEL=m
+CONFIG_INET6_XFRM_MODE_BEET=m
+CONFIG_IPV6_SIT=m
+CONFIG_NETWORK_SECMARK=y
+CONFIG_NETFILTER=y
+# CONFIG_BRIDGE_NETFILTER is not set
+CONFIG_NF_CONNTRACK=y
+CONFIG_NF_CT_NETLINK=y
+CONFIG_NETFILTER_XT_MARK=m
+CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
+CONFIG_NETFILTER_XT_TARGET_DSCP=y
+CONFIG_NETFILTER_XT_TARGET_NFLOG=y
+CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
+CONFIG_NETFILTER_XT_TARGET_SECMARK=y
+CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
+CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
+CONFIG_NETFILTER_XT_MATCH_DSCP=y
+CONFIG_NETFILTER_XT_MATCH_POLICY=y
+CONFIG_NETFILTER_XT_MATCH_STATE=y
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_NF_NAT_IPV4=m
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_IP_NF_FILTER=y
+CONFIG_IP_NF_TARGET_REJECT=y
+CONFIG_IP_NF_MANGLE=y
+CONFIG_NF_CONNTRACK_IPV6=m
+CONFIG_NF_NAT_IPV6=m
+CONFIG_IP6_NF_IPTABLES=m
+CONFIG_IP6_NF_MATCH_IPV6HEADER=m
+CONFIG_IP6_NF_FILTER=m
+CONFIG_IP6_NF_TARGET_REJECT=m
+CONFIG_IP6_NF_MANGLE=m
+CONFIG_BRIDGE=m
+CONFIG_VLAN_8021Q=m
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_HTB=m
+CONFIG_NET_SCH_CODEL=m
+CONFIG_NET_SCH_FQ_CODEL=m
+CONFIG_NET_CLS_U32=m
+CONFIG_CLS_U32_MARK=y
+CONFIG_BT=m
+CONFIG_BT_RFCOMM=m
+CONFIG_BT_HCIBTUSB=m
+CONFIG_BT_HCIBFUSB=m
+CONFIG_BT_HCIVHCI=m
+CONFIG_CFG80211=m
+CONFIG_NL80211_TESTMODE=y
+CONFIG_CFG80211_DEBUGFS=y
+CONFIG_CFG80211_WEXT=y
+CONFIG_MAC80211=m
+CONFIG_MAC80211_LEDS=y
+CONFIG_MAC80211_DEBUGFS=y
+CONFIG_MAC80211_DEBUG_MENU=y
+CONFIG_MAC80211_VERBOSE_DEBUG=y
+CONFIG_RFKILL=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_DEBUG_DEVRES=y
+CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_BLOCK=y
+CONFIG_ZRAM=m
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=m
+CONFIG_SCSI_SPI_ATTRS=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_DM=y
+CONFIG_DM_CRYPT=y
+CONFIG_DM_VERITY=y
+CONFIG_NETDEVICES=y
+CONFIG_TUN=m
+CONFIG_VETH=m
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+CONFIG_STMMAC_ETH=y
+# CONFIG_NET_VENDOR_VIA is not set
+CONFIG_PPP=m
+CONFIG_PPP_ASYNC=m
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+CONFIG_USB_RTL8152=m
+CONFIG_USB_NET_DM9601=m
+CONFIG_USB_NET_SMSC75XX=m
+CONFIG_USB_NET_SMSC95XX=m
+CONFIG_USB_NET_MCS7830=m
+# CONFIG_USB_NET_CDC_SUBSET is not set
+# CONFIG_USB_NET_ZAURUS is not set
+CONFIG_LIBERTAS_THINFIRM=m
+CONFIG_USB_NET_RNDIS_WLAN=m
+CONFIG_MAC80211_HWSIM=m
+CONFIG_HOSTAP=m
+CONFIG_HOSTAP_FIRMWAR

[PATCH V3 3/5] MIPS: Document Pistachio boot protocol and device-tree bindings

[Andrew Bresticker]

The Pistachio SoC boots only with device-tree.  Document the required
properties and nodes as well as the boot protocol between the bootlaoder
and the kernel.

Signed-off-by: Andrew Bresticker 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
---
No changes from v2.
Changes from v1:
 - switched to MIPS UHI hand-off protocol
---
 .../devicetree/bindings/mips/img/pistachio.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt

diff --git a/Documentation/devicetree/bindings/mips/img/pistachio.txt 
b/Documentation/devicetree/bindings/mips/img/pistachio.txt
new file mode 100644
index 000..a736d88
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/img/pistachio.txt
@@ -0,0 +1,42 @@
+Imagination Pistachio SoC
+=
+
+Required properties:
+
+ - compatible: Must include "img,pistachio".
+
+CPU nodes:
+--
+A "cpus" node is required.  Required properties:
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+A CPU sub-node is also required for at least CPU 0.  Since the topology may
+be probed via CPS, it is not necessary to specify secondary CPUs.  Required
+propertis:
+ - device_type: Must be "cpu".
+ - compatible: Must be "mti,interaptiv".
+ - reg: CPU number.
+ - clocks: Must include the CPU clock.  See ../../clock/clock-bindings.txt for
+   details on clock bindings.
+Example:
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "mti,interaptiv";
+   reg = <0>;
+   clocks = <&clk_core CLK_MIPS>;
+   };
+   };
+
+
+Boot protocol:
+--
+In accordance with the MIPS UHI specification[1], the bootloader must pass the
+following arguments to the kernel:
+ - $a0: -2.
+ - $a1: KSEG0 address of the flattened device-tree blob.
+
+[1] http://prplfoundation.org/wiki/MIPS_documentation
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 2/5] MIPS: Allow platforms to specify the decompressor load address

[Andrew Bresticker]

Platforms which use raw zboot images may need to link the image at
a fixed address if there is no other way to communicate the load
address to the bootloader.  Allow the per-platform Kbuild files
to specify an optional zboot image load address (zload-y) and fall
back to calc_vmlinuz_load_addr if unset.

Signed-off-by: Andrew Bresticker 
Cc: Lars-Peter Clausen 
---
No changes from v1/v2.
---
 arch/mips/boot/compressed/Makefile | 6 --
 arch/mips/jz4740/Platform  | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/compressed/Makefile 
b/arch/mips/boot/compressed/Makefile
index 61af6b6..82d0b13 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -12,6 +12,8 @@
 # Author: Wu Zhangjin 
 #
 
+include $(srctree)/arch/mips/Kbuild.platforms
+
 # set the default size of the mallocing area for decompressing
 BOOT_HEAP_SIZE := 0x40
 
@@ -66,8 +68,8 @@ $(obj)/piggy.o: $(obj)/dummy.o $(obj)/vmlinux.bin.z FORCE
 # Calculate the load address of the compressed kernel image
 hostprogs-y := calc_vmlinuz_load_addr
 
-ifeq ($(CONFIG_MACH_JZ4740),y)
-VMLINUZ_LOAD_ADDRESS := 0x8060
+ifneq ($(zload-y),)
+VMLINUZ_LOAD_ADDRESS := $(zload-y)
 else
 VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
$(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
diff --git a/arch/mips/jz4740/Platform b/arch/mips/jz4740/Platform
index ba91be9..c41d300 100644
--- a/arch/mips/jz4740/Platform
+++ b/arch/mips/jz4740/Platform
@@ -1,3 +1,4 @@
 platform-$(CONFIG_MACH_JZ4740) += jz4740/
 cflags-$(CONFIG_MACH_JZ4740)   += 
-I$(srctree)/arch/mips/include/asm/mach-jz4740
 load-$(CONFIG_MACH_JZ4740) += 0x8001
+zload-$(CONFIG_MACH_JZ4740)+= 0x8060
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 1/5] MIPS: Create a common

[Andrew Bresticker]

From: Kevin Cernekee 

11 platforms require at least one of these workarounds to be enabled; 22
platforms do not.  In the latter case we can fall back to a generic version.

Note that this also deletes an orphaned reference to RM9000_CDEX_SMP_WAR.

Suggested-by: Arnd Bergmann 
Signed-off-by: Kevin Cernekee 
Signed-off-by: Andrew Bresticker 
Reviewed-by: James Hogan 
---
No changes from v1/v2.
Changes from Kevin's v6:
 - Left cavium-octeon's war.h in-tact
---
 arch/mips/include/asm/mach-ar7/war.h   | 24 
 arch/mips/include/asm/mach-ath25/war.h | 25 -
 arch/mips/include/asm/mach-ath79/war.h | 24 
 arch/mips/include/asm/mach-au1x00/war.h| 24 
 arch/mips/include/asm/mach-bcm3384/war.h   | 24 
 arch/mips/include/asm/mach-bcm47xx/war.h   | 24 
 arch/mips/include/asm/mach-bcm63xx/war.h   | 24 
 arch/mips/include/asm/mach-cobalt/war.h| 24 
 arch/mips/include/asm/mach-dec/war.h   | 24 
 arch/mips/include/asm/mach-emma2rh/war.h   | 24 
 arch/mips/include/asm/mach-generic/war.h   | 24 
 arch/mips/include/asm/mach-jazz/war.h  | 24 
 arch/mips/include/asm/mach-jz4740/war.h| 24 
 arch/mips/include/asm/mach-lantiq/war.h| 23 ---
 arch/mips/include/asm/mach-lasat/war.h | 24 
 arch/mips/include/asm/mach-loongson/war.h  | 24 
 arch/mips/include/asm/mach-loongson1/war.h | 24 
 arch/mips/include/asm/mach-netlogic/war.h  | 25 -
 arch/mips/include/asm/mach-paravirt/war.h  | 25 -
 arch/mips/include/asm/mach-pnx833x/war.h   | 24 
 arch/mips/include/asm/mach-ralink/war.h| 24 
 arch/mips/include/asm/mach-tx39xx/war.h| 24 
 arch/mips/include/asm/mach-vr41xx/war.h| 24 
 23 files changed, 24 insertions(+), 530 deletions(-)
 delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
 delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
 delete mode 100644 arch/mips/include/asm/mach-dec/war.h
 delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
 create mode 100644 arch/mips/include/asm/mach-generic/war.h
 delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
 delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
 delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
 delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
 delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
 delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
 delete mode 100644 arch/mips/include/asm/mach-pnx833x/war.h
 delete mode 100644 arch/mips/include/asm/mach-ralink/war.h
 delete mode 100644 arch/mips/include/asm/mach-tx39xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-vr41xx/war.h

diff --git a/arch/mips/include/asm/mach-ar7/war.h 
b/arch/mips/include/asm/mach-ar7/war.h
deleted file mode 100644
index 99071e5..000
--- a/arch/mips/include/asm/mach-ar7/war.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2002, 2004, 2007 by Ralf Baechle 
- */
-#ifndef __ASM_MIPS_MACH_AR7_WAR_H
-#define __ASM_MIPS_MACH_AR7_WAR_H
-
-#define R4600_V1_INDEX_ICACHEOP_WAR0
-#define R4600_V1_HIT_CACHEOP_WAR   0
-#define R4600_V2_HIT_CACHEOP_WAR   0
-#define R5432_CP0_INTERRUPT_WAR0
-#define BCM1250_M3_WAR 0
-#define SIBYTE_1956_WAR0
-#define MIPS4K_ICACHE_REFILL_WAR   0
-#define MIPS_CACHE_SYNC_WAR0
-#define TX49XX_ICACHE_INDEX_INV_WAR0
-#define ICACHE_REFILLS_WORKAROUND_WAR  0
-#define R1_LLSC_WAR0
-#define MIPS34K_MISSED_ITLB_WAR0
-
-#endif /* __ASM_MIPS_MACH_AR7_WAR_H */
diff --git a/arch/mips/include/asm/mach-ath25/war.h 
b/arch/mips/include/asm/mach-ath25/war.h
deleted file mode 100644
index e3a5250..000
--- a/arch/mips/include/asm/mach-ath25/war.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU Gene

[PATCH V3 0/5] MIPS: Initial IMG Pistachio SoC support

[Andrew Bresticker]

This series adds basic support for the Imagination Technologies Pistachio
SoC.  Pistachio will boot using device-tree only.  v4.0-rc1 already includes
support for several of the peripherals on Pistachio, including MMC, SPI,
I2C, DMA, watchdog timer, PWM, and IR.  Clock and pinctrl support for
Pistachio is coming soon, as well as an initial device-tree and support
for USB and ethernet.

Patches 1 and 2 are cleanups in preparation for adding Pistachio support,
with patch 1 having been posted by Kevin late last year [1].  Patch 3
documents Pistachio's required device-tree properties/nodes and its boot
protocol.  Patch 4 adds support for Pistachio itself and finally patch 5
adds a defconfig for Pistachio.

Boot tested on an IMG Pistachio BuB ("bring-up board") and build tested
for all other affected platforms.  Based on v4.0-rc4.  A tree with these
changes is available at [2].

Changes from v2:
 - Addressed review comments from James
Changes from v1:
 - Switched to MIPS UHI hand-off protocol

Cc: Ezequiel Garcia 
Cc: James Hartley 
Cc: James Hogan 

[1] http://patchwork.linux-mips.org/patch/8837/
[2] https://github.com/abrestic/linux/tree/pistachio-platform-v3

Andrew Bresticker (3):
  MIPS: Allow platforms to specify the decompressor load address
  MIPS: Document Pistachio boot protocol and device-tree bindings
  MIPS: Add support for the IMG Pistachio SoC

Govindraj Raja (1):
  MIPS: pistachio: Add an initial defconfig

Kevin Cernekee (1):
  MIPS: Create a common 

 .../devicetree/bindings/mips/img/pistachio.txt |  42 +++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  27 ++
 arch/mips/boot/compressed/Makefile |   6 +-
 arch/mips/configs/pistachio_defconfig  | 336 +
 arch/mips/include/asm/mach-ar7/war.h   |  24 --
 arch/mips/include/asm/mach-ath25/war.h |  25 --
 arch/mips/include/asm/mach-ath79/war.h |  24 --
 arch/mips/include/asm/mach-au1x00/war.h|  24 --
 arch/mips/include/asm/mach-bcm3384/war.h   |  24 --
 arch/mips/include/asm/mach-bcm47xx/war.h   |  24 --
 arch/mips/include/asm/mach-bcm63xx/war.h   |  24 --
 arch/mips/include/asm/mach-cobalt/war.h|  24 --
 arch/mips/include/asm/mach-dec/war.h   |  24 --
 arch/mips/include/asm/mach-emma2rh/war.h   |  24 --
 arch/mips/include/asm/mach-generic/war.h   |  24 ++
 arch/mips/include/asm/mach-jazz/war.h  |  24 --
 arch/mips/include/asm/mach-jz4740/war.h|  24 --
 arch/mips/include/asm/mach-lantiq/war.h|  23 --
 arch/mips/include/asm/mach-lasat/war.h |  24 --
 arch/mips/include/asm/mach-loongson/war.h  |  24 --
 arch/mips/include/asm/mach-loongson1/war.h |  24 --
 arch/mips/include/asm/mach-netlogic/war.h  |  25 --
 arch/mips/include/asm/mach-paravirt/war.h  |  25 --
 arch/mips/include/asm/mach-pistachio/gpio.h|  21 ++
 arch/mips/include/asm/mach-pistachio/irq.h |  18 ++
 arch/mips/include/asm/mach-pnx833x/war.h   |  24 --
 arch/mips/include/asm/mach-ralink/war.h|  24 --
 arch/mips/include/asm/mach-tx39xx/war.h|  24 --
 arch/mips/include/asm/mach-vr41xx/war.h|  24 --
 arch/mips/jz4740/Platform  |   1 +
 arch/mips/pistachio/Makefile   |   1 +
 arch/mips/pistachio/Platform   |   8 +
 arch/mips/pistachio/init.c | 131 
 arch/mips/pistachio/irq.c  |  28 ++
 arch/mips/pistachio/time.c |  52 
 36 files changed, 694 insertions(+), 532 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt
 create mode 100644 arch/mips/configs/pistachio_defconfig
 delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
 delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
 delete mode 100644 arch/mips/include/asm/mach-dec/war.h
 delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
 create mode 100644 arch/mips/include/asm/mach-generic/war.h
 delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
 delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
 delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
 delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
 delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
 delete mode 100644 

[PATCH V3 4/5] MIPS: Add support for the IMG Pistachio SoC

[Andrew Bresticker]

Add initial support for boards based on the Imagination Pistachio SoC.
Pistachio is based on a dual-core MIPS interAptiv CPU and will boot
using device-tree.

Signed-off-by: James Hartley 
Signed-off-by: Andrew Bresticker 
---
Changes from v2:
 - addressed reviewed feedback from James
Changes from v1:
 - switched to MIPS UHI hand-off protocol
---
 arch/mips/Kbuild.platforms  |   1 +
 arch/mips/Kconfig   |  27 ++
 arch/mips/include/asm/mach-pistachio/gpio.h |  21 +
 arch/mips/include/asm/mach-pistachio/irq.h  |  18 
 arch/mips/pistachio/Makefile|   1 +
 arch/mips/pistachio/Platform|   8 ++
 arch/mips/pistachio/init.c  | 131 
 arch/mips/pistachio/irq.c   |  28 ++
 arch/mips/pistachio/time.c  |  52 +++
 9 files changed, 287 insertions(+)
 create mode 100644 arch/mips/include/asm/mach-pistachio/gpio.h
 create mode 100644 arch/mips/include/asm/mach-pistachio/irq.h
 create mode 100644 arch/mips/pistachio/Makefile
 create mode 100644 arch/mips/pistachio/Platform
 create mode 100644 arch/mips/pistachio/init.c
 create mode 100644 arch/mips/pistachio/irq.c
 create mode 100644 arch/mips/pistachio/time.c

diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index e5fc463..86c63d2 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -21,6 +21,7 @@ platforms += mti-malta
 platforms += mti-sead3
 platforms += netlogic
 platforms += paravirt
+platforms += pistachio
 platforms += pmcs-msp71xx
 platforms += pnx833x
 platforms += ralink
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c7a1690..343b238 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -352,6 +352,33 @@ config MACH_LOONGSON1
  the ICT (Institute of Computing Technology) and the Chinese Academy
  of Sciences.
 
+config MACH_PISTACHIO
+   bool "IMG Pistachio SoC based boards"
+   select ARCH_REQUIRE_GPIOLIB
+   select BOOT_ELF32
+   select BOOT_RAW
+   select CEVT_R4K
+   select CLKSRC_MIPS_GIC
+   select COMMON_CLK
+   select CSRC_R4K
+   select DMA_MAYBE_COHERENT
+   select IRQ_CPU
+   select LIBFDT
+   select MFD_SYSCON
+   select MIPS_CPU_SCACHE
+   select MIPS_GIC
+   select PINCTRL
+   select REGULATOR
+   select SYS_HAS_CPU_MIPS32_R2
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_SUPPORTS_LITTLE_ENDIAN
+   select SYS_SUPPORTS_MIPS_CPS
+   select SYS_SUPPORTS_MULTITHREADING
+   select SYS_SUPPORTS_ZBOOT
+   select USE_OF
+   help
+ This enables support for the IMG Pistachio SoC platform.
+
 config MIPS_MALTA
bool "MIPS Malta board"
select ARCH_MAY_HAVE_PC_FDC
diff --git a/arch/mips/include/asm/mach-pistachio/gpio.h 
b/arch/mips/include/asm/mach-pistachio/gpio.h
new file mode 100644
index 000..6c1649c
--- /dev/null
+++ b/arch/mips/include/asm/mach-pistachio/gpio.h
@@ -0,0 +1,21 @@
+/*
+ * Pistachio IRQ setup
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MACH_PISTACHIO_GPIO_H
+#define __ASM_MACH_PISTACHIO_GPIO_H
+
+#include 
+
+#define gpio_get_value __gpio_get_value
+#define gpio_set_value __gpio_set_value
+#define gpio_cansleep  __gpio_cansleep
+#define gpio_to_irq__gpio_to_irq
+
+#endif /* __ASM_MACH_PISTACHIO_GPIO_H */
diff --git a/arch/mips/include/asm/mach-pistachio/irq.h 
b/arch/mips/include/asm/mach-pistachio/irq.h
new file mode 100644
index 000..b94a09a
--- /dev/null
+++ b/arch/mips/include/asm/mach-pistachio/irq.h
@@ -0,0 +1,18 @@
+/*
+ * Pistachio IRQ setup
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MACH_PISTACHIO_IRQ_H
+#define __ASM_MACH_PISTACHIO_IRQ_H
+
+#define NR_IRQS 256
+
+#include_next 
+
+#endif /* __ASM_MACH_PISTACHIO_IRQ_H */
diff --git a/arch/mips/pistachio/Makefile b/arch/mips/pistachio/Makefile
new file mode 100644
index 000..32189c6
--- /dev/null
+++ b/arch/mips/pistachio/Makefile
@@ -0,0 +1 @@
+obj-y  += init.o irq.o time.o
diff --git a/arch/mips/pistachio/Platform b/arch/mips/pistachio/Platform
new file mode 100644
index 000..d80cd61
--- /dev/null
+++ b/arch/mips/pistachio/Platform
@@ -0,0 +1,8 @@
+#
+# IMG Pistachio SoC
+#
+platform-$(CONFIG_MACH_PISTACHIO)  += pistachio/
+cflags-$(CONFIG_MACH_PISTACHIO)+=  
\
+   -I$(srctree)/arch/mips/include/asm/mach-pistachio
+load-$(CONFIG_MACH_PISTACHIO)  += 0x8040
+zload-$(CONFIG_M

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Dr. H. Nikolaus Schaller]

Am 16.03.2015 um 22:20 schrieb Belisko Marek :

> On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek  wrote:
>> On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
>>> Signed-off-by: Marek Belisko 
>>> ---
>>> .../bindings/power_supply/twl4030_madc_battery.txt | 43 
>>> ++
>>> 1 file changed, 43 insertions(+)
>>> create mode 100644 
>>> Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> 
>>> diff --git 
>>> a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
>>> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> new file mode 100644
>>> index 000..bb3580c
>>> --- /dev/null
>>> +++ 
>>> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>> @@ -0,0 +1,43 @@
>>> +twl4030_madc_battery
>>> +
>>> +Required properties:
>>> + - compatible : "ti,twl4030-madc-battery"
>>> + - capacity-uah : battery capacity in uAh
>> 
>> Could we make it capacity-uAh ?
> This name was suggested by Mark Rutland [1] and naming convention
> should be all lowercase. There exists already bindings
> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
>> 
>>> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
>>> + for charging calibration (see example)
>>> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
>>> + for discharging calibration (see example)
>> 
>> Would "mV-to-capacity..." be more accurate? Also, would it make sense
> Again maybe mv but it can be added also later.
>> to introduce coefficients for temperature and discharge rate?
> What do you mean? Nothing like that is used in current driver why do
> we need to add it?

Temperature calibration should have already been done in the underlaying 
twl4030 iio driver.

Discharge rate is the real current flow reported in uA. Also reported by iio.

>> 
>> Thanks,
>>Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) 
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> 
> [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104
> 
> BR,
> 
> marek
> 

BR,
Nikolaus


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dts: cubox: Map gpio-keys and pps-gpio to gpio3 8

[George Joseph]

On Mon, Mar 16, 2015 at 2:50 PM, Russell King - ARM Linux
 wrote:
> On Mon, Mar 16, 2015 at 02:36:41PM -0600, George Joseph wrote:
>> The Cubox has a recessed button between the HDMI and RJ-45 connectors
>> that wasn't mapped in the device tree.  Since the button is normally
>> open and there's no external pull up/down, that pad (EIM_DA8) can be
>> used for almost anything so I've mapped it to gpio-keys BTN_0 and
>> pps-gpio.  Whichever driver claims it first wins.  If both drivers
>> are build as modules, you can even switch between them at run time
>> and the pinmux will adjust the pin configuration as required.
>> If neither driver claims the gpio, it's still available in the normal
>> gpio sysfs.
>
> I wonder why we want to have the PPS support in mainline, given that
> you would need to solder to the board to make use of that.  I can see
> the point of the gpio-keys going into mainline, but not the PPS bit.
> That's more like a local hack.
>

Well, it was just one less thing I'd have to patch locally for so I
took a chance. :)I'll remove the pps bits and resubmit.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Tony Lindgren]

* Pali Rohár  [150316 14:15]:
> On Monday 16 March 2015 22:01:43 Tony Lindgren wrote:
> > * Pali Rohár  [150316 13:59]:
> > > On Monday 16 March 2015 16:29:39 Tony Lindgren wrote:
> > > > I believe the last pending issues is the support for
> > > > ATAG_REVISION in device tree mode as posted by Pali.
> > > 
> > > No. In DT boot there is missing /proc/atags file (readable
> > > by userspace processes).
> > 
> > Oh OK thanks for the update.
> > 
> > > And also broken AES/SHA/MD5 support. Fix for crypto DT stuff
> > > I already sent.
> > 
> > But this is not a regression in mainline with legacy boot vs
> > device tree based booting, right? Sounds like it never worked
> > in the mainline or am thinking of some other set of patches?
> > 
> > Regards,
> > 
> > Tony
> 
> In legacy board code are DMA channels defined. In DT files not. 
> So I think this is regression. Omap secure devices are broken in 
> both legacy & DT code, but non secure could work with legacy 
> code. But all devices booted with DT are broken.

OK I'll apply the DMA channels into omap-for-v4.0/fixes in
that case.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Belisko Marek]

On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek  wrote:
> On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
>> Signed-off-by: Marek Belisko 
>> ---
>>  .../bindings/power_supply/twl4030_madc_battery.txt | 43 
>> ++
>>  1 file changed, 43 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
>> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> new file mode 100644
>> index 000..bb3580c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> @@ -0,0 +1,43 @@
>> +twl4030_madc_battery
>> +
>> +Required properties:
>> + - compatible : "ti,twl4030-madc-battery"
>> + - capacity-uah : battery capacity in uAh
>
> Could we make it capacity-uAh ?
This name was suggested by Mark Rutland [1] and naming convention
should be all lowercase. There exists already bindings
without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
>
>> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
>> + for charging calibration (see example)
>> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
>> + for discharging calibration (see example)
>
> Would "mV-to-capacity..." be more accurate? Also, would it make sense
Again maybe mv but it can be added also later.
> to introduce coefficients for temperature and discharge rate?
What do you mean? Nothing like that is used in current driver why do
we need to add it?
>
> Thanks,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[1] - http://lists.openwall.net/linux-kernel/2014/10/09/104

BR,

marek


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Pali Rohár]

On Monday 16 March 2015 22:01:43 Tony Lindgren wrote:
> * Pali Rohár  [150316 13:59]:
> > On Monday 16 March 2015 16:29:39 Tony Lindgren wrote:
> > > I believe the last pending issues is the support for
> > > ATAG_REVISION in device tree mode as posted by Pali.
> > 
> > No. In DT boot there is missing /proc/atags file (readable
> > by userspace processes).
> 
> Oh OK thanks for the update.
> 
> > And also broken AES/SHA/MD5 support. Fix for crypto DT stuff
> > I already sent.
> 
> But this is not a regression in mainline with legacy boot vs
> device tree based booting, right? Sounds like it never worked
> in the mainline or am thinking of some other set of patches?
> 
> Regards,
> 
> Tony

In legacy board code are DMA channels defined. In DT files not. 
So I think this is regression. Omap secure devices are broken in 
both legacy & DT code, but non secure could work with legacy 
code. But all devices booted with DT are broken.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v4 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Tony Lindgren  [150316 13:59]:
> * Marek Belisko  [150310 14:28]:
> > Added battery support for gta04 devices.
> > 
> > Signed-off-by: Marek Belisko 
> 
> Picking up this patch into omap-for-v4.1/dt branch thanks.

Actually not yet applying this as looks like Pavel just
had few comments on these properties.
 
> Tony
> 
> > ---
> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> > b/arch/arm/boot/dts/omap3-gta04.dtsi
> > index fb3a696..cbf515a 100644
> > --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> > +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> > @@ -49,6 +49,32 @@
> > ti,codec = <&twl_audio>;
> > };
> >  
> > +   battery {
> > +   compatible = "ti,twl4030-madc-battery";
> > +   capacity-uah = <120>;
> > +   ti,volt-to-capacity-charging-map = <4200 100>,
> > +<4100 75>,
> > +<4000 55>,
> > +<3900 25>,
> > +<3800 5>,
> > +<3700 2>,
> > +<3600 1>,
> > +<3300 0>;
> > +   ti,volt-to-capacity-discharging-map = <4200 100>,
> > +   <4100 95>,
> > +   <4000 70>,
> > +   <3800 50>,
> > +   <3700 10>,
> > +   <3600 5>,
> > +   <3300 0>;
> > +   io-channels = <&twl_madc 1>,
> > + <&twl_madc 10>,
> > + <&twl_madc 12>;
> > +   io-channel-names = "temp",
> > +  "ichg",
> > +  "vbat";
> > +   };
> > +
> > spi_lcd {
> > compatible = "spi-gpio";
> > #address-cells = <0x1>;
> > @@ -518,3 +544,7 @@
> >  &mcbsp2 {
> > status = "okay";
> >  };
> > +
> > +&twl_madc {
> > +   ti,system-uses-second-madc-irq;
> > +};
> > -- 
> > 1.9.1
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Tony Lindgren]

* Pali Rohár  [150316 13:59]:
> On Monday 16 March 2015 16:29:39 Tony Lindgren wrote:
> > I believe the last pending issues is the support for
> > ATAG_REVISION in device tree mode as posted by Pali.
> > 
> 
> No. In DT boot there is missing /proc/atags file (readable by 
> userspace processes).

Oh OK thanks for the update.

> And also broken AES/SHA/MD5 support. Fix for crypto DT stuff
> I already sent.

But this is not a regression in mainline with legacy boot vs
device tree based booting, right? Sounds like it never worked
in the mainline or am thinking of some other set of patches?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings

[Pavel Machek]

On Wed 2015-02-04 23:14:32, Marek Belisko wrote:
> Signed-off-by: Marek Belisko 
> ---
>  .../bindings/power_supply/twl4030_madc_battery.txt | 43 
> ++
>  1 file changed, 43 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 
> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> new file mode 100644
> index 000..bb3580c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
> @@ -0,0 +1,43 @@
> +twl4030_madc_battery
> +
> +Required properties:
> + - compatible : "ti,twl4030-madc-battery"
> + - capacity-uah : battery capacity in uAh

Could we make it capacity-uAh ?

> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values
> + for charging calibration (see example)
> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
> + for discharging calibration (see example)

Would "mV-to-capacity..." be more accurate? Also, would it make sense
to introduce coefficients for temperature and discharge rate?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Pali Rohár]

On Monday 16 March 2015 16:29:39 Tony Lindgren wrote:
> I believe the last pending issues is the support for
> ATAG_REVISION in device tree mode as posted by Pali.
> 

No. In DT boot there is missing /proc/atags file (readable by 
userspace processes). And also broken AES/SHA/MD5 support. Fix 
for crypto DT stuff I already sent.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v4 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Marek Belisko  [150310 14:28]:
> Added battery support for gta04 devices.
> 
> Signed-off-by: Marek Belisko 

Picking up this patch into omap-for-v4.1/dt branch thanks.

Tony

> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index fb3a696..cbf515a 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -49,6 +49,32 @@
>   ti,codec = <&twl_audio>;
>   };
>  
> + battery {
> + compatible = "ti,twl4030-madc-battery";
> + capacity-uah = <120>;
> + ti,volt-to-capacity-charging-map = <4200 100>,
> +  <4100 75>,
> +  <4000 55>,
> +  <3900 25>,
> +  <3800 5>,
> +  <3700 2>,
> +  <3600 1>,
> +  <3300 0>;
> + ti,volt-to-capacity-discharging-map = <4200 100>,
> + <4100 95>,
> + <4000 70>,
> + <3800 50>,
> + <3700 10>,
> + <3600 5>,
> + <3300 0>;
> + io-channels = <&twl_madc 1>,
> +   <&twl_madc 10>,
> +   <&twl_madc 12>;
> + io-channel-names = "temp",
> +"ichg",
> +"vbat";
> + };
> +
>   spi_lcd {
>   compatible = "spi-gpio";
>   #address-cells = <0x1>;
> @@ -518,3 +544,7 @@
>  &mcbsp2 {
>   status = "okay";
>  };
> +
> +&twl_madc {
> + ti,system-uses-second-madc-irq;
> +};
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Belisko Marek  [150316 13:47]:
> Hi Tony,
> 
> On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren  wrote:
> > * Sebastian Reichel  [150304 16:41]:
> >> Hi,
> >>
> >> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> >> > Signed-off-by: Marek Belisko 
> >> > ---
> >> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
> >> >  1 file changed, 30 insertions(+)
> >>
> >> DTS changes must go via omap-dt tree once the driver changes have been
> >> merged.
> >
> > And looks like you wanted to add ti, prefix to the binding. I'll
> > mark this one as read, please repost this one separately once the
> > driver changes are in Linux next.
> ti prefix Iis done in v4 series already [1]
> >
> > Regards,
> >
> > Tony
> 
> [1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.html

OK will pick it from there thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ARM: dts: am335x: Add DTS for ChiliSOM module

[Tony Lindgren]

* Rostislav Lisovy  [150209 06:51]:
> Since this is a SOM (System on Module) that will be part
> of another embedded board (and can't really exist on its own)
> define it as a "dtsi" that will be included in the Device tree
> describing the whole system later on.
> 
> Hardware specification:
> * AM335x SoC
> * up to 512 MB RAM
> * NAND Flash (8x interface, cs0)
> * UART0
> * PMIC
> * I2C0 (for PMIC)
> * 1x Ethernet MAC

Applying all three into omap-for-v4.1/dt with one change
below.
 
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
> +
> +&gpmc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&nandflash_pins>;
> + ranges = <0 0 0x0800 0x0100>; /* CS0 0 @addr 0x0800, size 
> 0x0100 */
> + nand@0,0 {
> + reg = <0 0 0x0100>; /* CS0 */

I've changed this to say just:
reg = <0 0 4>;  /* CS0, offset 0, IO size 4 */

As for NAND the device has just one IO register. The 0x0100
is the size of a minimum GPMC partition.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dts: cubox: Map gpio-keys and pps-gpio to gpio3 8

[Russell King - ARM Linux]

On Mon, Mar 16, 2015 at 02:36:41PM -0600, George Joseph wrote:
> The Cubox has a recessed button between the HDMI and RJ-45 connectors
> that wasn't mapped in the device tree.  Since the button is normally
> open and there's no external pull up/down, that pad (EIM_DA8) can be
> used for almost anything so I've mapped it to gpio-keys BTN_0 and
> pps-gpio.  Whichever driver claims it first wins.  If both drivers
> are build as modules, you can even switch between them at run time
> and the pinmux will adjust the pin configuration as required.
> If neither driver claims the gpio, it's still available in the normal
> gpio sysfs.

I wonder why we want to have the PPS support in mainline, given that
you would need to solder to the board to make use of that.  I can see
the point of the gpio-keys going into mainline, but not the PPS bit.
That's more like a local hack.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Belisko Marek]

Hi Tony,

On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren  wrote:
> * Sebastian Reichel  [150304 16:41]:
>> Hi,
>>
>> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
>> > Signed-off-by: Marek Belisko 
>> > ---
>> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
>> >  1 file changed, 30 insertions(+)
>>
>> DTS changes must go via omap-dt tree once the driver changes have been
>> merged.
>
> And looks like you wanted to add ti, prefix to the binding. I'll
> mark this one as read, please repost this one separately once the
> driver changes are in Linux next.
ti prefix Iis done in v4 series already [1]
>
> Regards,
>
> Tony

[1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.html

BR,

marek



-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support

[Tony Lindgren]

* Sebastian Reichel  [150304 16:41]:
> Hi,
> 
> On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote:
> > Signed-off-by: Marek Belisko 
> > ---
> >  arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
> >  1 file changed, 30 insertions(+)
> 
> DTS changes must go via omap-dt tree once the driver changes have been
> merged.

And looks like you wanted to add ti, prefix to the binding. I'll
mark this one as read, please repost this one separately once the
driver changes are in Linux next.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dts: cubox: Map gpio-keys and pps-gpio to gpio3 8

[George Joseph]

The Cubox has a recessed button between the HDMI and RJ-45 connectors
that wasn't mapped in the device tree.  Since the button is normally
open and there's no external pull up/down, that pad (EIM_DA8) can be
used for almost anything so I've mapped it to gpio-keys BTN_0 and
pps-gpio.  Whichever driver claims it first wins.  If both drivers
are build as modules, you can even switch between them at run time
and the pinmux will adjust the pin configuration as required.
If neither driver claims the gpio, it's still available in the normal
gpio sysfs.

Signed-off-by: George Joseph 
Tested-by: George Joseph 
---
 arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi 
b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index 6a524ca..7479fb6 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -3,6 +3,8 @@
  */
 #include "imx6qdl-microsom.dtsi"
 #include "imx6qdl-microsom-ar8035.dtsi"
+#include 
+#include 
 
 / {
ir_recv: ir-receiver {
@@ -66,6 +68,26 @@
spdif-controller = <&spdif>;
spdif-out;
};
+
+   pps {
+   compatible = "pps-gpio";
+   pinctrl-0 = <&pinctrl_gpio_pps>;
+   pinctrl-names = "default";
+   gpios = <&gpio3 8 0>;
+   interrupt-parent = <&intc>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-0 = <&pinctrl_gpio_key>;
+   pinctrl-names = "default";
+
+   button_0 {
+   label = "Button 0";
+   gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
 };
 
 &hdmi {
@@ -170,6 +192,18 @@
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x13059
>;
};
+
+   pinctrl_gpio_pps: gpio-pps {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_DA8__GPIO3_IO08  0x130c1
+   >;
+   };
+
+   pinctrl_gpio_key: gpio-key {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_DA8__GPIO3_IO08  0x17059
+   >;
+   };
};
 };
 
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] i2c: mux-pinctrl: Rework to honor disabled child nodes

[Sebastian Hesselbarth]

On 10.03.2015 17:28, Stephen Warren wrote:

On 03/09/2015 06:21 AM, Sebastian Hesselbarth wrote:

I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
incarnation of the devicetree node with different available sub-busses
to be rewritten.

This patch reworks i2c-mux-pinctrl driver to count the number of
available sub-nodes instead. The rework should be compatible to the old
way of probing for sub-busses and additionally allows to disable unused
sub-busses with standard DT property status = "disabled".

This also amends the corresponding devicetree binding documentation to
reflect the new functionality to disable unused sub-nodes. While at it,
also fix two references to binding documentation files that miss an
"i2c-"
prefix.


The DT binding changes at least,
Acked-by: Stephen Warren 


Wolfram,

are you going to pick this patch through your tree now that Stephen
ack'ed the binding documentation change, too?

I can also split the patch up into driver/doc changes if you prefer.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] dts: Add am335x-wega-rdk.dtb sources for phyBOARD-Wega-AM335x

[Tony Lindgren]

* Matwey V. Kornilov  [150312 23:58]:
> Hi,
> 
> Teresa replied me, but unfortunately I found that the answer not
> reached the public maillists. Briefly, we don't need this patch,
> PhyTec will send better one this year.

OK will ignore this one then. This year sounds a bit long time
to wait though.. How about maybe send it a bit sooner? :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/5] PCI: designware: Add disable IO support

[Arnd Bergmann]

On Monday 16 March 2015 13:00:51 Kumar Gala wrote:
> On Mar 16, 2015, at 9:20 AM, Gabriel FERNANDEZ  
> wrote:
> 
> > ST sti SoCs PCIe IPs are built around DesignWare IP Core.
> > But in these SoCs PCIe IP doesn't support IO.
> > 
> > This patch adds the possibility to disable it through
> > a DT property, by creating an empty IO window and by
> > removing PCI_COMMAND_IO from the setup register.
> > 
> > Signed-off-by: Fabrice Gasnier 
> > Signed-off-by: Gabriel Fernandez 
> > ---
> > .../devicetree/bindings/pci/designware-pcie.txt|  2 ++
> > drivers/pci/host/pcie-designware.c | 24 
> > --
> > drivers/pci/host/pcie-designware.h |  1 +
> > 3 files changed, 25 insertions(+), 2 deletions(-)
> 
> Why not just update the code such that if the ranges doesn’t have an IO
> space rather than introducing a new DT property?

I suspect we can simplify this now by changing over the designware PCI
code from pci_common_init_dev to calling pci_scan_root_bus() in the
same way that pci-versatile.c does. This would also clean up some
other areas of the driver and let you do proper error handling
in the probe.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller

[Florian Fainelli]

[snip]

> +static int brcmnand_dma_trans(struct brcmnand_host *host, u64 addr, u32 *buf,
> +   u32 len, u8 dma_cmd)
> +{
> + struct brcmnand_controller *ctrl = host->ctrl;
> + dma_addr_t buf_pa;
> + int dir = dma_cmd == CMD_PAGE_READ ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
> +
> + buf_pa = dma_map_single(ctrl->dev, buf, len, dir);

We are missing a dma_mapping_error() check here.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] media: i2c: add support for omnivision's ov2659 sensor

[Lad, Prabhakar]

Hi Hans,

Thanks for the review.

On Mon, Mar 16, 2015 at 9:24 AM, Hans Verkuil  wrote:
> Hi Prabhakar,
>
> On 03/15/2015 11:34 AM, Lad Prabhakar wrote:
>> From: Benoit Parrot 
>>
>> this patch adds support for omnivision's ov2659
>> sensor, the driver supports following features:
>> 1: Asynchronous probing
>> 2: DT support
>> 3: Media controller support
>>
>> Signed-off-by: Benoit Parrot 
>> Signed-off-by: Lad, Prabhakar 
>> Acked-by: Sakari Ailus 
>> ---
>>  Changes for v6:
>>  a: fixed V4L2_CID_PIXEL_RATE control to use link_frequency
>> instead of xvclk_frequency.
>>  b: Included Ack from Sakari
>>
>>  v5: https://patchwork.kernel.org/patch/6000161/
>>  v4: https://patchwork.kernel.org/patch/5961661/
>>  v3: https://patchwork.kernel.org/patch/5959401/
>>  v2: https://patchwork.kernel.org/patch/5859801/
>>  v1: https://patchwork.linuxtv.org/patch/27919/
>>
>>  .../devicetree/bindings/media/i2c/ov2659.txt   |   38 +
>>  MAINTAINERS|   10 +
>>  drivers/media/i2c/Kconfig  |   11 +
>>  drivers/media/i2c/Makefile |1 +
>>  drivers/media/i2c/ov2659.c | 1510 
>> 
>>  include/media/ov2659.h |   33 +
>>  6 files changed, 1603 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
>>  create mode 100644 drivers/media/i2c/ov2659.c
>>  create mode 100644 include/media/ov2659.h
>>
>> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
>> new file mode 100644
>> index 000..3ae6629
>> --- /dev/null
>> +++ b/drivers/media/i2c/ov2659.c
>
> 
>
>> +static const struct ov2659_pixfmt ov2659_formats[] = {
>> + {
>> + .code = MEDIA_BUS_FMT_YUYV8_2X8,
>> + .colorspace = V4L2_COLORSPACE_JPEG,
>> + .format_ctrl_regs = ov2659_format_yuyv,
>> + },
>> + {
>> + .code = MEDIA_BUS_FMT_UYVY8_2X8,
>> + .colorspace = V4L2_COLORSPACE_JPEG,
>> + .format_ctrl_regs = ov2659_format_uyvy,
>> + },
>> + {
>> + .code = MEDIA_BUS_FMT_RGB565_2X8_BE,
>> + .colorspace = V4L2_COLORSPACE_JPEG,
>> + .format_ctrl_regs = ov2659_format_rgb565,
>> + },
>> + {
>> + .code = MEDIA_BUS_FMT_SBGGR8_1X8,
>> + .colorspace = V4L2_COLORSPACE_SMPTE170M,
>> + .format_ctrl_regs = ov2659_format_bggr,
>> + },
>> +};
>
> The colorspaces defined here make no sense. Sensors should give you
> V4L2_COLORSPACE_SRGB. Certainly not COLORSPACE_JPEG (unless they encode
> to a JPEG for you) and SMPTE170M (SDTV) is unlikely as well, unless the
> documentation explicitly states that it uses that colorspace.
>
> Unfortunately, the product brief of this sensor does not mention the
> colorimetry information at all, nor does it give any information about
> the transfer function (aka gamma) used by the sensor. Since this sensor
> is advertised as an HDTV sensor I would guess the colorspace should either
> be SRGB or REC709, depending on the transfer function used.
>
Yes it needs to be V4L2_COLORSPACE_SRGB, Ill respin fixing this.

Cheers,
--Prabhakar Lad

> I see a lot of sensor drivers that wrongly use the JPEG colorspace. I'm 
> planning
> to fix them, since that is really wrong.
>
> Regards,
>
> Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 02:35 PM, Hans de Goede wrote:
> To be clear about my aarch64 remark, that relates to the behavior of aarch64 
> acpi using
> machines, those will also output to both a serial tty and tty0 when the acpi 
> equivalent
> of stdout-path is present and points to a serial tty.

I already made comments addressing the unsuitability of the license for the
aarch64 acpi console; the proposed SPCR table format is patented by Microsoft 
and
licensed incompatibly with GPLv2.

That said, the aarch64 acpi console should be treated like any other prom that
starts a console and so won't suffer from this breakage.

Regards,
Peter Hurley

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System

[Joe Perches]

On Mon, 2015-03-16 at 20:01 +0100, LABBE Corentin wrote:
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -10923,6 +10923,12 @@ L:   linux...@kvack.org
>  S:   Maintained
>  F:   mm/zswap.c
>  
> +ALLWINNER SECURITY SYSTEM
> +M:   Corentin Labbe 
> +L:   linux-cry...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/crypto/sunxi-ss/

Use alphabetic ordering for new sections please.

Please place this section between:

ALI1563 I2C DRIVER
and
ALPHA PORT


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6] crypto: Add Allwinner Security System crypto accelerator

[LABBE Corentin]

Hello

This is the driver for the Security System included in Allwinner SoC A20.
The Security System (SS for short) is a hardware cryptographic accelerator that
support AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on others Allwinner SoC: 
- A10s, A33 and A31 diagram speak about it with precisions 
(AES/DES/3DES/Md5/SHA1/PRNG)
- A10 and A13 manual give the same datasheet for SS than A20
- A23 speak about a security system but without precisions
- A80 datasheet speak about a security system with more functions
  (SHA224/SHA256/RSA/CRC) but without precisions
  But I do not have access on any of those hardware, tests are welcome.

  This driver currently supports:
  - MD5 and SHA1 hash algorithms
  - AES block cipher in CBC mode with 128/196/256bits keys.
  - DES and 3DES block cipher in CBC mode
  The driver exposes all those algorithms through the kernel cryptographic API.

  The driver support only CPU driven (aka poll mode) transfer mode,
  since the DMA engine of the A20 does not have a mainline driver yet.

  Changes since v5:
  - Hash functions now keep partial hash states in sunxi_ss structures
  - Use of spinlock instead of mutex
  - Remove the static sunxi_ss structures by using container of
  - Add export/import functions
  - replace lots of writel by writesl
  - replace lots of readl by readsl

  Changes since v4:
  - Rework all mutex path
  - Use ahash_request_ctx() in hash functions
  - Major rework of hash functions for solving mutex problems
  - Split sunxi_req_ctx in two since ciphers now use struct sunxi_tfm_ctx
  - Hash functions now test FIFO space register

  Changes since v3:
  - Remove all algorithms options from Kconfig, so now only one module is used
  - Add the sunxi_ss_cipher function to unify mode calculation
  - Remove the sunxi_cipher_exit empty function
  - Add some missing mutex_unlock()
  - Drop PRNG support, I wait for more comment on its results before 
re-enabling it.

  Changes since v2:
  - Fix Makefile and Kconfig for static kernel.

  Changes since v1:
  - annotate ss->base as __iomem
  - regroup all mutex in the ss_ctx structure
  - splited driver in 7 modules (core md5 sha1 aes des 3des prng) in sunxi-ss 
directory
  - use dev_exit_p() for .remove
  - added missing CRYPTO_BLKCIPHER dep in Kconfig
  - use ahash instead of shash
  - use ablkcipher instead of blkcipher
  - use crypto_rng_ctx instead of crypto_tfm_ctx
  - set seed as an u32
  - drop useless comment decoration
  - drop useless debug
  - ss_ctx is now a static pointer and whole structure being allocated
  - fix the platform_get_resource/devm_ioremap_resource pattern
  - invert getting die id and configuring clock
  - set clock value as a const unsigned long
  - add MODULE_ALIAS
  - use define names more consistency (SS_xxx)
  - fix PRNG errors
  - respell SS to Security System in DT documentation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 4/4] crypto: Add Allwinner Security System crypto accelerator

[LABBE Corentin]

Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC mode

Signed-off-by: LABBE Corentin 
---
 drivers/crypto/Kconfig|  17 ++
 drivers/crypto/Makefile   |   1 +
 drivers/crypto/sunxi-ss/Makefile  |   2 +
 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 408 +
 drivers/crypto/sunxi-ss/sunxi-ss-core.c   | 339 +
 drivers/crypto/sunxi-ss/sunxi-ss-hash.c   | 475 ++
 drivers/crypto/sunxi-ss/sunxi-ss.h| 200 +
 7 files changed, 1442 insertions(+)
 create mode 100644 drivers/crypto/sunxi-ss/Makefile
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-core.c
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
 create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2fb0fdf..9ba9759 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -436,4 +436,21 @@ config CRYPTO_DEV_QCE
  hardware. To compile this driver as a module, choose M here. The
  module will be called qcrypto.
 
+config CRYPTO_DEV_SUNXI_SS
+   tristate "Support for Allwinner Security System cryptographic 
accelerator"
+   depends on ARCH_SUNXI
+   select CRYPTO_MD5
+   select CRYPTO_SHA1
+   select CRYPTO_AES
+   select CRYPTO_DES
+   select CRYPTO_BLKCIPHER
+   help
+ Some Allwinner SoC have a crypto accelerator named
+ Security System. Select this if you want to use it.
+ The Security System handle AES/DES/3DES ciphers in CBC mode
+ and SHA1 and MD5 hash algorithms.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sunxi-ss.
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 3924f93..856545c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
 obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
 obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
new file mode 100644
index 000..8bb287d
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
+sunxi-ss-y += sunxi-ss-core.o sunxi-ss-hash.o sunxi-ss-cipher.o
diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c 
b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
new file mode 100644
index 000..3ed0ad0
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
@@ -0,0 +1,408 @@
+/*
+ * sunxi-ss-cipher.c - hardware cryptographic accelerator for Allwinner A20 SoC
+ *
+ * Copyright (C) 2013-2015 Corentin LABBE 
+ *
+ * This file add support for AES cipher with 128,192,256 bits
+ * keysize in CBC mode.
+ * Add support also for DES and 3DES in CBC mode.
+ *
+ * You could find the datasheet in Documentation/arm/sunxi/README
+ *
+ * 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 "sunxi-ss.h"
+
+static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
+{
+   struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
+   struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
+   const char *cipher_type;
+   struct sunxi_ss_ctx *ss = op->ss;
+
+   if (areq->nbytes == 0)
+   return 0;
+
+   if (areq->info == NULL) {
+   dev_err(ss->dev, "ERROR: Empty IV\n");
+   return -EINVAL;
+   }
+
+   if (areq->src == NULL || areq->dst == NULL) {
+   dev_err(ss->dev, "ERROR: Some SGs are NULL\n");
+   return -EINVAL;
+   }
+
+   cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
+
+   if (strcmp("cbc(aes)", cipher_type) == 0) {
+   mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op->keymode;
+   return sunxi_ss_aes_poll(areq, mode);
+   }
+
+   if (strcmp("cbc(des)", cipher_type) == 0) {
+   mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op->keymode;
+   return sunxi_ss_des_poll(areq, mode);
+   }
+
+   if (strcmp("cbc(des3_ede)", cipher_type) == 0) {
+   mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op->keymode;
+   return sunxi_ss_des_poll(areq, mode);
+   }
+
+   dev_err(ss->dev, "ERROR: Cipher %s not handled\n", cipher_type);
+   return -EINVAL;
+}
+
+int sunxi_ss

[PATCH v6 1/4] ARM: sun7i: dt: Add Security System to A20 SoC DTS

[LABBE Corentin]

The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.

This patch enable the Security System on the Allwinner A20 SoC Device-tree.

Signed-off-by: LABBE Corentin 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3a8530b..8995bec 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -680,6 +680,14 @@
status = "disabled";
};
 
+   crypto: crypto-engine@01c15000 {
+   compatible = "allwinner,sun7i-a20-crypto";
+   reg = <0x01c15000 0x1000>;
+   interrupts = <0 86 4>;
+   clocks = <&ahb_gates 5>, <&ss_clk>;
+   clock-names = "ahb", "mod";
+   };
+
spi2: spi@01c17000 {
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c17000 0x1000>;
-- 
2.0.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/4] ARM: sunxi: dt: Add DT bindings documentation for SUNXI Security System

[LABBE Corentin]

This patch adds documentation for Device-Tree bindings for the Security System 
cryptographic accelerator driver.

Signed-off-by: LABBE Corentin 
---
 Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/sunxi-ss.txt

diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt 
b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt
new file mode 100644
index 000..a566803
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt
@@ -0,0 +1,9 @@
+* Allwinner Security System found on A20 SoC
+
+Required properties:
+- compatible : Should be "allwinner,sun7i-a20-crypto".
+- reg: Should contain the Security System register location and length.
+- interrupts: Should contain the IRQ line for the Security System.
+- clocks : A phandle to the functional clock node of the Security System module
+- clock-names : Name of the functional clock, should be "ahb" and "mod".
+
-- 
2.0.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/4] MAINTAINERS: Add myself as maintainer of Allwinner Security System

[LABBE Corentin]

Signed-off-by: LABBE Corentin 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0e1abe8..ebca296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10923,6 +10923,12 @@ L: linux...@kvack.org
 S: Maintained
 F: mm/zswap.c
 
+ALLWINNER SECURITY SYSTEM
+M: Corentin Labbe 
+L: linux-cry...@vger.kernel.org
+S: Maintained
+F: drivers/crypto/sunxi-ss/
+
 THE REST
 M: Linus Torvalds 
 L: linux-ker...@vger.kernel.org
-- 
2.0.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller

[Florian Fainelli]

On 06/03/15 17:18, Brian Norris wrote:
> This core originated in Set-Top Box chips (BCM7xxx) but is used in a
> variety of other Broadcom chips, including some BCM63xxx, BCM33xx, and
> iProc/Cygnus. It's been used only on ARM and MIPS SoCs, so restrict it
> to those architectures.
> 
> There are multiple revisions of this core throughout the years, and
> almost every version broke register compatibility in some small way, but
> with some effort, this driver is able to support v4.0, v5.0, v6.x, v7.0,
> and v7.1. It's been tested on v5.0, v6.0, v7.0, and v7.1 recently, so
> there hopefully are no more lurking inconsistencies.
> 
> Signed-off-by: Brian Norris 
> ---

Looks good to me, just one nitpick below:

[snip]

> +static int brcmnand_revision_init(struct brcmnand_controller *ctrl)
> +{
> + static const unsigned int block_sizes_v6[] = { 8, 16, 128, 256, 512, 
> 1024, 2048, 0 };
> + static const unsigned int block_sizes_v4[] = { 16, 128, 8, 512, 256, 
> 1024, 2048, 0 };
> + static const unsigned int page_sizes[] = { 512, 2048, 4096, 8192, 0 };
> +
> + ctrl->nand_version = nand_readreg(ctrl, 0) & 0x;
> +
> + /* Only support v4.0+? */
> + if (ctrl->nand_version < 0x0400)
> + return -ENODEV;

It could be nice to have an informative error message here that this is
either:

- an unknown controller revision (> 7.1)
- an older controller revision
- a check against the compatible property, just in case?

[snip]

> + ctrl->cs_offsets = brcmnand_cs_offsets_v71;
> + } else {
> + ctrl->cs_offsets = brcmnand_cs_offsets;
> +
> + /* pre-v5.0 has a different CS0 offset layout */
> + if (ctrl->nand_version <= 0x0500)
> + ctrl->cs0_offsets = brcmnand_cs_offsets_cs0;

Based on this check, should the comment should be "pre-v5.0 and v5.0
have a different CS0 offset layout"?
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller

[Florian Fainelli]

On 06/03/15 17:18, Brian Norris wrote:
> Signed-off-by: Brian Norris 

Reviewed-by: Florian Fainelli 

> ---
>  .../devicetree/bindings/mtd/brcmstb_nand.txt   | 109 
> +
>  1 file changed, 109 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt 
> b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> new file mode 100644
> index ..933d44943cbb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> @@ -0,0 +1,109 @@
> +* Broadcom STB NAND Controller
> +
> +The Broadcom Set-Top Box NAND controller supports low-level access to raw 
> NAND
> +flash chips. It has a memory-mapped register interface for both control
> +registers and for its data input/output buffer. On some SoCs, this 
> controller is
> +paired with a custom DMA engine (inventively named "Flash DMA") which 
> supports
> +basic PROGRAM and READ functions, among other features.
> +
> +This controller was originally designed for STB SoCs (BCM7xxx) but is now
> +available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and
> +iProc/Cygnus. Its history includes several similar (but not fully register
> +compatible) versions.
> +
> +Required properties:
> +- compatible   : should contain "brcm,brcmnand" and an appropriate 
> version
> +  compatibility string, like "brcm,brcmnand-v7.0"
> +  Possible values:
> + brcm,brcmnand-v4.0
> + brcm,brcmnand-v5.0
> + brcm,brcmnand-v6.0
> + brcm,brcmnand-v7.0
> + brcm,brcmnand-v7.1
> + brcm,brcmnand
> +- reg  : the register start and length for NAND register region.
> + (optional) Flash DMA register range (if present)
> + (optional) NAND flash cache range (if at non-standard 
> offset)
> +- reg-names: a list of the names corresponding to the previous 
> register
> + ranges. Should contain "nand" and (optionally)
> + "flash-dma" and/or "nand-cache".
> +- interrupts   : The NAND CTLRDY interrupt and (if Flash DMA is 
> available)
> + FLASH_DMA_DONE
> +- interrupt-names  : May be "nand_ctlrdy" or "flash_dma_done"
> +- interrupt-parent : See standard interrupt bindings
> +- #address-cells   : <1> - subnodes give the chip-select number
> +- #size-cells  : <0>
> +
> +Optional properties:
> +- brcm,nand-has-wp  : Some versions of this IP include a 
> write-protect
> +  (WP) control bit. It is always available on >=
> +  v7.0. Use this property to describe the rare
> +  earlier versions of this core that include WP
> +
> +* NAND chip-select
> +
> +Each controller (compatible: "brcm,brcmnand") may contain one or more 
> subnodes
> +to represent enabled chip-selects which (may) contain NAND flash chips. Their
> +properties are as follows.
> +
> +Required properties:
> +- compatible: should contain "brcm,nandcs"
> +- reg   : a single integer representing the chip-select
> +  number (e.g., 0, 1, 2, etc.)
> +- #address-cells: see partition.txt
> +- #size-cells   : see partition.txt
> +- nand-ecc-strength : see nand.txt
> +- nand-ecc-step-size: must be 512 or 1024. See nand.txt
> +
> +Optional properties:
> +- nand-on-flash-bbt : boolean, to enable the on-flash BBT for this
> +  chip-select. See nand.txt
> +- brcm,nand-oob-sector-size : integer, to denote the spare area sector size
> +  expected for the ECC layout in use. This size, 
> in
> +  addition to the strength and step-size,
> +  determines how the hardware BCH engine will lay
> +  out the parity bytes it stores on the flash.
> +  This property can be automatically determined 
> by
> +  the flash geometry (particularly the NAND page
> +  and OOB size) in many cases, but when booting
> +  from NAND, the boot controller has only a 
> limited
> +  number of available options for its default ECC
> +  layout.
> +
> +Each nandcs device node may optionally contain sub-nodes describing the flash
> +partition mapping. See partition.txt for more detail.
> +
> +Example:
> +
> +nand@f0442800 {
> + compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand";
> + reg = <0xF0442800 0x600>,
> +   <0xF0443000 0x100>;
> + reg-names = "nand", "flash-dma";
> + interrupt-pa

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 16-03-15 19:23, Peter Hurley wrote:

On 03/16/2015 02:12 PM, Hans de Goede wrote:

Hi,

On 16-03-15 18:49, Peter Hurley wrote:

Hi Hans,

On 03/16/2015 12:31 PM, Hans de Goede wrote:

Hi All,

While updating my local working tree to 4.0-rc4 this morning I noticed that I 
no longer
get console / kernel messages output on the hdmi output of my ARM board / on 
tty0

This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d

Reverting this commit fixes this for me.

What is happening here is that the "add_preferred_console("stdout-path", 0, 
NULL);"
happens before the tty0 registers stopping tty0 from becoming part of the 
console list
since there already is a preferred console at that time.

This is an undesirable behavior change caused by the commit in question, on 
boards
where there is both video output, and a serial console configured through 
stdout-path
we want to have console output on both as we do not know which of the 2 will 
actually
be hooked up by the user.


I don't see this as a regression, but rather a misconfiguration.


As said it is an undesirable behavior change, whether you want to call that a 
regression
or not is not all that interesting. Fixing it however is important, as e.g. 
Fedora
ARM images rely on this behavior, both "regular" arm as well as aarch64.


What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?


This is on allwinner (sunxi) devices such as Allwinner A10 or A20 based boards, 
currently
the setting of stdout-path on these boards is done by (an unmodified) upstream 
u-boot.

To be clear about my aarch64 remark, that relates to the behavior of aarch64 
acpi using
machines, those will also output to both a serial tty and tty0 when the acpi 
equivalent
of stdout-path is present and points to a serial tty.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Tony Lindgren]

* Sebastian Reichel  [150316 11:26]:
> Hi,
> 
> On Mon, Mar 16, 2015 at 08:29:39AM -0700, Tony Lindgren wrote:
> > * Arnd Bergmann  [150315 05:10]:
> > > On Sunday 15 March 2015 10:50:42 Eliad Peller wrote:
> > > > yeah, i missed it :/
> > > > 
> > > > looks like there's no platform that defines platform data for it.
> > > > i'll replace the dev_get_platdata() with a function that only parses
> > > > the clock-frequency properties (the irq is taken in this case from the
> > > > spi_device).
> > > > (or maybe i should just drop it, as no one actually uses it?)
> > > 
> > > I don't think we should drop the driver, but dropping the platform_data
> > > support sounds reasonable. New users of this driver should all be using
> > > DT, and if there is a good reason to use platform_data, it's easily
> > > put back.
> > 
> > Well we have n8x0 and n900 using the spi driver. For those, n8x0 boot
> > all in dts mode, but n900 still also boots in legacy mode. It seems the
> > board-rx51-peripherals.c only passes the power_gpio though, so that
> > should be easy to keep around.
> > 
> > We should keep things still working for n900 in legacy mode until the
> > pending regressions with device tree based booting have been cleared
> > for at least one merge cycle. I believe the last pending issues is the
> > support for ATAG_REVISION in device tree mode as posted by Pali.
> 
> mh by migrating to newer gpiod interface platform data is no longer
> needed (instead the boardfile would need a gpiod_lookup_table). That
> way all of the dirty code is in the board file and will be removed
> once the time comes. See for example rx51_fmtx_gpios_table.
> 
> Note: This is independent of wl12xx changes, since N900 uses wl1251.

Oh sorry yes sounds like that's different platform data then. In that
case I see no reasons to drop the platform data for wl12xx.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Sebastian Reichel]

Hi,

On Mon, Mar 16, 2015 at 08:29:39AM -0700, Tony Lindgren wrote:
> * Arnd Bergmann  [150315 05:10]:
> > On Sunday 15 March 2015 10:50:42 Eliad Peller wrote:
> > > yeah, i missed it :/
> > > 
> > > looks like there's no platform that defines platform data for it.
> > > i'll replace the dev_get_platdata() with a function that only parses
> > > the clock-frequency properties (the irq is taken in this case from the
> > > spi_device).
> > > (or maybe i should just drop it, as no one actually uses it?)
> > 
> > I don't think we should drop the driver, but dropping the platform_data
> > support sounds reasonable. New users of this driver should all be using
> > DT, and if there is a good reason to use platform_data, it's easily
> > put back.
> 
> Well we have n8x0 and n900 using the spi driver. For those, n8x0 boot
> all in dts mode, but n900 still also boots in legacy mode. It seems the
> board-rx51-peripherals.c only passes the power_gpio though, so that
> should be easy to keep around.
> 
> We should keep things still working for n900 in legacy mode until the
> pending regressions with device tree based booting have been cleared
> for at least one merge cycle. I believe the last pending issues is the
> support for ATAG_REVISION in device tree mode as posted by Pali.

mh by migrating to newer gpiod interface platform data is no longer
needed (instead the boardfile would need a gpiod_lookup_table). That
way all of the dirty code is in the board file and will be removed
once the time comes. See for example rx51_fmtx_gpios_table.

Note: This is independent of wl12xx changes, since N900 uses wl1251.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 6/9] ARM: dt: dove: add Dove PMU DT entry to dove.dtsi

[Gregory CLEMENT]

Hi Russell,

On 12/03/2015 19:31, Russell King wrote:
> Add the PMU description to the Dove DT file.  The PMU provides multiple
> features, including an interrupt, reset, power and isolation controller.
> 
> Signed-off-by: Russell King 
> ---
>  arch/arm/boot/dts/dove.dtsi | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
> index a5441d5482a6..43d4ebf414be 100644
> --- a/arch/arm/boot/dts/dove.dtsi
> +++ b/arch/arm/boot/dts/dove.dtsi
> @@ -380,6 +380,15 @@
>   status = "disabled";
>   };
>  
> + pmu: power-management@d {
> + compatible = "marvell,dove-pmu";
> + reg = <0xd 0x8000>, <0xd8000 0x8000>;

Here you overlap some other nodes such as the thermal one (from 0xd001c to 
0xd0028),
the clock gate one (from 0xd0038 to 0xd003c), the gpio one, the pinctrl one ...

Could you be more specific?

Thanks,

Gregory

> + interrupts = <33>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
>   thermal: thermal-diode@d001c {
>   compatible = "marvell,dove-thermal";
>   reg = <0xd001c 0x0c>, <0xd005c 0x08>;
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Peter Hurley]

On 03/16/2015 02:12 PM, Hans de Goede wrote:
> Hi,
> 
> On 16-03-15 18:49, Peter Hurley wrote:
>> Hi Hans,
>>
>> On 03/16/2015 12:31 PM, Hans de Goede wrote:
>>> Hi All,
>>>
>>> While updating my local working tree to 4.0-rc4 this morning I noticed that 
>>> I no longer
>>> get console / kernel messages output on the hdmi output of my ARM board / 
>>> on tty0
>>>
>>> This is caused by:
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d
>>>
>>> Reverting this commit fixes this for me.
>>>
>>> What is happening here is that the "add_preferred_console("stdout-path", 0, 
>>> NULL);"
>>> happens before the tty0 registers stopping tty0 from becoming part of the 
>>> console list
>>> since there already is a preferred console at that time.
>>>
>>> This is an undesirable behavior change caused by the commit in question, on 
>>> boards
>>> where there is both video output, and a serial console configured through 
>>> stdout-path
>>> we want to have console output on both as we do not know which of the 2 
>>> will actually
>>> be hooked up by the user.
>>
>> I don't see this as a regression, but rather a misconfiguration.
> 
> As said it is an undesirable behavior change, whether you want to call that a 
> regression
> or not is not all that interesting. Fixing it however is important, as e.g. 
> Fedora
> ARM images rely on this behavior, both "regular" arm as well as aarch64.

What dts file is causing this problem?
Is it in mainline or distributed only in Fedora?


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION stable] "of: fix handling of '/' in options for of_find_node_by_path()" breaks stdout-path

[Leif Lindholm]

Hi Hans,

On Mon, Mar 16, 2015 at 04:53:22PM +0100, Hans de Goede wrote:
> While updating my local working tree to 4.0-rc4 this morning I noticed that I 
> no longer
> got any console (neither video output not serial console) on an Allwinner A20 
> ARM
> board.
> 
> This is caused by:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=106937e8ccdcf0f4b95fbf0fe9abd42766cade33
> 
> Reverting this commit fixes the serial console being gone for me.

Sorry about that.
 
> After this there still is an issue that tty0 no longer is seen as console, 
> where it
> used to be properly used as console in 3.19, I'll investigate that further 
> and send
> a separate mail about this.
> 
> Greg, this commit has a: "Cc:  # 3.19" please do not 
> apply
> this commit to stable!
> 
> u-boot sets stdout-path to this value on the board in question:
> "/soc@01c0/serial@01c28000:115200"
> 
> Looking at the first hunk of the patch in question, the problem is obvious:
> 
> @@ -714,16 +714,17 @@ static struct device_node 
> *__of_find_node_by_path(struct device_node *parent,
>  const char *path)
>  {
>   struct device_node *child;
> - int len = strchrnul(path, '/') - path;
> - int term;
> + int len;
> + const char *end;
> + end = strchr(path, ':');
> + if (!end)
> + end = strchrnul(path, '/');
> +
> + len = end - path;
>   if (!len)
>return NULL;
> - term = strchrnul(path, ':') - path;
> - if (term < len)
> - len = term;
> -
>  __for_each_child_of_node(parent, child) {
>   const char *name = strrchr(child->full_name, '/');
>   if (WARN(!name, "malformed device_node %s\n", child->full_name))
> 
> The new code to determine len will match (when starting at root) the name of
> all child nodes against: "soc@01c0/serial@01c28000" as it checks for
> the ":" first and then uses everything before it. Where as the old code
> would match against: "soc@01c0" which is the correct thing to do.
> 
> The best fix I can come up with is to check for both ":" and "/" and use
> the earlier one as end to calculate the length. I've not coded this out /
> tested this due to -ENOTIME. Note that I've also not audited the rest of
> the patch for similar issues.
> 
> I will happily test any patches to fix this.

Can you give this one a try for the first part of your problem?

And if you're happy with that, I can revert the previous version and
send a new combined fix.

Rob/Grant: am I OK to assume the existence of the phandle-tests
subnode for my unrelated test?

/
Leif

>From cbb150ddd277e5fe1c109e6a675f075f0611f71d Mon Sep 17 00:00:00 2001
From: Leif Lindholm 
Date: Mon, 16 Mar 2015 17:58:22 +
Subject: [PATCH] of: fix regression in of_find_node_opts_by_path()

This fixes a regression for dealing with paths that contain both a ':'
option separator and a '/' in the path preceding it. And adds a test
case to prove it.

Fixes: 106937e8ccdc ("of: fix handling of '/' in options for 
of_find_node_by_path()")
Reported-by: Hans de Goede 
Signed-off-by: Leif Lindholm 
---
 drivers/of/base.c | 10 --
 drivers/of/unittest.c |  5 +
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index adb8764..2ee7265 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -715,13 +715,11 @@ static struct device_node *__of_find_node_by_path(struct 
device_node *parent,
 {
struct device_node *child;
int len;
-   const char *end;
+   const char *p1, *p2;
 
-   end = strchr(path, ':');
-   if (!end)
-   end = strchrnul(path, '/');
-
-   len = end - path;
+   p1 = strchrnul(path, ':');
+   p2 = strchrnul(path, '/');
+   len = (p1 < p2 ? p1 : p2) - path;
if (!len)
return NULL;
 
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index aba8946..8d94349 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -97,6 +97,11 @@ static void __init of_selftest_find_node_by_name(void)
 "option path test, subcase #1 failed\n");
of_node_put(np);
 
+   np = 
of_find_node_opts_by_path("/testcase-data/phandle-tests:test/option", &options);
+   selftest(np && !strcmp("test/option", options),
+"option path test, subcase #2 failed\n");
+   of_node_put(np);
+
np = of_find_node_opts_by_path("/testcase-data:testoption", NULL);
selftest(np, "NULL option path test failed\n");
of_node_put(np);
-- 
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] ARM: cpuidle: Add a cpuidle ops structure to be used for DT

[Lorenzo Pieralisi]

On Tue, Mar 03, 2015 at 12:29:33PM +, Daniel Lezcano wrote:
> The current state of the different cpuidle drivers is the different PM

Nit: "The current state of cpuidle drivers is such that different ..."

> operations are passed via the platform_data using the platform driver
> paradigm.
> 
> This approach allowed to split the low level PM code from the arch specific
> and the generic cpuidle code.
> 
> Unfortunately there are complains about this approach as, in the context of 
> the

Nit: s/complains/complaints

> single kernel image, we have multiple drivers loaded in memory for nothing and
> the platform driver is not adequate for cpuidle.
> 
> This patch provides a common interface via cpuidle ops for all new cpuidle
> driver and a definition for the device tree.
> 
> It will allow with the next patches to a have a common definition with ARM64
> and share the same cpuidle driver.
> 
> The code is optimized to use the __init section intensively in order to reduce
> the memory footprint after the driver is initialized and unify the function
> names with ARM64.
> 
> In order to prevent multiple declarations and the specific cpuidle ops to be
> spread across the different headers, a mechanism, similar to the cgroup 
> subsys,
> has been introduced.
> 
> A new platform willing to add its cpuidle ops must add an entry in the file
> cpuidle_ops.h in the current form:
> 
>  #if IS_ENABLED(CONFIG_ARM_FOO_CPUIDLE)
>  CPUIDLE_OPS(foo)
>  #endif
> 
> ... and use the variable name in the specific low level code:
> 
> struct cpuidle_ops foo_cpuidle_ops;
> 
> The CPUIDLE_OPS macro will be processed in different way in the cpuidle.c 
> file,
> thus allowing to keep untouched the arm cpuidle core code in the future when
> a new platform is added.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  arch/arm/include/asm/cpuidle.h | 10 +
>  arch/arm/include/asm/cpuidle_ops.h |  3 ++
>  arch/arm/kernel/cpuidle.c  | 85 
> ++
>  arch/arm64/include/asm/cpuidle.h   |  5 ++-
>  4 files changed, 102 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/cpuidle_ops.h
> 
> diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
> index 348dc81..3d31459 100644
> --- a/arch/arm/include/asm/cpuidle.h
> +++ b/arch/arm/include/asm/cpuidle.h
> @@ -27,4 +27,14 @@ static inline int arm_cpuidle_simple_enter(struct 
> cpuidle_device *dev,
>   */
>  #define ARM_CPUIDLE_WFI_STATE ARM_CPUIDLE_WFI_STATE_PWR(UINT_MAX)
>  
> +struct cpuidle_ops {
> + const char *name;
> + int (*suspend)(int cpu, unsigned long arg);
> + int (*init)(struct device_node *, int cpu);
> +};
> +
> +extern int arm_cpuidle_suspend(int index);
> +
> +extern int arm_cpuidle_init(int cpu);

idle_cpu_suspend()
idle_cpu_init()

?

I am really not fussed about the naming.

To make this and x86 driver name compliant (well, function signatures
are a bit different) we could use:

arm_idle()
arm_idle_cpu_init()

even though I think the arch prefix is useless.

Side note: why is the x86 driver in drivers/idle ? To have another dir :) ?

> +
>  #endif
> diff --git a/arch/arm/include/asm/cpuidle_ops.h 
> b/arch/arm/include/asm/cpuidle_ops.h
> new file mode 100644
> index 000..be0a612
> --- /dev/null
> +++ b/arch/arm/include/asm/cpuidle_ops.h
> @@ -0,0 +1,3 @@
> +/*
> + * List of cpuidle operations
> + */
> diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
> index 45969f8..25e9789c 100644
> --- a/arch/arm/kernel/cpuidle.c
> +++ b/arch/arm/kernel/cpuidle.c
> @@ -10,8 +10,29 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  
> +#define CPUIDLE_OPS(__x) extern struct cpuidle_ops __x ## _cpuidle_ops;
> +#include 
> +#undef CPUIDLE_OPS
> +
> +#define CPUIDLE_OPS(__x) __x ## _cpuidle_ops_id,
> +enum cpuidle_ops_id {
> +#include 
> +CPUIDLE_OPS_COUNT,
> +};
> +#undef CPUIDLE_OPS
> +
> +#define CPUIDLE_OPS(__x) [__x ## _cpuidle_ops_id ] = &__x ## _cpuidle_ops,
> +static struct cpuidle_ops *supported_cpuidle_ops[] __initconst = {
> +#include 
> +};
> +#undef CPUIDLE_OPS
> +
> +static struct cpuidle_ops cpuidle_ops[NR_CPUS];

That's because you want platform cpuidle_ops to be __initdata ?

It should not be a big overhead on arm32 to have a number of
structs equal to NR_CPUS, on arm64 it is the other way around
there are few cpu_ops, but number of CPUs can be high so it
is an array of pointers.

I think it is ok to leave it as it is (or probably make cpuidle_ops
a single struct, I expect enable-method to be common across cpus).

> +
>  int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
>   struct cpuidle_driver *drv, int index)
>  {
> @@ -19,3 +40,67 @@ int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
>  
>   return index;
>  }
> +
> +int arm_cpuidle_suspend(int index)
> +{
> + int ret = -EOPNOTSUPP;
> + int cpu = smp_processor_id();
> +
> + if (cpuidle_ops[cpu].suspend)
> + ret = cpuidle_ops[cpu

Re: [REGRESSION] "of: Fix premature bootconsole disable with 'stdout-path'" breaks console on tty0

[Hans de Goede]

Hi,

On 16-03-15 18:49, Peter Hurley wrote:

Hi Hans,

On 03/16/2015 12:31 PM, Hans de Goede wrote:

Hi All,

While updating my local working tree to 4.0-rc4 this morning I noticed that I 
no longer
get console / kernel messages output on the hdmi output of my ARM board / on 
tty0

This is caused by:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/of?id=2fa645cb2703d9b3786d850db815414dfeefa51d

Reverting this commit fixes this for me.

What is happening here is that the "add_preferred_console("stdout-path", 0, 
NULL);"
happens before the tty0 registers stopping tty0 from becoming part of the 
console list
since there already is a preferred console at that time.

This is an undesirable behavior change caused by the commit in question, on 
boards
where there is both video output, and a serial console configured through 
stdout-path
we want to have console output on both as we do not know which of the 2 will 
actually
be hooked up by the user.


I don't see this as a regression, but rather a misconfiguration.


As said it is an undesirable behavior change, whether you want to call that a 
regression
or not is not all that interesting. Fixing it however is important, as e.g. 
Fedora
ARM images rely on this behavior, both "regular" arm as well as aarch64.


1. Your DT indicates the stdout device is a serial console; that is
the expected outcome. Here's what ePAPR has to say on the chosen/stdout-path
property node:

"A string that specifies the full path to the node representing the device 
to be
used for boot console output. If the character ":" is present in the value 
it
terminates the path. The value may be an alias."

If the serial console is not the stdout device then the DT should not
claim it is.

2. The tty0 console is not now, and has never been, always enabled.

The tty0 console is only enabled when either,
  a) there is no other console
  b) when specified on the command line (ie., "console=tty0") or
 by prom/dt.

Your situation is akin to adding the serial console to the command line; if
"console=tty0" is not also explicitly added, there is no boot console output
to tty0.

3. This same breakage will happen if any other device registers a console 
matching
the stdout-path at console_init() time (ie, with console_initcall() macro) 
before
the dummy console. The order in which consoles are inited via 
console_initcall()
is dependent on link order, so essentially not controllable across different
subsystems (or if there were consoles defined with the arch itself).

That said, I'll look into fixing your use-case automagically without requiring
configuration changes.


Thanks!

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html